[Bug libstdc++/101439] New: std::atomic<__uint128_t>::load() crashes - possible fix with mutable

["doodspav at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101439

            Bug ID: 101439
           Summary: std::atomic<__uint128_t>::load() crashes - possible
                    fix with mutable
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doodspav at gmail dot com
  Target Milestone: ---

The following code will cause a segfault on x86 from g++4.8 up to g++11.1
(currently the latest non-trunk version on Godbolt):

```
#include <atomic>

struct S { long i, j; };
const std::atomic<S> x{ {0, 0} };

int f(const std::atomic<S>* p) {
    S y = *p;
    return y.i;
}

int main() {
    return f(&x);
}
```
(demonstrated here: https://godbolt.org/z/eWcTv5fdY for however long the link
remains alive)

Loading the value from `x` causes libatomic to use `lock cmpxchg16b` on
read-only memory, crashing the program (since `lock cmpxchg16b` always performs
a write). 

This has been reported in bug report 95722 (and touched upon in 70490), however
those treat it as a libatomic bug (which it technically is), whereas here I
seek to treat it as a libstdc++ bug.

A "simple" workaround for C++ that doesn't involve changing anything in
libatomic would be to mark all members in any 16 byte specialisation of
`std::atomic` as `mutable`, preventing the compiler from placing it in
read-only memory. This is what MSVC does in their implementation (as does
Boost.Atomic I think). This shouldn't break anything as far as I can tell.

This code (using `_Atomic`) also causes a segfault in C. I can't really think
of a similar fix there (maybe just act as if DR459 never happened?).