On 12/8/21 10:14 AM, Jonathan Wakely wrote:
On Wed, 8 Dec 2021 at 16:49, Martin Sebor wrote:
I don't anticipate this change to lead to the same fallout
because it's unlikely for GCC to synthesize invalid memory
orders out of thin air;
Agreed. I don't think we'll have the same kind of issues. 99% of uses
of memory orders just use the constants explicitly, passing them
directly to the std::atomic member functions (or something that calls
them).
Ack.
and b) because the current solution
can only detect the problems in calls to atomic functions at
-O0 that are declared with attribute always_inline. This
includes member functions defined in the enclosing atomic
class but not namespace-scope functions. To make
the detection possible those would also have to be
always_inline. If that's a change you'd like to see I can
look into making it happen.
I think we can ignore the namespace-scope functions in <atomic>. Most people do.
I was thinking it would be nice to provide the same quality
for the C/C++ portability interface (see the test below that
triggers the warning at -O0 in C but requires -O1 to get it
in C++). But it's not a big deal.
Martin
#if __cplusplus
# include <atomic>
using std::memory_order_release;
using std::atomic_load_explicit;
extern std::atomic<int> eai;
#else
# include <stdatomic.h>
extern _Atomic int eai;
#endif
int load (void)
{
return atomic_load_explicit (&eai, memory_order_release);
}
