On Fri, Sep 2, 2011 at 4:10 PM, Jason Merrill <ja...@redhat.com> wrote: > On 09/02/2011 04:53 AM, Richard Guenther wrote: >> >> On Thu, Sep 1, 2011 at 5:19 PM, Jason Merrill<ja...@redhat.com> wrote: >>> >>> I think it would make sense to expose this information to the back end >>> somehow. A hook would do the trick: call it type_data_size or >>> type_min_size >>> or some such, which in the C++ front end would return TYPE_SIZE >>> (CLASSTYPE_AS_BASE (t)) for classes or just TYPE_SIZE for other types. >> >> That's too late to work with LTO, you'd need to store that information >> permanently somewhere. > > OK. > >> Maybe move this whole C++ specific bitfield handling where it belongs, >> namely to the C++ frontend? > > I don't think that is the way to go; C is adopting the same memory model, > and this is the only sane thing to do with bit-fields. > >> I suggest to always not re-use tail padding for now (I believe if your >> parent object is a COMPONENT_REF, thus, x.parent.bitfield, >> you can use the TYPE_SIZE vs. field-decl DECL_SIZE discrepancy >> to decide about whether the tail-padding was reused, but please >> double-check that ;))) > > But you don't always have a COMPONENT_REF; you still need to avoid touching > the tail padding when you just have a pointer to the type because it might > be a base sub-object. > > I wonder what would break if C++ just set TYPE_SIZE to the as-base size?
Good question. Probably argument passing, as the as-base size wouldn't get a proper mode assigned form layout_type then(?) for small structs? Maybe worth a try ... Richard. > Jason >
