Re: g++ and aliasing bools

[mike stump <mrs at windriver dot com>]

> Date: Fri, 25 Jan 2002 11:44:21 -0800
> From: Mark Mitchell <mark@codesourcery.com>
> To: Joe Buck <jbuck@synopsys.COM>, David Edelsohn <dje@watson.ibm.com>
> cc: Paolo Carlini <pcarlini@unitus.it>, "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>

> Your proof has at least one bug.  A type that has no baseclasses or
> virtuals can contain (as a data member) a type that does; such a
> type is at least as complex as the contained type.  (Similarly, an
> array of classes with virtual bases, etc.)  You need to recurse
> through the type structure.

Ah, but I believe the CLASSTYPE_NON_POD_P test may conservative
enough in this case, in particular, it does:

      if (! pod_type_p (type))
        /* DR 148 now allows pointers to members (which are POD themselves),
           to be allowed in POD structs.  */
	   CLASSTYPE_NON_POD_P (t) = 1;

in class.c, thus cutting off the recursive case of members.

The cases of virtuals and bases are handled by:

  CLASSTYPE_NON_POD_P (t)
    |= (CLASSTYPE_NON_AGGREGATE (t) || TYPE_HAS_DESTRUCTOR (t) 
    || TYPE_HAS_ASSIGN_REF (t));

and for CLASSTYPE_NON_AGGREGATE in the case of bases, by:

  /* An aggregate cannot have baseclasses.  */
  CLASSTYPE_NON_AGGREGATE (t) |= (n_baseclasses != 0);

and in the case of virtuals, by:

  CLASSTYPE_NON_AGGREGATE (t) |= (TYPE_HAS_CONSTRUCTOR (t)
				   || TYPE_POLYMORPHIC_P (t));

We can see the limiting of virtuals by:

/* Nonzero if this class has a virtual function table pointer.  */
#define TYPE_CONTAINS_VPTR_P(NODE)		\
  (TYPE_POLYMORPHIC_P (NODE)					\
   || TYPE_USES_VIRTUAL_BASECLASSES (NODE))

So, if we believe it, we know that either TYPE_POLYMORPHIC_P is true,
or TYPE_USES_VIRTUAL_BASECLASSES is true, if the type has a vtable
pointer.  TYPE_USES_VIRTUAL_BASECLASSES should only be true, if the
type has base classes.  We can see this as this is only set in:

       if (via_virtual || TYPE_USES_VIRTUAL_BASECLASSES (basetype))
           {
	         TYPE_USES_VIRTUAL_BASECLASSES (ref) = 1;

in decl.c, and we can only get there if we process a basetype.

> It may be that with that change, your sketch is correct -- but the
> fact that you missed this point just makes me more nervous.

I found it trivial to spot; it hit me the same second his words/code
first hit my eyes, though, yes, there may be other trivial things
about it that we have missed.