[gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Duncan]

Nikos Chantziaras posted on Fri, 01 Jul 2011 03:11:09 +0300 as excerpted:

> On 07/01/2011 03:04 AM, Frank Peters wrote:
>> On Fri, 01 Jul 2011 02:44:36 +0300 Nikos Chantziaras<realnc@×××××.de>
>> wrote:
>>
>>
>>>> Your code is buggy, because you're breaking C's aliasing rules. You
>>>> are not allowed to use a different pointer type to dereference a
>>>> variable of a different type. Doing so results in undefined behavior.
>>>
>>>
>> Well, the error occurs only within the loop structure.  If I manually
>> "unroll" the loop using the same pointers there is no error when
>> compiled with "O2."
>>
>> IOW, the problem is how the loop is optimized under -O2.
>
> When there's "undefined behavior", it really means just that: you cannot
> make any assumptions about when the result is going to be correct and
> when not.  It might as well depend on whether it was raining yesterday.

I had wondered if this might be an "undefined behavior" optimization bug, 
but don't personally know enough about C coding to tell.

However, what I have observed, both here and for instance in the recent 
glibc memcp vs memmove instructions (don't ask me if those are 
abbreviated correctly, I'm not a coder, just a user who followed the 
situation as reported in the community press with some interest, 
particularly because I DO tend to unmask and try new versions with such 
issues before they're officially ready), is that in the quest for further 
optimizations, all the "easy" stuff is pretty much already done.  It's 
now the harder, more obscure optimizations that might break code making 
bad assumptions about "undefined behavior", etc, that's the leading edge 
of technology, at least as seen in the FLOSS world encompassing gcc and 
glibc.

The -fno-strict-aliasing thing was a big deal for gcc 4.5, precisely 
because it DOES allow corner-case optimization where it wasn't tried 
before, but does so by taking advantage of "undefined behavior" being 
just that, undefined, to make assumptions about shortcuts the authors did 
NOT take because to do so would be undefined, based on the absence of a 
flag saying NOT to make such assumptions because the author DID take such 
shortcuts, relying on the previous behavior where it is specifically 
defined as "undefined".

As it happens, there was quite a lot of code making such assumptions, 
that needed -fno-strict-aliasing in the short term, but hopefully, 
recoded not to make invalid assumptions about the behavior of 
specifically "undefined behavior" in the longer term.

It's just that sort of testing, bug reporting, and patching, that keeps 
gentoo devs (and indeed, those of many distributions) busy, as new 
versions of gcc and various system libraries come out, and why at times 
they seem to take "forever" to stabilize, or even get unmasked into ~arch 
(where gcc-4.6 has yet to appear, fwiw).

FWIW, I don't know a whole lot about fixing such things in the C/C++/
whatever code itself, but I've developed quite some experience finding 
and applying patches from bugzilla, etc, that haven't made their way into 
any package version available in the tree for negatively affected 
packages that I use, yet, as I do frequently package.unmask new gccs, 
etc, before they're officially unmasked, which generally takes place 
after those patches have actually made it into in-tree versions... which 
can be quite some time!

gcc-config helps as it makes it quite easy to switch between versions for 
specific packages, but OTOH, that doesn't always help with for instance 
kde, when cmake is built with and depends on the newer gcc, but one of 
the kde packages trying to build with cmake is still broken with the 
newer gcc.  Switch to the newer gcc and you can't compile the broken-with-
it package, switch to the older one and cmake is broken, so you /still/ 
can't compile the package!  If that occurs after you've already rebuild 
90% of the system including 80% of kde with the new version... and it 
DOES have you pulling your hair out!  Been there!  Done that!  Which is 
why I've not tried gcc 4.6 yet, tho I'm getting restless and beginning to 
consider it.

So expect more of this type of thing as the gcc and glibc optimizers try 
to squeeze ever more performance out of their optimizations, because all 
the "safe" optimizations have been had, and they're deep into "undefined 
behavior" territory now, taking advantage of the fact that it's undefined 
to change it here and there, thus eking out yet another corner-case 
optimization, whilst ensuring the gentoo devs don't run out of things to 
do, ensuring compatibility of old code with new compiler and system 
library versions. =:^]

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman