Re: type based aliasing again

[Mark Mitchell <mark@codesourcery.com>]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

    Richard> The goal of trying to avoid it is unrealistic and
    Richard> misguided; it can't be done.  So this cannot be a valid
    Richard> reason to reject a change.

You are right that it cannot be done.  However, it is good to strive
for things which are good, even if they are impossible to achieve.
(For example, we strive to make GCC a bug-free compiler, even though
that will never happen.)

You've chosen to respond to a long conversation all at once.  Let me
try to sum up the current state, as I see it:

  o We all agree that if it is technically feasible to warn about
    invalid code, we should.  It will be difficult to produce
    a useful warning, but, if someone can figure out how, I don't
    think there's any debate that this is worthwhile.  Even if
    there are some false positives.

  o Code which will "work" with the proposed change may (will) 
    break with future releases of GCC.  This will lead to worse
    headaches for users than the simple rule: don't treat memory
    as having multiple types, or else use -fno-strict-aliasing.
    Users will be particularly at risk because when the behavior
    gets worse (from their point of view) warnings will go away,
    not appear.

    Mark> The compiler should continue to aggressively break
    Mark> code that misbehaves in this way.

    Richard> This proposes to break users' code, just to bully them
    Richard> into changing it.  That is a callous and harsh attitude
    Richard> towards the users of GCC.  No wonder users are angry.
    Richard> They know that the problems are not due to necessity, but
    Richard> due to callous disregard for them.

That is a harsh statement, which I take personally.  I have
volunteered a lot of time and effort responding directly to users
needs and wishes.  You should not read intent into statements, without
asking the speaker to clarify first.  Please treat me with the same
respect I have shown Joe Buck and others who have raised this issue,
including those who have called me nasty names in the past.

There is no way that we can guarantee the long-term viability of this
variety of invalid code.  Seemingly minor changes to the compiler will
change the set of programs which "work", with your proposal.  Other
compilers are already doing these optimizations.  Thus, portable code,
including most GNU project code, simply must not contain these invalid
constructs.  I firmly belive that it is better for users to have a
simple, easy to follow guideline, than a shifting, confusing one.
Perhaps that is where you and I differ, but it does not imply that
either of us have disregard for users.

I have spent a good deal of time considering not only this proposal,
but many others that have appeared on this list.  Thus, I have
*reluctantly* concluded that there is no graceful failure mode.  Of
course, I am willing to be persuaded.

There is a lot of code out there that assumes bitfields are unsigned.
That's not always true; such code breaks in those situations.  Users
must know, when compiling such code, that they must specify
-funsigned-bitfields.  This situation is similar: users must know that
they must specify -fno-strict-aliasing when compiling these programs.

If we can figure out how to do the warning, we should; that's more
than we can offer in many other similar cases (like in the bitfield
case).

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