Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Thomas Koenig <tkoenig@netcologne.de>]

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