[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

["ebotcazou at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #19 from ebotcazou at gcc dot gnu dot org  2006-01-19 06:55 -------
> Good news, I think I found the problem.  Bad news, I can't think of any
> solution.  Please read my comments at the end of this information:

Thanks for your efforts.

> What I've discovered is that the -O2 option causes these sckw static objects
> to be placed randomly in memory, NOT in the order they are declared.  In all
> previous instances of the gcc compiler, input order was preserved for static
> objects.  This is the 'problem'.  With -O2 in gcc 3.4.4, order is not
> preserved.  So the scan falls off the end when the ending sckw is misplaced.

OK, that makes sense.  See http://gcc.gnu.org/gcc-3.4/changes.html, Caveats
section, bullet #13.  Note that this reordering is permitted by ISO C (or more
precisely, it is not forbidden by ISO C).

> My question is this:  Is there some option that can be used with -O2 that will
> preserve the input-order of static and/or global objects?  It would be handy
> if global objects were also kept in order, such as:
> 
> long r1;
> long r2;
> long r3;
> etc.

Yes, the workaround is given on the aforementioned page.

> Alternatively, is there some way I can force the input-order of sckw objects?

Yes, by using an array of such structures.

> By the way, I placed a 'break' at the if-test for flg2, but it never sprung. 
> Another 'break' at the increment statement {kwp += 1;} was sprung.  That's how
> I found these sckw objects were in random order.  'gdb' has problems with -O2
> and -g combined.

Yes, debugging code compiled with -O2 -g is not for the fainthearted. :-)  GDB
is primarily aimed at debugging user code so generally used on code compiled
with -O0 -g.  It is indeed not really tuned for debugging the compiler itself.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791