* [gentoo-amd64] GCC-4.5.2 Has Serious Problems @ 2011-06-30 21:45 Frank Peters 2011-06-30 22:30 ` Alex Schuster 2011-06-30 23:35 ` [gentoo-amd64] " Nikos Chantziaras 0 siblings, 2 replies; 20+ messages in thread From: Frank Peters @ 2011-06-30 21:45 UTC (permalink / raw To: gentoo-amd64 [-- Attachment #1: Type: text/plain, Size: 2548 bytes --] Hello, After banging my head for a while over some strange results, I began to suspect GCC-4.5.2, the latest version in portage, was creating faulty code. It seems to a correct suspicion. What follows is a short C program that reproduces my particular problem, but there are likely many other situations where GCC could fail. The code may be a difficult for some people to follow but only the output is what actually matters. Simpler examples will certainly exist but I have not had the chance to develop them. The program is included here as both in-line text and as a file attachment (gcc_test.c). The problem is described below. ------------------------------------ #include <stdio.h> #include <stdlib.h> int main(void) { int n; double x; unsigned long int arg; unsigned long int *px = (unsigned long int*)&x; x=0.0; n=0; arg=0x4010000000000000; while(n<5) { printf("%lx %g\n",arg, x); *px=arg; printf("%lx %g\n\n",arg, x); n++; arg=arg+0x0010000000000000; } exit(0); } ------------------------- What this code does is not very important (it uses pointers to enter hexadecimal values into a floating point variable within a short loop). The output is what matters. Compiling with "gcc -O2 -march=native -o gcc_test gcc_test.c" produces this output: Loop: 0 Val = 4010000000000000, X before = 0 Val = 4010000000000000, X after = 0 --> X should be 4!!! Loop: 1 Val = 4020000000000000, X before = 0 Val = 4020000000000000, X after = 4 Loop: 2 Val = 4030000000000000, X before = 4 Val = 4030000000000000, X after = 8 The printf statements are included before and after the variable, x, is assigned a value. Notice how in the first iteration of the loop the x variable does *not* get assigned a value. The value of x during the first iteration should be 4. The problem can be fixed by compiling the program with "O1" optimization: gcc -O1 -march=native -o gcc_test gcc_test.c Using "O1" the output now becomes: Loop: 0 Val = 4010000000000000, X before = 0 Val = 4010000000000000, X after = 4 --> Now it works!!! Loop: 1 Val = 4020000000000000, X before = 4 Val = 4020000000000000, X after = 8 Loop: 2 Val = 4030000000000000, X before = 8 Val = 4030000000000000, X after = 16 This is now the correct output. In the first iteration the X variable is assigned the proper value. For anyone who wants to try to duplicate these results, please feel free to do so. So I will have to conclude that GCC-4.5.2 has serious problems. This kind of erroneous behavior could appear anywhere. Frank Peters [-- Attachment #2: gcc_test.c --] [-- Type: text/x-csrc, Size: 393 bytes --] #include <stdio.h> #include <stdlib.h> int main(void) { int n; double x; unsigned long int arg; unsigned long int *px = (unsigned long int*)&x; x=0.0; n=0; arg=0x4010000000000000; while(n<3) { printf("%s %d\n%s %lx, %s %g\n", "Loop:", n,"Val =", arg, "X before = ", x); *px=arg; printf("%s %lx, %s %g\n\n", "Val =", arg, "X after = ", x); n++; arg=arg+0x0010000000000000; } exit(0); } ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-amd64] GCC-4.5.2 Has Serious Problems 2011-06-30 21:45 [gentoo-amd64] GCC-4.5.2 Has Serious Problems Frank Peters @ 2011-06-30 22:30 ` Alex Schuster 2011-06-30 23:34 ` Frank Peters 2011-06-30 23:35 ` [gentoo-amd64] " Nikos Chantziaras 1 sibling, 1 reply; 20+ messages in thread From: Alex Schuster @ 2011-06-30 22:30 UTC (permalink / raw To: gentoo-amd64 Frank Peters writes: > After banging my head for a while over some strange results, I began > to suspect GCC-4.5.2, the latest version in portage, was creating > faulty code. > > It seems to a correct suspicion. [...] > The problem can be fixed by compiling the program with "O1" > optimization: Or -O3. > For anyone who wants to try to duplicate these results, please feel > free to do so. > > So I will have to conclude that GCC-4.5.2 has serious problems. > This kind of erroneous behavior could appear anywhere. Oh dear, that's scary. I can confirm this. With -O0, -O1 and -O3, all is fine. -O2 gives the result you see. And with -Os, I get yet another result (0/0, 4/4, 8/8). This is an AMD Athlon(tm) Dual Core Processor 4850e, gcc has been copmpiled with these use flags: fortran gtk mudflap multilib nls nptl openmp Who will file the bug report now? Wonko ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-amd64] GCC-4.5.2 Has Serious Problems 2011-06-30 22:30 ` Alex Schuster @ 2011-06-30 23:34 ` Frank Peters 0 siblings, 0 replies; 20+ messages in thread From: Frank Peters @ 2011-06-30 23:34 UTC (permalink / raw To: gentoo-amd64 On Fri, 01 Jul 2011 00:30:57 +0200 Alex Schuster <wonko@wonkology.org> wrote: > > Who will file the bug report now? > Thanks for the confirmation. GCC-4.5.2, some may claim, is already old hat. I just tried the same experiment using GCC-4.6.0 and there is no problem. The program works with "O2" optimization. So I will be using GCC-4.6.0 from now on. But the problem does deserve some looking into, I would think. Frank Peters ^ permalink raw reply [flat|nested] 20+ messages in thread
* [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems 2011-06-30 21:45 [gentoo-amd64] GCC-4.5.2 Has Serious Problems Frank Peters 2011-06-30 22:30 ` Alex Schuster @ 2011-06-30 23:35 ` Nikos Chantziaras 2011-06-30 23:44 ` Nikos Chantziaras 1 sibling, 1 reply; 20+ messages in thread From: Nikos Chantziaras @ 2011-06-30 23:35 UTC (permalink / raw To: gentoo-amd64 On 07/01/2011 12:45 AM, Frank Peters wrote: > Hello, > > After banging my head for a while over some strange results, I began > to suspect GCC-4.5.2, the latest version in portage, was creating > faulty code. > > It seems to a correct suspicion. >[...] > int n; > double x; > unsigned long int arg; > unsigned long int *px = (unsigned long int*)&x; 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. Short answer, GCC is correct, you are wrong :-) To compile code that breaks aliasing rules, always use the "-fno-strict-aliasing" option. In this case: gcc -O2 -fno-strict-aliasing ^ permalink raw reply [flat|nested] 20+ messages in thread
* [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems 2011-06-30 23:35 ` [gentoo-amd64] " Nikos Chantziaras @ 2011-06-30 23:44 ` Nikos Chantziaras 2011-07-01 0:04 ` Frank Peters ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Nikos Chantziaras @ 2011-06-30 23:44 UTC (permalink / raw To: gentoo-amd64 On 07/01/2011 02:35 AM, Nikos Chantziaras wrote: > On 07/01/2011 12:45 AM, Frank Peters wrote: >> Hello, >> >> After banging my head for a while over some strange results, I began >> to suspect GCC-4.5.2, the latest version in portage, was creating >> faulty code. >> >> It seems to a correct suspicion. >> [...] >> int n; >> double x; >> unsigned long int arg; >> unsigned long int *px = (unsigned long int*)&x; > > 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. And here you can read more thorough information about strict aliasing: http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems 2011-06-30 23:44 ` Nikos Chantziaras @ 2011-07-01 0:04 ` Frank Peters 2011-07-01 0:11 ` Nikos Chantziaras 2011-07-01 0:25 ` Frank Peters 2011-07-01 1:04 ` Frank Peters 2 siblings, 1 reply; 20+ messages in thread From: Frank Peters @ 2011-07-01 0:04 UTC (permalink / raw To: gentoo-amd64 On Fri, 01 Jul 2011 02:44:36 +0300 Nikos Chantziaras <realnc@arcor.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. Frank Peters ^ permalink raw reply [flat|nested] 20+ messages in thread
* [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems 2011-07-01 0:04 ` Frank Peters @ 2011-07-01 0:11 ` Nikos Chantziaras 2011-07-01 0:58 ` Duncan 0 siblings, 1 reply; 20+ messages in thread From: Nikos Chantziaras @ 2011-07-01 0:11 UTC (permalink / raw To: gentoo-amd64 On 07/01/2011 03:04 AM, Frank Peters wrote: > On Fri, 01 Jul 2011 02:44:36 +0300 > Nikos Chantziaras<realnc@arcor.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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems 2011-07-01 0:11 ` Nikos Chantziaras @ 2011-07-01 0:58 ` Duncan 2011-07-01 1:23 ` Frank Peters 0 siblings, 1 reply; 20+ messages in thread From: Duncan @ 2011-07-01 0:58 UTC (permalink / raw To: gentoo-amd64 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@arcor.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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems 2011-07-01 0:58 ` Duncan @ 2011-07-01 1:23 ` Frank Peters 2011-07-01 1:52 ` Duncan ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Frank Peters @ 2011-07-01 1:23 UTC (permalink / raw To: gentoo-amd64 On Fri, 1 Jul 2011 00:58:46 +0000 (UTC) Duncan <1i5t5.duncan@cox.net> wrote: > > I had wondered if this might be an "undefined behavior" optimization bug, > Well, the amd64 users list may not be the appropriate place to discuss C programming, but the problem here stems from attempting to do things with C that are not supposed to be done with C. Such things are aptly called "tricks" because they stray away from the convention. Ideally, I suppose, for these purposes would be to use assembly language routines mixed into the C code. But this is not as easy as with the "tricks." Anyway, I'm glad I presented this issue. It has definitely improved my understanding. GCC has dozens, if not hundreds, of compile options and I know the actual function of only a small few. Frank Peters ^ permalink raw reply [flat|nested] 20+ messages in thread
* [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems 2011-07-01 1:23 ` Frank Peters @ 2011-07-01 1:52 ` Duncan 2011-07-01 2:15 ` Ian McCulloch 2011-07-01 4:36 ` Mark Knecht 2 siblings, 0 replies; 20+ messages in thread From: Duncan @ 2011-07-01 1:52 UTC (permalink / raw To: gentoo-amd64 Frank Peters posted on Thu, 30 Jun 2011 21:23:21 -0400 as excerpted: > Anyway, I'm glad I presented this issue. It has definitely improved my > understanding. GCC has dozens, if not hundreds, of compile options and > I know the actual function of only a small few. Indeed. The gcc manpage is a veritable treasure-trove of interesting options, even (especially?) for those who who don't know C but either aspire to be or already consider themselves Gentoo power-users. And this sort of issue discussion is perfect for a gentoo list, as even for those who don't really understand it, it provides a glimpse into the sorts of things gentoo devs must deal with on a daily basis (yes, I guess that is sort of repeating the point I made before, but it's true). -- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems 2011-07-01 1:23 ` Frank Peters 2011-07-01 1:52 ` Duncan @ 2011-07-01 2:15 ` Ian McCulloch 2011-07-01 4:36 ` Mark Knecht 2 siblings, 0 replies; 20+ messages in thread From: Ian McCulloch @ 2011-07-01 2:15 UTC (permalink / raw To: gentoo-amd64@lists.gentoo.org On Fri, 1 Jul 2011, Frank Peters wrote: > On Fri, 1 Jul 2011 00:58:46 +0000 (UTC) > Duncan <1i5t5.duncan@cox.net> wrote: > >> >> I had wondered if this might be an "undefined behavior" optimization bug, >> > > Well, the amd64 users list may not be the appropriate place to discuss > C programming, but the problem here stems from attempting to do things > with C that are not supposed to be done with C. Such things are aptly > called "tricks" because they stray away from the convention. I don't think that is true - C has ALWAYS had rules on strict aliasing, even from the first attempts at standardization. Unfortunately it is only recently that common compilers and hardware have really taken advantage of the way the language works to give better optimizing performance by storing more variables in registers rather than reloading pointers from memory every time. Mostly this is due to the small number of registers in the x86 architecture, doesn't lend itself to these optimisations as well as other architectures. Contrast with Itanium for example with lots of registers, some of which are designed to be preserved across a function call. FORTRAN compilers have taken advantage of aliasing optimizations right from the beginning (ie, since the 1960's!), and commodity C compilers are only now just catching up! So these are hardly new optimizations. > > Ideally, I suppose, for these purposes would be to use assembly language > routines mixed into the C code. But this is not as easy as with the > "tricks." Not at all, it is about producing more efficient assembly, using the language rules that have existed practically forever. If programmers have become accustomed to violating those rules, then they'll just have to get accustomed to not violating them. The rules aren't hard! And if you DO want to alias pointers of different types, then there are well-defined ways of doing that, and the resulting code tends to be much more readable too. Regards, Ian ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems 2011-07-01 1:23 ` Frank Peters 2011-07-01 1:52 ` Duncan 2011-07-01 2:15 ` Ian McCulloch @ 2011-07-01 4:36 ` Mark Knecht 2011-07-01 5:22 ` Frank Peters 2 siblings, 1 reply; 20+ messages in thread From: Mark Knecht @ 2011-07-01 4:36 UTC (permalink / raw To: gentoo-amd64 On Thu, Jun 30, 2011 at 6:23 PM, Frank Peters <frank.peters@comcast.net> wrote: > On Fri, 1 Jul 2011 00:58:46 +0000 (UTC) > Duncan <1i5t5.duncan@cox.net> wrote: > >> >> I had wondered if this might be an "undefined behavior" optimization bug, >> > > Well, the amd64 users list may not be the appropriate place to discuss > C programming, but the problem here stems from attempting to do things > with C that are not supposed to be done with C. Such things are aptly > called "tricks" because they stray away from the convention. > > Ideally, I suppose, for these purposes would be to use assembly language > routines mixed into the C code. But this is not as easy as with the > "tricks." > > Anyway, I'm glad I presented this issue. It has definitely improved > my understanding. GCC has dozens, if not hundreds, of compile options > and I know the actual function of only a small few. > > Frank Peters > > I think it's completely appropriate for this list. This distro expects that we put CFLAG options in make.conf so I need to hear about this stuff even if I don't have to background to completely understand what's really causing the problem. - Mark ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems 2011-07-01 4:36 ` Mark Knecht @ 2011-07-01 5:22 ` Frank Peters 0 siblings, 0 replies; 20+ messages in thread From: Frank Peters @ 2011-07-01 5:22 UTC (permalink / raw To: gentoo-amd64 On Thu, 30 Jun 2011 21:36:38 -0700 Mark Knecht <markknecht@gmail.com> wrote: > > I think it's completely appropriate for this list. This distro expects > that we put CFLAG options in make.conf so I need to hear about this > stuff even if I don't have to background to completely understand > what's really causing the problem. > In this case, or in the case of any program where "-fno-strict-aliasing" could make a difference, the maintainer of the program would include the option in the ebuild. The user would not have to worry too much about it. But yes, it is always good to know about the compiler flags. To see exactly what compile flags are being used in your programs, here is a neat method I picked up from somewhere. Just open a terminal and enter the following command: echo 'int main(){return 0;}' > test.c && gcc -v -Q $CFLAGS test.c -o test && rm test.c test In place of $CFLAGS just substitute any option of interest. There will be a flood of output, but just scroll back a few lines to find the "options passed:" and "options enabled:" sections. For example, using "-O2" for $CFLAGS indicates that "-fstrict-aliasing" is used, but it is not used with "-O1." It also shows that with "-O2" the option "-mno-sse4" is used, and so if you want to use SSE4 for certain programs (e.g. video, audio) you will need to specifically enable it. There may be an even slicker way to reveal the flags, but this is the only way I know. Frank Peters ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems 2011-06-30 23:44 ` Nikos Chantziaras 2011-07-01 0:04 ` Frank Peters @ 2011-07-01 0:25 ` Frank Peters 2011-07-01 1:04 ` Frank Peters 2 siblings, 0 replies; 20+ messages in thread From: Frank Peters @ 2011-07-01 0:25 UTC (permalink / raw To: gentoo-amd64 On Fri, 01 Jul 2011 02:44:36 +0300 Nikos Chantziaras <realnc@arcor.de> wrote: > >> unsigned long int *px = (unsigned long int*)&x; > And here you can read more thorough information about strict aliasing: > > http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing > Thanks for this link. I can see what's happening now. These types of pointers are admittedly unusual, but it's the only quick way I know to load a double variable with a certain bit pattern, or to convert big/small endian values, etc. I ordinarily don't do these things, but when I do I 'll keep this aliasing in mind. Frank Peters ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems 2011-06-30 23:44 ` Nikos Chantziaras 2011-07-01 0:04 ` Frank Peters 2011-07-01 0:25 ` Frank Peters @ 2011-07-01 1:04 ` Frank Peters 2011-07-01 2:18 ` Duncan ` (2 more replies) 2 siblings, 3 replies; 20+ messages in thread From: Frank Peters @ 2011-07-01 1:04 UTC (permalink / raw To: gentoo-amd64 On Fri, 01 Jul 2011 02:44:36 +0300 Nikos Chantziaras <realnc@arcor.de> wrote: > > And here you can read more thorough information about strict aliasing: > > http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing > You've saved the day in more ways than one. A few days ago I posted about a possible problem with a floating point test called the UCBTEST. After examining the source code of this test, I see violations of aliasing rules throughout. It's hard to efficiently manipulate variables without them. Of course, this code was written before the C99 standard and so is exempt. But the use of "-fno-strict-aliasing" will apply with the UCBTEST as well. Thanks again for the information. Frank Peters ^ permalink raw reply [flat|nested] 20+ messages in thread
* [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems 2011-07-01 1:04 ` Frank Peters @ 2011-07-01 2:18 ` Duncan 2011-07-01 2:22 ` Barry Schwartz 2011-07-01 11:53 ` Nikos Chantziaras 2 siblings, 0 replies; 20+ messages in thread From: Duncan @ 2011-07-01 2:18 UTC (permalink / raw To: gentoo-amd64 Frank Peters posted on Thu, 30 Jun 2011 21:04:29 -0400 as excerpted: > On Fri, 01 Jul 2011 02:44:36 +0300 Nikos Chantziaras <realnc@arcor.de> > wrote: > >> And here you can read more thorough information about strict aliasing: >> >> http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing >> > You've saved the day in more ways than one. > > A few days ago I posted about a possible problem with a floating point > test called the UCBTEST. After examining the source code of this test, > I see violations of aliasing rules throughout. It's hard to efficiently > manipulate variables without them. > > Of course, this code was written before the C99 standard and so is > exempt. But the use of "-fno-strict-aliasing" will apply with the > UCBTEST as well. Truthfully, I thought sure this was a direct follow-on to that! So I'm happy to see that the same cause and solutions apply. =:^) As I said in an earlier post, tho, expect there to be more problems like that with code of that age as time goes on, because they're well past the easy optimizations now, and into stuff like this. So it may be wise to keep an eye out and test the minor gcc version bumps with an eye toward such issues. They generally put out a porting guide, etc, with the new version, that you can read for clues in case the tests start doing unexpected things again. (If you pay attention to flameeyes' blog, he tends to cover such things reasonably early on after release of a new gcc version as well, as he does tinderbox runs to see how bad the interaction of the new version is with the current gentoo ~arch tree as a whole and eventually to test that the latest ~arch packages are updated or patched to fix the problem, before that gcc version gets unmasked to ~arch. By no means do I agree with everything he says, but he really is an asset to gentoo and would be sorely missed should one of his sick episodes make it impossible for him to continue, or if he simply decided he had better things to do with his time. The switch to --as-needed in Gentoo's default ldflags was largely due to his work, explaining the issues for other devs, testing and filing bugs, helping with the hard cases, and in general pushing it until it happened, for instance, and every single gentoo user benefits from that in the form of less mandatory rebuilds, every time they update. It may well have happened without him, but it might have taken a decade longer, too. And because gentoo devs normally push those patches upstream where they can, that has been a benefit to the entire FLOSS community, not just gentoo, as well, reducing "dependency hell" for everyone.) -- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems 2011-07-01 1:04 ` Frank Peters 2011-07-01 2:18 ` Duncan @ 2011-07-01 2:22 ` Barry Schwartz 2011-07-01 2:43 ` Frank Peters 2011-07-01 11:53 ` Nikos Chantziaras 2 siblings, 1 reply; 20+ messages in thread From: Barry Schwartz @ 2011-07-01 2:22 UTC (permalink / raw To: gentoo-amd64 Frank Peters <frank.peters@comcast.net> skribis: > A few days ago I posted about a possible problem with a floating > point test called the UCBTEST. After examining the source code > of this test, I see violations of aliasing rules throughout. > It's hard to efficiently manipulate variables without them. C is essentially a glorified assembly language for PDP-11, designed for bit-twiddling, which the original K&R book encouraged, and which this code is doing. So all is well, from my point of view. :) Fancy optimizations are not to be trusted on assembly code; never be afraid to turn them off. You probably don’t need them, anyway. :) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems 2011-07-01 2:22 ` Barry Schwartz @ 2011-07-01 2:43 ` Frank Peters 0 siblings, 0 replies; 20+ messages in thread From: Frank Peters @ 2011-07-01 2:43 UTC (permalink / raw To: gentoo-amd64 On Thu, 30 Jun 2011 21:22:39 -0500 Barry Schwartz <chemoelectric@chemoelectric.org> wrote: > > C is essentially a glorified assembly language > IMO, that's why C is the best. It is very close to the machine and the programmer has to be very attentive to details of hardware as well as to software concepts. > for bit-twiddling, which the original K&R book encouraged, and which > this code is doing. So all is well, from my point of view. :) Bit manipulations on integers and strings are natural. The difficulty is with floating point variables which are not just bits but also a complex format that does not respect byte boundaries. The ordinary bit operators cannot apply to floating point. The only way to ordinarily get data in/out is to use the built-in conversion routines. The language was never designed, AFAIK, to directly manipulate floating point bits. > Fancy > optimizations are not to be trusted on assembly code; never be afraid > to turn them off. You probably don’t need them, anyway. :) > Certainly true. But in this case, -fno-strict-aliasing is absolutely necessary. Also, I, as probably most others, would rather not concentrate so much on the compiler as on the task of coding itself. Frank Peters ^ permalink raw reply [flat|nested] 20+ messages in thread
* [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems 2011-07-01 1:04 ` Frank Peters 2011-07-01 2:18 ` Duncan 2011-07-01 2:22 ` Barry Schwartz @ 2011-07-01 11:53 ` Nikos Chantziaras 2011-07-01 16:53 ` Frank Peters 2 siblings, 1 reply; 20+ messages in thread From: Nikos Chantziaras @ 2011-07-01 11:53 UTC (permalink / raw To: gentoo-amd64 On 07/01/2011 04:04 AM, Frank Peters wrote: > A few days ago I posted about a possible problem with a floating > point test called the UCBTEST. After examining the source code > of this test, I see violations of aliasing rules throughout. > It's hard to efficiently manipulate variables without them. You can alias them with a char* (a char pointer can alias everything in a valid and defined manner). What you do is use the char* to scan over the target type. And since a char is always guaranteed to be 8 bits, it's very suited for doing endian conversions. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems 2011-07-01 11:53 ` Nikos Chantziaras @ 2011-07-01 16:53 ` Frank Peters 0 siblings, 0 replies; 20+ messages in thread From: Frank Peters @ 2011-07-01 16:53 UTC (permalink / raw To: gentoo-amd64 On Fri, 01 Jul 2011 14:53:45 +0300 Nikos Chantziaras <realnc@arcor.de> wrote: > > You can alias them with a char* (a char pointer can alias everything in > a valid and defined manner). What you do is use the char* to scan over > the target type. And since a char is always guaranteed to be 8 bits, > it's very suited for doing endian conversions. > Yes, that's true, but in my case another concern was having data that is more easily human readable. A text file full of single-byte data is harder to read than a file with full 64 or 32 bit strings. For endian conversions, though, the char pointer is recommended. But with the availability of the "-fno-strict-aliasing" option it doesn't seem to matter which method is chosen. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2011-07-01 16:56 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-06-30 21:45 [gentoo-amd64] GCC-4.5.2 Has Serious Problems Frank Peters 2011-06-30 22:30 ` Alex Schuster 2011-06-30 23:34 ` Frank Peters 2011-06-30 23:35 ` [gentoo-amd64] " Nikos Chantziaras 2011-06-30 23:44 ` Nikos Chantziaras 2011-07-01 0:04 ` Frank Peters 2011-07-01 0:11 ` Nikos Chantziaras 2011-07-01 0:58 ` Duncan 2011-07-01 1:23 ` Frank Peters 2011-07-01 1:52 ` Duncan 2011-07-01 2:15 ` Ian McCulloch 2011-07-01 4:36 ` Mark Knecht 2011-07-01 5:22 ` Frank Peters 2011-07-01 0:25 ` Frank Peters 2011-07-01 1:04 ` Frank Peters 2011-07-01 2:18 ` Duncan 2011-07-01 2:22 ` Barry Schwartz 2011-07-01 2:43 ` Frank Peters 2011-07-01 11:53 ` Nikos Chantziaras 2011-07-01 16:53 ` Frank Peters
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox