-fno-strict-aliasing in CWARNFLAGS?
Hi, When building Xming on Linux with a MinGW cross-compiler for Windows... I only get warnings about strict-aliasing from libX11 and libXt (i.e. when not using -fno-strict-aliasing). The xserver, pixman and Mesa are all happy bunnies strict. Now whether they work strict is another question! I'm trialling this at the moment (with only libX11 and libX11 built no-strict). Thanks, Colin Harrison ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
On Tue, 2010-02-02 at 16:18 -0500, Gaetan Nadon wrote: On Tue, 2010-02-02 at 09:28 -0800, Jeremy Huddleston wrote: What's the rationale behind having -fno-strict-aliasing in CWARNFLAGS? Do we actually have code somewhere that needs -fno-strict-aliasing? If so, we should restrict -fno-strict-aliasing to that project (and try to address the reason for the need) rather than putting it in util-macros. I did a bit of research. This option has been used since the first day in git for xserver: +if test x$GCC = xyes; then + GCC_WARNINGS1=-Wall -Wpointer-arith -Wstrict-prototypes + GCC_WARNINGS2=-Wmissing-prototypes -Wmissing-declarations + GCC_WARNINGS3=-Wnested-externs -fno-strict-aliasing + GCC_WARNINGS=$GCC_WARNINGS1 $GCC_WARNINGS2 $GCC_WARNINGS3 + if test x$WERROR = xyes; then + GCC_WARNINGS=${GCC_WARNINGS} -Werror + fi + XSERVER_CFLAGS=$GCC_WARNINGS $XSERVER_CFLAGS +fi This is not a warning option, so it should not be there to begin with (or the macro name was wrong). I tried to understand why it's there. The gcc compiler makes optimization based on aliasing assumptions. If the code does not follow the rules, it can cause runtime failure. According to this post, the Perl code has removed the -fno-strict-aliasing as it cannot safely assume that compilers won't optimize anyway. They figured it was better to fix the code, where applicable. That was in 2002. http://www.nntp.perl.org/group/perl.perl6.internals/2002/12/msg14281.html There are posts about good code that failed under strict aliasing optimization, only to be flagged afterwards by others who demonstrated that the code worked by luck when not optimized. Help with understanding strict aliasing rules: http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html The rules about pointer type conversions are at 6.3.2.3. The appropriate paragraphs are paragraphs 1 and 7: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf I have not seen any compelling reasons to turn off this optimization. Maybe 10 years ago when it was first introduced. I have seen reports of large number of warnings, but from older gcc versions. As it is today, we are losing some optimization that could be beneficial. I'd like to question that assertion. My impression has been that strict aliasing is a concept only really understood by maybe a handful of people, and I've seen kernel hackers much brighter than myself say it's not worth the trouble. Traditionally, -fno-strict-aliasing was definitely necessary for the X server and/or some drivers to work correctly. According to my gcc documentation, -Wstrict-aliasing=2 still seems rather unsafe, and even -Wstrict-aliasing (which corresponds to -Wstrict-aliasing=3) isn't perfect. Due to all of the above, I think it would be prudent to at least establish significant gains from strict aliasing before enabling it on a wide scale. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
On Wed, 2010-02-03 at 10:15 +, Colin Harrison wrote: Michel Dänzer wrote: Traditionally, -fno-strict-aliasing was definitely necessary for the X server and/or some drivers to work correctly. Strict aliasing used to be a can'o worms... http://lkml.org/lkml/2003/2/26/158 and last time I tried strict aliasing for Xming (many moons ago) I fell flat on my face. But is series 4 gcc now much better? Problems with strict aliasing are usually due to strict aliasing violations in the code being compiled, not bugs in the compiler. So newer compilers can't really help (in fact the opposite may be true, as I think newer versions of gcc tend to obey strict aliasing even more strictly), the only help would be fixing the code bugs. I'm sure some of them have been fixed... We shall see (I'm testing with libX11 and libXt unchanged; but everything else ...most X.Org libs, most clients, pixman, Mesa and xserver... with strict aliasing) BTW I use -Os optimisation for all except -O2 for pixman and don't build any xserver drivers. According to the gcc 4.3 documentation: The `-fstrict-aliasing' option is enabled at levels `-O2', `-O3', `-Os'. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
2010/2/3 Michel Dänzer mic...@daenzer.net: On Tue, 2010-02-02 at 16:18 -0500, Gaetan Nadon wrote: On Tue, 2010-02-02 at 09:28 -0800, Jeremy Huddleston wrote: What's the rationale behind having -fno-strict-aliasing in CWARNFLAGS? Do we actually have code somewhere that needs -fno-strict-aliasing? If so, we should restrict -fno-strict-aliasing to that project (and try to address the reason for the need) rather than putting it in util-macros. I did a bit of research. This option has been used since the first day in git for xserver: +if test x$GCC = xyes; then + GCC_WARNINGS1=-Wall -Wpointer-arith -Wstrict-prototypes + GCC_WARNINGS2=-Wmissing-prototypes -Wmissing-declarations + GCC_WARNINGS3=-Wnested-externs -fno-strict-aliasing + GCC_WARNINGS=$GCC_WARNINGS1 $GCC_WARNINGS2 $GCC_WARNINGS3 + if test x$WERROR = xyes; then + GCC_WARNINGS=${GCC_WARNINGS} -Werror + fi + XSERVER_CFLAGS=$GCC_WARNINGS $XSERVER_CFLAGS +fi This is not a warning option, so it should not be there to begin with (or the macro name was wrong). I tried to understand why it's there. The gcc compiler makes optimization based on aliasing assumptions. If the code does not follow the rules, it can cause runtime failure. According to this post, the Perl code has removed the -fno-strict-aliasing as it cannot safely assume that compilers won't optimize anyway. They figured it was better to fix the code, where applicable. That was in 2002. http://www.nntp.perl.org/group/perl.perl6.internals/2002/12/msg14281.html There are posts about good code that failed under strict aliasing optimization, only to be flagged afterwards by others who demonstrated that the code worked by luck when not optimized. Help with understanding strict aliasing rules: http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html The rules about pointer type conversions are at 6.3.2.3. The appropriate paragraphs are paragraphs 1 and 7: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf I have not seen any compelling reasons to turn off this optimization. Maybe 10 years ago when it was first introduced. I have seen reports of large number of warnings, but from older gcc versions. As it is today, we are losing some optimization that could be beneficial. I'd like to question that assertion. My impression has been that strict aliasing is a concept only really understood by maybe a handful of people, and I've seen kernel hackers much brighter than myself say it's not worth the trouble. Here's one link: http://lkml.org/lkml/2003/2/26/158 Traditionally, -fno-strict-aliasing was definitely necessary for the X server and/or some drivers to work correctly. I know in mesa it's been required. Here are two bugs fixed/worked around by -fno-strict-aliasing. https://bugs.freedesktop.org/show_bug.cgi?id=6046 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394311 -- Dan ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
2010/2/3 Michel Dänzer mic...@daenzer.net: On Wed, 2010-02-03 at 10:15 +, Colin Harrison wrote: Michel Dänzer wrote: Traditionally, -fno-strict-aliasing was definitely necessary for the X server and/or some drivers to work correctly. Strict aliasing used to be a can'o worms... http://lkml.org/lkml/2003/2/26/158 and last time I tried strict aliasing for Xming (many moons ago) I fell flat on my face. But is series 4 gcc now much better? Problems with strict aliasing are usually due to strict aliasing violations in the code being compiled, not bugs in the compiler. So newer compilers can't really help (in fact the opposite may be true, as I think newer versions of gcc tend to obey strict aliasing even more strictly), the only help would be fixing the code bugs. I'm sure some of them have been fixed... Here's an example of newer gcc changing behavior with strict aliasing that I just happened to see the other day. http://jeffreystedfast.blogspot.com/2010/01/weird-bugs-due-to-gcc-44-and-strict.html -- Dan ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
Ok. In light of the discussion here, I think it would be best to take Gaetan's option 3 here: 1) We should turn -fno-strict-aliasing on in the 9 (note that this number does not include xf86 drivers) modules that traditionally had it: libICE libSM libX11 libXau libXfont libXft libXpm libXres xorg-server xf86-* (somene else should check which ones traditionally had this CFLAG) 2) We should remove it from the CWARNFLAGS in util-macros (and turn on the warning) 3) We should audit the modules where we added it in #1 and slowly remove it where safe. --Jeremy On Feb 3, 2010, at 10:55, Soeren Sandmann wrote: Dan Nicholson dbn.li...@gmail.com writes: Here's one link: http://lkml.org/lkml/2003/2/26/158 Traditionally, -fno-strict-aliasing was definitely necessary for the X server and/or some drivers to work correctly. I know in mesa it's been required. Here are two bugs fixed/worked around by -fno-strict-aliasing. https://bugs.freedesktop.org/show_bug.cgi?id=6046 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394311 I recently turned it on in pixman because completely reasonable code like this: void pixman_contract (uint32_t * dst, const uint64_t *src, int width) { int i; /* Start at the beginning so that we can do the contraction in * place when src == dst */ for (i = 0; i width; i++) { const uint8_t a = src[i] 56, r = src[i] 40, g = src[i] 24, b = src[i] 8; dst[i] = a 24 | r 16 | g 8 | b; } } is actually illegal under the C aliasing rules, and GCC can and will break it unless you use -fno-strict-aliasing. I don't think any other compiler makes use of type based aliasing, perhaps because they rightly - consider the standard broken. Soren ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel smime.p7s Description: S/MIME cryptographic signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
On 2010-02-03 15:02, Michael Cree wrote: On 04/02/10 07:55, Soeren Sandmann wrote: I recently turned it on in pixman because completely reasonable code like this: void pixman_contract (uint32_t * dst, const uint64_t *src, int width) { int i; /* Start at the beginning so that we can do the contraction in * place when src == dst */ is actually illegal under the C aliasing rules, and GCC can and will break it unless you use -fno-strict-aliasing. I'm confused. Why does this break the aliasing rules? If *dst and *src point to (alias) the same memory, it breaks the rules since they are different types. The compiler is free to assume that dst and src are disjoint. It may eg. unroll the loop and re-order the loads and stores, resulting in something the programmer didn't expect if they do overlap. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
On 04/02/10 09:17, Peter Harris wrote: On 2010-02-03 15:02, Michael Cree wrote: On 04/02/10 07:55, Soeren Sandmann wrote: I recently turned it on in pixman because completely reasonable code like this: void pixman_contract (uint32_t * dst, const uint64_t *src, int width) { int i; /* Start at the beginning so that we can do the contraction in * place when src == dst */ is actually illegal under the C aliasing rules, and GCC can and will break it unless you use -fno-strict-aliasing. I'm confused. Why does this break the aliasing rules? If *dst and *src point to (alias) the same memory, it breaks the rules since they are different types. Thanks, yes, it's now obvious. Looking back at the code I now see that I completely missed the comment that says it is possible that src == dest. When I read code and see two different pointer types in the functions arguments I naturally assume that it is _intended_ that they are two different areas of memory. I always program like that and I guess that programming practice comes from once knowing the C standard well many years ago. Cheers Michael. ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
On Wed, 2010-02-03 at 11:35 -0800, Jeremy Huddleston wrote: Ok. In light of the discussion here, I think it would be best to take Gaetan's option 3 here: 1) We should turn -fno-strict-aliasing on in the 9 (note that this number does not include xf86 drivers) modules that traditionally had it: libICE libSM libX11 libXau libXfont libXft libXpm libXres xorg-server xf86-* (somene else should check which ones traditionally had this CFLAG) 2) We should remove it from the CWARNFLAGS in util-macros (and turn on the warning) 3) We should audit the modules where we added it in #1 and slowly remove it where safe. --Jeremy I think this wikipedia article says it all: http://en.wikipedia.org/wiki/Aliasing_(computing) The Python project and Linux kernel are not observing strict alias rules. From a practical view point, the only *safe* way of changing the current situation is to move the option from macros to each module. Some exclusions are possible up-front like protos (just header files) and fonts. Each module would then decide if they want to invest time and effort to change/test their code. Some modules don't have maintainers, so there will be no real change for them. Gaetan On Feb 3, 2010, at 10:55, Soeren Sandmann wrote: Dan Nicholson dbn.li...@gmail.com writes: Here's one link: http://lkml.org/lkml/2003/2/26/158 Traditionally, -fno-strict-aliasing was definitely necessary for the X server and/or some drivers to work correctly. I know in mesa it's been required. Here are two bugs fixed/worked around by -fno-strict-aliasing. https://bugs.freedesktop.org/show_bug.cgi?id=6046 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394311 I recently turned it on in pixman because completely reasonable code like this: void pixman_contract (uint32_t * dst, const uint64_t *src, int width) { int i; /* Start at the beginning so that we can do the contraction in * place when src == dst */ for (i = 0; i width; i++) { const uint8_t a = src[i] 56, r = src[i] 40, g = src[i] 24, b = src[i] 8; dst[i] = a 24 | r 16 | g 8 | b; } } is actually illegal under the C aliasing rules, and GCC can and will break it unless you use -fno-strict-aliasing. I don't think any other compiler makes use of type based aliasing, perhaps because they rightly - consider the standard broken. Soren ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
Michael Cree mc...@orcon.net.nz writes: What I do see is that the variables a, r, g and b are essentially declared unsigned char (what I presume uint8_t is typedefed to) and a calculation is performed that will lose its intended result due to shifting an unsigned char more bits to the left than is available in the unsigned char. The variables are promoted to int before the shift takes place, so the code works fine, apart from the aliasing issue. Soren ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
On 04/02/10 14:28, Soeren Sandmann wrote: Michael Creemc...@orcon.net.nz writes: What I do see is that the variables a, r, g and b are essentially declared unsigned char (what I presume uint8_t is typedefed to) and a calculation is performed that will lose its intended result due to shifting an unsigned char more bits to the left than is available in the unsigned char. The variables are promoted to int before the shift takes place, so the code works fine, apart from the aliasing issue. Yeah, I remembered that once I thought about it a bit more after hitting the send button... oops :-/ I once knew all this stuff intimately; I could've even written out a complete operator precedence table from memory! Having only programmed in C on occasion over the last 12 years I now realise that some of that knowledge is getting a little hazy. While I unfortunately polluted the thread with my misguided ramblings I have nevertheless found this discussion very useful. Cheers Michael. ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
-fno-strict-aliasing in CWARNFLAGS?
What's the rationale behind having -fno-strict-aliasing in CWARNFLAGS? Do we actually have code somewhere that needs -fno-strict-aliasing? If so, we should restrict -fno-strict-aliasing to that project (and try to address the reason for the need) rather than putting it in util-macros. ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
On Tue, 2010-02-02 at 09:28 -0800, Jeremy Huddleston wrote: What's the rationale behind having -fno-strict-aliasing in CWARNFLAGS? Do we actually have code somewhere that needs -fno-strict-aliasing? If so, we should restrict -fno-strict-aliasing to that project (and try to address the reason for the need) rather than putting it in util-macros. I did a bit of research. This option has been used since the first day in git for xserver: +if test x$GCC = xyes; then + GCC_WARNINGS1=-Wall -Wpointer-arith -Wstrict-prototypes + GCC_WARNINGS2=-Wmissing-prototypes -Wmissing-declarations + GCC_WARNINGS3=-Wnested-externs -fno-strict-aliasing + GCC_WARNINGS=$GCC_WARNINGS1 $GCC_WARNINGS2 $GCC_WARNINGS3 + if test x$WERROR = xyes; then + GCC_WARNINGS=${GCC_WARNINGS} -Werror + fi + XSERVER_CFLAGS=$GCC_WARNINGS $XSERVER_CFLAGS +fi This is not a warning option, so it should not be there to begin with (or the macro name was wrong). I tried to understand why it's there. The gcc compiler makes optimization based on aliasing assumptions. If the code does not follow the rules, it can cause runtime failure. According to this post, the Perl code has removed the -fno-strict-aliasing as it cannot safely assume that compilers won't optimize anyway. They figured it was better to fix the code, where applicable. That was in 2002. http://www.nntp.perl.org/group/perl.perl6.internals/2002/12/msg14281.html There are posts about good code that failed under strict aliasing optimization, only to be flagged afterwards by others who demonstrated that the code worked by luck when not optimized. Help with understanding strict aliasing rules: http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html The rules about pointer type conversions are at 6.3.2.3. The appropriate paragraphs are paragraphs 1 and 7: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf I have not seen any compelling reasons to turn off this optimization. Maybe 10 years ago when it was first introduced. I have seen reports of large number of warnings, but from older gcc versions. As it is today, we are losing some optimization that could be beneficial. This option has been there for so long (most likely copied along), I doubt you will will get a clear answer for each of the 240 xorg modules. It would take a few modules to try it out first. ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
On Feb 2, 2010, at 13:18, Gaetan Nadon wrote: I have not seen any compelling reasons to turn off this optimization. Maybe 10 years ago when it was first introduced. I have seen reports of large number of warnings, but from older gcc versions. As it is today, we are losing some optimization that could be beneficial. This option has been there for so long (most likely copied along), I doubt you will will get a clear answer for each of the 240 xorg modules. It would take a few modules to try it out first. I see it in libX11 has historically used -fno-strict-aliasing: http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=db7c6fdeeaef9475458498e4cf09d6b1329e9aa3 but adding XORG_CWARNFLAGS to XORG_DEFAULT_OPTIONS has caused this to change for other modules. Looking at historic versions of modules, I see it present in: libICE libSM libX11 libXau libXfont libXft libXpm libXres xorg-server of course most of these seem to have just copied the entire GCC_WARNINGS block and probably didn't actually need -fno-strict-aliasing ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
On Tue, 2010-02-02 at 14:00 -0800, Jeremy Huddleston wrote: On Feb 2, 2010, at 13:18, Gaetan Nadon wrote: I have not seen any compelling reasons to turn off this optimization. Maybe 10 years ago when it was first introduced. I have seen reports of large number of warnings, but from older gcc versions. As it is today, we are losing some optimization that could be beneficial. This option has been there for so long (most likely copied along), I doubt you will will get a clear answer for each of the 240 xorg modules. It would take a few modules to try it out first. I see it in libX11 has historically used -fno-strict-aliasing: http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=db7c6fdeeaef9475458498e4cf09d6b1329e9aa3 but adding XORG_CWARNFLAGS to XORG_DEFAULT_OPTIONS has caused this to change for other modules. Looking at historic versions of modules, I see it present in: libICE libSM libX11 libXau libXfont libXft libXpm libXres xorg-server of course most of these seem to have just copied the entire GCC_WARNINGS block and probably didn't actually need -fno-strict-aliasing Of course. Whatever the reasons were, if anyone remembers, may not apply anymore. Devising a plan for it's removal will not be an easy task. I see 3 options: 1) take it out of macros, 1 patch 2) transfer it to all makefiles and then removing it gradually, that's 2*240 +1 patches 3) override in 'n' makefiles until proven safe. Then take it out macros. That's 2*n +1 patches. I am curious how you can about this. signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
On Feb 2, 2010, at 17:11, Gaetan Nadon wrote: On Tue, 2010-02-02 at 14:00 -0800, Jeremy Huddleston wrote: On Feb 2, 2010, at 13:18, Gaetan Nadon wrote: I have not seen any compelling reasons to turn off this optimization. Maybe 10 years ago when it was first introduced. I have seen reports of large number of warnings, but from older gcc versions. As it is today, we are losing some optimization that could be beneficial. This option has been there for so long (most likely copied along), I doubt you will will get a clear answer for each of the 240 xorg modules. It would take a few modules to try it out first. I see it in libX11 has historically used -fno-strict-aliasing: http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=db7c6fdeeaef9475458498e4cf09d6b1329e9aa3 but adding XORG_CWARNFLAGS to XORG_DEFAULT_OPTIONS has caused this to change for other modules. Looking at historic versions of modules, I see it present in: libICE libSM libX11 libXau libXfont libXft libXpm libXres xorg-server of course most of these seem to have just copied the entire GCC_WARNINGS block and probably didn't actually need -fno-strict-aliasing Of course. Whatever the reasons were, if anyone remembers, may not apply anymore. Devising a plan for it's removal will not be an easy task. I see 3 options: 1) take it out of macros, 1 patch I sent that patch already. 2) transfer it to all makefiles and then removing it gradually, that's 2*240 +1 patches I don't think that's wise. If anything, you should just put it in the ones where it was prior to XORG_CWARNFLAGS (the 9 mentioned above). That being said, I also enabled the warning which should mention when it discovers code sensitive to the -fstrict-aliasing optimization, and none of the libs in the list above spewed such a warning. 3) override in 'n' makefiles until proven safe. Then take it out macros. That's 2*n +1 patches. We could do that for the 9 modules above. I'm fairly confident that the libs don't need it, but I haven't rebuilt all of the server to be confident it doesn't spew any warnings about strict-aliasing. ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
On Tue, 2010-02-02 at 17:34 -0800, Jeremy Huddleston wrote: On Feb 2, 2010, at 17:11, Gaetan Nadon wrote: On Tue, 2010-02-02 at 14:00 -0800, Jeremy Huddleston wrote: On Feb 2, 2010, at 13:18, Gaetan Nadon wrote: I have not seen any compelling reasons to turn off this optimization. Maybe 10 years ago when it was first introduced. I have seen reports of large number of warnings, but from older gcc versions. As it is today, we are losing some optimization that could be beneficial. This option has been there for so long (most likely copied along), I doubt you will will get a clear answer for each of the 240 xorg modules. It would take a few modules to try it out first. I see it in libX11 has historically used -fno-strict-aliasing: http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=db7c6fdeeaef9475458498e4cf09d6b1329e9aa3 but adding XORG_CWARNFLAGS to XORG_DEFAULT_OPTIONS has caused this to change for other modules. Looking at historic versions of modules, I see it present in: libICE libSM libX11 libXau libXfont libXft libXpm libXres xorg-server of course most of these seem to have just copied the entire GCC_WARNINGS block and probably didn't actually need -fno-strict-aliasing Of course. Whatever the reasons were, if anyone remembers, may not apply anymore. Devising a plan for it's removal will not be an easy task. I see 3 options: 1) take it out of macros, 1 patch I sent that patch already. 2) transfer it to all makefiles and then removing it gradually, that's 2*240 +1 patches I don't think that's wise. If anything, you should just put it in the ones where it was prior to XORG_CWARNFLAGS (the 9 mentioned above). That being said, I also enabled the warning which should mention when it discovers code sensitive to the -fstrict-aliasing optimization, and none of the libs in the list above spewed such a warning. 3) override in 'n' makefiles until proven safe. Then take it out macros. That's 2*n +1 patches. We could do that for the 9 modules above. I'm fairly confident that the libs don't need it, but I haven't rebuilt all of the server to be confident it doesn't spew any warnings about strict-aliasing. Oh, just 9. It thought these were just examples and that there were many more. I noticed the patch later, sorry. I had a quick look in xserver and I saw some warnings, as expected. signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel