From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 03F16388C021 for ; Tue, 2 Mar 2021 21:25:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 03F16388C021 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 122LFQ34131521; Tue, 2 Mar 2021 16:25:37 -0500 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 371w45gby8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Mar 2021 16:25:37 -0500 Received: from m0098417.ppops.net (m0098417.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 122LHegl149821; Tue, 2 Mar 2021 16:25:36 -0500 Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com with ESMTP id 371w45gbxm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Mar 2021 16:25:36 -0500 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 122LCXwV029874; Tue, 2 Mar 2021 21:25:36 GMT Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by ppma02dal.us.ibm.com with ESMTP id 3710sqnnq4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Mar 2021 21:25:36 +0000 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp22034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 122LPZlw41287974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 2 Mar 2021 21:25:35 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 16CA5B205F; Tue, 2 Mar 2021 21:25:35 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A15ADB2065; Tue, 2 Mar 2021 21:25:34 +0000 (GMT) Received: from ibm-toto.the-meissners.org (unknown [9.65.200.124]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTPS; Tue, 2 Mar 2021 21:25:34 +0000 (GMT) Date: Tue, 2 Mar 2021 16:25:33 -0500 From: Michael Meissner To: Segher Boessenkool Cc: 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: <20210302212532.GA17674@ibm-toto.the-meissners.org> Mail-Followup-To: Michael Meissner , Segher Boessenkool , gcc-patches@gcc.gnu.org, David Edelsohn , Bill Schmidt , Peter Bergner , Joseph Myers References: <20210301171432.GA7962@ibm-toto.the-meissners.org> <20210301171852.GB9185@ibm-toto.the-meissners.org> <20210301231544.GG29191@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210301231544.GG29191@gate.crashing.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-02_08:2021-03-01, 2021-03-02 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 mlxscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 bulkscore=0 clxscore=1015 adultscore=0 lowpriorityscore=0 priorityscore=1501 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103020160 X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: 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:25:40 -0000 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. 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. Note the second issue would affect x86_64 cross compilers as well, since they use those two functions to do the _Float128/Decimal versions. 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. I don't think rewriting the Decimal conversions not to use GLIBC is really practical. I certainly do not have the FP math skills to do this without losing precision, etc. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meissner@linux.ibm.com, phone: +1 (978) 899-4797