On 09.10.21 01:18, Iain Sandoe wrote:
I meant the case where the user writes, with an old, KIND=16 is double
double compiler,
subroutine foo(a)
real(kind=16) :: a
a = a + 1._16
end subroutine foo
and puts it in a library or an old object file, and in new code with an
IEEE QP compiler calls that with
real(kind=16) :: a
a = 2._16
call foo(a)
print *,a
this will result in silent generation of garbage values, since Fortran
does not mangle the function name based on it types. For both cases, the
subroutine will be called foo_ (or MOD..._foo).
hmm, well I thought about that case, but … isn’t this “pilot error”?
if one compiles different parts of a project with incompatible command line
options…
… or, say, compile with -mavx512 and then try to run code on hardware without
such a vector unit?
Getting wrong answers silently can likely be done with other command line
option mismatches.
Again, it depends.
What I was thinking about what a scenario where we do not change the
SONAME on POWER and rely on name mangling to get to the correct version
of a libgfortran library function. That could work, but it would not
work for user procedures.
I have thought of mangling the name of all user Fortran procedures
which contain a reference to an IEEE QP in their argument list, like
_foo%QP, but that would fall down for C interop. So, no luck there.
So, a new SONAME at least on POWER is mandatory, I think.
The question is still if we can avoid a new SONAME for >99% of our users
for no gain at all for them. Is there a possibility of aliasing the
SONAME somehow (grasping at straws here)?
Best regards
Thomas
