The bug happens at both x86_64 and aarch64

The bug wont happens at gcc-c++-10.3.1-1.2.el8_5

This changed with https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d119f34c952f8718fdbabc63e2f369a16e92fa07, so the old behavior can be brought by -fno-ipa-modref.

However, I think the program invokes undefined behavior.  For clarity, this is the union after
preprocessing:

union Status {
  struct Wrapper { uint32_t value; };
  Wrapper wrapper;
  Status(uint32_t v = 0) { wrapper.value = v; } 
  Status &operator=(uint32_t v) { wrapper.value = v; return *this; }
  operator uint32_t &() { return wrapper.value; }
  operator uint32_t() const { return wrapper.value; }
  typedef uint32_t StorageType;
  BitFieldMember<StorageType, 0, 10> readers;
  BitFieldMember<StorageType, 10, 10> waitToRead;
  BitFieldMember<StorageType, 20, 10> writers;
};

so this union has 4 members.  [class.union] says that "At most one of the
non-static data members of an object of union type can be active at any time,
that is, the value of at most one of the non-static data members can be stored
in a union at any time."

Then the program does this:

    Status status; // activates .wrapper
    status.writers = 1; // activates .writers
    status.waitToRead = 1; // activates .waitToRead
    NonRecursiveRWLock lock;
    lock.m_status = status; // invokes Status::operator uint32_t&, which uses the non-active member .wrapper, which is UB

So I think this program is invalid.

But the union is actually a union of bitfields.

union {
   int value;
   struct {
      int readers : 10;
      int waitToRead : 10;
      int writers : 10;
   };
}


And this bit-field structure pattern is widely spread in years referred as "Safe Bitfields in C++".

Such as:

https://preshing.com/20150324/safe-bitfields-in-cpp/
https://zditect.com/code/cpp/safe-bitfields-in-c.html
https://m.blog.naver.com/framkang/220414843423
https://www.reddit.com/r/programming/comments/3i6q2w/safe_bitfields_in_c/
https://www.intensedebate.com/people/UUD
https://gfjiangly.github.io/cpu_parallel/you-can-do-any-kind-of-atomic-read-modify-write-operation.html

So if gcc-11 breaks this pattern, a lot of existing code will be hurt.

Ah, sorry; I missed that BitFieldMember and Wrapper actually *are* standard-layout classes, therefore the exception
about a common initial sequence (here, a uint32_t) in [class.union.general] kicks in.

I'm going to file an upstream bug, sorry again and thanks for the report.

Upstream PR opened.

We have to fix this upstream first.  A workaround is to use -fno-strict-aliasing.

(In reply to Marek Polacek from comment #4)
> Ah, sorry; I missed that BitFieldMember and Wrapper actually *are*
> standard-layout classes, therefore the exception
> about a common initial sequence (here, a uint32_t) in [class.union.general]
> kicks in.
> 
> I'm going to file an upstream bug, sorry again and thanks for the report.

Is there any progress in upstream?

(In reply to Kirby Zhou from comment #8)
> (In reply to Marek Polacek from comment #4)
> > Ah, sorry; I missed that BitFieldMember and Wrapper actually *are*
> > standard-layout classes, therefore the exception
> > about a common initial sequence (here, a uint32_t) in [class.union.general]
> > kicks in.
> > 
> > I'm going to file an upstream bug, sorry again and thanks for the report.
> 
> Is there any progress in upstream?

It looks like the developers don't want to implement this rule; rather, users should use may_alias:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106389#c5

(In reply to Marek Polacek from comment #9)
> (In reply to Kirby Zhou from comment #8)
> > (In reply to Marek Polacek from comment #4)
> > > Ah, sorry; I missed that BitFieldMember and Wrapper actually *are*
> > > standard-layout classes, therefore the exception
> > > about a common initial sequence (here, a uint32_t) in [class.union.general]
> > > kicks in.
> > > 
> > > I'm going to file an upstream bug, sorry again and thanks for the report.
> > 
> > Is there any progress in upstream?
> 
> It looks like the developers don't want to implement this rule; rather,
> users should use may_alias:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106389#c5

Could you please give some example to show how to use may_alias to workaround this problem?

(In reply to Kirby Zhou from comment #10)
> (In reply to Marek Polacek from comment #9)
> > (In reply to Kirby Zhou from comment #8)
> > > (In reply to Marek Polacek from comment #4)
> > > > Ah, sorry; I missed that BitFieldMember and Wrapper actually *are*
> > > > standard-layout classes, therefore the exception
> > > > about a common initial sequence (here, a uint32_t) in [class.union.general]
> > > > kicks in.
> > > > 
> > > > I'm going to file an upstream bug, sorry again and thanks for the report.
> > > 
> > > Is there any progress in upstream?
> > 
> > It looks like the developers don't want to implement this rule; rather,
> > users should use may_alias:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106389#c5
> 
> Could you please give some example to show how to use may_alias to
> workaround this problem?

There's an example in https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#index-may_005falias-type-attribute
I hope it works for you.

There's also a recent example in the glibcsources:

commit 8d7b6b4cb27d4dec1dd5f7960298c1699275f962
Author: Florian Weimer <fweimer>
Date:   Sat May 18 09:33:19 2024 +0200

    socket: Use may_alias on sockaddr structs (bug 19622)
    
    This supports common coding patterns.  The GCC C front end before
    version 7 rejects the may_alias attribute on a struct definition
    if it was not present in a previous forward declaration, so this
    attribute can only be conditionally applied.
    
    This implements the spirit of the change in Austin Group issue 1641.
    
    Suggested-by: Marek Polacek <polacek>
    Suggested-by: Jakub Jelinek <jakub>
    Reviewed-by: Sam James <sam>
    Reviewed-by: Carlos O'Donell <carlos>

https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8d7b6b4cb27d4dec1dd5f7960298c1699275f962