Linux and aliasing?

Tim Hollebeek tim@franck.Princeton.EDU
Wed Jun 30 15:43:00 GMT 1999


Jason Merrill writes ...
> 
> It seems to me that this issue is broader than the kernel; any code that
> uses casts to, say, get at the bitwise representation of a floating point
> value is likely to break.  This seems like a very unfortunate state of
> affairs, because this sort of failure is inherently hard to track down.  We
> can't just silently emit bad code and say that the standard allows us to do
> that; as Linus says, it's a QOI issue.
> 
> One simple and safe solution would be to turn off -fstrict-aliasing in any
> function which contains a pointer cast (reinterpret_casts only in C++),
> along with a warning.  Power users could override this behavior with a flag.

No, this is not a simple and safe solution.  Simply because it doesn't work.

Consider:

extern int *get_representation(float *);

float fiddle() {
    float d = 3.14159;
    int *s;

    s = get_representation(&d); /* Look, Ma, no casts! */
    (*s) |= 0x00300;
    return d; /* oops! */
}

-fno-strict-aliasing is the only safe solution, if you want to
guarantee this definition of "bad" code never occurs.  Sure, there are
cases where you can prove pointer aliasing can't happen, but then we
don't need the ANSI rules at all anyway!

The interesting case is where the ANSI rules say something can't be
aliased, but it is impossible or very hard for gcc to say whether this
assertion is correct or not (the above case falls in the impossible
category).  If you want to be safe, -fno-strict-aliasing is the
solution.  But when it's on, you can't warn about such pointer stores
since you'd have to warn about any store you can't prove points to an
object of the same type.  Requires data flow -> zillions of false
positives.

-Tim



More information about the Gcc mailing list