Re: type based aliasing again

[Marc Lehmann <marc@gimp.org>]

On Fri, Sep 10, 1999 at 02:34:28AM -0400, Richard Stallman <rms@gnu.org> wrote:
>     The compiler should continue to aggressively break code that
>     misbehaves in this way.
> 
> This proposes to break users' code, just to bully them into changing
> it.  That is a callous and harsh attitude towards the users of GCC.
> No wonder users are angry.  They know that the problems are not due to
> necessity, but due to callous disregard for them.

This is a view of the problem that isn't really correct. Gcc is generally
trying to be helpful for users to write portable code (portable even among
gcc versions).

Agressively breaking code actually helps. It's like compiling abort() into a
program where it stumbles into undefined behaviour - it helps the user to
catch the error as early as possible.

Trying to preserve invalid code just because the compiler can do it in most
cases will result in a much larger disaster for future revisions, when the
compiler might just optimize the program away for _valid_ reasons.

If gcc had broken that program early on (because is was invalid) the error
would have been fixed earlier. "Aggressively breaking code" just means
"try to behave as close as possible to future versions".

Viable solutions for aliasing problems are:

- try to spit out warnings, wherever possible. Do not try to salvage invalid
  programs, though.
- for old code use the corresponding compiler flag.

> This treatment of users brings shame on the GNU Project.

To the contrary, it will help the users to write better programs that have a
lower chance to break in the future. If they don't want to they can switch of
aliasing assumptions in the compiler.

What's needed is documentation (e.g. the FAQ entry for that).

On Fri, Sep 10, 1999 at 02:34:30AM -0400, Richard Stallman <rms@gnu.org> wrote:
> I am not proposing this as a feature, just as a way to avoid evitable
> trouble for users.  We should not even try to document a class of
> cases that are "supposed" to work, because I'm not saying these
> are "supposed" to work.  We should just let them work.

In other words: "hey, people, this happens to work, but it will most
certainly not work with any other compiler, nor with future releases of
gcc. It's also impossible to tell you what may break or what may survive at
the moment."

Trying to spit out warnings is the way to go. Trying to salvage programs
that will definitely break at some later date is not useful. We could
just as well say "well, you can always store and calulcate years with two
digits only, but be advised that might not work for some cases".

> support.  We must not let ourselves start thinking that C code is
> "wrong", just because it is not conforming ISO C code.

However, the ISO C *defines* what is C. Not more and not less.

We can opt to *implement* our own version of C, and we can even call it
"C" (as we did), but failing to *define* its semantics is not going to
help anybody.

A language with unclear semantics (or semantics that will change with
compiler revisions) is not of practical use, IMHO.

All this, however, does not say we should try to aggressively warn people
about their code.

> C programs use many cases that are not conforming, but do work.

Now, and on this platform. If gcc would only available for, say, x86, we
could go on with that. But I conjecture that many of these "invalid but
works" programs will deifnitely break with gcc on some current or future
architecture.

IA64 was mentioned, for example. There it is of paramount importance to
aggressively optimize - otherwise performance will be unusable. So this
might mean, in the not-so-far-future "your programs works fine, except on
Merced or the E2k".

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |