Re: type based aliasing again

[Joe Buck <jbuck@synopsys.COM>]

>     Joe> The change is simply to postpone the type-based check until
>     Joe> after the other analysis is done.  If we detect that the
>     Joe> references collide, but the types say that we can assume they
>     Joe> don't, we issue a warning and then tell the compiler that
>     Joe> there is aliasing.  (A variant is to silently accept the
>     Joe> code, but I would prefer issuing a warning).  If we fall into
>     Joe> the "maybe" case, we assume no aliasing if the types don't
>     Joe> match.

Mark Mitchell writes:
> I'd thought vaguely about this alternative in the past.  It is indeed
> technically feasible.
> 
> However, I have a rather serious objection: it means that users cannot
> tell whether their code is valid, even according to the GCC rules,
> without knowing the internals of the compiler.

This is only true if we say that code for which we issue the warning is
valid under the GCC rules.  We could just as well say that it is *invalid*
and we are issuing the warning to help the user.  So I don't see how
doing this could cause any harm.  Yes, we won't catch all cases, but
we'll be educating users.  They'll see the warning occasionally, ask
about it, and learn.

> However, I do think this might be a good way to get useful warnings.
> So, I would amend your proposal to "issue a warning and then tell the
> compiler that there is no aliasing."  This would make it easier for
> users to tell that there is a problem, which would indeed be a major
> benefit.

This is fine with me, in fact that is really what I am proposing. (RMS
might have wanted to just accept it, but he said that a warning would
be OK with him).

> The compiler should continue to aggressively break code that
> misbehaves in this way.

This is a philosophical issue.  If you change "break" to "warn about"
I could go along, but some users may be depending on code that they
cannot fix immediately.