This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Aliasing fun
- From: mike stump <mrs at windriver dot com>
- To: dan at dberlin dot org, dewar at gnat dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 25 Jan 2002 11:12:56 -0800 (PST)
- Subject: Re: Aliasing fun
> Date: Fri, 25 Jan 2002 11:28:46 -0500 (EST)
> From: Daniel Berlin <dan@dberlin.org>
> To: dewar@gnat.com
> cc: gcc@gcc.gnu.org
> Right now, we do nothing for structs and classes in C++ (or any
> aggregate type for that matter), regardless of any factors. I want
> to just do better than what we have now, and both the other Dan and
> I think (or at least, theorize) that without any trouble, we can do
> it right all the time for a restricted subset that corresponds to c
> structs (Ie no inheritance).
I think we can reuse the reasoning about C for the C++ case were we
are reasoning about the same types. In C++, this should be when
CLASSTYPE_NON_POD_P
is false. I don't think the bar should be so high in this case, as
this is the previously solved case for C. This might be overly
conservative, but, it's a start.
>From there, people can research exactly when something isn't a pod,
and then reason (prove) about aliasing, but the bar here is higher.
For example, conservatively, we might be add those classes that just
have destructor for example. The existence of a dtor probably doesn't
change the aliasing. Likewise private and protected. And so on.
Maybe TYPE_POLYMORPHIC_P has a more complex interaction with aliasing.
The notion of zero bases misses this, not NON_POD is more
conservative. This is why one should start with not NON_POD first.
This is the lowest hanging aggregate fruit.
I think we should talk about it some, and see if anyone can come up
with a case where doing PODs would be problematic, failing problems, I
think this is conservative enough to go in.
However, even the person doing POD need to read and understand the C++
and C standard, and be familiar with things like layout-compatible
types and what that means to aliasing. It isn't just a slam dunk:
14Two POD-struct (9) types are layout-compatible if they have the same
number of members, and corresponding members (in order) have layout-
compatible types (3.9).
15Two POD-union (9) types are layout-compatible if they have the same
number of members, and corresponding members (in any order) have
layout-compatible types (3.9).
+------- BEGIN BOX 2 -------+
Shouldn't this be the same set of types?
+------- END BOX 2 -------+
16If a POD-union contains two or more POD-structs that share a common
initial sequence, and if the POD-union object currently contains one
of these POD-structs, it is permitted to inspect the common initial
part of any of them. Two POD-structs share a common initial sequence
if corresponding members have layout-compatible types (and, for bit-
fields, the same widths) for a sequence of one or more initial
members.
17A pointer to a POD-struct object, suitably converted, points to its
initial member (or if that member is a bit-field, then to the unit in
which it resides) and vice versa. [Note: There might therefore be
unnamed padding within a POD-struct object, but not at its beginning,
as necessary to achieve appropriate alignment. ]
They should be able to read the language standard and find the code in
the shared code with the C frontend (hopefully) and notice a tight
(conservative) correspondence. Hum, maybe I am now arguing Mark's
viewpoint...
For those that don't know C++, POD came from Plain Old [C] Datatype.