https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109553
Wilco <wilco at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wilco at gcc dot gnu.org
--- Comment #2 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #1)
> > but even for atomic load we may want to hint to the user to avoid doing an
> > atomic load from const types.
>
> this does not make sense. The "const" in "const T *" only means you cannot
> modify the object via the pointer, not mean the value of the object won't
> change. Consider:
>
> void thread1(int *ptr)
> {
> /* ... */
> __atomic_add_fetch (ptr, 1, __ATOMIC_SEQ_CST);
> /* ... */
> }
>
> void thread2(const int *ptr)
> {
> /* ... */
> int t = __atomic_load_n (ptr, __ATOMIC_SEQ_CST);
> /* ... */
> }
>
> It's perfectly legal the two "ptr" can point to the same object. Then if
> you use the usual load intead of __atomic_load_n, a race will happen.
It would be legal if __atomic_load_n is documented to use a const argument, but
it doesn't allow const:
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/_005f_005fatomic-Builtins.html#g_t_005f_005fatomic-Builtins:~:text=Built%2Din%20Function%3A%20type%20__atomic_load_n%20(type%20*ptr%2C%20int%20memorder)
Since atomic accesses are about synchronizing writes with reads, a diagnostic
would be useful, particularly for the case Kyrill mentioned.
