From mboxrd@z Thu Jan  1 00:00:00 1970
From: craig@jcb-sc.com
To: dje@watson.ibm.com
Cc: craig@jcb-sc.com
Subject: Re: type based aliasing again
Date: Thu, 30 Sep 1999 18:02:00 -0000
Message-ID: <19990915063641.12930.qmail@deer>
References: <9909142205.AA26966@marc.watson.ibm.com>
X-SW-Source: 1999-09n/msg00584.html
Message-ID: <19990930180200.bewYBppDy7xY90U6Xl37Nd2XFY7Sgqfg92msJftZ6eA@z>

>>>>>> craig  writes:
>
>craig> (I won't even get into the stunning news that the FSF has reportedly
>craig> just changed the rules of the very difficult job of compiler development,
>craig> apparently *since* the EGCS team agreed to become GCC and under the
>craig> aegis of the FSF.)
>
>	How is asking that the compiler try to provide compatibility by
>default where it is easy, such as not coupling -fstrict-aliasing to a -O#
>level, an unreasonable and burdensome request?  This is a one-line change
>removing flag_strict_aliasing from optimize >= 2 stanza in toplev.c.  You
>are arguing against an interpretation of the request that takes it to an
>extreme, not the request itself. 
[and]
>	Of course my description is an over-simplification of the FSF's
>request.  The rest of your message describing that this is an impossible
>task to get every aspect right so GCC should ignore this requirement
>altogether is illogical and unhelpful.

I am arguing only against the statement you made about what the
FSF now requires of GCC.  You omitted that statement in the
quote.  That statement *clearly* suggested the FSF had recently
introduced additional requirements of GCC.

If you'd like to retract that statement, rather than criticize *me*
for calling attention to the ludicrousness of that statement,
I'd appreciate it if you'd do so.  I offered a gentle hint for you
to do so earlier, instead, you chose to attack me.

Pending that, I'm stunned by the complete lack of integrity you've
shown in trying to shift blame for your unnecessary over-simplification
to me.  That a GCC Steering Committee member would refer to my
entirely true statement as "illogical and unhelpful" is something
I find *extremely* disturbing, sufficient (especially in conjunction
with the *huge* waste of time this discussion has been to date, and
will continue to be, in various forms, until the end of time) to cause
me to question why I bother with *any* sort of GCC development,
especially in the form of offering my input.

The long and short of it is, regardless of whether *you* consider
your statement to have been "of course...an over-simplification",
*many* readers, and, frankly *too* many participants in this discussion,
did *not* recognize it as such, instead interpreting it as support
for their position to "fix" this "problem" in GCC.  I don't need
to identify any such people -- the length of the email discussion here,
and elsewhere, is sufficient to make the veracity of it clear
to those who are paying attention.

That's why I felt it necessary to *clearly* and *unambiguously* identify
the concept as you presented it as a ludicrous one for compiler developers
(or even most programmers, for that matter) to try and follow.

If you can't simply and directly communicate what the FSF, or any
other person, said, without over-simplifying in a way that *increases*
apparent support for your position, I suggest you stay out of these
discussions in the future.  Your demagoguery in this case was definitely
not appreciated by me.  If you have a problem with that, then I'll go
away and not bother this mailing list ever again.


As to your point that users expect -fno-alias-analysis not because
they ever read the standard but because that's how compilers used
to behave:

  Game.

  Set.

  Match.

In other words: RMS has said this wouldn't be interpreted as a "feature".
You've just contradicted that with your attempt to use history to
justify your agreement with his position.  So, as long as GCC tends
to make buggy code appear to work, there will always be the same
degree of justification to *continue* to do so.

If the GCC Steering Committee wishes to restore any sanity to this
situation, it should immediately declare the discussion over, and
the decision to be: use -fno-alias-analysis if your code might
not conform to the pertinent requirements of ISO C.

Period.

People who want warnings can get together and write software that
gives it to them, as I suggested, seemingly, weeks ago.

(I'm not holding my breath.  I'd much rather work on software that
actually implements the pertinent standards and specifications *correctly*,
than watch talented, enthusiastic people sap their energies in
largely irrelevant discussions like this.  That this whole thing
was recently started by RMS, who *should* have a better sense of
proportion vis-a-vis volunteer resources and undefined codes, and
who has veto power over the GCC Steering Committee, is very, very sad.)

        tq vm, (burley)