On Mon, 2010-11-01 at 12:33 -0700, Jeremy Huddleston wrote: > 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..."
Yes, contains only warning flags, nothing else. > XORG_CFLAGS_NO_STRICT_ALIASING would set > CFLAGS_NO_STRICT_ALIASING="-fno-strict-aliasing" It would be called CFLAGS_STRICT_ALIASING with -fstrict-aliasing, under an "opt-in" principle. > XORG_CWARNFLAGS would be updated to call these two and set > CWARNFLAGS="$(CFLAGS_WARNINGS) $(CFLAGS_NO_STRICT_ALIASING)" Nope. Our good old CWARNFLAGS would remain untouched for eternity and will eventually fall off the radar screen. > > > 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. Those modules would use the new CFLAGS_WARNINGS, and only this one. > > 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. Those modules would use both the new CFLAGS_WARNINGS and the new CFLAGS_STRICT_ALIASING, under an opt-in principle > > > > 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. > > I could produce a patch for util-macros + server + some module that don't need aliasing as a better illustration. The end result is that it will look as if the CWARNFLAGS saga had never happened. We don't want to drag it forever.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
