Re: type based aliasing again

[Joe Buck <jbuck at synopsys dot COM>]

> One of your assumptions is that the only times we ask `does x alias y'
> are when it is sensible to do so. :-)  We likely do so at other times
> as well; I didn't point this out, but should have.  Consider:
> 
>   void *v = malloc (4);
>   if (p)
>     * ((float *) v) = 3;
>   else
>     * ((int *) v) = 7;
> 
> This code is conforming.  I don't mind terribly if we warn on this
> code; I bet the number of false positives will be small.  But, we
> shouldn't force the compiler to go slower in this case.  

I guess I am missing something in this example.  Could you explain
why we would get a warning?  The accesses are legal.  Yes, if you
check whether the two assignments alias there would be the possibility
of a false warning if you aren't careful.

> You asked users with nonconformant code whether local analysis would
> spot the bugs.  In some cases it will.  In others, it won't.  In some,
> it will depend on what the compiler does.  For example, does it inline
> some function?  If so, more things become local.  So, now you have
> programs that might work with -O3 but might break with -O2.

But this is just the reverse of what happens now; since -O2 will do
more reordering than -O, we already have programs that work with -O
and don't work with -O2 because of type-based aliasing.

> Saying "Don't violate ANSI/ISO aliasing rules, or else use
> -fno-strict-aliasing" is a simple, easy-to-follow rule.  I don't think
> we should muddy that with confusing semantics depending on GCC
> internals.

I don't disagree.  You see, my code is silent in the presence of -Wall,
so in that sense the choice of A vs B would be a no-op for me; either
way, I would find and fix the aliasing bug.  If we issue a warning,
and the users never bother to clean up the warning, it is the user's
loss when the code later breaks.

So, if I can only have your amended proposal, I suppose I'll take it.
It's better than nothing.