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-serverxf86-* (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/158Traditionally, -fno-strict-aliasing was definitely necessary for the Xserver 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=394311I 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
