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

[Gaetan Nadon]

On Thu, 2010-02-25 at 10:57 -0800, Keith Packard wrote:

> Having this be consistent across all protocol libraries and server
> modules seems like a good idea, even if there aren't obvious bugs
> present now, 

Drivers and apps excluded? (or case by case)


> future changes in GCC may well cause old code to break in
> the future and we'll need a hook to make sure that we can apply
> options
> globally across the system.


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.

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

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)


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.

The legacy CWARNFLAGS would be left alone to handle previous versions of
xserver/libs...


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