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

Krzysztof Parzyszek via All-commits all-commits at lists.llvm.org
Tue Sep 23 12:14:10 PDT 2025


  Branch: refs/heads/users/kparzysz/r07-base-variant-argument
  Home:   https://github.com/llvm/llvm-project
  Commit: 2b1bc65cbd8fceffd44a84e0339b5f0965d7f4b1
      https://github.com/llvm/llvm-project/commit/2b1bc65cbd8fceffd44a84e0339b5f0965d7f4b1
  Author: Krzysztof Parzyszek <Krzysztof.Parzyszek at amd.com>
  Date:   2025-09-23 (Tue, 23 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 parsing

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