Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems
Date: Fri, 01 Jul 2011 01:00:34
In Reply to: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems by Nikos Chantziaras
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


Subject Author
Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems Frank Peters <frank.peters@×××××××.net>