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

[Keith Packard]

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 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'.

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

Yeah, probably forever too.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100225/63f1b423/attachment.pgp>