[PATCH xserver 1/3] config: add -fno-strict-aliasing now that it is out of $CWARNFLAGS

[Gaetan Nadon]

On Thu, 2010-02-25 at 16:55 -0800, Keith Packard wrote:

> On Thu, 25 Feb 2010 18:16:21 -0500, Gaetan Nadon <memsize at videotron.ca> wrote:
> 
> > Drivers and apps excluded? (or case by case)
> 
> Drivers are part of the server. I'd hope that we would have noticed if
> any of the apps are broken by now though.
> 
> > It's easy to add a variable, say $(PROJECT_CFLAGS) that is added in each
> > makefile. Ideally it would be empty, meaning there is no problem to
> > solve. If a new feature is implemented which causes several bugs, we can
> > turn it off by adding the appropriate option until it stabilizes and
> > then remove it.
> 
> Yeah, a global PROJECT_CFLAGS might be nice, just in case.
> > Macros:
> > XORG_PROJECT_CFLAGS which defines $(PROJECT_CFLAGS) variable
> > XORG_WARNING_CFLAGS which defines $(WARNING_CFLAGS) variable set to -W*
> > XORG_OPTIMIZATION_CFLAGS which defines $(OPTIMIZATION_CFLAGS) variable
> > set to -fno-strict-aliasing
> 
> Yeah, that should work; if someone has a better idea for names, please
> speak up though.
> 
> > Proposed content for makefiles where -fno-strict-aliasing is needed:
> > AM_CFLAGS = \
> >      $(PROJECT_CFLAGS) \
> >      $(WARNING_CFLAGS) \
> >      $(OPTIMIZATION_CFLAGS)
> > 
> > Proposed content for makefiles where -fno-strict-aliasing is *not*
> > needed:
> > AM_CFLAGS = \
> >      $(PROJECT_CFLAGS) \
> >      $(WARNING_CFLAGS)
> 
> I'm tempted to suggest that we just use $(OPTIMIZATION_CFLAGS)
> everywhere, or give it a name which reflects where it should be used
> instead of making people guess.
> 

Let's put it everywhere. It simplifies usage, we may need to add another
option in the future. If it ever gets fixable in a large portion of the
system, we can remove it from the macro and add it locally to a few
makefiles.

> > Let's rewrite history using these macros:
> > 
> > ~2005: gnu changes optimization that breaks a fair amount of code. The
> > -fno-strict-aliasing is added in XORG_PROJECT_CFLAGS which returns the
> > system to the previous state. Further investigation shows that it may
> > never be possible to change all the code, so a new
> > XORG_OPTIMIZATION_CFLAGS macro is created and becomes a permanent
> > solution for a large part of the system. The -fno-strict-aliasing option
> > is then removed from XORG_PROJECT_CFLAGS and ready for the next problem.
> > 
> > The word "WARNING" and OPTIMIZATION" are taken from the compiler options
> > category. There are many other categories like Debugging or Linker. By
> > naming the macro according to the category, we would never be in a
> > situation where we stick an optimization option in a warning macro. If
> > another optimization goes bad, it would go in XORG_OPTIMIZATION_CFLAGS
> > as well.
> 
> Ok, these descriptions make sense, but again, if we're doing this, we
> should use the flag everywhere. It's hard to imagine what code in X
> would actually benefit from the GCC 'improvements'.


LLVM release notes:


        The C back-end produces code that violates the ANSI C Type-Based Alias Analysis rules. 
        As such, special options may be necessary to compile the code 
        (for example, GCC requires the -fno-strict-aliasing option). 
        This problem probably cannot be fixed.


GNOME patch:


        commit 53e0b83f80172a779e4972067c5e9a9c6b9c94c2
        Author: Matthew Barnes <mbarnes at xxxxxxxxxx>
        Date: Tue Feb 2 12:27:38 2010 -0500
        
        Disable strict aliasing optimization.
        
        [...]
        
        GCC 4.4 got more aggressive in it's aliasing optimizations, changing
        behavior that -- according to the C99 standard -- is supposed to be
        undefined. We may still have aliasing abuses lying around that rely
        on GCC's previous "undefined" behavior but are hidden by type casts,
        so disable the strict-aliasing optimzation until GCC (or even LLVM)
        learns how to detect them and warn us about it.


Comments on performance:
http://stackoverflow.com/questions/1225741/performance-impact-of-fno-strict-aliasing

"Understanding Strict Aliasing" by Mike Acton:
http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html



> 
> > The legacy CWARNFLAGS would be left alone to handle previous versions of
> > xserver/libs...
> 
> Yeah, probably forever too.

Indeed


I'll submit a patch for the new macro definitions. Comments are welcome
at anytime.

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100226/95aeec5e/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/20100226/95aeec5e/attachment.pgp>