https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118791
--- Comment #9 from waffl3x <waffl3x at protonmail dot com> --- (In reply to Jason Merrill from comment #6) > omp_declare_variant_finalize_one works by building a forwarding call to the > variant, i.e. rvalue_int_variant(std::forward<T&&>(p)). Normal template > argument deduction from T&& vs int&& then deduces int for T, as substituting > int for T produces int&&, which is the desired type. Note that the decltype > checks pass. > > It's not clear to me that this behavior is wrong; the OpenMP standard says > nothing about templates. (OpenMP 6.0, 328:30) For a function variant to be a replacement candidate to be called instead of the base function, I interpret this to mean that the function variant is called instead of the base function, so I would assume deduction should be as if the variant were called directly. But... (In reply to Jakub Jelinek from comment #7) > The OpenMP wording here (taken from 6.0 but I think it hasn't changed much > over the years) is: > > "The function variant is determined by base language standard name lookup > rules ([basic.lookup]) of variant-name using the argument types at the call > site after implementation defined changes have been made according to the > OpenMP context." > > Note, it was a result of your suggestion how to do it (the original proposal > was to mark the function the other way, on variant says that it is a variant > of some base but with overloaded functions and templates that isn't clear > how that would work at all. > > The "implementation defined changes" are just for simd, so in this testcase > it should be really just the argument dependent lookup with the given > argument types. I'm not sure how that would conflict with this stuff, I was initially thinking it might be inconsequential for this bug but thinking about it more I'm not so sure.
