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 AE7243858D28 for ; Mon, 18 Jul 2022 15:40:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AE7243858D28 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 26IFbQKe000898; Mon, 18 Jul 2022 15:40:28 GMT Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hda5era3y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Jul 2022 15:40:28 +0000 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 26IFKlp4000399; Mon, 18 Jul 2022 15:40:27 GMT Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by ppma05wdc.us.ibm.com with ESMTP id 3hbmy9dpn7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Jul 2022 15:40:27 +0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 26IFeQwE43516188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 18 Jul 2022 15:40:26 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 847D3AE062; Mon, 18 Jul 2022 15:40:26 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D08A6AE060; Mon, 18 Jul 2022 15:40:25 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.211.68.56]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTP; Mon, 18 Jul 2022 15:40:25 +0000 (GMT) Message-ID: <35d6420eb96ff01c3624a3de05659dece2b6a60b.camel@us.ibm.com> From: Carl Love To: Pedro Alves , "gdb-patches@sourceware.org" , Will Schmidt , Ulrich Weigand Date: Mon, 18 Jul 2022 08:40:25 -0700 In-Reply-To: <8ae117dd-17c2-382d-637a-64a3be7b185b@palves.net> References: <3fe4fcaf067f3bc3d4124df3ed6ba009a174f933.camel@us.ibm.com> <8ae117dd-17c2-382d-637a-64a3be7b185b@palves.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) X-TM-AS-GCONF: 00 X-Proofpoint-GUID: F_YTFQk-PPUfV-y6wDnoyP5Fn_0bP_mh X-Proofpoint-ORIG-GUID: F_YTFQk-PPUfV-y6wDnoyP5Fn_0bP_mh Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 2 URL's were un-rewritten MIME-Version: 1.0 Subject: RE: [PATCH] Add IEEE FLOAT128 support to test gdb.base/whatis-ptype-typedefs.exp X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-07-18_14,2022-07-18_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 spamscore=0 impostorscore=0 malwarescore=0 clxscore=1015 priorityscore=1501 suspectscore=0 lowpriorityscore=0 mlxlogscore=999 phishscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207180067 X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2022 15:40:34 -0000 On Mon, 2022-07-18 at 16:22 +0100, Pedro Alves wrote: > On 2022-07-13 8:38 p.m., Carl Love via Gdb-patches wrote: > > > GCC enabled IEEE FLOAT 128-bit support starting with GCC 12 by > > default. > > Previously long double was the default for 128-bit floating point > > support. > > This patch updates the expected result for the "long doube" tests > > to > > _Float128 if GCC 12 is used. The previous "long double" result is > > expected for GCC 11 and older versions. > > This whole paragraph reads as if all archs were changed, but it was > just Power, right? Yes, it should say the default on PowerPC changed to IEEE. Per comments from Ulrich, I need to investigate further to figure out where the _Float128 is coming from as the string doesn't occur in the source code. From my initial look, I don't see the string in the gdb code or the test case source code, the source DWARF or objdump output. In function check_typedef (gdb/gdbtpyes.c) there is a while loop that iterates thru the type removing the typedefs. Initially the type->name = long_double_typedef but then changes to _Float128. I don't know where the typedef all gets setup but I would think it comes from reading the source code DWARF. Anyway, I am working on figuring out where and how the _Float128 gets setup. > > And isn't it the case that after the change, for GCC, "long double" > _IS_ IEEE FLOAT 128-bit? > > Doesn't that mean that GCC and GDB now have a mismatch of what they > think "long double" is? > Like for example, if the user copies an expression from their program > and evaluates in gdb, > and that expression uses "long double", then GDB will evaluate it > differently from how GCC would? > > Shouldn't GDB instead adjust its "long double" type depending on the > ABI, mapping "long double" > to the right format? And then, the testcase (probably) wouldn't > change? > > BTW, I was expecting to see GCC's default change mentioned at: > > > https://gcc.gnu.org/gcc-12/changes.html > > > but I can't seem to find it there, other than a Fortran reference > which seems related. I did find: > > > https://gcc.gnu.org/wiki/Ieee128PowerPC#Transition > > > > The patch has been run on Power 7 (gcc version 4.8.5), Power 10 > > (gcc > > version 12.1) and Intel x86_64 (gcc version 11.2.0) to verify the > > patch > > fixes the 74 test failures on Power 10 with GCC 12 and does not > > introduce > > any regression failures on older versions of GCC. > > Seems like x86 with gcc 12 would better be tested as well. > > > --- > > .../gdb.base/whatis-ptype-typedefs.exp | 26 ++++++++++++++- > > ---- > > 1 file changed, 20 insertions(+), 6 deletions(-) > > > > diff --git a/gdb/testsuite/gdb.base/whatis-ptype-typedefs.exp > > b/gdb/testsuite/gdb.base/whatis-ptype-typedefs.exp > > index be76183ca79..a17084a19ec 100644 > > --- a/gdb/testsuite/gdb.base/whatis-ptype-typedefs.exp > > +++ b/gdb/testsuite/gdb.base/whatis-ptype-typedefs.exp > > @@ -77,6 +77,12 @@ proc prepare {lang} { > > # > > # This can be "c" or "c++". > > # > > + > > +# GCC 12 uses IEEE 128-bit floating point as the default starting > > with GCC 12. > > On all archs? > > > +# The table below consists of the compiler independent tests. The > > GCC version > > +# specific tests are appended to the end of the table based on the > > compiler > > +# version. > > + > > # Columns in the table represent: > > # EXP # whatis # ptype # > > language > > set table { > > @@ -97,12 +103,6 @@ set table { > > {"double_typedef2" "double_typedef" "double"} > > {"v_double_typedef" "double_typedef" "double"} > > {"v_double_typedef2" "double_typedef2" "double"} > > - > > - {"long_double_typedef" "long double" "long > > double"} > > - {"long_double_typedef2" "long_double_typedef" "long > > double"} > > - {"v_long_double_typedef" "long_double_typedef" "long > > double"} > > - {"v_long_double_typedef2" "long_double_typedef2" "long > > double"} > > - > > {"colors_typedef" "(enum )?colors" "enum colors( : > > unsigned int)? {red, green, blue}"} > > {"colors_typedef2" "colors_typedef" "enum colors( : > > unsigned int)? {red, green, blue}"} > > {"v_colors_typedef" "colors_typedef" "enum colors( : > > unsigned int)? {red, green, blue}"} > > @@ -151,6 +151,20 @@ set table { > > "c++"} > > } > > > > +# Add the long double tests on the version of GCC > > +if { [test_compiler_info gcc-*] && [gcc_major_version] >= 12 } { > > What about x86 + gcc 12 ? > > > + lappend table {"long_double_typedef" "long > > double" "_Float128"} > > + lappend table > > {"long_double_typedef2" "long_double_typedef" "_Float128"} > > + lappend table > > {"v_long_double_typedef" "long_double_typedef" "_Float128"} > > + lappend table {"v_long_double_typedef2" > > "long_double_typedef2" "_Float128"} > > + > > +} else { > > + lappend table {"long_double_typedef" "long > > double" "long double"} > > + lappend table > > {"long_double_typedef2" "long_double_typedef" "long double"} > > + lappend table > > {"v_long_double_typedef" "long_double_typedef" "long double"} > > + lappend table {"v_long_double_typedef2" > > "long_double_typedef2" "long double"} > > +} > >