-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