From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 6C0AA3861026 for ; Tue, 2 Mar 2021 21:54:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6C0AA3861026 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 122Lr787013598; Tue, 2 Mar 2021 15:53:07 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 122Lr69S013594; Tue, 2 Mar 2021 15:53:06 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 2 Mar 2021 15:53:06 -0600 From: Segher Boessenkool To: Michael Meissner , gcc-patches@gcc.gnu.org, David Edelsohn , Bill Schmidt , Peter Bergner , Joseph Myers Subject: Re: [PATCH 2/3 V2] Do not include stdio.h in libgcc's Decimal/Float128 conversions. Message-ID: <20210302215306.GL29191@gate.crashing.org> References: <20210301171432.GA7962@ibm-toto.the-meissners.org> <20210301171852.GB9185@ibm-toto.the-meissners.org> <20210301231544.GG29191@gate.crashing.org> <20210302212532.GA17674@ibm-toto.the-meissners.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210302212532.GA17674@ibm-toto.the-meissners.org> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2021 21:54:13 -0000 On Tue, Mar 02, 2021 at 04:25:33PM -0500, Michael Meissner wrote: > On Mon, Mar 01, 2021 at 05:15:44PM -0600, Segher Boessenkool wrote: > > On Mon, Mar 01, 2021 at 12:18:52PM -0500, Michael Meissner wrote: > > > The _sprintfkf.c file was including stdio.h to get the definition of sprintf. > > > > (declaration of) > > > > > This patch modifies this so that stdio.h is not included in order to support > > > freestanding cross compilers that might not provide stdio.h. > > > > So the code cannot work at all there? Will not link? > > > > > + We use __builtin_sprintf so that we don't have to include stdio.h to define > > > + sprintf. Stdio.h might not be present for freestanding cross compilers that > > > + do not need to include a library. */ > > > > "declare sprintf", and the function is called stdio.g (all lowercase). > > It is often written , which makes it easier to handle in > > sentences. > > > > > @@ -54,5 +57,5 @@ int __sprintfkf (char *restrict string, > > > if (__sprintfieee128) > > > return __sprintfieee128 (string, format, number); > > > > > > - return sprintf (string, format, (long double) number); > > > + return __builtin_sprintf (string, format, (long double) number); > > > > sprintf as well as __builtin_sprintf do not exist exactly when > > does not (or are not guaranteed to exist, anyway). > > There are 2 issues: > > The first issue is whether you get an error when you are building a cross > compiler and the target you are using does not provide a stdio.h. This is the > error that this patch fixes. I tend to regard not being able to build the > toolchain are higher in priority than whether it works at runtime. And I see both as basic requirements. A patch that adds X should make X work. If you want to make decimal and/or QP float work only on 64-bit LE Linux you should say so. And in that case, that is certainly not acceptable if it doesn't "sorry" at configure time already. > The second is whether you get an error at link time because there is not > sprintf or strtold functions. For normal archive libraries, this would only be > an issue if you actually do the conversion. I have my doubts whether there is > any extant code that wants to convert _Float128 to one of the Decimal types or > vice versa. So what are these patches for at all, again? Anyway, if some conversion doesn't work (or cannot work correctly at all, which is the same thing), you should simply disable the conversion routines themselves (and then cascade that through the possible callers:just make them say "sorry, unimplemented"). > Note the second issue would affect x86_64 cross compilers as well, since they > use those two functions to do the _Float128/Decimal versions. Yes, it cannot work correctly at all there, either. > I am open to suggestions of how to move forward. I think we have to have a way > to build cross compilers without decimal support (i.e. my third patch). > Secondarily, I think we should allow the compiler to be built if there is no > stdio.h, but the user did not disable decimal floating point. Yes. So just do not use it then. Disable the feature that would use it. > I don't think rewriting the Decimal conversions not to use GLIBC is really > practical. It is necessary if you want to support it on any other systems than the one you use. Segher