[haiku-development] Disabling Strict Aliasing for GCC4 Builds
- From: "Michael Lotz" <mmlr@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 17 Apr 2008 22:36:06 +0200
Hi all
I have today (for reasons I don't really know anymore) read up on
strict aliasing as defined in C99. As possibly already seen gcc4 prints
many prominent messages during a gcc4 Haiku build ("dereferencing type-
punned pointer will break strict aliasing rules"). I'll just do a quick
example and will not try to explain aliasing in details as that is
covered in "http://en.wikipedia.org/wiki/Aliasing_(computing)" and the
external links for example.
As far as I've understood the subject (and I really hope I got it
right) the problem could be demonstrated by a code snippet:
double someDouble = 0.0;
int someInt = *(int *)&some;
The above code breaks strict aliasing rules because strict aliasing
rules mandate that a pointer to one type (&someDouble in this case)
does not alias (point to the same location in memory) as a pointer of
another type (the (int *) in the cast here). Obviously by doing this
kind of "conversion" there's a double and an integer pointer pointing
to the same location in memory which results in aliasing. When gcc is
used with strict aliasing (-fstrict-aliasing) which it is by default
for -O2, -O3 or -Os (us using -O2) then it will use the strict aliasing
rules to do optimizations. It could therefore optimize something with
the assumption of no aliasing being present. It could for example take
a certain value as constant because of the assumption that it cannot be
altered by writing to some pointer or it could do an operation purly in
registers without writing back to memory in between. In those cases
having an aliasing pointer which should not be there (breaking the
strict aliasing rules) and reading from it or writing to it will result
in undefined and possibly unexpected behaviour. In the above example it
is not really a problem and in many cases it won't be a problem that
generates unexpected code...
But as there are lots of those warnings in our case (and gcc doesn't
even guarantee that it will point out all instances of this problem)
I'd assume that at least a few of them point to actual problems.
Therefore these optimizations might result in unexpected behaviour at
some places and could introduce many subtle and hard to identify bugs
into gcc4 builds. When moving to gcc4 (assuming we want to take
advantage of those optimizations at all) we will probably have to
investigate each of these warnings and determine where there is a valid
concern and change the code accordingly. For the time being I suggest
we set "-fno-strict-aliasing" for gccs above 2 to rule out such
problems. I attached a diff to BuildSetup that would do just that.
I'd be interested in comments on that topic before applying anything
though. Is my understanding of the problem correct at all, do we care
about those optimizations and how would others suggest we move forward
with that?
Regards
Michael
Index: build/jam/BuildSetup
===================================================================
--- build/jam/BuildSetup (revision 25000)
+++ build/jam/BuildSetup (working copy)
@@ -156,6 +156,12 @@
HAIKU_GCC_BASE_FLAGS = -pipe ;
}
+# disable strict aliasing on anything newer than gcc 2 as it may lead to
unexpected results.
+# TODO: remove this when all code has been analized/fixed with regard to
aliasing.
+if $(HAIKU_GCC_VERSION[1]) >= 3 {
+ HAIKU_GCC_BASE_FLAGS += -fno-strict-aliasing ;
+}
+
# override gcc 2.95.3's header directory -- strictly necessary only when using
# the BeOS native compiler (since its headers are incompatible), but it doesn't
# harm for the cross-compiler either.
Other related posts:
