-
Notifications
You must be signed in to change notification settings - Fork 13.7k
[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
Merged
Merged
Changes from all commits
Commits
Show all changes
13 commits
Select commit
Hold shift + click to select a range
a89ed30
[Clang] Implement P2809: Trivial infinite loops are not Undefined Beh…
cor3ntin 5671ea9
Remove the mustprogress attributes on functions.
cor3ntin c7293a0
Fix release notes
cor3ntin 2d9290b
Address Erich's feedback
cor3ntin 0323287
Fix release notes (take 2)
cor3ntin 7d8aa18
Revert "Remove the mustprogress attributes on functions."
cor3ntin 9e656a8
Fix tests and Address Shafik's comments
cor3ntin 043132f
Merge remote-tracking branch 'llvm_be_very_careful/main' into corenti…
cor3ntin b99e8b2
Format
cor3ntin 6b43d8c
Format again
cor3ntin d97c458
Merge remote-tracking branch 'llvm_be_very_careful/main' into corenti…
cor3ntin 2acda98
Trivial infinite loops are considered infinite,
cor3ntin aa5f785
Remove useless C99 check
cor3ntin File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -908,6 +908,69 @@ void CodeGenFunction::EmitIfStmt(const IfStmt &S) { | |
incrementProfileCounter(&S); | ||
} | ||
|
||
bool CodeGenFunction::checkIfLoopMustProgress(const Expr *ControllingExpression, | ||
bool HasEmptyBody) { | ||
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 = | ||
!ControllingExpression || | ||
(ControllingExpression->EvaluateAsInt(Result, getContext()) && | ||
Result.Val.isInt()); | ||
|
||
bool CondIsTrue = CondIsConstInt && (!ControllingExpression || | ||
Result.Val.getInt().getBoolValue()); | ||
|
||
// Loops with non-constant conditions must make progress in C11 and later. | ||
if (getLangOpts().C11 && !CondIsConstInt) | ||
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 (CGM.getCodeGenOpts().getFiniteLoops() == | ||
CodeGenOptions::FiniteLoopsKind::Always || | ||
getLangOpts().CPlusPlus11) { | ||
if (HasEmptyBody && CondIsTrue) { | ||
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 +1005,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 +1121,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 +1170,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()); | ||
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The 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 comment
The 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.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The 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 comment
The 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 comment
The 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 comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have any motivation for doing so?
In addition of being extremely mind-bendy, there is no practical application.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The 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 comment
The 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 comment
The 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 comment
The 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: