Re: -fno-strict-aliasing in CWARNFLAGS?

2010-02-03 Thread Michel Dänzer 
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?

2010-02-03 Thread Michel Dänzer 
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-02-03 Thread Dan Nicholson 
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-02-03 Thread Dan Nicholson 
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?

2010-02-03 Thread Jeremy Huddleston 

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?

2010-02-03 Thread Peter Harris 
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?

2010-02-03 Thread Michael Cree 
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?

2010-02-03 Thread Gaetan Nadon 
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?

2010-02-03 Thread Soeren Sandmann 
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?

2010-02-03 Thread Michael Cree 
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

Re: -fno-strict-aliasing in CWARNFLAGS?

2010-02-02 Thread Gaetan Nadon 
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?

2010-02-02 Thread Jeremy Huddleston 

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?

2010-02-02 Thread Gaetan Nadon 
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?

2010-02-02 Thread Jeremy Huddleston 

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?

2010-02-02 Thread Gaetan Nadon 
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