================
@@ -3371,6 +3379,20 @@ Sema::ActOnBreakStmt(SourceLocation BreakLoc, Scope
*CurScope) {
if (S->isOpenMPLoopScope())
return StmtError(Diag(BreakLoc, diag::err_omp_loop_cannot_use_stmt)
<< "break");
+
+ // OpenACC doesn't allow 'break'ing from a compute construct, so diagnose if
+ // we are trying to do so. This can come in 2 flavors: 1-the break'able
thing
+ // (besides the compute construct) 'contains' the compute construct, at which
+ // point the 'break' scope will be the compute construct. Else it could be a
+ // loop of some sort that has a direct parent of the compute construct.
+ // However, a 'break' in a 'switch' marked as a compute construct doesn't
+ // count as 'branch out of' the compute construct.
+ if (S->isOpenACCComputeConstructScope() ||
+ (!S->isDirectlySwitchScope() && S->getParent() &&
----------------
alexey-bataev wrote:
> A case like above just says "error: 'break' statement not in loop or switch
> statement", which seems inaccurate for OpenACC given the 'ignorability'
> requirement of the language.
What is "ignorability"? Sorry, just asking to understand the context more
correctly.
> ALSO, it doesn't help the 'continue' case, where the inverse is the
> requirement (a continue on the 'annotated loop' is perfectly fine, but not
> one that would jump out of the pragma).
This should be handled by getContinueParent, which is also handled by FnScope.
These constructs, if enabled, should be pretty similar to lambdas, so I assume
it should be fine to diagnose dangling break/continue here. The diagnostics
might be improved, though.
https://github.com/llvm/llvm-project/pull/82543
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
