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
