This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: g++ and aliasing bools
- From: Daniel Berlin <dan at dberlin dot org>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Dan Nicolaescu <dann at godzilla dot ICS dot UCI dot EDU>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 24 Jan 2002 17:15:26 -0500 (EST)
- Subject: Re: g++ and aliasing bools
On Thu, 24 Jan 2002, Mark Mitchell wrote:
> > What do you consider "proof"?
>
> The sort of thing that appears in a computer science textbook when
> proving that an algorithm is sound. Or at least what is often called
> a "sketch of a proof".
>
> > What more than not causing any regressions are you looking for?
>
> A proof that this is not an algorithmic mistake. This
> is an aspect of GCC that we can reason about formally; the semantics
> of alias sets are reasonably well defined, and the semantics of the
> C++ abstract machine are reasonably well defined in this regard, so
> it should be reasonably possible to convince ourselves that this
> change is safe in the abstract if it is.
What change?
I simply suggested it might be possible to do it.
I'm confused as to why you think it's such a tricky thing to do C++
aliasing that it requires any kind of formal sketch of a proof.
I've read about 6 papers now on aliasing and static type determination in
C++, and all just treat them as C structs that contain other C structs,
with the special case that virtual bases are unions.
Isn't this the correct way to do it?
Other than virtual bases, don't the addresses of each subobject, and
thus, their members, have to be different?
The draft standard (I don't feel like opening the formal standard, i'm
not near a graphical workstation of any kind right now) says
" A base class subobject may be of zero size (_class_);
however, two subobjects that have the same class type and that belong
to the same most derived object must not be allocated at the same
address (_expr.eq_). ]"
Doesn't this mean that excluding the virtual base class case, we could
simply treat them as structs with other structs embedded in them (Which is
already an improvement over what we have now)
Or are all of the papers i've read on the subject just not being
compliant, and getting lucky?
It's also interesting that it appears pro64 simply removed that check, and
calls record_component_aliases.
--Dan