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 _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
