Possible optimizer bug on sparc-solaris?

[Warren_Baird at cimmetry dot com]

To:   gcc-bugs@gcc.gnu.org
cc:

Subject:  Possible optimizer bug on sparc-solaris?

I'm using gcc-3.2.2 with solaris 8 on a sparc machine.  I encountered
a strange problem in our code the other day that I think may be caused
by an optimization bug.  There were a series of three

   if (foo) {
      free(foo);
      foo = NULL;
   }

constructs at the bottom of the function.  When compiled with -O2
control would jump into the middle of an unrelated function in the
same file immediately after the last free.  I had to do quite a bit of
reading to figure out what was going on.  Here's what gdb shows me as
the machine code around the last call to free (0xfb3437b0)


    0xfb3437ac <MyFunc+1468>: mov  1, %i0
    0xfb3437b0 <MyFunc+1472>: call  0xfb3a415c <__JCR_LIST__+4900>
    0xfb3437b4 <MyFunc+1476>: add  %o7, -3904, %o7
    0xfb3437b8 <MyFunc+1480>: fcmped  %f6, %f8
    0xfb3437bc <MyFunc+1484>: nop
    0xfb3437c0 <MyFunc+1488>: fbuge  0xfb343760

I don't know much about sparc assembly, but it looks like it always
executes the statement immediately following the 'call' before
actually executing the call, so 0xfb3437b4 is executed *before* we go
into the call to free, and since %o7 is supposed to store the current
program counter when calling a routine, free's %i7 register (supposed
to contain the program counter to return to) actually points 3904
bytes before where is it is supposed to be.  So when free is finished,
control passed to some random bit of code and things quickly crash.

If I add a printf immediately after the free, or if I just compile
with -O instead of -O2, everything works fine.  In -O mode the
assembly looks like this:

    0xfb345fc0 <MyFunc+7860>: mov  1, %i0
    0xfb345fc4 <MyFunc+7864>: call  0xfb3a615c <__JCR_LIST__+4900>
    0xfb345fc8 <MyFunc+7868>: mov  %i4, %o0

This looks to me like an optimizer bug - with the optimizer deciding
to use %o7 when it shouldn't.  However, I haven't had time to
try and repro this in a standalone chunk of code that I could submit
as a bug.

Two questions: Does this look like an optimizer bug?  If so, is it
worth submitting a bug report without a standalone chunk of code that
repros the problem?

Is there perhaps a way to tell the optimizer to just ignore register
%o7 when optimizing?  It might hurt performance a little, but if it
avoids crashes like this it might be worth it to us.

I know 3.2.2 is a bit old now, but I looked through the fixed bugs
list for gcc-3.2.3 and gcc-3.3 and couldn't see anything related to
this issue.

Thanks for your help.