-
Notifications
You must be signed in to change notification settings - Fork 14.6k
[Clang] Implement P2809: Trivial infinite loops are not Undefined Behavior #90066
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
a89ed30
5671ea9
c7293a0
2d9290b
0323287
7d8aa18
9e656a8
043132f
b99e8b2
6b43d8c
d97c458
2acda98
aa5f785
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -122,7 +122,7 @@ C++23 Feature Support | |
materialize temporary object which is a prvalue in discarded-value expression. | ||
- Implemented `P1774R8: Portable assumptions <https://wg21.link/P1774R8>`_. | ||
|
||
- Implemented `P2448R2: Relaxing some constexpr restrictions <https://wg21.link/P2448R2>`_. | ||
- Implemented `P2809R3: Trivial infinite loops are not Undefined Behavior <https://wg21.link/P2809R3>`_. | ||
|
||
C++2c Feature Support | ||
^^^^^^^^^^^^^^^^^^^^^ | ||
|
@@ -131,6 +131,8 @@ C++2c Feature Support | |
|
||
- Implemented `P2573R2: = delete("should have a reason"); <https://wg21.link/P2573R2>`_ | ||
|
||
- Implemented `P2573R2: = delete("should have a reason"); <https://wg21.link/P2573R2>`_ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What is going on here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good question! |
||
|
||
|
||
Resolutions to C++ Defect Reports | ||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -908,6 +908,73 @@ void CodeGenFunction::EmitIfStmt(const IfStmt &S) { | |||||
incrementProfileCounter(&S); | ||||||
} | ||||||
|
||||||
bool CodeGenFunction::checkIfLoopMustProgress(const Expr *ControllingExpression, | ||||||
bool IsTrivialCXXLoop) { | ||||||
if (CGM.getCodeGenOpts().getFiniteLoops() == | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this not reversed? If a loop is finite, I thought it is NOT There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hrm... I see this is exsting code, but this confuses me/is reverse from what I thought. |
||||||
CodeGenOptions::FiniteLoopsKind::Always) | ||||||
return true; | ||||||
if (CGM.getCodeGenOpts().getFiniteLoops() == | ||||||
CodeGenOptions::FiniteLoopsKind::Never) | ||||||
return false; | ||||||
|
||||||
// Now apply rules for plain C (see 6.8.5.6 in C11). | ||||||
// Loops with constant conditions do not have to make progress in any C | ||||||
// version. | ||||||
// As an extension, we consisider loops whose constant expression | ||||||
// can be constant-folded. | ||||||
Expr::EvalResult Result; | ||||||
bool CondIsConstInt = | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The following does not have UB according to the standard, but Clang treats it as UB:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. is_constant_evaluated is equivalent to if consteval, i.e. it's true in a context which is manifestly constant-evaluated. So... is the condition manifestly constant-evaluated in this case? If it is, that's fine, I guess, but the standard definition of "manifestly constant-evaluated" should probably be amended to reflect that. Otherwise, I'm not sure how to interpret the standard here; whether an expression is manifestly constant-evaluated changes the way it's represented in the AST. See also #89565. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. One case to consider:
If you treat the condition of the loop as manifestly constant-evaluated, the loop is finite: the condition evaluates to false. If we say it's not manifestly constant-evaluated, but do some sort of constant-evaluation anyway, it's a well-defined infinite loop. If we somehow treat it as manifestly constant-evaluated for the constant evaluation, but don't use the result of the constant evaluation at runtime, it's UB. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess we could also say that if the condition would evaluate to false if we treat it as manifestly constant-evaluated, it's not manifestly constant-evaluated. So we'd amend [expr.const]p20 to say something like: "An expression or conversion is manifestly constant-evaluated if it is [...] the condition of trivially empty iteration statement, is a constant expression when interpreted as a constant-expression, and the constant expression would evaluate to true". There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In any case, addressing this probably doesn't require modifying any of the code in this patch; the change would be to make Sema introduce a ConstantExpr when appropriate. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Do we have any motivation for doing so? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As a standards-wording issue, the standard has to do something here: it doesn't define what it means to constant-evaluate something in a context that isn't manifestly constant-evaluated. As a practical matter, it's very unlikely the precise wording the standard uses actually matters, sure. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This was extensively discussed in CWG. The wording makes the evaluation for the purposes of determining whether the loop is trivially infinite a manifestly constant-evaluated context. It leaves the normal evaluation as not a manifestly constant-evaluated context. The operative words are "interpreted as a constant-expression" in https://eel.is/c++draft/stmt.iter.general#3. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So... we treat it as a manifestly constant-evaluated for the purpose of checking whether the loop is trivial, but then flips to not manifestly constant-evaluated for the actual evaluation at runtime? The wording could use some clarification... Due to the way Sema::CheckForImmediateInvocation works, once we decide an expression is not manifestly constant-evaluated, we can't actually constant-evaluate it, I think; the AST is modified. Maybe we can run constant-evaluation before Sema::CheckForImmediateInvocation runs, though. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes.
The absence of wording to change the condition itself (that is, what is used at runtime) to be manifestly constant-evaluated is intentional. This wording is not unique. It is also used for the determination of constant initialization, which #89565 (that you referred to) points out is also broken in Clang (however, in contrast to the condition case, once determined to be constant initialization, the initializer itself is considered manifestly constant-evaluated).
I think that makes sense. The constant-expression that we are evaluating introduces an immediate function context that suppresses immediate invocations (https://eel.is/c++draft/expr.const#16). Example: struct A {
constexpr A(const int &x) : p(&x) {}
const int *p;
};
consteval A a() { return {42}; }
enum { X = (a(), 0) }; // OK, no immediate invocations; Clang and GCC both accept |
||||||
!ControllingExpression || | ||||||
(ControllingExpression->EvaluateAsInt(Result, getContext()) && | ||||||
Result.Val.isInt()); | ||||||
bool IsTrue = CondIsConstInt && | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
(!ControllingExpression || Result.Val.getInt().getBoolValue()); | ||||||
|
||||||
if (getLangOpts().C99 && CondIsConstInt) | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Where did getLangOpts().C99 come from? I think the old code treated c89/c99/c++98 as equivalent (never must-progress). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Good catch. that is supposed to be C89. I guess C && !c11 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This turns out to just not be useful at all (but harmless) because we end up landing at the end of the function (and return false there) |
||||||
return false; | ||||||
|
||||||
// Loops with non-constant conditions must make progress in C11 and later. | ||||||
if (getLangOpts().C11) | ||||||
return true; | ||||||
|
||||||
// [C++26][intro.progress] (DR) | ||||||
// The implementation may assume that any thread will eventually do one of the | ||||||
// following: | ||||||
// [...] | ||||||
// - continue execution of a trivial infinite loop ([stmt.iter.general]). | ||||||
if (getLangOpts().CPlusPlus11) { | ||||||
if (IsTrivialCXXLoop && IsTrue) { | ||||||
CurFn->removeFnAttr(llvm::Attribute::MustProgress); | ||||||
efriedma-quic marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
return false; | ||||||
} | ||||||
return true; | ||||||
} | ||||||
|
||||||
return false; | ||||||
} | ||||||
|
||||||
// [C++26][stmt.iter.general] (DR) | ||||||
// A trivially empty iteration statement is an iteration statement matching one | ||||||
// of the following forms: | ||||||
// - while ( expression ) ; | ||||||
// - while ( expression ) { } | ||||||
// - do ; while ( expression ) ; | ||||||
// - do { } while ( expression ) ; | ||||||
// - for ( init-statement expression(opt); ) ; | ||||||
// - for ( init-statement expression(opt); ) { } | ||||||
template <typename LoopStmt> static bool hasEmptyLoopBody(const LoopStmt &S) { | ||||||
if constexpr (std::is_same_v<LoopStmt, ForStmt>) { | ||||||
if (S.getInc()) | ||||||
return false; | ||||||
} | ||||||
const Stmt *Body = S.getBody(); | ||||||
if (!Body || isa<NullStmt>(Body)) | ||||||
return true; | ||||||
if (const CompoundStmt *Compound = dyn_cast<CompoundStmt>(Body)) | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It does not look like the test cover the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I added some tests (and test for false conditions, which are not trivial in c++) |
||||||
return Compound->body_empty(); | ||||||
return false; | ||||||
} | ||||||
|
||||||
void CodeGenFunction::EmitWhileStmt(const WhileStmt &S, | ||||||
ArrayRef<const Attr *> WhileAttrs) { | ||||||
// Emit the header for the loop, which will also become | ||||||
|
@@ -942,13 +1009,12 @@ void CodeGenFunction::EmitWhileStmt(const WhileStmt &S, | |||||
// while(1) is common, avoid extra exit blocks. Be sure | ||||||
// to correctly handle break/continue though. | ||||||
llvm::ConstantInt *C = dyn_cast<llvm::ConstantInt>(BoolCondVal); | ||||||
bool CondIsConstInt = C != nullptr; | ||||||
bool EmitBoolCondBranch = !CondIsConstInt || !C->isOne(); | ||||||
bool EmitBoolCondBranch = !C || !C->isOne(); | ||||||
const SourceRange &R = S.getSourceRange(); | ||||||
LoopStack.push(LoopHeader.getBlock(), CGM.getContext(), CGM.getCodeGenOpts(), | ||||||
WhileAttrs, SourceLocToDebugLoc(R.getBegin()), | ||||||
SourceLocToDebugLoc(R.getEnd()), | ||||||
checkIfLoopMustProgress(CondIsConstInt)); | ||||||
checkIfLoopMustProgress(S.getCond(), hasEmptyLoopBody(S))); | ||||||
|
||||||
// When single byte coverage mode is enabled, add a counter to loop condition. | ||||||
if (llvm::EnableSingleByteCoverage) | ||||||
|
@@ -1059,14 +1125,13 @@ void CodeGenFunction::EmitDoStmt(const DoStmt &S, | |||||
// "do {} while (0)" is common in macros, avoid extra blocks. Be sure | ||||||
// to correctly handle break/continue though. | ||||||
llvm::ConstantInt *C = dyn_cast<llvm::ConstantInt>(BoolCondVal); | ||||||
bool CondIsConstInt = C; | ||||||
bool EmitBoolCondBranch = !C || !C->isZero(); | ||||||
|
||||||
const SourceRange &R = S.getSourceRange(); | ||||||
LoopStack.push(LoopBody, CGM.getContext(), CGM.getCodeGenOpts(), DoAttrs, | ||||||
SourceLocToDebugLoc(R.getBegin()), | ||||||
SourceLocToDebugLoc(R.getEnd()), | ||||||
checkIfLoopMustProgress(CondIsConstInt)); | ||||||
checkIfLoopMustProgress(S.getCond(), hasEmptyLoopBody(S))); | ||||||
|
||||||
// As long as the condition is true, iterate the loop. | ||||||
if (EmitBoolCondBranch) { | ||||||
|
@@ -1109,15 +1174,11 @@ void CodeGenFunction::EmitForStmt(const ForStmt &S, | |||||
llvm::BasicBlock *CondBlock = CondDest.getBlock(); | ||||||
EmitBlock(CondBlock); | ||||||
|
||||||
Expr::EvalResult Result; | ||||||
bool CondIsConstInt = | ||||||
!S.getCond() || S.getCond()->EvaluateAsInt(Result, getContext()); | ||||||
|
||||||
const SourceRange &R = S.getSourceRange(); | ||||||
LoopStack.push(CondBlock, CGM.getContext(), CGM.getCodeGenOpts(), ForAttrs, | ||||||
SourceLocToDebugLoc(R.getBegin()), | ||||||
SourceLocToDebugLoc(R.getEnd()), | ||||||
checkIfLoopMustProgress(CondIsConstInt)); | ||||||
checkIfLoopMustProgress(S.getCond(), hasEmptyLoopBody(S))); | ||||||
|
||||||
// Create a cleanup scope for the condition variable cleanups. | ||||||
LexicalScope ConditionScope(*this, S.getSourceRange()); | ||||||
|
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -1465,6 +1465,7 @@ void CodeGenFunction::GenerateCode(GlobalDecl GD, llvm::Function *Fn, | |||||
|
||||||
// Ensure that the function adheres to the forward progress guarantee, which | ||||||
// is required by certain optimizations. | ||||||
// The attribute will be removed if the body contains a trivial empty loop. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
if (checkIfFunctionMustProgress()) | ||||||
CurFn->addFnAttr(llvm::Attribute::MustProgress); | ||||||
|
||||||
|
Uh oh!
There was an error while loading. Please reload this page.