topic Re: Run time error with cc -O optimization on in Operating System - HP-UX

Run time error with cc -O optimization on

Gus Larsson — Thu, 15 Aug 2002 11:37:53 GMT

Hello,
I am getting a weird run-time condition that occurs when I use the cc "-O" optimization but not when I use no optimization. Here is the code in question:
j = 0;
while ((j < num) && (i != ids[j])) {
printf ("\nWe shouldnt be here if theyre equal!");
j++;
}
j and num are both local integers, and num is set to the result of a function call several lines earlier. In the test we were running, num happens to be zero. However, the inside of the while-loop is executed if the "-O" optimization is used! This doesn't happen when no optimization is used.

I browsed the patch list but didn't see any relating specifically to this problem. Is there a particular patch that I should use? I am running on HP-UX 11.0 on a J5600, and "what /usr/bin/cc" gives this:
/usr/bin/cc:
LINT A.11.01.20 CXREF A.11.01.20
HP92453-01 A.11.01.20 HP C Compiler
$ CUPI80_IC7 Jan 7 1999 11:20:34 $

Thanks for any info,

Gus Larsson

Re: Run time error with cc -O optimization on

H.Merijn Brand (procura — Thu, 15 Aug 2002 11:46:27 GMT

a5:/ 101 # swlist -l product | grep ANSI
C-ANSI-C B.11.11.04 HP C/ANSI C Compiler
PHSS_25985 1.0 ANSI C compiler General patch
a5:/ 102 #

Re: Run time error with cc -O optimization on

Olav Baadsvik — Thu, 15 Aug 2002 11:53:46 GMT

Hi,

I advise you to upgrade to a newer
version of the compiler.
I have seen similar problems solved
by upgrading the compiler.

Regards
Olav

Re: Run time error with cc -O optimization on

Gus Larsson — Thu, 15 Aug 2002 16:24:51 GMT

Hi, I feel both those answers are on the right track, but applying patches so far this morning has not helped. Here is what I get now for "what /usr/bin/cc":
/usr/bin/cc:
LINT A.11.01.25171.GP CXREF A.11.01.25171.GP
HP92453-01 A.11.01.25171.GP HP C Compiler
$ Sep 8 2000 23:13:51 $

And typing "swlist -l product | grep ANSI" gives this:

C-ANSI-C B.11.01.20 HP C/ANSI C Compiler
PHSS_25171 1.0 ANSI C compiler cumulative patch

I still get the error when I compile my code with the default "-O" optimization. The only patches I have been able to apply were PHSS_25171 and PHSS_25249; trying to apply other promising patches failed because I apparently didn't have the right base file sets. Whatever.
Thanks for any help,
Gus

Re: Run time error with cc -O optimization on

Martin Schneider_2 — Fri, 16 Aug 2002 07:31:26 GMT

Gus,

I think this is a pretty common phenomenon. With some compilers, optimization is documented to give unpredictable results in some cases, and in numerous cases, we haven't had any other chance but disable optimization for selected source files.

In many cases, the fact that an error disappears when compiling non-optimized is a side effect of the now different memory layout, but in more cases than not, we gave up on trying to find the cause for the error, and just switched off optimization for the source file.

Regards,

Martin

Re: Run time error with cc -O optimization on

Martin Schneider_2 — Fri, 16 Aug 2002 07:46:24 GMT

This could also have to do with signedness of variables. Try declaring all variables involved (num, i, j) as either signed or unsigned. Comparing a signed to an unsigned var can give the wrong answer if the sign bit is on and gets counted as a power of two.

Re: Run time error with cc -O optimization on

H.Merijn Brand (procura — Fri, 16 Aug 2002 07:57:27 GMT

You're still on an old C compiler version. Do you have recent "Application" CD's? Can you order them on SUM, or request them from your HP representative?

Re: Run time error with cc -O optimization on

Judy Traynor — Fri, 16 Aug 2002 10:19:49 GMT

add the latest libc patch

Re: Run time error with cc -O optimization on

Gus Larsson — Mon, 19 Aug 2002 19:42:20 GMT

Thank you for all the replies. I called my HP rep and installed the latest C compiler but still got the error. When I did (sort of) what Martin suggested and explicitly declared my loop indeces as "unsigned int", the error magically went away. Thanks again.