https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69002
--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> --- FWIW, I think it would make sense to diagnose some of the constructs for other reasons besides accessing a member (of an atomic struct). For example, in write1(), the function is most likely not going to do what its author or caller expects: i.e., it updates a copy of the argument, not the original. It makes no sense (in this case) for the argument to be atomic since it clearly is not shared with other threads. So GCC should probably warn about it, and could also treat it as non-atomic and emit better code (the latter part is the subject of bug 68622). How to write2() depends on whether the function is intended to initialize the argument or simply assign to it. If the former, either atomic_init (p, s); or atomic_store_explicit (p, s, memory_order_relaxed); would work. Obviously, without knowing more about the context in which it's called we can't tell which alternative is appropriate. Which makes me wonder if how the function accesses an atomic object referenced by its argument should be made part of the interface (e.g., via some attribute).
