[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