From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9878 invoked by alias); 30 Jun 2005 01:17:15 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 9868 invoked by uid 22791); 30 Jun 2005 01:17:11 -0000 Received: from h-68-164-203-246.nycmny83.covad.net (HELO dberlin.org) (68.164.203.246) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 30 Jun 2005 01:17:11 +0000 Received: from [127.0.0.1] (HELO localhost) by dberlin.org (CommuniGate Pro SMTP 4.3.4) with ESMTP id 8185103; Wed, 29 Jun 2005 21:17:08 -0400 Subject: Re: PARM_DECL of DECL_SIZE 0, but TYPE_SIZE of 96 bits From: Daniel Berlin To: Richard Henderson Cc: Gcc Mailing List In-Reply-To: <20050629235504.GA23780@redhat.com> References: <1120085832.7612.81.camel@linux-009002219098> <20050629235504.GA23780@redhat.com> Content-Type: text/plain Date: Thu, 30 Jun 2005 01:17:00 -0000 Message-Id: <1120094227.8950.12.camel@linux-009002219098> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-06/txt/msg01289.txt.bz2 On Wed, 2005-06-29 at 16:55 -0700, Richard Henderson wrote: > On Wed, Jun 29, 2005 at 06:57:12PM -0400, Daniel Berlin wrote: > > I'm going to work around this by using TYPE_SIZE, but it would be nice > > if somebody could explain the purpose for this behavior (if it's a bug, > > i'll file a bug report). I would imagine we don't have truly empty > > things in C++, so you could simply assert that TREE_INT_CST_LOW of > > whatever you are setting DECL_SIZE to is not 0 and find these that way. > > It is most definitely a bug. I'm surprised about the 0 instead > of a NULL there. The later would easily be explicable by > forgetting to call layout_decl. Okay, well, here's what happens: 1. layout_decl gets called on the original PARM_DECL, when it's still a template parameter, which sets the size to type_size, which is still 0 at that point, so we get DECL_SIZE of INTEGER_CST (0). 2. We copy the parm_decl when instantiating the template. 3. layout_decl gets called later on the copy of the PARM_DECL in the instantiated function, which has a DECL_SIZE of INTEGER_CST (0) still. layout_decl does nothing to DECL_SIZE and DECL_SIZE_UNIT of this PARM_DECL in this case, even though TYPE_SIZE has changed from 0 to 96 bits. I imagine the correct thing to do here is to 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. or 2. Add code in layout_decl to copy TYPE_SIZE/TYPE_SIZE_UNIT if the DECL_SIZE is integer_cst (0) or 3. Not call layout_decl on the template types until they are completed. Doing 1 fixes the bug I'm seeing and seems to do the correct thing, but I'm not a C++ person, so there may be dragons this way. --Dan