From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id F15CF3858C5F for ; Wed, 1 Feb 2023 11:29:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F15CF3858C5F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675250948; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zrTvnOs4wLZ5cqBDVhzeCyfszyhKepIM7mR47yediy8=; b=g7HR+E/k9Q7GB60LEASCwBTXAi/EG2rHkEY2zmnu5pEy7OROixn7bC2vfxB/5i3uvhR0N1 EV70D5WCfIl60MyEbB1PgBIH3XDkoTlMp5ToBQzdR++pIr/8BKHO4mD5xfob43uAtAGRm3 9rde6bZKswZVVQtTjaeJ3WJGw4g6tEA= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-58-gQ7OBzi3M9WAE0oxvpE4Mg-1; Wed, 01 Feb 2023 06:29:05 -0500 X-MC-Unique: gQ7OBzi3M9WAE0oxvpE4Mg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 64B082A59561; Wed, 1 Feb 2023 11:29:05 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.58]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 51A0E112132C; Wed, 1 Feb 2023 11:29:04 +0000 (UTC) From: Florian Weimer To: Jakub Jelinek Cc: libc-alpha@sourceware.org, gcc@gcc.gnu.org, fortran@gcc.gnu.org Subject: Re: libquadmath, glibc, and the Q format flag References: <87lelhzmad.fsf@oldenburg.str.redhat.com> Date: Wed, 01 Feb 2023 12:29:02 +0100 In-Reply-To: (Jakub Jelinek's message of "Wed, 1 Feb 2023 12:07:13 +0100") Message-ID: <878rhhzksh.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * 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