Linux and aliasing?

Andi Kleen
Sat Jun 5 06:23:00 GMT 1999

On Sat, Jun 05, 1999 at 02:37:20PM +0200, Toon Moene wrote:
> Ah, yes, but the discussion is whether we should have gcc generate
> "reasonable" behaviour where "reasonable" is defined by a small group of
> users.  Note that all "behaviours" not explicitly required by the
> Standard are prone to:

Generating faulty code is in my book always unreasonable, even when
the source is not strictly conforming (and the compiler has a realistic
chance to detect it).  

The argument that it may inhibit some optimizations for strictly conforming 
programs I also cannot follow. As I understand it there are basically two 

1. One casts a pointer to a object to some other non-char pointer and doesn't
access it. This is although strictly conforming rather useless, and should
be optimized away anyways. This case is not interesting.

2. One casts a pointer to a object to some other non-char pointer, and 
uses the new pointer to access the object. The standard says that is undefined.
Strictly conforming programs cannot do that. Currently gcc generates code
for it that most likely will result in a bug in the program. The casting
proposal turns the "wrong code" interpretation of undefined into something
that has a good chance to make a lot of old programs work again. 

Because case (1) is not interesting (it is a noop) I don't think worrying
about missing optimizations in noops is a good use of one's time.

Now of course I agree that it is a good idea to convert the code in the
long run to be strict-aliasing safe, simply to give the optimizer more
information. For some projects like Linux it is although a long and 
difficult way. I think the best compromise would be to turn -fstrict-aliasing
off per default (like what is already proposed) and to offer a new
-flose-aliasing switch that turns the "turn off alias analysis for casts"

I'm playing a bit with a patch that just implements that and and works in a 
similar way as Linus outlined. I am not sure if it is worth to try to detect
the case (1) (casting but result is not directly accessed), or to simply
set the alias set to 0 for a pointer cast. I think it is not.

Mark, even when you don't like it, would you as alias-expert-in-residence
think that the basic strategy is workable?

> 1. Erosion (within a decade, gcc maintainers forget why we did this in
>    the first place: "Hey, look at this code - what hair - and it is
>    undefined behaviour according to the Standard in the first place;
>    rip it out")

If it is clearly documented that will not happen.

> 2. Contradiction (the C0X Standard defines the previously undefined
>    behaviour, but in a way incompatible with the "reasonable" behaviour
>    we thought up here).

I don't think that such a vague possibility should guide a gcc design 
decision ("in 30 years an asteroid may crash onto earth and ruin your 
whole day - don't implement it because the exception handlers don't handle 
that event") Also there is no cue in the future directions that that may 
happen. In any case it wouldn't strike me as a strong enough argument
to suppress a useful feature.

> Cheers,
> [In 24 hours I'm off for my first X3J3 meeting - it shows, doesn't it?]



This is like TV. I don't like TV.

More information about the Gcc mailing list