[flang-commits] [flang] [flang][PFT-to-MLIR] Do not wrap the DO of an OpenMP loop construct (PR #216280)

[Tom Eccles via flang-commits]

================
@@ -2497,74 +2498,125 @@ hasIncomingBranch(const Fortran::lower::pft::Evaluation &construct) {
   return walk(funit->evaluationList);
 }
 
-/// True if \p eval is a DoConstruct driven directly into an enclosing acc.loop
-/// by the OpenACCLoopConstruct / OpenACCCombinedConstruct lowering — the
-/// immediate body DO, or one of the N collapsed iterator DOs reached by
-/// walking down from the body DO under a `collapse(N)` clause.
-static bool isAccLoopBody(const Fortran::lower::pft::Evaluation &eval) {
+/// The DoConstructs enclosing (and including) a DO evaluation; index k holds
+/// the one at depth k, so index 0 is the evaluation's own DO.
+using DoConstructChain = llvm::SmallVector<const parser::DoConstruct *, 4>;
+
+/// Value of \p intExpr, or INT64_MAX if it isn't a compile-time constant.
+static int64_t
+constantValueOrMax(const parser::ScalarIntConstantExpr &intExpr) {
+  if (const auto *expr = semantics::GetExpr(intExpr))
+    if (auto v = evaluate::ToInt64(*expr))
----------------
tblah wrote:

I don't think there is any guarantee that the integer is representable inside of an i64.

For this particular usage it is hard to imagine how one would write source code which would get through semantics and trigger an overflow here, but I think it at least warrants an assertion and a mention in the doc comment of the function.

https://github.com/llvm/llvm-project/pull/216280