libquadmath, glibc, and the Q format flag

[Florian Weimer]

* Jakub Jelinek:

> On Wed, Feb 01, 2023 at 11:56:42AM +0100, Florian Weimer via Gcc wrote:
>> I recently discovered that libquadmath registers custom printf callbacks
>> on load.  As far as I can tell, this is done so that the Q format flag
>> can be used to print floating point numbers, using format strings such
>> as "%Qf".  To enable Q flag processing, libquadmath has to register
>> replacements for all floating point format specifiers (aAeEfFgG).
>> 
>> Unfortunately, this has the side effect that even with out the Q flag,
>> printing any floating point number enters a generic, slow path in glibc,
>> prior to the number formatting itself.  The effect is quite pronounced.
>> For example this admittedly silly benchmarking script
>> 
>>     for i=1,5000000 do
>>         print(i, i * math.pi)
>>     end
>> 
>> runs for 5.8 seconds without libquadmath.so.0 loaded on my x86-64
>> system.  With libquadmath.so.0 from GCC 12 loaded, it runs for 6.3
>> seconds.
>> 
>> This impacts most (all?) Fortran code on GNU/Linux because libgfortran
>> depends on libquadmath.
>
> Not anymore.
> If GCC is configured against new enough glibc (with _Float128 support)
> libgfortran.so.5 is no longer linked against -lquadmath, and -lquadmath
> is added only --as-needed to ld command line, so if all the Fortran object
> files that need real(kind=16) (or quad complex) are built by such configured
> GCC, -lquadmath is not linked in (just needs to be present).

Hmm, I missed that recent change.

Would it make sense to drop the libgfortran RPM dependency on
libquadmath in Fedora rawhide?

> And, even for C, users can just use the standard glibc _Float128 support
> (if they don't mind strfromf128) if they target new enough glibc.
> So, libquadmath should be left over for non-glibc uses or uses with old
> glibc.
>
>> Would it make sense to transplant the implementation of the Q specifier
>> from libquadmath to glibc, and disable the registration code in
>> libquadmath if glibc is recent enough?  At least for the targets that
>> today have float128 support in glibc?
>
> Thus I'm not sure it is worth it.

Yeah, if most implicit libquadmath uses are history, then it's probably
not going to be needed (unless some standard suggests to use the Q
flag).

Thanks,
Florian