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?
>
> nathanI don't have any objections.
signature.asc
Description: OpenPGP digital signature
