https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115076
Bug ID: 115076
Summary: [OpenMP] "declare variant" scoping rules and
visibility
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
CC: burnus at gcc dot gnu.org
Target Milestone: ---
Created attachment 58196
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58196&action=edit
test case
The OpenMP 5.0 spec says: "If the context selector that is associated with a
declared function variant is compatible with the OpenMP context of a call to a
base function according to the matching rules defined in Section 2.3.3 then a
call to the variant is a candidate to replace the base function call."
The 5.1 spec (and later versions) add the requirement that the declare variant
be "visible" at the call site (it uses this term generally to refer to visible
according to the scoping rules of the base language):
"If a declare variant directive for the base function is visible at the call
site and the static part of the context selector that is associated with the
declared function variant is compatible with the OpenMP context of the call
according to the matching rules defined in Section 2.3.3 then the variant is a
replacement candidate to be called instead of the base function."
GCC's present implementation of "declare variant" dates back to the initial 5.0
spec for this feature. The front ends store "declare variant" info on
attributes on the base function, and the list of candidates for each call site
isn't produced until gimplification, based on "declare variant" directives
collected everywhere in the compilation unit and recorded on the associated
decl. This leads to surprising behavior; in each of the attached test cases,
both calls to foo() are resolved to baz() even though the "declare variant"
directive isn't in scope at the first call.
It seems to me that the list of visible variants needs to be collected by the
front ends at each call site and inserted into the tree structure produced,
instead of relying on global attributes. Perhaps the existing
OMP_METADIRECTIVE tree node type could be adapted/re-used here, similar to how
the patch set for adding dynamic selector support
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650725.html
re-uses the gimple metadirective data structures for late resolution of
"declare variant" as well.
