Re: [Evolution-hackers] gcc 4.4 may be causing a number of bugs in Evolution

[Jeffrey Stedfast <fejj novell com>]

Paul Smith wrote:
> 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.
>   

s/C standard/C99 standard/

In C89, a type-cast was a type-cast and had well understood and defined
behavior. And in C89, aliasing was legal and widely used. So while it
might not /technically/ be a bug in gcc now that it's focusing on c99,
it can be argued it's a bug since it broke previous behavior. It can
also easily be argued that, in the case of "undefined behavior", a
compiler should default to doing what the other (and/or older versions
of the same) compilers do. In this case, other compilers (and older
versions of gcc) handle aliasing the same, but the new gcc 4.4 behavior
changed.

Hence why I call it a bug ;-)

Jeff