[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