Re: g++ and aliasing bools

[Mark Mitchell <mark at codesourcery dot com>]

> Let's proceed in another way.  I think that, for the purpose of Dan's
> proof, he should be allowed to accept as a postulate that c_get_alias_set
> is correct when applied to C.  If this postulate is not acceptable,
> then it seems that if someone owes us a proof, it is Mark, not Daniel.
> However, c_get_alias_set has been there long enough that we have
> reasonable confidence in it.

Agreed.

> I think it's also fair to assume as a postulate that the current
> conservative cxx_get_alias_set is safe.  Again, long experience.

Agreed.

> cxx_get_alias_set ()
> {
> 	if (AGGREGATE_TYPE && HAS_BASECLASSES && HAS_VIRTUALS)
> 		return 0;
> 	return c_get_alias_set();
> }
>

> While this is not a formal proof, it's enough to convince me that Daniel's
> change is safe.

Your proof has at least one bug.  A type that has no baseclasses or
virtuals can contain (as a data member) a type that does; such a type
is at least as complex as the contained type.  (Similarly, an array
of classes with virtual bases, etc.)  You need to recurse through the
type structure.

It may be that with that change, your sketch is correct -- but the
fact that you missed this point just makes me more nervous.  It
shows that smart people with long experience with C++ can get tripped
up here.

One of the problems with this kind of change is that it can result
in a bug in a one million line program that is seemingly irreducible,
and isn't even very easy to isolate.  We need to be very careful.

That said, if this change is safe, we should definitely do it.  It's
just that "this change causes no regressions" isn't close to being
good enough for this kind of change.

I certainly support C++ optimization improvements!

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