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

[Gaetan Nadon]

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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101101/31ab8c76/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101101/31ab8c76/attachment.pgp>