Hi Jakub,
0000000000251038 000006ad00000015 R_PPC64_JMP_SLOT 0000000000000000
__cabsieee128 + 0
All these should for POWER_IEEE128 use atan2q@QUADMATH_1.0 etc.
So, seems all these come from f951 compiled sources.
For user code, I think the agreement was if you want to use successfully
-mabi=ieeelongdouble, you need glibc 2.32 or later, which is why the Fortran
FE doesn't conditionalize on whether glibc 2.32 is available or not and just
emits __WHATEVERieee128 entrypoints.
That was the idea, I think.
But for Fortran compiled sources in libgfortran, we need to use
__WHATEVERieee128 only if glibc 2.32 or later and WHATEVERq (from
libquadmath) otherwise.
I guess easiest would be to do this always in the FE, but we need to
determine in the FE if the target is glibc 2.32 or later.
Instead of determining this in the front end, maybe we can add
an option (documented, but marked as useful as only for internal
use and with no guarantee that it will remain) and use that option
when compiling libgfortran.
On the other side, on glibc 2.32+ build, we still use some libquadmath APIs
when we shouldn't:
readelf -Wr
/home/jakub/gcc/obj/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5
| grep QUADMATH
00000000002502c8 0000002600000015 R_PPC64_JMP_SLOT 0000000000000000
fmaq@QUADMATH_1.0 + 0
00000000002505f8 0000006700000015 R_PPC64_JMP_SLOT 0000000000000000
tanq@QUADMATH_1.0 + 0
0000000000250930 0000009b00000015 R_PPC64_JMP_SLOT 0000000000000000
fabsq@QUADMATH_1.0 + 0
0000000000250940 0000009d00000015 R_PPC64_JMP_SLOT 0000000000000000
sinq@QUADMATH_1.0 + 0
0000000000250c98 000000cf00000015 R_PPC64_JMP_SLOT 0000000000000000
copysignq@QUADMATH_1.0 + 0
0000000000251038 0000010700000015 R_PPC64_JMP_SLOT 0000000000000000
cosq@QUADMATH_1.0 + 0
0000000000251068 0000010a00000015 R_PPC64_JMP_SLOT 0000000000000000
fmodq@QUADMATH_1.0 + 0
These should use __fmaieee128, __tanieee128 etc. instead.
This one seems easily fixed by the following patch, ok for power-ieee128?
OK!
Best regards
Thomas
