-fno-strict-aliasing in CWARNFLAGS?

Gaetan Nadon memsize at videotron.ca
Wed Feb 3 15:05:42 PST 2010


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.lists at 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 at lists.x.org
> > http://lists.x.org/mailman/listinfo/xorg-devel
> 
> _______________________________________________
> xorg-devel mailing list
> xorg-devel at lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.x.org/archives/xorg-devel/attachments/20100203/20d5c0f0/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-devel/attachments/20100203/20d5c0f0/attachment.pgp 


More information about the xorg-devel mailing list