<!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 Thu, 2010-02-25 at 16:55 -0800, Keith Packard wrote: <BLOCKQUOTE TYPE=CITE> <PRE> On Thu, 25 Feb 2010 18:16:21 -0500, Gaetan Nadon <<A HREF="mailto:memsize@videotron.ca">memsize@videotron.ca</A>> 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. </PRE> </BLOCKQUOTE> 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. <BLOCKQUOTE TYPE=CITE> <PRE> > 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'. </PRE> </BLOCKQUOTE> LLVM release notes: <BLOCKQUOTE> <PRE> 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 <TT>-fno-strict-aliasing</TT> option). This problem probably cannot be fixed. </PRE> </BLOCKQUOTE> GNOME patch: <BLOCKQUOTE> <PRE> commit 53e0b83f80172a779e4972067c5e9a9c6b9c94c2 Author: Matthew Barnes <mbarnes@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. </PRE> </BLOCKQUOTE> Comments on performance: <A HREF="http://stackoverflow.com/questions/1225741/performance-impact-of-fno-strict-aliasing">http://stackoverflow.com/questions/1225741/performance-impact-of-fno-strict-aliasing</A> "Understanding Strict Aliasing" by Mike Acton: <A HREF="http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html">http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html</A> <BLOCKQUOTE TYPE=CITE> <PRE> > The legacy CWARNFLAGS would be left alone to handle previous versions of > xserver/libs... Yeah, probably forever too. </PRE> </BLOCKQUOTE> <PRE> Indeed </PRE> I'll submit a patch for the new macro definitions. Comments are welcome at anytime. Thanks </BODY> </HTML>