https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #26 from mwahab at gcc dot gnu.org --- (In reply to torvald from comment #21) > (In reply to Andrew Haley from comment #20) > > (In reply to mwahab from comment #19) > > > (In reply to Andrew Haley from comment #18) > > > > > > It looks inconsistent with C11 S7.17.7.4-2 (C++11 S29.6.4-21) "Further, if > > > the comparison is true, memory is affected according to the value of > > > success, and if the comparison is false, memory is affected according to > > > the > > > value of failure." (where success and failure are the memory model > > > arguments.) In this case, the write to *exp should be > > > memory_order_seq_cst. > > > > But no store actually takes place, so the only effect is that of the read. > > You can't have a sequentially consistent store without a store. > > I agree. If you continue reading in the C++11 paragraph that you cited, > you'll see that if just one MO is provided and the CAS fails, an acq_rel MO > is downgraded to acquire and a release MO to relaxed. This is consistent > with no update of the atomic variable (note that expected is not atomic, so > applying an MO to accesses to it is not meaningful in any case). However, > if the provided MO is seq_cst, I think a failed CAS still needs to be > equivalent to a seq_cst load. Yes, the last two sentences in the C++11 paragraph make it clear: "If the operation returns true, these operations are atomic read-modify-write operations (1.10). Otherwise, these operations are atomic load operations." In that case, the Aarch64 code looks ok.
