configure: Disable strict aliasing.
authorBen Pfaff <blp@nicira.com>
Wed, 1 Oct 2014 00:03:07 +0000 (17:03 -0700)
committerBen Pfaff <blp@nicira.com>
Wed, 1 Oct 2014 15:46:06 +0000 (08:46 -0700)
commit538919d3a672eab8a561048acf9a8e1721cd559c
tree63e273ba237f767738f5a1067c33c0346b7b48d0
parentd25e2f572b50c600dd38ec37fd1d70401c5d6990
configure: Disable strict aliasing.

The C standard allows compilers to do type-based alias analysis, which
means that the compiler is allowed to assume that pointers to objects of
different types are pointers to different objects.  For example, a compiler
may assume that "uint16_t *a" and "uint32_t *b" point to different and
nonoverlapping locations because the pointed-to types are different.  This
can lead to surprising "optimizations" with compilers that by default do
this kind of analysis, which includes GCC and Clang.

The one escape clause that the C standard gives us is that character types
must be assumed to alias any other object.  We've always tried to use this
escape clause to avoid problems with type-based alias analysis in the past.
I think that we should continue to try to do this in the future.  It's hard
to tell what compiler we might want to use in the future, and one never
knows what kind of control that compiler allows over alias analysis.

However, recently I helped another developer debug a nasty and confusing
issue, which turned out to be the result of a surprising compiler
optimization due to alias analysis.  I've seen enough of these that I don't
think it's worthwhile to risk more problems than we have to.  Thus, this
commit turns off type-based alias analysis in GCC and Clang.

Linus Torvalds thinks that type-base alias analysis is not sane, at least
as GCC implements it: https://lkml.org/lkml/2003/2/26/158

The GCC manual says that -Wstrict-aliasing is only effective without
-fno-strict-aliasing, otherwise I'd keep -Wstrict-aliasing also.

Indications are that MSVC doesn't do type-based alias analysis by default.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
configure.ac