On Mon, 2010-02-01 at 11:52 -0500, Jeffrey Stedfast wrote:
> This weekend I discovered a particularly nasty bug in gcc 4.4 where gcc
> would mistakenly optimize out important sections of code
> when it encountered a particular trick used in a ton of places inside
> Evolution (EDList and pretty much everywhere custom single-linked lists
> are used inside at least Camel and likely other places as well).
> 
> A temporary solution is to pass the -fno-strict-aliasing argument to gcc.
> 
> Unfortunately, the gcc developers claim that this is not a bug:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907

It is not a bug in GCC: GCC will compile a program that conforms to the
C standard 100% correctly.  Evolution is relying on behavior that is
left as undefined by the standard.  Optimizations often cause undefined
code to behave incorrectly, defined as "contrary to the author's
intent", where non-optimized versions of the code "work".  That doesn't
mean that the compiler has a bug.

You can argue, very successfully, that this is a QOI issue and GCC
should not enable this particular optimization by default, even at -O2,
since other common compilers do not do it and it can break previously
working code.  Of course that's true of very many other optimizations,
too.  The GCC devs decided, for better or worse, to push the envelope
here.

However, luckily it's easy to force GCC to choose to interpret the
undefined behavior in a different, more traditional way (that is, not
try to use alias optimizations): as you point out by setting the
-fno-strict-aliasing argument.  Or, of course, you could rework the code
to not use undefined behavior.  Sometimes that's tricky, sometimes it's
easy.


I should point out that we ran into this exact same problem at work when
we switched to a newer version of GCC: after doing some performance/etc.
testing both with/without -fno-strict-aliasing we decided it was worth
it to fix the undefined behavior and keep the optimization.  However our
environment is extremely performance-sensitive.  You might come to a
different conclusion for Evolution of course.


Cheers!

_______________________________________________
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Reply via email to