Hi Iain,
If one wanted to prioritize library SO name stability - then, perhaps, the
approach Jonathan mentioned has been used for libstdc++ (add new
symbols for ieee128 with a different mangling to the existing r/c_16 ..)
would be preferable (the FE then has to choose the relevant symbol/
mangling depending on target).
That's not all that would have to be changed. Consider
write (*,*) 1.0_16
end program
which is translated (using -fdump-tree-original) to
_gfortran_st_write (&dt_parm.0);
{
static real(kind=16) C.3873 = 1.0e+0;
_gfortran_transfer_real128_write (&dt_parm.0, &C.3873, 16);
}
_gfortran_st_write_done (&dt_parm.0);
so we actually pass a separate kind number as well (why, I'm not sure).
We would have to go through libgfortran with a fine comb to find all
the occurrences. Probably some m4 hackery in iparm.m4 and ifunction.m4.
So, doable from the library side, if some work.
Things get interesting for user code, calling a routine compiled
for double double with newer IEEE QP will result in breakage.
We cannot use the KIND number to differentiate, because we must
assume that people have used KIND=16 and selected_real_kind(30)
interchangably, and we certainly do not want to nail people to
the old double double precision on hardware for which IEEE QP
is available. So, KIND=15 for IEEE QP is out.
It's not an easy problem, unfortunately.
