[Bug middle-end/124822] -Winvalid-memory-model warning only appears with -fsanitize=thread with __atomic_compare_exchange

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124822

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
C testcase:
static inline int
foo (int *p, int m, int n)
{
  int q = 0;
  return __atomic_compare_exchange_n (p, &q, 42, 0, m, n);
}

int
bar (int *p)
{
  return foo (p, __ATOMIC_RELAXED, __ATOMIC_RELEASE);
}

I guess the fix is easy, pass_waccess::check_atomic_builtin needs to check
BUILT_IN_TSAN_ATOMIC* in addition to BUILT_IN_ATOMIC* and BUILT_IN_SYNC*, and
pass_waccess::check_call IFN_ATOMIC* calls.

But the question is if we should do it for GCC 16 and how should it interact
with
C++17 P0418R2 (if such model combinations are valid in C++ when using ,
I think the header needs to replace the invalid for __atomic* combinations with
valid ones).

[Bug middle-end/124822] -Winvalid-memory-model warning only appears with -fsanitize=thread

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124822

Drea Pinski  changed:

   What|Removed |Added

  Known to work|16.0|

--- Comment #2 from Drea Pinski  ---
The warning does not show up with GCC 16 at all even with -fsanitize=thread.

[Bug middle-end/124822] -Winvalid-memory-model warning only appears with -fsanitize=thread

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124822

--- Comment #1 from Drea Pinski  ---
I thought there was an issue for this already.

[Bug middle-end/124822] -Winvalid-memory-model warning only appears with -fsanitize=thread

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124822

Drea Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2026-04-08
 Ever confirmed|0   |1

--- Comment #3 from Drea Pinski  ---
Confirmed.

I think the reason why the trunk does not warn at all is because waccess2 is no
longer warning (due to r16-6531-g6345c1c11c2024); let me file a seperate issue
for that.

But for the reason why GCC 15.2.0 didn't warn for this case is because the code
just does not handle the internal function ATOMIC_COMPARE_EXCHANGE, only the
builtin __atomic_compare_exchange_8.


  _11 = .ATOMIC_COMPARE_EXCHANGE (_4, _10, __p2.4_9, 264, 0, 3);
vs:
  _10 = __atomic_compare_exchange_8 (_4, &h, __p2.4_9, 1, 0, 3);