Aliasing fun

[Daniel Berlin]

On Fri, 25 Jan 2002, Robert Dewar wrote:

> <<My point about undecidability is that using just the C++ standard, it's
> not just that we can be  conservative and get it correct, it's quite
> possible we'll get the wrong  answers for type alias sets, because of
> implementation specific  details that the C++ standard doesn't define.
> Mark wants a semi-formal proof that the ABI details provide us enough to
> get it right all the time, before we try to do it for all cases. Which i
> have no problem with, in reality, but it's not what is being suggested
> here.
> >>
> 
> If there are cases where the C++ standard does not provide sufficient
> information to prove that two sets are unaliased, then there are two
> possibilities (neither of which has anything to do with undecidability,
> you seem to think that undecidability means not-able-to-be-decided in
> the above, and that of course is not the case at all the term undecidable
> has a formal meaning).
But we are of course, not talking in a formal setting here, nor have i 
applied a formal meaning of undecidability (except in a few cases when 
referring to papers), though i am quite aware of 
what it is.

> 
> 1. You simply decide that the items are not provably in separate alias sets,
> so they go in the same set.
> 
> 2. You know that your implementation has well documented and guaranteed
> additional permissible constraints that allow you to decide that the two
> items should be in different sets, and allow you to prove that this is
> the case.
Which is what Mark wants to prove before allowing someone to fully 
implement TBAA for C++, and something *I HAVE NO PROBLEM WITH*.
I do not however, believe we should have to reprove that our existing C 
struct aliasing works on c structs, which is all that is required to 
implement the suggestion that for C++ TBAA, when we find a struct or class 
that has no C++ specific features to it (IE inheritance), we apply the 
TBAA we have for structs for C.
I'm perfectly willing to copy and adjust that code to handle any small 
differences that come about because of wording of the C standard.
I'm not willing, nor do i think it necessary, to prove our C struct 
aliasing code works for C structs, in any formal way.  Nor was it 
apparently necessary when the code was introduced.

You have not raised any points or explained anything to me I did not 
already know, Robert.  You in fact, cut out the one things that is the 
real issue here, in order to point out facts about the other, completely 
inconsequential issues (IE nothing related to gcc).
Which doesn't help.

 > > >>If our testsuite doesen't adequately test this, then so be it. > 
> The test suite does not BEGIN to be an adequate test here in my 
opinion.
Which, the item you cut out, or for all of C++?
I'd agree it's not a good enough testsuite to test aliasing for all of 
C++.
I'm surprised if it's not good enough to not be able to catch [simple, as 
in, no inheritance, etc,  C++ class] member aliasing problems that may 
arise.

>