jfb added inline comments.
================ Comment at: lib/Sema/SemaChecking.cpp:10668 + if (Source->isAtomicType() || Target->isAtomicType()) + S.Diag(E->getBeginLoc(), diag::warn_atomic_implicit_seq_cst); + ---------------- rjmccall wrote: > jfb wrote: > > rjmccall wrote: > > > Why would the target be an atomic type? And if it is an atomic type, > > > isn't that an initialization of a temporary? In what situation does it > > > make sense to order the initialization of a temporary? > > In this case: > > > > ``` > > void bad_assign_1(int i) { > > atom = i; // expected-warning {{implicit use of sequentially-consistent > > atomic may incur stronger memory barriers than necessary}} > > } > > ``` > > > > We want to warn on assignment to atomics being implicitly `seq_cst`. > > > > Though you're right, initialization shouldn't warn because it isn't atomic. > > The issue is that `ATOMIC_VAR_INIT` is what needs to get used, and that's > > weird to test. I'll add a test that just assigns (which is what > > `ATOMIC_VAR_INIT` expands to for clang), and I'll need to update the code > > to detect that pattern and avoid warning in that case. I guess I have to > > look at the `Expr` and figure out if the LHS is a `Decl` or something like > > that. > Do we really implicitly convert the RHS of that assignment to atomic type? > That seems wrong; `_Atomic` is really a type qualifier, and the RHS should > not be converted to `_Atomic(T)` any more than it would be converted to > `volatile T` for an assignment into a `volatile` l-value. I don't make the rules man! I just enforce (and try to warn) on them! C17: > 6.5.16.1 Simple assignment > **Constraints** > One of the following shall hold: 114) > — the left operand has atomic, qualified, or unqualified arithmetic type, and > the right has arithmetic type; > — the left operand has an atomic, qualified, or unqualified version of a > structure or union type compatible with the type of the right; > — the left operand has atomic, qualified, or unqualified pointer type, and > (considering the type the left operand would have after lvalue conversion) > both operands are pointers to qualified or unqualified versions of compatible > types, and the type pointed to by the left has all the qualifiers of the type > pointed to by the right; > — the left operand has atomic, qualified, or unqualified pointer type, and > (considering the type the left operand would have after lvalue conversion) > one operand is a pointer to an object type, and the other is a pointer to a > qualified or unqualified version of void, and the type pointed to by the left > has all the qualifiers of the type pointed to by the right; > — the left operand is an atomic, qualified, or unqualified pointer, and the > right is a null pointer constant; or > — the left operand has type atomic, qualified, or unqualified _Bool, and the > right is a pointer. > > **Semantics** > In simple assignment (=), the value of the right operand is converted to the > type of the assignment expression and replaces the value stored in the object > designated by the left operand. > > 114)The asymmetric appearance of these constraints with respect to type > qualifiers is due to the conversion (specified in 6.3.2.1) that changes > lvalues to "the value of the expression" and thus removes any type qualifiers > that were applied to the > typecategoryoftheexpression(forexample,itremovesconstbutnotvolatilefromthetypeint > volatile * const). Repository: rC Clang https://reviews.llvm.org/D51084 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits