This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: g++ and aliasing bools

> The basic argument is this: I am allowed to implement C++ in a way that
> zero-sized classes don't exist (they always come out as at least one
> byte).  For such implementations I can clearly use the C rules, as there
> is an equivalent C program.  If I then replace the inefficient

[Implicitly, we're still in the simple_enough case here, i.e., no virtuals,
etc.  Perhaps the argument applies more generally, but we don't know yet.]

> implementation with an efficient one, the language specification does not
> care, for the purpose of aliasing.  The type-based aliasing rules are
> independent of implementation, so if they come out correctly for the
> inefficient implementation, we get the same answer for the efficient one.

OK, I'll buy that.

I think we need to make explicit Kenner's point; namely that our alias
sets do not talk about addresses.  In particular, Kenner's semantics
for alias sets allow the case that two MEMs do not alias (because they
are in different alias sets), but that the addresses of those things are
the same.  Therefore, the compiler is *not* allowed to turn the
following pseudo-code:

  if ((void*) x != (void*)y)



even if it knows that "*x" and "*y" do not alias.  (That makes sense

  int i;
  int *ip = &i;
  short *sp = (short*) &i;

  if ((void*) ip != (void*) sp)

is well-defined -- assuming typical implementation definitions
regarding pointer widths, conversions, etc. -- and does not call

We need this fact to make your proof safe -- but it is indeed the
right semantics and it is how we use alias sets at present.  We
should just put this into the comments in alias.c somewhere.

OK, you've convinced me to extend simple_enough to the cases with
zero-sized thingies, so long as the other conditions still hold.

Mark Mitchell         
CodeSourcery, LLC     

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]