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

Tobias Burnus
2024-04-18T12:02:31Z

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