This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++0x] contiguous bitfields race implementation


On 09/02/2011 04:53 AM, Richard Guenther wrote:
On Thu, Sep 1, 2011 at 5:19 PM, Jason Merrill<jason@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?

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]