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@...>
>>>> 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
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
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