Re: type based aliasing again

[Mark Mitchell <mark@codesourcery.com>]

  Mark Mitchell writes:
  > There will be cases where A will pessimize code that does not have
  > undefined behavior.  So, in fact, C is impossible, and A penalizes
  > conforming code.  Thus, B is the only remaining sensible option.

  Your conclusion does not follow from the premise, unless you add
  extra assumptions, like "It is not sensible to ever pessimize any
  conforming program the least little bit, no matter how rare such
  programs might be."

Agreed, modulo the strength of the statement.  Yes, I assumed it is
not sensible to pessimize conforming programs, and, yes, affected
conforming programs are probably semi-rare.

  Could you give an example of such a case?  It seems that it could
  only occur if

  1. There is an illegal access, but
  2. It can never be reached, but
  3. We can't tell that it will never be reached.

Right.  That's probably not as uncommon as it sounds.

One of your assumptions is that the only times we ask `does x alias y'
are when it is sensible to do so. :-)  We likely do so at other times
as well; I didn't point this out, but should have.  Consider:

  void *v = malloc (4);
  if (p)
    * ((float *) v) = 3;
  else
    * ((int *) v) = 7;

This code is conforming.  I don't mind terribly if we warn on this
code; I bet the number of false positives will be small.  But, we
shouldn't force the compiler to go slower in this case.  

Why might we want to know if these locations alias?  Hard to say.
But, we might.  For example, we might want to know if both values
could be live; type-based alias analysis says that at most one can be,
precisely because they are different types at the same address.

You might convince me that B is *not* sensible.  But, I doubt you will
convince me that A *is* sensible.  I really, really don't want to have
people complaining in a few years when we break some program that used
to work, just because we made our alias analysis behave slightly
differently.  I want all these programs to break today, so they get
fixed, rather than slowly break them one by one over the next several
years.

You asked users with nonconformant code whether local analysis would
spot the bugs.  In some cases it will.  In others, it won't.  In some,
it will depend on what the compiler does.  For example, does it inline
some function?  If so, more things become local.  So, now you have
programs that might work with -O3 but might break with -O2.  (It's not
that that can't already happen, but we shouldn't introduce gratuitous
ways of doing it.)  What some user thinks of as a local property GCC
may not.  Frightening though it is, people are sure to depend on the
warning as indicating that their code is *correct*; they will then
complain when it stops working, even though we were warning them it
was broken.

Saying "Don't violate ANSI/ISO aliasing rules, or else use
-fno-strict-aliasing" is a simple, easy-to-follow rule.  I don't think
we should muddy that with confusing semantics depending on GCC
internals.

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