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

[Iain Sandoe <idsandoe@googlemail.com>]

Hi Thomas,

recognising that this is complex - the intent here is to see if there are ways
to partition the problem (where the pain falls does depend on the choices
made).

perhaps:

 *A  library (interface, name)
 *B  compiler internals
 *C  user-facing changes

> On 8 Oct 2021, at 17:26, Thomas Koenig <tkoenig@netcologne.de> wrote:
> 

>> 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).

(A) the points here ^^ are:

1/ the SO name could be left as it is
2/ a target that defaulted to QP routines would still (perhaps under
   some command line flag be able to use the older implementation).

I think both of those could be very helpful to end-users…

> 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.

(B) This is the second area of interest, the fact that changes in the compiler internals
would be needed - and those take the time of the volunteers to implement (believe
me, I am painfully aware of how that pressure falls).

> 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.

> 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.  

you don’t *have* to use the KIND number to differentiate to the library or the compiler
(although some alternate, more flexible, token would have to be invented).

(C) It’s the mapping between that internal token and the user’s view of the world that
needs to be defined in terms of what the combination of platform and command line
flags implies to the treatment of KIND=NN and selected_real_kind().

> So, KIND=15 for IEEE QP is out.

(C) I must confess this kind of change is where things seem very tricky to me.

changing how the language represents things seems to be something
that would benefit from agreement between compiler vendors

> It's not an easy problem, unfortunately.

no. it is not.
Iain