> On 9 Oct 2021, at 10:11, Thomas Koenig <tkoe...@netcologne.de> wrote:
>
>
> 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.
What I’m missing is why it has to.
IF the user wants to use old (or not-owned) code compiled for double-double,
then
she must select a command-line option to use that on Power(New).
Else
The user recompiles all the code in her project to use the new shiny QP.
I doubt there’s a way for this to proceed in a way that a user of Power (New)
can
avoid having to think it through - a new library SO name won’t help them with
the
interop with thier own (or not owned) code.
> 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.
agreed, I did the same thought exercise.
> 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
