g++ and aliasing bools

[Daniel Berlin]

On Fri, 25 Jan 2002, Daniel Berlin wrote:

> On Fri, 25 Jan 2002, Robert Dewar wrote:
> 
> > <<However, the important point is that the language semantics don't allow
> > us to get it *right*, not just deciding. We may get it *wrong*, and think
> > we have it *right*.
> > >>
> > 
> > Then you have misread the language specs, or GCC is wrong, no other
> > possibilities exist!
> Incorrect on all three points.
> First, The devil is in the implementation specific portions that are part 
> of the 
> C++ ABI spec, and tell you what the layout of vtables, etc, is. This is 
> what one needs, in addition to the language spec, to be able to tell 
> aliasing properly.
> At least, this is what is thought, anyway, it still might not be enough.
> The language spec by itself, however, is *not* enough, and just using the 
> rules in it will ignore the whole problem of shared vtables, and given you 
> wrong answers *because* implementations do share pieces of classes.
> Second, GCC is right  because it just says that in C++, all aggregate type 
> can alias anything, avoiding the probblem altogether
> Third, the above is a third dpossibility, which not only exists, but is 
> the current situation.

The second is what we are trying to change, if it hasn't clicked by now. 
We want to say that everything besides simple c-like structs can alias 
anything, and simple c-like structs have the same aliasing properties as 
c structs.

Simple c-like structs means classes and structs in C++ which have no base 
classes, and no virtual functions.
If people agree that these are equivalent to c-structs (from an aliasing 
perspective, obviously there are some formal syntactical differences), then we can.
If they don't, then apparently someone else needs to take the time to 
prove it formally, at which point we can add 6 lines of code (or 
whatever, it depends on whether someone can point out any small 
difference in aliasing properties that need to be accounted for) to g++ to 
do it.

There is no "problem" as aliasing for C++ works today, because it doesn't 
do anything for things that aren't in reality, C.

Therein lies the other half of why i don't think the above needs to be 
proven formally, if they are agreed to be equivalent

Already, for non-aggregate types, the routine for C++ TBAA simply calls 
the c routine.

The whole code is literally:

cxx_get_alias_set ()
{
	if (AGGREGATE_TYPE)
		return 0;
	return c_get_alias_set();
}

The above suggestion is simply saying "AGGREGATE_TYPE is way too 
conservative, we only need to return 0 for those things that have C++ 
specific features that may affect aliasing, like virtual functions, or 
inheritance", so let's change it to:

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

If C has the right alias semantics for all non-aggregate types, is there 
something special about the subset of aggregate types without 
baseclasses or virtuals in C++ that is different from C from an aliasing 
perspective.
No one has said yes yet, and unless someone can think of some reason why 
they *would* be different, i don't see why it should be formally proven. 

The basic question, therefore, is, "Do structs/classes in C++ that have no 
C++ specific features to them, have the same aliasing rules as C"
I.E.
Is the aliasing for
"
	struct dan
	{
		int a;
	};
"
The same for C and C++.
If so, then we should be able to change the test in cxx_get_alias_set so 
that for the case of structs that have no C++ specific features, we treat 
them as c structs for aliasing.
 --Dan