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