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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #1 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to ktkachov from comment #0)
> When reasoning about optimal sequences for atomic operations for various
> targets the issue of read-only memory locations keeps coming up,
> particularly when talking about doing non-native larger-sized accesses
> locklessly
> 
> I wonder if the frontends in GCC should be more assertive with warnings on
> such constructs. Consider, for example:
> #include <stdint.h>
> 
> uint32_t
> load_uint32_t (const uint32_t *a)
> {
>   return __atomic_load_n (a, __ATOMIC_ACQUIRE);
> }
> 
> void
> casa_uint32_t (const uint32_t *a, uint32_t *b, uint32_t *c)
> {
>   __atomic_compare_exchange_n (a, b, 3, 0, __ATOMIC_ACQUIRE,
> __ATOMIC_ACQUIRE);
> }
> 
> Both of these functions compile fine with GCC.
> With Clang casa_uint32_t  gives a hard error:
> error: address argument to atomic operation must be a pointer to non-const
> type ('const uint32_t *' (aka 'const unsigned int *') invalid)
>   __atomic_compare_exchange_n (a, b, 3, 0, __ATOMIC_ACQUIRE,
> __ATOMIC_ACQUIRE);
> 
> I would argue that for both cases the compiler should emit something. I
> think an error is a appropriate for the __atomic_compare_exchange_n case,

Agree, but...

> 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.

Reply via email to