Message ID | YgvntWSjngfiP75i@toto.the-meissners.org |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 504943858419 for <patchwork@sourceware.org>; Tue, 15 Feb 2022 17:50:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 504943858419 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1644947419; bh=iAMMex+JXhkLVGI8aOz3RHPu0oLakQoHkOCyHvzy5X4=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=ExpfNCzbfEDO2OI/7uldLJfTSlJZCg1xgx1nqQOKTUhP8tHpSxiu2eSAGCOEjD+iw dgO70m/LZ5HP5PWucheWsAPIF5VwCVida9fuViTQRH7D0Xn7RWyQ7GILfx1NVm1uI2 ywTDuEQPuCkNsa99B73CJRQnRiU1rwewCgj6+YlY= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 20A723858C74 for <gcc-patches@gcc.gnu.org>; Tue, 15 Feb 2022 17:49:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 20A723858C74 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 21FHHcEr018292; Tue, 15 Feb 2022 17:49:48 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3e8gesrp0b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Feb 2022 17:49:47 +0000 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 21FHLJ9j025829; Tue, 15 Feb 2022 17:49:47 GMT Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com with ESMTP id 3e8gesrp04-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Feb 2022 17:49:46 +0000 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 21FHmXts022009; Tue, 15 Feb 2022 17:49:46 GMT Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by ppma01dal.us.ibm.com with ESMTP id 3e64hc5j5p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Feb 2022 17:49:46 +0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 21FHniSW34799960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 15 Feb 2022 17:49:44 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EE153AE05C; Tue, 15 Feb 2022 17:49:43 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5AD11AE062; Tue, 15 Feb 2022 17:49:43 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.77.136.59]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTPS; Tue, 15 Feb 2022 17:49:43 +0000 (GMT) Date: Tue, 15 Feb 2022 12:49:41 -0500 To: gcc-patches@gcc.gnu.org, Michael Meissner <meissner@linux.ibm.com>, Segher Boessenkool <segher@kernel.crashing.org>, David Edelsohn <dje.gcc@gmail.com>, Bill Schmidt <wschmidt@linux.ibm.com>, Peter Bergner <bergner@linux.ibm.com>, Will Schmidt <will_schmidt@vnet.ibm.com> Subject: [PATCH], PR target/99708 - Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__ Message-ID: <YgvntWSjngfiP75i@toto.the-meissners.org> Mail-Followup-To: Michael Meissner <meissner@linux.ibm.com>, gcc-patches@gcc.gnu.org, Segher Boessenkool <segher@kernel.crashing.org>, David Edelsohn <dje.gcc@gmail.com>, Bill Schmidt <wschmidt@linux.ibm.com>, Peter Bergner <bergner@linux.ibm.com>, Will Schmidt <will_schmidt@vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: JLN7USgNcL3g2XhJtFEeNe2YIRjN8mtQ X-Proofpoint-GUID: tdDVXUDYYl9RlfsN8pra8ty1_oqiE6Ta X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-15_04,2022-02-14_04,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 malwarescore=0 spamscore=0 mlxlogscore=936 bulkscore=0 adultscore=0 suspectscore=0 priorityscore=1501 phishscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202150101 X-Spam-Status: No, score=-10.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, KAM_MANYTO, KAM_SHORT, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Michael Meissner via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Michael Meissner <meissner@linux.ibm.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
, PR target/99708 - Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__
|
|
Commit Message
Michael Meissner
Feb. 15, 2022, 5:49 p.m. UTC
Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__. Define the sizes of the PowerPC specific types __float128 and __ibm128 if those types are enabled. I tested this on a little endian power9 system and there were no regressions. Can I check this into the trunk, and after a burn-in period, can I check this into the GCC 10 and 11 branches? 2022-02-15 Michael Meissner <meissner@the-meissners.org> gcc/ PR target/99708 * config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__ if we have float128 support. gcc/testsuite/ PR target/99708 * gcc.target/powerpc/pr99708.c: New test. --- gcc/config/rs6000/rs6000-c.cc | 12 ++++++++++-- gcc/testsuite/gcc.target/powerpc/pr99708.c | 21 +++++++++++++++++++++ 2 files changed, 31 insertions(+), 2 deletions(-) create mode 100644 gcc/testsuite/gcc.target/powerpc/pr99708.c
Comments
On Tue, Feb 15, 2022 at 12:49:41PM -0500, Michael Meissner wrote: > Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__. > > Define the sizes of the PowerPC specific types __float128 and __ibm128 if those > types are enabled. This is very silly of course, both of these are 16 bytes. Abusing this to see if the types exist is at least as silly (there are much better mechanisms to do this). So, this facilitates bad habits and bad code. But, whatever, the macros are just stating totally obvious and redundant facts, no problem, let's just ignore that pepople only want it to abuse it. > gcc/ > PR target/99708 > * config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Define > __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__ if we have float128 > support. No. __SIZEOF_IBM128__ should be defined if and only if __ibm128 is defined. This should be tested directly, it should not depend on that some other code did what it does today. That would also make the code much more obvious. Segher
On Tue, Feb 15, 2022 at 01:45:06PM -0600, Segher Boessenkool wrote: > On Tue, Feb 15, 2022 at 12:49:41PM -0500, Michael Meissner wrote: > > Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__. > > > > Define the sizes of the PowerPC specific types __float128 and __ibm128 if those > > types are enabled. > > This is very silly of course, both of these are 16 bytes. Abusing this > to see if the types exist is at least as silly (there are much better > mechanisms to do this). This is just trying to close out the PR that people asked for. > So, this facilitates bad habits and bad code. But, whatever, the macros > are just stating totally obvious and redundant facts, no problem, let's > just ignore that pepople only want it to abuse it. > > > gcc/ > > PR target/99708 > > * config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Define > > __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__ if we have float128 > > support. > > No. __SIZEOF_IBM128__ should be defined if and only if __ibm128 is > defined. In the current implementation, __ibm128 is only defined if __float128 was defined. I did have patches 6 months or so to define __ibm128 on any system with IBM 128-bit long double. But those were never applied to the trunk. > This should be tested directly, it should not depend on that some other > code did what it does today. That would also make the code much more > obvious. Given __float128 and __ibm128 are defined at the same time, I don't see the need for a separate target-supports.exp test, and so forth. But if you want that, I can easily do it.
On Tue, Feb 15, 2022 at 03:18:30PM -0500, Michael Meissner wrote: > On Tue, Feb 15, 2022 at 01:45:06PM -0600, Segher Boessenkool wrote: > > On Tue, Feb 15, 2022 at 12:49:41PM -0500, Michael Meissner wrote: > > > Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__. > > > > > > Define the sizes of the PowerPC specific types __float128 and __ibm128 if those > > > types are enabled. > > > > This is very silly of course, both of these are 16 bytes. Abusing this > > to see if the types exist is at least as silly (there are much better > > mechanisms to do this). > > This is just trying to close out the PR that people asked for. I put many arguments in that PR why this is a futile thing to have. On all older compilers these macros will not be defined, but the types often are. If you are willing to not support older compilers properly anyway, you could just *always* use the types, which will work with most very old compilers as well (and the approach using these propesed predefines will *not*!) This is (not) solving a non-problem. > > So, this facilitates bad habits and bad code. But, whatever, the macros > > are just stating totally obvious and redundant facts, no problem, let's > > just ignore that pepople only want it to abuse it. > > > > > gcc/ > > > PR target/99708 > > > * config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Define > > > __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__ if we have float128 > > > support. > > > > No. __SIZEOF_IBM128__ should be defined if and only if __ibm128 is > > defined. > > In the current implementation, __ibm128 is only defined if __float128 was > defined. I did have patches 6 months or so to define __ibm128 on any system > with IBM 128-bit long double. But those were never applied to the trunk. > > > This should be tested directly, it should not depend on that some other > > code did what it does today. That would also make the code much more > > obvious. Read that last paragraph again please? This is the only thing that needs changing. > Given __float128 and __ibm128 are defined at the same time, I don't see the > need for a separate target-supports.exp test, and so forth. But if you want > that, I can easily do it. No, I'm asking for it in the code that does the predefine. Not in the testcase, testcases are dirty pretty much always, and it is acceptable there because the scope is so limited. Segher
On Tue, Feb 15, 2022 at 04:05:11PM -0600, Segher Boessenkool wrote: > On all older compilers these macros will not be defined, but the types > often are. If you are willing to not support older compilers properly > anyway, you could just *always* use the types, which will work with most > very old compilers as well (and the approach using these propesed > predefines will *not*!) The types are not defined on older systems. Both __ibm128 (ibm128_float_type_node) and __float128 (ieee128_float_type_node) are only defined if TARGET_FLOAT128_TYPE is true. TARGET_FLOAT128_TYPE is only true if both TARGET_FLOAT128_ENABLE_TYPE and TARGET_VSX are true. TARGET_FLOAT128_ENABLE_TYPE is only true on linux64 systems. Now, the code to set __SIZEOF_IBM128__ and __SIZEOF_FLOAT128__ is in the code that also defines __FLOAT128__. This code checks whether the __float128 and __ibm128 keywords are allowed. These keywords are only set if TARGET_FLOAT128_TYPE is true, and if the user did not use the -mno-float128 option. In the GCC 7 time frame, we did not set this by default, but in the modern compilers, it is always set by default on Linux 64-bit systems.
On Tue, Feb 15, 2022 at 06:05:06PM -0500, Michael Meissner wrote: > On Tue, Feb 15, 2022 at 04:05:11PM -0600, Segher Boessenkool wrote: > > On all older compilers these macros will not be defined, but the types > > often are. If you are willing to not support older compilers properly > > anyway, you could just *always* use the types, which will work with most > > very old compilers as well (and the approach using these propesed > > predefines will *not*!) > > The types are not defined on older systems. They are defined since GCC 6. Using new macros to see if the types exist will miss all of GCC 6, 7, 8, 9, 10, 11. > Both __ibm128 (ibm128_float_type_node) and __float128 (ieee128_float_type_node) > are only defined if TARGET_FLOAT128_TYPE is true. > > TARGET_FLOAT128_TYPE is only true if both TARGET_FLOAT128_ENABLE_TYPE and > TARGET_VSX are true. > > TARGET_FLOAT128_ENABLE_TYPE is only true on linux64 systems. > > Now, the code to set __SIZEOF_IBM128__ and __SIZEOF_FLOAT128__ is in the code > that also defines __FLOAT128__. This code checks whether the __float128 and > __ibm128 keywords are allowed. These keywords are only set if > TARGET_FLOAT128_TYPE is true, and if the user did not use the -mno-float128 > option. In the GCC 7 time frame, we did not set this by default, but in the > modern compilers, it is always set by default on Linux 64-bit systems. __SIZEOF_IBM128__ should be defined based on what we have for the __ibm128 type, not on what we have for the __float128 type Yes I know we *currently* define those under the same conditions, but why write code that is more fragile than needed? Please don't. It is easy to do it correctly, so it is no real hassle for the writer of the code, and it is much better for the reader. Segher
diff --git a/gcc/config/rs6000/rs6000-c.cc b/gcc/config/rs6000/rs6000-c.cc index 15251efc209..b5f771d1308 100644 --- a/gcc/config/rs6000/rs6000-c.cc +++ b/gcc/config/rs6000/rs6000-c.cc @@ -581,9 +581,17 @@ rs6000_target_modify_macros (bool define_p, HOST_WIDE_INT flags, { rs6000_define_or_undefine_macro (define_p, "__FLOAT128__"); if (define_p) - rs6000_define_or_undefine_macro (true, "__float128=__ieee128"); + { + rs6000_define_or_undefine_macro (true, "__float128=__ieee128"); + rs6000_define_or_undefine_macro (true, "__SIZEOF_FLOAT128__=16"); + rs6000_define_or_undefine_macro (true, "__SIZEOF_IBM128__=16"); + } else - rs6000_define_or_undefine_macro (false, "__float128"); + { + rs6000_define_or_undefine_macro (false, "__float128"); + rs6000_define_or_undefine_macro (false, "__SIZEOF_FLOAT128__"); + rs6000_define_or_undefine_macro (false, "__SIZEOF_IBM128__"); + } } /* OPTION_MASK_FLOAT128_HARDWARE can be turned on if -mcpu=power9 is used or via the target attribute/pragma. */ diff --git a/gcc/testsuite/gcc.target/powerpc/pr99708.c b/gcc/testsuite/gcc.target/powerpc/pr99708.c new file mode 100644 index 00000000000..d478f7bc4c0 --- /dev/null +++ b/gcc/testsuite/gcc.target/powerpc/pr99708.c @@ -0,0 +1,21 @@ +/* { dg-do run } */ +/* { require-effective-target ppc_float128_sw } */ +/* { dg-options "-O2 -mvsx -mfloat128" } */ + +/* + * PR target/99708 + * + * Verify that __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__ are properly defined. + */ + +#include <stdlib.h> + +int main (void) +{ + if (__SIZEOF_FLOAT128__ != sizeof (__float128) + || __SIZEOF_IBM128__ != sizeof (__ibm128)) + abort (); + + return 0; +} +