On Feb 24, 2010, at 05:45, Gaetan Nadon wrote: > On Wed, 2010-02-24 at 09:34 +0100, Michel Dänzer wrote: > >> On Tue, 2010-02-23 at 11:11 -0800, Jeremy Huddleston wrote: >>> On Feb 23, 2010, at 11:07, Keith Packard wrote: >>> >>>> On Tue, 23 Feb 2010 13:37:18 -0500, Gaetan Nadon >>>> <[email protected]> wrote: >>>> >>>>> This patch will ensure the xserver continues to suppress the >>>>> optimization, based on strict aliasing rules, after the option >>>>> is removed from $CWARNFLAGS. There is no change in the object >>>>> code produced. >>>> >>>> I don't think we need to allow any of the code in the X server to be >>>> 'optimized' in this fashion, so I don't see a need to allow for >>>> per-directory selection. >>> >>> It would be helpful if I had the option to remove this flag from >>> XQuartz. >> >> Out of curiosity, what significant benefit have you measured from using >> -fstrict-aliasing? >> >> > > Excellent question which I carefully want to avoid :-) > > The problem I want to solve is the following: someone added > -fnostrict-aliasing a long time ago and I don't know why. Then it got > copied to a number of libraries, then got included in a macro > (XORG_CWARNFLAGS), which then got included by over a hundred modules, > still not knowing why. > > There are over 50 modules that are compiling with no warning flags at > all. I don't want to contribute to the spread of this option. The patch > is about *transferring* the option out of the macro back to the modules > (where the skills are) and let them decide if they want that option or > not.
Additionally, before being copied into XORG_CWARNFLAGS fairly recently, this was only in a handful of modules: libICE libSM libX11 libXau libXfont libXft libXpm libXres xorg-server (I didn't check xf86-drivers) So adding it across the board is rather far-reaching, IMO. I believe it should only be added back to the modules listed above.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
