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

[Iain Sandoe <idsandoe@googlemail.com>]

> On 8 Oct 2021, at 23:55, Thomas Koenig via Gcc <gcc@gcc.gnu.org> wrote:
> 
> 
> Hi Iain,
> 
>>> Things get interesting for user code, calling a routine compiled
>>> for double double with newer IEEE QP will result in breakage.
>> That would not happen with the proposal above, since the library would
>> have different entry points for the two formats.
> 
> 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.

Iain

> There is no choice - we need to make object code compiled by the user
> incompatible between the old and the new format on the systems where
> we make the switch.
> 
> This is starting to look like a can of worms from Pandora's box,
> if you pardon my mixed metaphors.

> 
> Best regards
> 
> 	Thomas