From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 3D9D43857828 for ; Wed, 3 Mar 2021 19:13:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3D9D43857828 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 123J3LCh030373; Wed, 3 Mar 2021 14:13:01 -0500 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 372f84tg9g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Mar 2021 14:13:00 -0500 Received: from m0098394.ppops.net (m0098394.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 123J4ff4036649; Wed, 3 Mar 2021 14:13:00 -0500 Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0a-001b2d01.pphosted.com with ESMTP id 372f84tg8m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Mar 2021 14:13:00 -0500 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 123JCBiD023111; Wed, 3 Mar 2021 19:12:59 GMT Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by ppma04wdc.us.ibm.com with ESMTP id 3712phs8jd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Mar 2021 19:12:59 +0000 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 123JCwGr28246388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 Mar 2021 19:12:58 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C4235B205F; Wed, 3 Mar 2021 19:12:58 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4C8E2B2067; Wed, 3 Mar 2021 19:12:58 +0000 (GMT) Received: from ibm-toto.the-meissners.org (unknown [9.65.200.124]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTPS; Wed, 3 Mar 2021 19:12:58 +0000 (GMT) Date: Wed, 3 Mar 2021 14:12:56 -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: <20210303191256.GA29681@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> <20210302212532.GA17674@ibm-toto.the-meissners.org> <20210302215306.GL29191@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210302215306.GL29191@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-03_06:2021-03-03, 2021-03-03 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 mlxlogscore=999 mlxscore=0 malwarescore=0 suspectscore=0 spamscore=0 impostorscore=0 bulkscore=0 lowpriorityscore=0 priorityscore=1501 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103030133 X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, 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: Wed, 03 Mar 2021 19:13:05 -0000 On Tue, Mar 02, 2021 at 03:53:06PM -0600, Segher Boessenkool wrote: > 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. Well in general the only supported configuration for _Float128 is 64-bit LE Linux, but this is more due to the infrastructure not supporting it. If you want to support _Float128 on big endian, you need a GLIBC that provides the necessary support. As far as I know, GLIBC does not build the _Float128 support on big endian. You also need to set the minimum CPU to power7, because _Float128 is passed in Altivec registers. I think some of the configure tests use the default cpu used in building GCC (i.e. power4 if you don't use --with-cpu). As we have discussed many times, on 32-bit BE, you cannot use hardware _Float128 support on power9/power10 because there is no TImode in 32-bit. Various machine independent parts of GCC require an integer type to be the same size as basic types. If somebody made TImode work, we can remove the restriction and allow _Float128 to work on 32-bit. With the current compiler on BE, if you use -mcpu=power7 or newer, it will enable the _Float128/__float128 keywords, and generate the code. But until there is an expectation of library support, it won't work for the general user. > > 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? The whole reason for the patches is to provide the support when we flip the default long double type from the IBM 128-bit type to the IEEE 128-bit type that conversions between long double and the Decimal types will succeed. I suspect in real life it won't be an issue, since Decimal is not used that much. But it is more likely people will want to convert between binary long double and Decimal128. I missed the fact that it had hidden dependencies for cross compilers. So I am trying to fix this. > 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. If you remember, the original versions of the patch would only work if you configured the compiler to use GLIBC 2.32 or newer (such as using the --with-advance-toolchain at14.0 option). You did not like this because as you pointed out, you might use a different GLIBC when linking. So I wrote the current patch that uses weak references to see if we did link with GLIBC 2.32. If the library is present, we use the functions in that library. If not, we have to give an approximate answer. I used the existing IBM 128-bit support to do the conversion. Given GLIBC 2.32 is the minimum version of GLIBC that supports IEEE 128-bit long doubles, if you link against an earlier library, you will not get the conversions from long double. You will only get the conversion if you explicitly use _Float128. > > 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. Sure, but it is a massive amount of work. And I don't have the necessary skills to insure that the conversion process will not suffer from errors. -- 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