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

[Keith Packard]

On Wed, 24 Feb 2010 08:45:50 -0500, Gaetan Nadon <memsize at videotron.ca> wrote:

> The problem I want to solve is the following: someone added
> -fnostrict-aliasing a long time ago and I don't know why. Then it got
> copied to a number of libraries, then got included in a macro
> (XORG_CWARNFLAGS), which then got included by over a hundred modules,
> still not knowing why.

-fno-strict-aliasing allows us to cast pointers around and have the
compiler treat them as potentially pointing to the same object (which
they often do). This is a huge semantic change in the compiler which can
affect code in very subtle ways, especially when code casts pointers
between different data types.

I can't see any way we could ever enable this optimization in our code
base, given what the code does. ANSI-C arbitrarily changed the rules
here, potentially breaking all existing applications. It's just a bad
decision from a standards committee. Fortunately, we can still get the
original behaviour.

Note that the Linux kernel *always* uses the -fno-strict-aliasing
option.
 
> There are over 50 modules that are compiling with no warning flags at
> all. I don't want to contribute to the spread of this option. The patch
> is about *transferring* the option out of the macro back to the modules
> (where the skills are) and let them decide if they want that option or
> not.

Nope. The modules do not know what various macros they're using do, nor
will they work correctly without this option if they adopt code from
other parts of the system.

All parts of the X server, including drivers, (and probably the protocol
libraries) should be compiled with -fno-strict-aliasing and there should
be no way to turn it off.

-- 
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/20100224/8712cd22/attachment.pgp>