-fno-strict-aliasing in CWARNFLAGS?
jeremyhu at apple.com
Wed Feb 3 11:35:36 PST 2010
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:
xf86-* (somene else should check which ones traditionally had this
2) We should remove it from the CWARNFLAGS in util-macros (and turn on
3) We should "audit" the modules where we added it in #1 and slowly
remove it where safe.
On Feb 3, 2010, at 10:55, Soeren Sandmann wrote:
> Dan Nicholson <dbn.lists at gmail.com> writes:
>> Here's one link:
>>> 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.
> I recently turned it on in pixman because completely reasonable code
> like this:
> 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.
> xorg-devel mailing list
> xorg-devel at lists.x.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5820 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20100203/0b4bf57b/attachment.bin
More information about the xorg-devel