Re: [power-ieee128] RFH: LTO broken

[Thomas Koenig <tkoenig@netcologne.de>]

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