<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0"> </HEAD> <BODY> On Wed, 2010-02-03 at 11:35 -0800, Jeremy Huddleston wrote: <BLOCKQUOTE TYPE=CITE> <PRE> 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 </PRE> </BLOCKQUOTE> I think this wikipedia article says it all: <A HREF="http://en.wikipedia.org/wiki/Aliasing_(computing)">http://en.wikipedia.org/wiki/Aliasing_(computing)</A> 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 <BLOCKQUOTE TYPE=CITE> <PRE> On Feb 3, 2010, at 10:55, Soeren Sandmann wrote: > Dan Nicholson <<A HREF="mailto:dbn.lists@gmail.com">dbn.lists@gmail.com</A>> writes: > >> Here's one link: >> >> <A HREF="http://lkml.org/lkml/2003/2/26/158">http://lkml.org/lkml/2003/2/26/158</A> >> >>> 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. >> >> <A HREF="https://bugs.freedesktop.org/show_bug.cgi?id=6046">https://bugs.freedesktop.org/show_bug.cgi?id=6046</A> >> <A HREF="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394311">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394311</A> > > 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 > <A HREF="mailto:xorg-devel@lists.x.org">xorg-devel@lists.x.org</A> > <A HREF="http://lists.x.org/mailman/listinfo/xorg-devel">http://lists.x.org/mailman/listinfo/xorg-devel</A> _______________________________________________ xorg-devel mailing list <A HREF="mailto:xorg-devel@lists.x.org">xorg-devel@lists.x.org</A> <A HREF="http://lists.x.org/mailman/listinfo/xorg-devel">http://lists.x.org/mailman/listinfo/xorg-devel</A> </PRE> </BLOCKQUOTE> </BODY> </HTML>