[cfe-commits] PATCH: Large re-working of bitfield IR-gen, and a fix for PR13691

[John McCall]

On Sep 11, 2012, at 4:41 PM, Richard Smith wrote:
> On Tue, Sep 11, 2012 at 11:33 AM, John McCall <rjmccall at apple.com> wrote:
> On Sep 11, 2012, at 11:07 AM, Chandler Carruth wrote:
> > On Fri, Aug 31, 2012 at 1:01 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> >> Another nasty case I just thought of:
> >>
> >> struct x { int i : 24; };
> >> struct y { int i : 24; char j; };
> >> union z {
> >>   struct x x;
> >>   struct y y;
> >> };
> >> union z a;
> >> void f(int i) {
> >>   a.x.i = i;
> >> }
> >> void g(char j) {
> >>   a.y.j = j
> >> }
> >>
> >> The two writes are to separate memory locations. :)
> >
> > Wait, hold on... I'm deeply confused. Maybe because I don't know how C11 unions work?
> >
> > With C++11, only one side of the union is allowed to be active, and so I don't think they are separate memory locations?
> 
> I agree that this isn't a problem, but the analysis is a bit more complicated;
> it hinges on the fact that it's okay to *read* from an inactive union member
> under the common-prefix exception, but it's not okay to *write* to it.  The
> same analysis applies in both standards:
> 
> Is this still OK if the extra union member is volatile? Chandler and I have discussed this, and it's far from clear that it would be. (In particular, we can conceive of a seemingly-reasonable case where the union sits on an MMIO port, and only the fourth byte has volatile semantics.)

I see no reason why making the member volatile changes anything.
Other members in the union can be assumed not to exist, because the
active union member *must* be the one we're assigning to — indeed,
in C such an assignment is how you change the active union member.
Those bytes are simply padding.  In C, we have this:

C11 6.2.6.1p6:
  When a value is stored in an object of structure or union type,
  including in a member object, the bytes of the object representation
  that correspond to any padding bytes take unspecified values.

C++ is much vaguer, but I don't think there's any intent to guarantee that
padding bytes won't be disturbed!

John.