[all-commits] [llvm/llvm-project] 3188e9: [clang][OpenMP] Diagnose badly-formed collapsed im...

Julian Brown via All-commits all-commits at lists.llvm.org
Mon Aug 19 06:37:53 PDT 2024


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 3188e9b4e0f106abd683829906a21a98655bb794
      https://github.com/llvm/llvm-project/commit/3188e9b4e0f106abd683829906a21a98655bb794
  Author: Julian Brown <julian.brown at amd.com>
  Date:   2024-08-19 (Mon, 19 Aug 2024)

  Changed paths:
    M clang/include/clang/Basic/DiagnosticSemaKinds.td
    M clang/lib/Sema/SemaOpenMP.cpp
    A clang/test/OpenMP/loop_collapse_1.c
    A clang/test/OpenMP/loop_collapse_2.cpp

  Log Message:
  -----------
  [clang][OpenMP] Diagnose badly-formed collapsed imperfect loop nests (#60678) (#101305)

This patch fixes a couple of cases where Clang aborts with loop nests
that are being collapsed (via the relevant OpenMP clause) into a new,
combined loop.

The problematic cases happen when a variable declared within the loop
nest is used in the (init, condition, iter) statement of a more
deeply-nested loop. I don't think these cases (generally?) fall under
the non-rectangular loop nest rules as defined in OpenMP 5.0+, but I
could be wrong (and anyway, emitting an error is better than crashing).

In terms of implementation: the crash happens because (to a first
approximation) all the loop bounds calculations are pulled out to the
start of the new, combined loop, but variables declared in the loop nest
"haven't been seen yet". I believe there is special handling for
iteration variables declared in "for" init statements, but not for
variables declared elsewhere in the "imperfect" parts of a loop nest.

So, this patch tries to diagnose the troublesome cases before they can
cause a crash. This is slightly awkward because at the point where we
want to do the diagnosis (SemaOpenMP.cpp), we don't have scope
information readily available. Instead we "manually" scan through the
AST of the loop nest looking for var decls (ForVarDeclFinder), then we
ensure we're not using any of those in loop control subexprs
(ForSubExprChecker). All that is only done when we have a "collapse"
clause.

Range-for loops can also cause crashes at present without this patch, so
are handled too.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications


More information about the All-commits mailing list