buggy optimization levels...

Chuck Swiger cswiger at mac.com
Sat Aug 2 09:19:24 PDT 2003


Erik Trulsson wrote:
> On Thu, Jul 31, 2003 at 10:30:57PM -0400, Chuck Swiger wrote:
[ ... ]
>> I understand that figuring out why the kernel died can be hard, 
>> particularly if the failures aren't concise and completely reproducable, 
>> and thus tracing the problem back to making the right change to gcc to fix 
>> the optimization that caused the observed failure is thus also hard.
> 
> Note that it is not necessarily gcc which is at fault for such
> failures. It may be a bug in gcc, but it may also be a bug in the code
> being compiled that has a bug that only shows up under higher
> optimization levels.
> The latter is probably somewhat more common actually.

Does the last comment mean that you can provide at least one example of code 
which behaves differently when compiled with "cc -O" versus "cc -O2"?

Otherwise, what does "more common" mean in the context of zero examples?

[ ... ]
>>...and makes it so that -O2, -O3, etc does not enable GCSE optimization.
> 
> But if the bug is not in gcc but in the code being compiled (and which
> only happens to show up when compiled with GCSE optimization) 

Even if the code contains a bug, "cc -O" and "cc -O -fgcse" should produce the 
same results.  Excluding certain well-defined exceptions (-ffast-math comes to 
mind), compiler optimizations likes -fgcse are not allowed to change the meaning 
of compiled code, do we agree?

 > ...such a patch would disable this optimization for correct code also
 > even though it is not necessary there.

Such a patch would disable the optimization for all cases.

If there exists any lexically correct input source code (ie, which parses 
validly) where compiling with -fgcse results in different behavior, that 
optimization is unsafe and should not be enabled by -O2 in any circumstance.

-- 
-Chuck



More information about the freebsd-questions mailing list