[mjbedy@mtu.edu: Re: type based aliasing again]

[craig AT jcb-sc dot com]

>  Can you relay the message I just sent you to the gcc list? Some Nazi
>RBL has decided that the mail server at school is unacceptable. Since
>this afternoon, apparently...

------- Start of forwarded message -------
X-Authentication-Warning: tamarack.cs.mtu.edu: mjbedy owned process doing -bs
Date: Thu, 16 Sep 1999 02:45:35 -0400 (EDT)
From: "Michael J. Bedy" <mjbedy@mtu.edu>
X-Sender: mjbedy@tamarack.cs.mtu.edu
To: craig@jcb-sc.com
cc: gcc@gcc.gnu.org, rms@gnu.org
Subject: Re: type based aliasing again
In-Reply-To: <19990915212407.16268.qmail@deer>
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: fc349364129d0bf55e30de62e0b1c2bb



On 15 Sep 1999 craig@jcb-sc.com wrote:

> >Unfortunatly, it seems that one of
> >the worst traits of the community is a rather cavilier attitude towards
> >backward compatability. 
> 
> My concern remains: to the extent we spend time trying to accommodate
> people who write, and refuse to maintain yet continue to distribute,
> *broken* code, we do a *worse* job providing true backwards
> compatibility, among many other things that *are*, properly, the job
> of GCC (as well as other free-software components) to provide.
> 
> However, *in* context, that sentence could be interpreted to suggest
> that GCC defaulting to -fno-alias-analysis would constitute
> backwards compatibility.

  Yes, but that is not what that sentence is supposed to mean in context,
and I'm fairly sure that was clear in my previous e-mail.

> And the whole point some people (like RMS) have been trying to make
> is that we should *not* think of this as a "feature".
> 
> If it's not a feature, then backwards compatibility is not an issue.

  I believe the above sentence is untrue. The behaviour of the compiler
has changed, reguardless of any lables we might throw on the situation.
This change is a positive one, as it can result in better code. Therefore,
we want to keep this change. -fno-strict-aliasing should NOT be the
default for this reason.

  However, this change is one that can affect the correctness of the users
code. If we can warn the user by writing a reasonable amount of code then
it seems to be the "nice" thing to do. Even if we can't catch all
occurances (as is mentioned earlier in this thread), the ones we can catch
may be quite a help to the user. 

  The assembly thing (which I don't 100% understand - I have no need to
use it so I don't completely know the issue) is a good example, I think.
The behavior of the compiler was deliberatly changed. I don't care about
what the documentation said, or who was broken before, or any of that. The
fact is that code that used to work began (as I understand it) to fail
silently. This is bad, even if it IS in an FAQ somewhere. Now a warning
has been added. So the change, which is a positive one, gets to stay, but
the user gets fair warning from the compiler.

  Perhaps a recent example from my own experiance will shed light on why I
feel this way.

  As I mentioned in my previous e-mail, I am a grad student writing a
thesis having to do with compilers. I was handed the sources to the
research compiler that is used around here. As research software tends to
be, it is an enourmous pile of rickety code that has been modified by so
many people that nobody knows what the hell is going on in a lot of it. In
this case, it is written in fairly old (5-6 years) C++.

  I compiled myself up gcc 2.95.1+libg++ (it needs libg++), and set about
compiling it on my Linux box. Well, it turns out that export is a C++
keyword, and gcc complained harshly about several variables in the source
that were named "export." Since the compiler barfed on the use of this
word, I was easily able to change them to "rexport", or something of that
sort.

  Now imagine that this export thing, instead of spewing an error,
silently went on to miscompile the code. (I know it couldn't in this case,
but pretend.) I had no clue, previous to this, that there were variables
named export in the source. I would have absolutly no clue what was going
on in the bowls of this thing to cause me to get 2+6=-421 or something
stupid like that. But, as a user, since the compiler warned me I had
absolutely no problems with changing the code to suit the compiler better.

  It is unfortuante that it is immpossile to spew a warning on every
instance of the alias problem, but I think it is necessary to provide a
warning when we can do so with a minimum of effort.

> 
> >  In short, and in general, I think it is good policy to, if possible,
> >include a warning whenever the behaviour of the compiler changes. I think
> >the worst solution possible is the current silent corruption that is
> >currently default in gcc.
> 
> We *did* issue a warning.  It's in the FAQ and elsewhere in the docs.
> 

   See above.


> It's also in the fact that *every* new release of a compiler is likely
> to change its behavior vis-a-vis a previous release.  Generally, that
> is the whole *point* of a new release.  The question of "what changes
> to behavior are acceptable and what are not" is not as "obvious" as
> you might think, else we wouldn't be having these discussions.
> 
> And there is no current silent corruption that is default in GCC
> as pertains this thread.  If you believe that, you were misinformed,
> and should abstain from repeating this misinformation in any other
> forum in the future.
> 

   ? Please explain? I thought the whole point of this thread is the
effect that alias analysis has had on Linux, god knows what else, etc. I
though the effect was "incorrect" code (code that does not run as
intended) generated by gcc since it assumed that ANSI rules were being
followed by the source. Maybe silent corruption was a bad choice of words,
and "incorrect" code (including the quotes) is a better one.


> The whole problem here is simply one of miseducation, or ignorance,
> on the part of people who think they know what GCC is.  We need not
> change one line of code to fix *that* problem, and if we don't
> fix that problem, rewriting GCC from scratch will not fix it either.
> Certainly changing a few lines will have no worthwhile overall effect.
> 

  Ok. What is GCC? Gcc to me is the free/opensource/whatever compiler
maintain by the GCC team, which is an absolutly essentail part of the free
software movement. I'm not sure what this has to do with the discussion at
hand.

>         tq vm, (burley)
> 
------- End of forwarded message -------