https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109553
Bug ID: 109553
Summary: Atomic operations vs const locations
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
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, but even
for atomic load we may want to hint to the user to avoid doing an atomic load
from const types.
