Re: type based aliasing again

[craig at jcb-sc dot com]

>	The FSF has stated, only just recently, that not breaking existing
>programs because of undefined behavior is a goal that GCC should try to
>meet.  Removing -fstrict-aliasing is a simple change that will meet this
>goal and not dimish the functionality of this optimization for those who
>want to invoke it explicitly.

I really, really doubt that removing -fstrict-aliasing is the only
change needed that will meet this goal.

I suggest the FSF, and all others who support this interpretation,
read every line of the C, C++, and Fortran standards (just for
starters), highlight every effective denotation of something the
user's code plus data can do as "undefined", and research thoroughly
what it'll take to make GCC not "break" these programs.  Division by
zero?  Square root of negative number?  Dereferencing a NULL pointer?
How about when the result isn't used?  How about writing via a NULL
pointer but never trying to read the result back?  These are all
undefined, in one language or another, and GCC will, by one
definition or another, break existing code that invokes these
undefined behaviors.

(Having spent many years now as a compiler developer, and having
hashed relevant issues out on comp.lang.fortran, I can assure you
of one thing: anyone who says "a compiler should not break an
existing program because of undefined behavior" has *not one clue*
about compiler development or standards and specifications.  If they
did, they would state it this way: "a compiler *can* not break an
existing program because of undefined behavior".  If the behavior is
undefined, nothing the compiler causes the program to do at run time
can be considered "breakage".)

(I won't even get into the stunning news that the FSF has reportedly
just changed the rules of the very difficult job of compiler development,
apparently *since* the EGCS team agreed to become GCC and under the
aegis of the FSF.)

        tq vm, (burley)

P.S. Personally, I'll just assume the FSF was misquoted.