------- 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
