https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125312
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2026-05-15
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
On IRC Liu Hao found the problem.
For my cross-compiler I see this with GCC 16:
#define _GLIBCXX_ATOMIC_WORD_BUILTINS 1
but for a native mingw-w64 build that isn't defined. The build logs show:
configure:16480: checking for atomic builtins for _Atomic_word
configure:16482:
/home/lh_mouse/GitHub/MINGW-packages/mingw-w64-gcc/src/build-MINGW64/./gcc/xgcc
-shared-libgcc
-B/home/lh_mouse/GitHub/MINGW-packages/mingw-w64-gcc/src/build-MINGW64/./gcc
-nostdinc++
-L/home/lh_mouse/GitHub/MINGW-packages/mingw-w64-gcc/src/build-MINGW64/x86_64-w64-mingw32/libstdc++-v3/src
-L/home/lh_mouse/GitHub/MINGW-packages/mingw-w64-gcc/src/build-MINGW64/x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/home/lh_mouse/GitHub/MINGW-pngw-w64-gcc/src/build-MINGW64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include -c -O0 -S conftest.cpp >&5
configure:16471:10: fatal error:
/home/lh_mouse/GitHub/MINGW-packages/mingw-w64-gcc/src/gcc/libstdc++-v3/config/cpu/generic/atomic_word.h:
No such file or directory
[10:17] <lh_mouse> compilation terminated.
[10:17] <lh_mouse> configure:16485: $? = 1
This results in GCC being built without native atomics, using a library call
that uses a mutex instead. If MSYS2 was built using GCC 15, it will use native
atomics. This means that atomic ops are no longer atomic, because sometimes
they use a mutex and plain non-atomic instructions, but other times they use
hardware atomic instructions (without locking the mutex). This has undefined
behaviour.
The changes to how atomics are detected by configure were done by
r16-427-g86627faec10da5
The problem is that the new configure test uses a unix-style path, which fails
on Windows. The path needs to be translated to a Windows path, or the test
needs to use a different way to find the header.
tl;dr atomics are broken in GCC 16.1 for native mingw builds (but not
cross-compilers).
