From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-45231-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 23943 invoked by alias); 25 Jan 2002 21:50:06 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 23759 invoked from network); 25 Jan 2002 21:49:57 -0000
Received: from unknown (HELO mail.wrs.com) (147.11.1.11)
  by sources.redhat.com with SMTP; 25 Jan 2002 21:49:57 -0000
Received: from kankakee.wrs.com (kankakee [147.11.37.13])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA15129;
	Fri, 25 Jan 2002 13:47:57 -0800 (PST)
From: mike stump <mrs@windriver.com>
Received: (from mrs@localhost)
	by kankakee.wrs.com (8.9.3+Sun/8.9.0) id NAA04598;
	Fri, 25 Jan 2002 13:49:15 -0800 (PST)
Date: Fri, 25 Jan 2002 14:49:00 -0000
Message-Id: <200201252149.NAA04598@kankakee.wrs.com>
To: dje@watson.ibm.com, jbuck@synopsys.COM, mark@codesourcery.com
Subject: Re: g++ and aliasing bools
Cc: gcc@gcc.gnu.org, pcarlini@unitus.it
X-SW-Source: 2002-01/txt/msg01695.txt.bz2

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