This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [C++] Re: PARM_DECL of DECL_SIZE 0, but TYPE_SIZE of 96 bits
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Geoffrey Keating <geoffk at geoffk dot org>
- Cc: Richard Henderson <rth at redhat dot com>, Gcc Mailing List <gcc at gcc dot gnu dot org>
- Date: Thu, 30 Jun 2005 21:47:44 -0400
- Subject: Re: [C++] Re: PARM_DECL of DECL_SIZE 0, but TYPE_SIZE of 96 bits
- References: <1120085832.7612.81.camel@linux-009002219098> <20050629235504.GA23780@redhat.com> <1120094227.8950.12.camel@linux-009002219098> <20050630043542.GA24390@redhat.com> <m2k6kbk0ro.fsf@geoffk.org>
On Thu, 2005-06-30 at 14:11 -0700, Geoffrey Keating wrote:
> Richard Henderson <rth@redhat.com> writes:
>
> > On Wed, Jun 29, 2005 at 09:17:07PM -0400, Daniel Berlin wrote:
> > > 1. In require_complete_types_for_parms, in the C++ FE, reset DECL_SIZE
> > > to NULL before we call layout_decl on the parm and let layout_decl
> > > figure out what to do.
> >
> > This is what relayout_decl does.
> >
> > > 2. Add code in layout_decl to copy TYPE_SIZE/TYPE_SIZE_UNIT if the
> > > DECL_SIZE is integer_cst (0)
> >
> > Bad.
> >
> > > 3. Not call layout_decl on the template types until they are completed.
> >
> > Certainly an option; not doing extra work is good.
> >
> > 4. Make sure that template types are incomplete. That is, with
> > TYPE_SIZE/TYPE_SIZE_UNIT unset.
>
> I think this makes a lot of sense considering the language semantics.
This i'm not sure how to do.
:)
I've submitted a patch for option 1 for the moment, and i'll go explore
option 4 while someone considers that (since it's blocking 22071, which
has been a regression for a few weeks now :( )