https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122267
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> Anyway, better testcase would be
> struct alignas (8) S { char a; double b; } s;
> because the earlier struct S could have s.b actually aligned, in this case
> it can't.
It would be undefined behaviour to use std::atomic_ref a(s.b) (and it fails an
assertion in the constructor with -D_GLIBCXX_ASSERTIONS).
> I think __atomic_compare_exchange (&s.b, ...) etc. will not crash at least
> in the usual CPU setting where non-aligned loads/stores are ok, but the CPU
> doesn't guarantee the operation is actually atomic even when LOCK prefix is
> used if it is not appropriately aligned.
There's a pre-existing bug (before r16-4349) for atomic_ref<double> and
atomic_ref<T*> on cris-elf and m69k-linux-gnu, because they have weaker
alignment for those types. We need to align those to sizeof(double) and
sizeof(T*) respectively. But that was already wrong in GCC 15 so I'll fix that
separately.
