Re: type based aliasing again

[Mark Mitchell <mark AT codesourcery.com>]

>>>>> "David" == David Edelsohn <dje@watson.ibm.com> writes:

    David> 	As far as I can tell, the C standard allowed it to the
    David> extent that its behavior was undefined.  It was not
    David> disallowed and was left to the implementation what result
    David> it produced.  Most compilers, including GCC, have been
    David> producing a reasonable result under most circumstances when
    David> faced with this construct.

Although this again has no bearing on what we should *do*, it's worth
nothing that "undefined" has a much strong meaning than what you say
here.  "Implementation-defined" is the term used when the
implementation is expected to pick some behavior.  Undefined means
that program is erroneous, but the implementation is not required to
issue a diagnostic.  Other examples of undefined behavior include
dereferencing the NULL pointer, for example.  The behavior with
respect to accessing different fields in a union is
implementation-defined; the behavior of casting a double* to an int*
and then storing through it when it really points to a double is
undefined.  It would be reasonable (from the point of view of the
standard, not of GCC) to refuse to compile this at all, or to issue an
error at run-time, say.

    David> 	When the compiler and architecture allow this
    David> construct to produce reasonable results and other compilers
    David> produce reasonable results and GCC still can produce
    David> reasonable results more often when an optional optmization
    David> is not applied, then why not allow tihs construct to work
    David> unless the user specifically request more aggressive
    David> optimization?

Many new optimizations will break programs.  For example, if we remove
empty loops, people who wrote them for timing purposes lose.  If we
eliminate dead stores, people who forgot to say `volatile' lose.
Users of inline assembly often lose, if they forgot to mention a
clobber, etc.  People who depend on particular floating-point
computations in languages where the compiler can reorder operands lose
when we do the reordering.  Real programs really depend on all these
things, even though they shouldn't.  So, I don't think this is a very
good argument; it implies, to a first approximation, that no new
optimization is OK.  That's not 100% accurate, but it's not that far
off, either.

That doesn't mean that we shouldn't do what you suggest
w.r.t. -fstrict-aliasing.

There's a fundamental user-interface question here: is the default
behavior to generate fast code for conforming programs, or code that
works even for non-conforming programs?  Both defaults are sensible;
the first because users don't have to use lots of funny options to get
fast code, the second because legacy code doesn't get broken.  There
are broader ramifications as well; some people will reject GCC because
compared to some other `cc -O', `gcc -O' is slower.  Others because
with some other `cc -O' code works while `gcc -O' does not.  There's
no easy answer.

We don't need a global decision on this point; we can do it on an
option-by-option basis.  But, we should have an overall sentiment, or
we will forever have the same debates.

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