1 |
Nikos Chantziaras posted on Fri, 01 Jul 2011 03:11:09 +0300 as excerpted: |
2 |
|
3 |
> On 07/01/2011 03:04 AM, Frank Peters wrote: |
4 |
>> On Fri, 01 Jul 2011 02:44:36 +0300 Nikos Chantziaras<realnc@×××××.de> |
5 |
>> wrote: |
6 |
>> |
7 |
>> |
8 |
>>>> Your code is buggy, because you're breaking C's aliasing rules. You |
9 |
>>>> are not allowed to use a different pointer type to dereference a |
10 |
>>>> variable of a different type. Doing so results in undefined behavior. |
11 |
>>> |
12 |
>>> |
13 |
>> Well, the error occurs only within the loop structure. If I manually |
14 |
>> "unroll" the loop using the same pointers there is no error when |
15 |
>> compiled with "O2." |
16 |
>> |
17 |
>> IOW, the problem is how the loop is optimized under -O2. |
18 |
> |
19 |
> When there's "undefined behavior", it really means just that: you cannot |
20 |
> make any assumptions about when the result is going to be correct and |
21 |
> when not. It might as well depend on whether it was raining yesterday. |
22 |
|
23 |
I had wondered if this might be an "undefined behavior" optimization bug, |
24 |
but don't personally know enough about C coding to tell. |
25 |
|
26 |
However, what I have observed, both here and for instance in the recent |
27 |
glibc memcp vs memmove instructions (don't ask me if those are |
28 |
abbreviated correctly, I'm not a coder, just a user who followed the |
29 |
situation as reported in the community press with some interest, |
30 |
particularly because I DO tend to unmask and try new versions with such |
31 |
issues before they're officially ready), is that in the quest for further |
32 |
optimizations, all the "easy" stuff is pretty much already done. It's |
33 |
now the harder, more obscure optimizations that might break code making |
34 |
bad assumptions about "undefined behavior", etc, that's the leading edge |
35 |
of technology, at least as seen in the FLOSS world encompassing gcc and |
36 |
glibc. |
37 |
|
38 |
The -fno-strict-aliasing thing was a big deal for gcc 4.5, precisely |
39 |
because it DOES allow corner-case optimization where it wasn't tried |
40 |
before, but does so by taking advantage of "undefined behavior" being |
41 |
just that, undefined, to make assumptions about shortcuts the authors did |
42 |
NOT take because to do so would be undefined, based on the absence of a |
43 |
flag saying NOT to make such assumptions because the author DID take such |
44 |
shortcuts, relying on the previous behavior where it is specifically |
45 |
defined as "undefined". |
46 |
|
47 |
As it happens, there was quite a lot of code making such assumptions, |
48 |
that needed -fno-strict-aliasing in the short term, but hopefully, |
49 |
recoded not to make invalid assumptions about the behavior of |
50 |
specifically "undefined behavior" in the longer term. |
51 |
|
52 |
It's just that sort of testing, bug reporting, and patching, that keeps |
53 |
gentoo devs (and indeed, those of many distributions) busy, as new |
54 |
versions of gcc and various system libraries come out, and why at times |
55 |
they seem to take "forever" to stabilize, or even get unmasked into ~arch |
56 |
(where gcc-4.6 has yet to appear, fwiw). |
57 |
|
58 |
FWIW, I don't know a whole lot about fixing such things in the C/C++/ |
59 |
whatever code itself, but I've developed quite some experience finding |
60 |
and applying patches from bugzilla, etc, that haven't made their way into |
61 |
any package version available in the tree for negatively affected |
62 |
packages that I use, yet, as I do frequently package.unmask new gccs, |
63 |
etc, before they're officially unmasked, which generally takes place |
64 |
after those patches have actually made it into in-tree versions... which |
65 |
can be quite some time! |
66 |
|
67 |
gcc-config helps as it makes it quite easy to switch between versions for |
68 |
specific packages, but OTOH, that doesn't always help with for instance |
69 |
kde, when cmake is built with and depends on the newer gcc, but one of |
70 |
the kde packages trying to build with cmake is still broken with the |
71 |
newer gcc. Switch to the newer gcc and you can't compile the broken-with- |
72 |
it package, switch to the older one and cmake is broken, so you /still/ |
73 |
can't compile the package! If that occurs after you've already rebuild |
74 |
90% of the system including 80% of kde with the new version... and it |
75 |
DOES have you pulling your hair out! Been there! Done that! Which is |
76 |
why I've not tried gcc 4.6 yet, tho I'm getting restless and beginning to |
77 |
consider it. |
78 |
|
79 |
So expect more of this type of thing as the gcc and glibc optimizers try |
80 |
to squeeze ever more performance out of their optimizations, because all |
81 |
the "safe" optimizations have been had, and they're deep into "undefined |
82 |
behavior" territory now, taking advantage of the fact that it's undefined |
83 |
to change it here and there, thus eking out yet another corner-case |
84 |
optimization, whilst ensuring the gentoo devs don't run out of things to |
85 |
do, ensuring compatibility of old code with new compiler and system |
86 |
library versions. =:^] |
87 |
|
88 |
-- |
89 |
Duncan - List replies preferred. No HTML msgs. |
90 |
"Every nonfree program has a lord, a master -- |
91 |
and if you use the program, he is your master." Richard Stallman |