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

Jeremy Huddleston jeremyhu at apple.com
Mon Nov 1 12:33:58 PDT 2010


On Nov 1, 2010, at 05:48, Gaetan Nadon wrote:

> On Mon, 2010-11-01 at 11:32 +0100, Mark Kettenis wrote:
> 
>> I may be somewhat overcautious, but I would keep -fno-strict-aliasing
>> as a default.  And I'd only enable -fstrict-aliasing for particular
>> bits of code where it has a significant performance benefit, and
>> people have done a careful analysis of the code to see if it is free
>> of aliasing issues.
> 
> 
> The cautious approach is the only one that will get consensus.
> Here is a proposal:
> 
> 
>     1. Separate the aliasing flag from the warning flags as outlined in
>        a previous post. This is prep work, status quo is preserved. In
>        addition it prevents adding aliasing flag to modules that
>        currently don't have it without their knowledge or consent.

So we would create two new macros:

XORG_CFLAGS_WARNINGS would set CFLAGS_WARNINGS="-Wall -Wformat -W..."
XORG_CFLAGS_NO_STRICT_ALIASING would set CFLAGS_NO_STRICT_ALIASING="-fno-strict-aliasing"
XORG_CWARNFLAGS would be updated to call these two and set CWARNFLAGS="$(CFLAGS_WARNINGS) $(CFLAGS_NO_STRICT_ALIASING)"

>     2. On a per module basis, remove the no aliasing option where there
>        is a technical agreement.

For modules that never had the flag historically, we'll update it from CWARNFLAGS to CFLAGS_WARNINGS and bump the required util-macros.

For modules that did have it historically, we'll leave them alone initially.  As we audit them, we'll change CWARNFLAGS to either CFLAGS_WARNINGS or CFLAGS_WARNINGS CFLAGS_NO_STRICT_ALIASI.  This will help us keep track of what has been audited to determine what really needs the flag versus what might've inherited it by accident.


> so we don't have both -fno-strict-aliasing and -fstrict-aliasing on the
> same gcc command. Also note that not all modules have CWARNFLAGS in
> their Makefiles.
> 
> This preserves backward compatibility as CWARNFLAGS remains intact for
> previous versions of the modules.




More information about the xorg-devel mailing list