https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124827
--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <[email protected]>: https://gcc.gnu.org/g:4684e14e0148525851e0de37c124cfa30a3d5793 commit r16-8561-g4684e14e0148525851e0de37c124cfa30a3d5793 Author: Jakub Jelinek <[email protected]> Date: Fri Apr 10 11:47:59 2026 +0200 warn-access: -Winvalid-memory-model fixes [PR124827] A few years ago Martin moved for unknown reasons -Winvalid-memory-model diagnostics from expansion to the gimple-ssa-warn-access middle end warning black hole. A recent change limited the second instance of the pass to only a small subset of warnings. This regressed diagnostics of -Winvalid-memory-model with -fsanitize=thread, because invalid cases are not warned about anymore during waccess2 and during waccess3 we've already transformed those builtins into corresponding tsan builtins. The following patch fixes that regression by handling the tsan atomic builtins as well. While doing that, I've also fixed formatting and noticed other bogosities in the code, e.g. existance of xchg_models. No idea where Martin got that from, neither C11, nor C23, nor various versions of C++ nor GCC documentation have any restrictions on what memory models can be used for atomic_exchange_explicit, so why is it trying to prevent __ATOMIC_ACQUIRE? And incorrectly so, __atomic_exchange_N has 3 arguments, and suc_arg is 0 based, so setting it to 3 meant it didn't check anything because the 4th argument doesn't exist. So fixed to use all_models with the correct arg index. Besides this, there is another problem that we fold some atomic builtins into IFN_ATOMIC* internal functions. That isn't a 16 Regression though, could be fixed by also diagnosing this stuff for the IFN_ATOMIC_* calls, but I'm not doing it right now because there is yet another problem. C++17 in https://wg21.link/p0418r2 dropped some of the restrictions, in particular that for the compare and exchange cases failure mode can't be stronger than success mode. So I'm hesistant to add further warnings for 16 (beyond just fixing the -fsanitize=thread inconsistency), unsure if we should somehow mark the atomic builtins from the C++ <atomic> APIs that the no stronger checking shouldn't be done for those, or simply mark those for all of C++17 and later, something else? C23/C2Y I think still require it and it is reasonable requirement, 2026-04-10 <[email protected]> PR middle-end/124827 * gimple-ssa-warn-access.cc (xchg_models): Remove. (pass_waccess::check_atomic_builtin): Fix up sucs_arg for BUILT_IN_ATOMIC_EXCHAGE_* and use all_models instead of xchg_models. Handle BUILT_IN_TSAN_ATOMIC*. Formatting fixes. * gcc.dg/tsan/atomic-invalid.c: New test.
