[Bug c/113905] [OpenMP] Declare variant rejects variant-function re-usage

[burnus at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113905

--- Comment #5 from Tobias Burnus  ---
I have asked at OpenMP.org's lang mailing list. Alex replied:

> This should be invalid (or so was the intent) as the
> construct set doesn’t match.

Thus, it seems as if GCC handles it correctly :-)

(Or at least as intended by (at least one) involved in specifying it.)

[Bug c/113905] [OpenMP] Declare variant rejects variant-function re-usage

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113905

--- Comment #4 from sandra at gcc dot gnu.org ---
Hmmm.  Look also at item 2 at the bottom of page 283, that says that construct
selectors for a variant function are added to its enclosing OpenMP context.  I
thought this was the reason for the restriction; if you've got different
construct contexts, which one do you use to resolve metadirectives or calls to
other variant functions in its body?  I guess that if you want that to work
you'd have to clone the variant function for each base function it's used with.

This probably all ties in with PR 115076, the issue about the current "declare
variant" implementation using global state instead of following the usual
scoping rules.

[Bug c/113905] [OpenMP] Declare variant rejects variant-function re-usage

[burnus at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113905

--- Comment #3 from Tobias Burnus  ---
I bet that the spec writers ment the following (i.e. with the text written in
brackets):

“If a procedure is determined to be a function variant through more than one
declare variant directive [for a given base function] then the construct
selector set of their context selectors must be the same."

The current wording is otherwise a bit odd.

BTW: Besides requiring that their context selector is the same, also
append_args and adjust_args must be effectively the same (ignoring different
parameter names for C/C++ as long as the result of adjust_args effectively the
same).

[Bug c/113905] [OpenMP] Declare variant rejects variant-function re-usage

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113905

--- Comment #2 from sandra at gcc dot gnu.org ---
Isn't this explicitly prohibited by the spec?  Second bullet point at the top
of page 295 in TR13 says:

"If a procedure is determined to be a function variant through more than one
declare variant directive then the construct selector set of their context
selectors must be the same."

[Bug c/113905] [OpenMP] Declare variant rejects variant-function re-usage

[burnus at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113905

--- Comment #1 from Tobias Burnus  ---
Ups, testcase was lost. Re-written from scratch:
---
int var1() { return 1; }
int var2() { return 2; }

#pragma omp declare variant (var1) match(construct={target})
#pragma omp declare variant (var2) match(construct={parallel})
int foo() { return 42; }

#pragma omp declare variant (var2) match(construct={parallel})
#pragma omp declare variant (var2) match(construct={target})
int bar() { return 99; }

int main() {
  __builtin_printf("foo: %d (expected: 42)\n", foo());
  __builtin_printf("bar: %d (expected: 99)\n", bar());
  #pragma omp parallel if(0)
  {
__builtin_printf("foo: %d (expected: 2)\n", foo());
__builtin_printf("bar: %d (expected: 1)\n", bar());
  }
  #pragma omp target //device(-1 /*omp_initial_device*/)
  {
__builtin_printf("foo: %d (expected: 1)\n", foo());
__builtin_printf("bar: %d (expected: 2)\n", bar());
  }
}