Generated files in libgfortran for Fortran intrinsic procedures (was: Updated Sourceware infrastructure plans)

[Tobias Burnus]

Hi Janne,

Janne Blomqvist wrote:
> back when I was active I did think about this
> issue. IMHO the best of my ideas was to convert these into C++
> templates.

I think this will work – but we have to be super careful:

With C++, there is the problem that we definitely do not want to add 
dependency on libstdc++ nor to use some features which require special 
hardware support (like exceptions [always bad], symbol aliases, ...). — 
On some systems, a full C++ support might be not available, like 
embedded systems (including some odd embedded OS) or offloading devices.

The libstdc++ dependency would be detected by linking as we currently 
do. For in-language features, we have to ensure the appropriate flags 
-fno-exceptions (and probably a few more). And it should be clear what 
language features to use.

If we do, I think that would surely be an option.

> What we're essentially doing with the M4 stuff and the
> proposed in-house Python reimplementation is to make up for lack of
> monomorphization in plain old C. Rather than doing some DIY templates,
> switch the implementation language to something which has that feature
> built-in, in this case C++.  No need to convert the entire libgfortran
> to C++ if you don't want to, just those objects that are generated
> from the M4 templates. Something like
>
> template<typename T>
> void matmul(T* a, T* b, T* c, ...)
> {
>     // actual matmul code here
> }
>
> extern "C" {
>    // Instantiate template for every type and export the symbol
>    void matmul_r4(gfc_array_r4* a, gfc_array_r4* b, gfc_array_r4* c, ...)
>    {
>      matmul(a, b, c, ...);
>    }
>    // And so on for other types
> }

Cheers,

Tobias