[haiku-development] Re: Disabling Strict Aliasing for GCC4 Builds
- From: "Duane Ryan" <bailey.d.r@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 17 Apr 2008 16:50:06 -0400
Well, in general it's good coding to follow strict aliasing. In conjunction
with the restrict keyword, this can result in a) more stable code, and b)
faster code, because the compiler doesn't have to worry about potential
aliasing.
How about this: is there any reason why we SHOULD allow potential aliasing?
Also, for more information, see here:
http://www.cellperformance.com/mike_acton/2006/05/demystifying_the_restrict_keyw.html
On Thu, Apr 17, 2008 at 4:36 PM, Michael Lotz <mmlr@xxxxxxxx> wrote:
> 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)<http://en.wikipedia.org/wiki/Aliasing_%28computing%29>"
> 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
>
Other related posts:
