libquadmath, glibc, and the Q format flag

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

	Jakub