aaron.ballman accepted this revision. aaron.ballman added a comment. This revision is now accepted and ready to land.
LGTM with an extra comment added. ================ Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:683-685 + // C++17 onwards require that we evaluate the RHS first. + // Compute RHS and save it in a temporary variable so we can + // load it again later. ---------------- shafik wrote: > aaron.ballman wrote: > > tbaeder wrote: > > > aaron.ballman wrote: > > > > tbaeder wrote: > > > > > tbaeder wrote: > > > > > > aaron.ballman wrote: > > > > > > > In C, the evaluation of the operands are unsequenced. C doesn't > > > > > > > currently have constexpr functions, only constexpr objects, but > > > > > > > that eliminates mutating operations like compound assignment... > > > > > > > for the moment. Perhaps a FIXME comment for figuring out how to > > > > > > > handle C? > > > > > > > > > > > > > > (The situation I'm worried about in C is with UB dealing with > > > > > > > unsequenced operations, like rejecting: > > > > > > > https://godbolt.org/z/W11jchrKc) > > > > > > Could C make them sequenced when introducing constexpr functions? :) > > > > > Since we already emit a warning for this, we could in the future just > > > > > check if the statement is in a constexpr function and emit an error > > > > > instead? We're emitting the warning for c++ pre-17 as well but we > > > > > don't make it an error, I guess because it's not UB there? > > > > If we're actually leaving the operations unsequenced before C++17, then > > > > we should reject that code because it is UB: > > > > http://eel.is/c++draft/basic#intro.execution-10 > > > > > > > > The wording in C++14 for assignment operations is: > > > > > In all cases, the assignment is sequenced after the value computation > > > > > of the right and left operands, and before the value computation of > > > > > the assignment expression. > > > > > > > > So the left and right operands are unsequenced relative to one another. > > > > > > > I was looking at the existing implementation when writing this patch: > > > https://github.com/llvm/llvm-project/blob/1a7a00bdc99fa2b2ca19ecd2d1069991b3c1006b/clang/lib/AST/ExprConstant.cpp#L8545-L8568 > > > which always seems to evaluate RHS first (and actually abort for C++ <= > > > 14, but for unrelated reasons, probably because this statement is just > > > not supported in a constexpr context there). > > I think the existing implementation is incorrect to accept this in C++14 > > and earlier: > > > > https://eel.is/c++draft/basic.exec#intro.execution-10.sentence-4 > > http://eel.is/c++draft/expr.const#5.8 > I filed a bug on this a while ago that we don't catch unsequenced > modifications in constant expressions contexts: > https://github.com/llvm/llvm-project/issues/37768 > > I am almost sure I had a conversation with @rsmith about this. > Let's add the FIXME comment here as well and come back to address the issue with sequencing later. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D149550/new/ https://reviews.llvm.org/D149550 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
