[PATCH util-macros 1/2] Don't disable strict aliasing (-fno-strict-aliasing) globally

Patrick Horgan phorgan1 at yahoo.com
Tue Nov 2 16:55:13 PDT 2010


On 11/01/2010 12:18 AM, Michel Dänzer wrote:
> On Son, 2010-10-31 at 15:54 -0700, Jeremy Huddleston wrote:
>> Resurrecting this thread as I just realized it was never actually fixed.
>>
>> I propose we actually follow up on these changes. We should remove
>> -fno-strict-aliasing from XORG_CWARNFLAGS and only add them to the
>> modules that actually require it. We can start out consercatively by
>> adding it to the modules listed in the email below (as well as the
>> xf86-* drivers that historically had the flag which I didn't check at
>> the time of the first email... I know intel needs it)
> I still haven't seen any measurements showing any benefits from making
> this change. Are there any?
-fno-strict-aliasing disables a whole class of 
optimizations in gcc which means that not only do you 
lose the benefit of what they do today, but any future 
optimizations as well.

The converse is the problem with ignoring 
strict-aliasing warnings, because even if gcc generates 
correct code today, they are warning you that in the 
presence of optimization they might not generate 
correct code in the future.

All such cases have fixes without having to turn on 
no-strict-aliasing.  To see an example of where gcc 
would generate incorrect code today after warning, and 
the fix for it, you can look at the section on strict 
aliasing in the boost warning doc.

https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines

  It also shows that programming in a way that doesn't 
generate the warnings give C/C++ more information about 
the code that it uses to generate better assembler.  
(Disclosure: Of course I think it's great since I wrote 
it.)

Patrick


More information about the xorg-devel mailing list