]> git.ipfire.org Git - thirdparty/gcc.git/commit
warn-access: -Winvalid-memory-model fixes [PR124827] master trunk
authorJakub Jelinek <jakub@redhat.com>
Fri, 10 Apr 2026 09:47:59 +0000 (11:47 +0200)
committerJakub Jelinek <jakub@gcc.gnu.org>
Fri, 10 Apr 2026 09:47:59 +0000 (11:47 +0200)
commit4684e14e0148525851e0de37c124cfa30a3d5793
tree4eab7b9650a6dcc405cabf08fdc2ef776c3dc1cf
parent506e6398b93cc4ea635a11b908c9d6f5bf7245e2
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  <jakub@redhat.com>

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.
gcc/gimple-ssa-warn-access.cc
gcc/testsuite/gcc.dg/tsan/atomic-invalid.c [new file with mode: 0644]