From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id AEAB53857832 for ; Thu, 4 Mar 2021 01:01:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AEAB53857832 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 1240XRPE134739; Wed, 3 Mar 2021 20:01:40 -0500 Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 372met1acf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Mar 2021 20:01:40 -0500 Received: from m0098416.ppops.net (m0098416.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 1240vLaA046202; Wed, 3 Mar 2021 20:01:40 -0500 Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0b-001b2d01.pphosted.com with ESMTP id 372met1ac0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Mar 2021 20:01:39 -0500 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 1240qCTd018232; Thu, 4 Mar 2021 01:01:39 GMT Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by ppma03dal.us.ibm.com with ESMTP id 3720r0hh4s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 04 Mar 2021 01:01:39 +0000 Received: from b01ledav002.gho.pok.ibm.com (b01ledav002.gho.pok.ibm.com [9.57.199.107]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 12411caX26870242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 4 Mar 2021 01:01:38 GMT Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 97D0F12405A; Thu, 4 Mar 2021 01:01:38 +0000 (GMT) Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3343D124054; Thu, 4 Mar 2021 01:01:38 +0000 (GMT) Received: from ibm-toto.the-meissners.org (unknown [9.65.200.124]) by b01ledav002.gho.pok.ibm.com (Postfix) with ESMTPS; Thu, 4 Mar 2021 01:01:38 +0000 (GMT) Date: Wed, 3 Mar 2021 20:01:36 -0500 From: Michael Meissner To: Joseph Myers Cc: Michael Meissner , Segher Boessenkool , Bill Schmidt , David Edelsohn , gcc-patches@gcc.gnu.org Subject: Re: [PATCH 2/3 V2] Do not include stdio.h in libgcc's Decimal/Float128 conversions. Message-ID: <20210304010136.GA29907@ibm-toto.the-meissners.org> Mail-Followup-To: Michael Meissner , Joseph Myers , Segher Boessenkool , Bill Schmidt , David Edelsohn , gcc-patches@gcc.gnu.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> <20210302215306.GL29191@gate.crashing.org> <20210303191256.GA29681@ibm-toto.the-meissners.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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_07:2021-03-03, 2021-03-03 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 malwarescore=0 adultscore=0 mlxlogscore=999 spamscore=0 lowpriorityscore=0 priorityscore=1501 clxscore=1015 phishscore=0 impostorscore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103040001 X-Spam-Status: No, score=-5.0 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: Thu, 04 Mar 2021 01:01:44 -0000 On Wed, Mar 03, 2021 at 11:33:52PM +0000, Joseph Myers wrote: > On Wed, 3 Mar 2021, Michael Meissner via Gcc-patches wrote: > > > 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. > > I'm not sure exactly what the machine-independent requirement is, but > _Float128 is supported for 32-bit x86, riscv, sparc and s390 at least. > > There's no support for _Float128 in the 32-bit powerpc ABI, but I don't > think there is anything architecture-independent preventing such support > on 32-bit platforms where TImode is unsupported (i.e. not supported by the > scalar_mode_supported_p hook). The problem is several parts of GCC insists that there be an integer MODE that is the same size as the scalar MODE. I recall it happens in moves (such as during calls), but it could be other places as well. In theory, it would be nice to get this fixed, but the practicality is you can go down a lot of places to find the next bug and fix that. Maybe there is somebody who has enough time and patience to fix all of the places that demand that there be an integer type large enough to hold scalar types like _Float128 and generate alternate code. Or perhaps implement enough of TImode so that it doesn't cause issues. But in order to do the work and make sure it does not cause issues for 32-bit and hardware _Float128, you need to build on a big endian power9 system. In the compile farm there is gcc135, but it is run little endian. BTW, during the initial development of MMA, I ran into the same issue for the vector pair and vector quad types. Each of the approaches that we took had some serious issues. What I did in the initial stages of development is add dummy moves that would never succeed for 256 and 512-bit integers, and then use partial integers to represent that these weren't quite real integers. However, even then we discovered various parts of the compiler would strip off the partial integer type and use the full integer type, even though there was no real support for that type. Peter and Aaron eventually solved this by adding support for opaque modes. However, Float128 needs to be a scalar floating point mode, not an opaque mode. -- 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