On Wed, 24 Feb 2010 08:45:50 -0500, Gaetan Nadon <[email protected]> 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. -- [email protected]
pgpUpFYBnYOH3.pgp
Description: PGP signature
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
