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
