Re: Possible optimizer bug on sparc-solaris?

["Eric Botcazou" <ebotcazou at libertysurf dot fr>]

> I figured that...   Unfortunately it seems to be really dependant on
> memory layout...  Adding a printf anywhere in the function moves the
> assignment to %o7, as did many other small changes I made while trying
> to track the bug down - it's probably going to be really hard to build a
> self-contained test-case... I'm afraid that I won't even have time to try
> and build a test-case for a couple of weeks at least...

As the problem appears to be an obvious miscompilation (i.e easily
human-pinpointable in the asm file), we probably don't need a runnable
testcase, only a compilable one, which is far easier: simply compile the
file with --save-temps. Now, the resulting file very likely contains things
you don't want to be exposed to the rest of the world, so it's up to you to
reduce/obfuscate/modify it. Then, if you deem it appropriate, post it as a
testcase.

> I agree whole-heartedly...  Unfortunately we're stabilizing our code for a
> release right now, and I'm worried that there may be other places in our
> code where this is happening...  I could back off to -O1 for the entire
> code base, but I'd rather not do that.  Is there I way we can disable %o7
> until was have a proper fix for the bug?

Not really AFAIK. %o7/%i7 is obviously a special register so I'd not suggest
trying weird things on it. If the problem is that fragile, I'd suggest to
work around it locally instead, this is certainly the safest route. Of
course you can do so only reactively, not preventively...

- Eric