Aliasing fun

[mike stump]

> 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.