[PATCH][RFC]Overloading intrinsics

[Richard Biener]

On Thu, Nov 8, 2018 at 7:39 PM Thomas Koenig <tkoenig@netcologne.de> wrote:
>
> Am 08.11.18 um 14:33 schrieb Martin Liška:
> > As Richi mentioned, the list of middle-end built-ins does not scale well.
>
> It is not clear to me what that means. Could you elaborate?
> At the moment, this would still be my preferred solution.
>
> (If it is a problem of too-long lines:  Repeated uses of the
> option with different names should just work, or can
> be made to work).
>
> > So the way discussed in this sub-thread looks preferred.
>
> I have given this some more thought.
>
> First, any solution should include sincos and other functions
> that are not Fortran intrnisics.

As I said I agree with the fact that the Fortran FE needs to annotate
the middle-end builtins.  That means we are talking about a way
to declare/amend the C ABI math functions with additional attributes.

This means that technically using

intrinsic :: ...

isn't correct.  That leaves us with the choice of adding a custom
"pragma" where we can of course choose the syntax freely.
I guess

!GCC$ ...

at the start of a translation unit doesn't affect any behavior you
quote below.

Whether the proposed syntax needs to mimic fortran syntax
remains a question but a simplistic

!GCC$ builtin "sinf" attributes omp-simd-notinbranch

would work up to the point where when parsing this the FE needs
to lookup the corresponding builtin for "sinf".  math-builtins.def
seems to only contain the unsuffixed names and we likely build
variants with f and l somewhere during processing.  But eventually
we should be able to process math-builtins.def for this lookup
(and ignore ones that are not listed given the user would have to
declare a fortran function with appropriate C binding himself).

Note that the sincos vectorized variant from glibc is useless
(it uses the wrong ABI)

> Second, if you include any additional lines from an external
> file, they have to be syntactially valid outside any translation
> unit, or you will run into the exact problem that you
> describe below:
>
> > Does it mean that the '#include "vector-math.f90"' should be put before
> > a program directive?
>
> The problem is that you can start a valid program without a PROGRAM
> statement, so
>
>         intrnisic :: sin
>         end
>
> is a valid program, and for
>
>        intrinsic :: sin
>        program foo
>
> the compiler correctly complains.  So, you need to take out the
> need for the intrinsic:: sin line.
>
> (Also, the user is free to declare a variable sin, although it
> is not advisable).
>
> >> So, you could use either the intrinsic name with the precision or (maybe
> >> that is an even better idea) the name of the C function that is
> >> overloaded.
> >
> > I've got it. It's implemented in attached patch.
>
> It's not quite clear to me Which of the two options you mean :-)
> Regards
>
>         Thomas