From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 554E3385B834 for ; Tue, 24 Mar 2020 23:35:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 554E3385B834 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: MCTUQFeD+hW3Wxy/QsPwGGsLorynr2b8RlItkH2L6dqoGgyURyDUTuKyvtTAA7+8aI0MURTcNS EQHGDDql6bQRQ/BuhIVOWHhpKRFc94AAf7JgMhq8AKCFX97s/WGZupHI9IT66XSLjrogOH7a1B 9BTkZHPhAQnE5O67I6cgyoWA3mQyBIrRa1zbBu4wLXkXerrcmgSDIlzeNH8ooLyXWJXeHrz352 zjOp3jwsggTCuH6UhUHfU7LlLUGTnrjaxCry9OcSMts1PkabicvRQpKJonDdrm4RWSLHp2QN8O zT8= X-IronPort-AV: E=Sophos;i="5.72,302,1580803200"; d="scan'208";a="47074079" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 24 Mar 2020 15:35:50 -0800 IronPort-SDR: AJyXYaLnsegqCB6sCXtpG46N/CtstEiTOhfVnLlLvA9BejQVc+IUrtqcKImR0UdkMSZMB4nTgQ fmdkhIto92kWvnmOgsTVc+gcMLpRVZoL+06ziWbMUzrY0Jh3huUKSuVCwuVRlWmsPnc0Qt+1/Y 1m1Gn8LggnEyuY9AtVJkEFR4xGFC7ShIerlEUdru1PWhDMNoRUVDkwlWrboartYi+yISx4EK+u l0ENEcUxlwbW4PKv0EtRtSdQM7tkNp0o96rUpAbsRvU3BFx2f8/n+QwMhTlNHK0CoESlPZ4g6C MEU= Date: Tue, 24 Mar 2020 23:35:45 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: "Paul E. Murphy" CC: Subject: Re: [PATCH] Improve __LONG_DOUBLE_USES_FLOAT128 commentary In-Reply-To: <20200214225416.28284-1-murphyp@linux.vnet.ibm.com> Message-ID: References: <20200214225416.28284-1-murphyp@linux.vnet.ibm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-03.mgc.mentorg.com (139.181.222.3) To SVR-IES-MBX-03.mgc.mentorg.com (139.181.222.3) X-Spam-Status: No, score=-18.0 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 23:35:52 -0000 On Fri, 14 Feb 2020, Paul E. Murphy wrote: > +/* The macro __LONG_DOUBLE_USES_FLOAT128 is used to determine the > + choice of the underlying ABI of long double during a single compilation. > + > + If the value is non-zero, any API which is parameterized by the long > + double type (i.e the scanf/printf family of functions or the explicitly > + parameterized math.h functions) will be redirected to a compatible > + implementation using _Float128 ABI via symbols suffixed with ieee128. > + > + These redirections usually take the form of an "ASM Label" as called out > + int Chapter 6.47.4 in the GCC 9 manual. And in very rare cases, a > + macro. They do not alter or otherwise change the ABI stability of glibc. I don't think this paragraph about how the redirections are implemented should be present at all; it's simply a description of how the redirection macros work, which belongs with the implementation of those macros if anywhere. (And referencing particular section numbers in the GCC manual is a bad idea; section names may be somewhat stable, numbers are very unstable.) > diff --git a/sysdeps/ieee754/ldbl-128ibm-compat/bits/long-double.h b/sysdeps/ieee754/ldbl-128ibm-compat/bits/long-double.h I think it's best for the detailed comment defining the semantics of the macro to be only in the default bits/long-double.h file, with architecture-specific files having comments that only discuss the architecture-specific details for that architecture. That avoids having multiple places that need updating with any improvement to the documentation. -- Joseph S. Myers joseph@codesourcery.com