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
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
