libgfortran.so SONAME and powerpc64le-linux ABI changes (2nd patch)

[Thomas Koenig]

Hi Michael,

> It adds target hooks so the back end can overwrite the kind number for types.
> I made the IBM long double type use KIND=15 instead of KIND=16, and Float128
> uses KIND=16 as we've discussed.  The tests for long double are still
> failing, so I suspect we will need some way of signalling about the long double
> which uses a funky kind (king=15).

There is still no conclusion how to deal with the two 16-bit types.  I
have also asked on the J3 mailing list, and received a few different
opinions and options as well.

We can:

- Support KIND=16 == IEEE_QP only in the compiler, and supply a CONVERT
   option from IBM_QP to IEEE_QP only.  People who would need the old
   format (why anybody would do that, I have no idea, but some may)
   would have to use the old compiler.

- Support KIND=16 == IEEE_QP and KIND=15 = IBM_QP in the compiler, and
   implement SELECTED_REAL_KIND according to the Fortran standard.  This
   would mean that people who put in a precision of 20 digits as a
   shorthand for REAL(KIND=16) will get the old version.  This will
   lead to endless confusion, and penalize people who used
   SELECTED_REAL_KIND, so it should be avoided.

- Support KIND=16 == IEEE_QP and KIND=15 = IBM_QP in the compiler, and
   have SELECTED_REAL_KIND return 16 for anything above double precision.
   This would actually violate the Fortran standard, and has been
   generally viewed by J3 as not a good idea.  It would, however, work
   well for most users.  Those who actually need IBM_QP would have to
   specify it specifically.

- Have a compiler switch which selects between IEEE_QP and IBM_QP.
   This was a suggestion by Steve Lionel formerly of DEC and Intel,
   and they did that when they had a few floating point formats on
   the Alpha to choose from.  We would then have to specially annotate
   the KIND=16 library routines, and also maybe indicate the different
   argument types in module files.  Anything else would be user error.
   They also had the CONVERT options to go with it.

Question: Which option would we want to pursue?  I actually think the
fourth one (the suggestion by Steve Lionel) is the best one.

Other opinions?

Best regards

	Thomas