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.129.124]) by sourceware.org (Postfix) with ESMTPS id ED9993858D39 for ; Wed, 1 Feb 2023 10:56:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ED9993858D39 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=1675249008; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=kLmocT4odQhQdyK9NsaT0KAEDhG5o7T0M/LnqznXdlM=; b=NypWyKxRPwtNudApV5hgfaAiBakWe/63q7K//Gg7TZ5vr/0/UmBt77XUXkrADQE8YyaDkJ UQJDAvvRCwbuY41u/7FiRJ4/xDG8eMzFRtQ9oK4aDHS4O245mA0Z44cJMSyn0ms5lE4okA GkuIzqTj5/d9AWDs6Yvtqu1+JX3HhIs= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-501-Ae4TU0chM9yyTQNbtnT2lA-1; Wed, 01 Feb 2023 05:56:45 -0500 X-MC-Unique: Ae4TU0chM9yyTQNbtnT2lA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 03283800B23; Wed, 1 Feb 2023 10:56:45 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.58]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 02D1540C1255; Wed, 1 Feb 2023 10:56:43 +0000 (UTC) From: Florian Weimer To: libc-alpha@sourceware.org, gcc@gcc.gnu.org, fortran@gcc.gnu.org Subject: libquadmath, glibc, and the Q format flag Date: Wed, 01 Feb 2023 11:56:42 +0100 Message-ID: <87lelhzmad.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.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.6 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: 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. 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? Thanks, Florian