On Thu, Aug 30, 2018 at 5:09 PM JonY <10wa...@gmail.com> wrote:
>
> On 08/30/2018 11:59 AM, Nathan Sidwell wrote:
> > On 08/29/2018 11:06 PM, Liu Hao wrote:
> >
> >> It is strictly an ABI break but I doubt whether code in real world
> >> that got broken by this bug ever exists. Usually when people expect
> >> consecutive bitfields to be packed into a single word they wouldn't
> >> put irrelevant declarations between them.
> >
> > You're probably right. I'm guessing this bug was found because:
> >
> > int bob : 1;
> > int get_bob () const {return bob;}
> > void set_bob (bool v) {bob=v;}
> > int bill : 1;
> > ...
> >
> > might be a useful style.
> >
> >> An important reason why such code could be rare is that the following
> >> code compiles differently as C and C++:
> >
> >> struct foo
> >> {
> >> unsigned a : 21;
> >> union x1 { char x; };
> >> unsigned b : 11;
> >> union x1 u;
> >> };
> >
> > (for C++) this happens to be a case we already get right. <aside> I
> > think that'd be a C vendor extension, I don't think unnamed fields are
> > permitted there?
> >
> > Here's a version of the patch to completely resolve the issue, tested on
> > trunk. I noticed regular x86 targets support the ms_struct attribute,
> > so we can give this wider testing. I did consider trying to reorder the
> > field decls before struct layour, but that seemed a more invasive change
> > -- besides it might be nice to be able to remove the template-specific
> > CLASSTYPE_DECL_LIST which almost but not quite mirrors TYPE_FIELDS.
> >
> > Ok for trunk, ok for 8?
> >
> > nathan
>
> I don't have any objections.
Me neither if appropriately documented in changes.html.
Richard.
>
