[all-commits] [llvm/llvm-project] d73ffe: [flang][OpenMP] Introduce variant argument, custom...

Krzysztof Parzyszek via All-commits all-commits at lists.llvm.org
Thu Sep 25 05:59:20 PDT 2025


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: d73ffe57f983c8ef9490e420d972ae3373b3f175
      https://github.com/llvm/llvm-project/commit/d73ffe57f983c8ef9490e420d972ae3373b3f175
  Author: Krzysztof Parzyszek <Krzysztof.Parzyszek at amd.com>
  Date:   2025-09-25 (Thu, 25 Sep 2025)

  Changed paths:
    M flang/include/flang/Parser/dump-parse-tree.h
    M flang/include/flang/Parser/parse-tree.h
    M flang/lib/Parser/openmp-parsers.cpp
    M flang/lib/Parser/unparse.cpp
    M flang/lib/Semantics/resolve-names.cpp

  Log Message:
  -----------
  [flang][OpenMP] Introduce variant argument, customize OmpArgument par… (#160372)

…sing

The DECLARE_VARIANT directive takes two names separated by a colon as an
argument: base-name:variant-name. Define OmpBaseVariantNames to
represent this, since no existing argument alternative matches it.

However, there is an issue. The syntax "name1:name2" can be the argument
to DECLARE_VARIANT (if both names are OmpObjects), but it can also be a
reduction-specifier if "name2" is a type. This conflict can only be
resolved once we know what the names are, which is after name resolution
has visited them. The problem is that name resolution has side-effects
that may be (practically) impossible to undo (e.g. creating new symbols,
emitting diagnostic messages).

To avoid this problem this PR makes the parsing of OmpArgument
directive- sensitive: when the directive is DECLARE_VARIANT, don't
attempt to parse a reduction-specifier, consider OmpBaseVariantNames
instead. Otherwise ignore OmpBaseVariantNames in favor of
reduction-specifier.



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