https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71789
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |lto
CC| |jason at gcc dot gnu.org,
| |jsm28 at gcc dot gnu.org
Component|middle-end |c++
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well, clearly C++ atomic_int (aka atomic<int>) and C atomic_int (aka _Atomic
int)
do not inter-operate.
It might be possible that you are lucky for the x86_64 ABI but certainly
TBAA will not treat things like aggregate copies of C++ atomic_int as
possibly clobbering a C _Atomic int.
I'm not sure what standards bodies thought on this issue but it looks hard
to apply a workaround to LTO (the types would need to share TYPE_CANONICAL
which is impossible at the moment as one is a plain INTEGER_TYPE and one
is a RECORD_TYPE).
