-fno-strict-aliasing in CWARNFLAGS?

[Jeremy Huddleston]

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5820 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20100203/0b4bf57b/attachment.bin