Re: type based aliasing again

[Richard Stallman <rms at gnu dot org>]

    >I say we should keep user code found in real programs working, as long
    >as that is easy to do.  Sometimes it is necessary or important to
    >break code people use, and then it's worth doing so.  But when we have
    >an easy and painless way to keep certain code working, then breaking
    >it is not necessary or important, so we shouldn't.

    I don't really disagree with this.  The "easy to do" part is important.

It is beyond important, it is the point of the idea.  That is where
this alternative differs from the others that people have been
considering.

    I want to emphasize that "easy to do", in RMS's terms, means to me
    that the compiler should *itself* never make this assessment.  It should
    be made only by compiler writers, based on a cursory examination.

That's what I have in mind, too.  The thing that might or might not
be "easy to do" is the *change* in GCC, that people could write.

    It is so difficult to explain this so users don't misunderstand this
    as some sort of promise for a long-term accommodation of certain sorts
    of broken code, that I don't suggest we do it in anything that appears
    to be user documentation.

That's what I have in mind, too.

It looks like people have until now rejected consideration of all but
these two alternatives:

1. Document these cases as a feature, and keep it working
come hell or high water.

2. Make absolutely no effort to keep these cases working.

These are two extremes in a continuum.  If we really had only these
two choices, #2 would be better, for the reasons others have given.
But if we admit the intermediate possibilities, we can usually find
one that is better than either extreme:

3. Make a little effort to keep these cases working today.

Actually, in some sense #2 is not the ultimate extreme.  We could go
even further:

4. Make damned sure these cases will not behave as expected.

This would be a subcase of the -fconfound-me option you proposed.  I
mention it to show how #2 is different from this--and what that
implies.

Some people argue that users will "get the wrong ideas" if any of
these cases do work.  Well, if that is possible, it is happening now,
because some of these cases do work.  With -O0, they all work.  Unless
we do #4, some of them will always work.


I'm not the GCC maintainer any more, and I don't have time to get
involved in more than a handful of the technical decisions about GCC,
even if I wanted to.  This particular issue is important because many
users are unhappy with it.  But there's a bigger question at stake:
what is the right basis for making such decisions about GCC?  That
question is crucial for this issue now, and will be crucial for other
issues in the future.

To do a good job, we must consider option #3.  On some issues, there
will be a good way to use option #3; on others, there won't be.  But
if we don't use it when there is a way, we will make GCC a harsh
compiler.  Please, always consider option #3.