<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0"> </HEAD> <BODY> On Mon, 2010-11-01 at 12:33 -0700, Jeremy Huddleston wrote: <BLOCKQUOTE TYPE=CITE> <PRE> 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..." </PRE> </BLOCKQUOTE> Yes, contains only warning flags, nothing else. <BLOCKQUOTE TYPE=CITE> <PRE> XORG_CFLAGS_NO_STRICT_ALIASING would set CFLAGS_NO_STRICT_ALIASING="-fno-strict-aliasing" </PRE> </BLOCKQUOTE> It would be called CFLAGS_STRICT_ALIASING with -fstrict-aliasing, under an "opt-in" principle. <BLOCKQUOTE TYPE=CITE> <PRE> XORG_CWARNFLAGS would be updated to call these two and set CWARNFLAGS="$(CFLAGS_WARNINGS) $(CFLAGS_NO_STRICT_ALIASING)" </PRE> </BLOCKQUOTE> Nope. Our good old CWARNFLAGS would remain untouched for eternity and will eventually fall off the radar screen. <BLOCKQUOTE TYPE=CITE> <PRE> > 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. </PRE> </BLOCKQUOTE> Those modules would use the new CFLAGS_WARNINGS, and only this one. <BLOCKQUOTE TYPE=CITE> <PRE> 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. </PRE> </BLOCKQUOTE> Those modules would use both the new CFLAGS_WARNINGS and the new CFLAGS_STRICT_ALIASING, under an opt-in principle <BLOCKQUOTE TYPE=CITE> <PRE> > 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. </PRE> </BLOCKQUOTE> 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. </BODY> </HTML>