https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118488
--- Comment #8 from waffl3x <waffl3x at protonmail dot com> --- (In reply to Jakub Jelinek from comment #7) > (In reply to waffl3x from comment #6) > > > > Reposting from PR118791, > > > > (OpenMP 6.0 113:1-2) > > variant substitution > > The replacement of a call to a base function by a call to a function > > variant > > > > I would argue this specifies that would be required, but I recognize > > the can of worms this is opening so more discussion is probably > > warranted. > > I think that is meant for the simd stuff only. > Say int base (int, int, float); then could map to __v8si variant (__v8si, > __v8si, __v8sf); or __v4si variant2 (__v4si, __v4si, __v4sf); etc. based on > the simd length in the loop etc. > This is something we don't implement yet and I think clang doesn't either. I don't think that is what is being described here, also I would assume the transformations that they describe in the section you're referencing would be made at the call site if substitution occurred. This impacts both name lookup for the variant function, and how arguments are passed along. I don't think it conflicts with my interpretation of (OpenMP 6.0 113:1-2), but I do think it causes implementation difficulties, but I digress. I couldn't find any other sections that expand upon how variant substitution is supposed to be handled, but I did find something else. See OpenMP 6.0, 187:10-16 as it is formatted too much to include here. The relevant lines are 14 and 16: 14 lvalue-expression = target-call ( [expression-list] ); 16 target-call ( [expression-list] ); This is specific to dispatch, so I'm pretty certain it doesn't apply everywhere, but at least in a "function-dispatch structured block" explicit template arguments appear to be ill-formed. It seems to me we need more input from OpenMP on whether this was intended to be the case more generally and they forgot to do so, or if the lack of explicit template arguments here is just an oversight.
