Hi Bill,
We had previously been concerned about whether the
necessary name mangling support would be possible, but it sounds like you aren't
overly worried about that.
We can always add a letter to the kind number, or use a different
number in the encoding, or someting
This has to be done in fortran/iresolve.c, where the function
name is set, for example, in gfc_resolve_matmul, by
f->value.function.name
= gfc_get_string (PREFIX ("matmul_%c%d"), gfc_type_letter (f->ts.type),
f->ts.kind);
Easy enough to add something there if ts.type is BT_REAL,
ts.kind is 16 and the compiler is currently using
double double (for example), or just use KIND=15 then
(although that would only be a naming convention).
On the library side, it could become a bit harier, because there
is some m4 stuff going on there, and as we all know, m4 is sort
of a write-only language...
The place to look into are the macro definitions in
libgfortran/iparm/iparm.m4. If we leave these alone
(which might be easier), we could then define GFC_REAL_15
to be IBM long double and change the Makefile.am to make
sure they are compiled with the right options.
As far as I can see, the rtype_kind and atype_kind numbers
are never used in calculations, just for namings, so we
should be safe.
As far as the other functions are concerned, we have the
list in gfortran.map. Anything with _r16 should have a
_r15 equivalent.
Hmm... one question there. I assume there is no problem if
something in gfortran.map is not present in the library file,
correct? So, I think we should be able to put symbols there
which are unused on other systems.
So, I think the idea of differentiating the two real types
by the KIND number encoded in the file names should work.
Best regards
Thomas
