Re: type based aliasing again

[Mark Mitchell <mark@codesourcery.com>]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.COM> writes:

    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.

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.  (It's dependent on
what the compiler can figure out about two addresses aliasing.  If the
compiler gets dumber, code breaks.  The compiler shouldn't get dumber,
in general, but it might in certain situations, while getting smarter
in others.  For example, if we replace some optimization algorithm
with another, we might do better in the average case, but worse in
some particular case.  Things that we used to know aliased we're now
not sure about.  Programs break.)

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.

The compiler should continue to aggressively break code that
misbehaves in this way.  Because we cannot (for technical reasons)
guarantee behavior in the future, we should break programs now; that
will make for fewer surprises down the road.

Coding like this is really no different than, say, assuming that you
call a varargs function without a prototype in sight.  It used to work
on most systems, and it still works on some.  But, it's not portable,
and people shouldn't do it.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com