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 CE9A03858D28 for ; Mon, 18 Jul 2022 15:55:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CE9A03858D28 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 26IFoGYY004716; Mon, 18 Jul 2022 15:55:38 GMT Received: from ppma03wdc.us.ibm.com (ba.79.3fa9.ip4.static.sl-reverse.com [169.63.121.186]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hdagmr2tb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Jul 2022 15:55:38 +0000 Received: from pps.filterd (ppma03wdc.us.ibm.com [127.0.0.1]) by ppma03wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 26IFLDX9018398; Mon, 18 Jul 2022 15:55:37 GMT Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by ppma03wdc.us.ibm.com with ESMTP id 3hbmy8ws7j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Jul 2022 15:55:37 +0000 Received: from b03ledav005.gho.boulder.ibm.com (b03ledav005.gho.boulder.ibm.com [9.17.130.236]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 26IFtaGt41615662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 18 Jul 2022 15:55:36 GMT Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 99990BE058; Mon, 18 Jul 2022 15:55:36 +0000 (GMT) Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 42E22BE04F; Mon, 18 Jul 2022 15:55:36 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.211.68.56]) by b03ledav005.gho.boulder.ibm.com (Postfix) with ESMTP; Mon, 18 Jul 2022 15:55:36 +0000 (GMT) Message-ID: <59bb735e3c610f42e305fb84e42fe36e38c20808.camel@us.ibm.com> From: Carl Love To: Pedro Alves , "gdb-patches@sourceware.org" , Will Schmidt , Ulrich Weigand Date: Mon, 18 Jul 2022 08:55:35 -0700 In-Reply-To: <35d6420eb96ff01c3624a3de05659dece2b6a60b.camel@us.ibm.com> References: <3fe4fcaf067f3bc3d4124df3ed6ba009a174f933.camel@us.ibm.com> <8ae117dd-17c2-382d-637a-64a3be7b185b@palves.net> <35d6420eb96ff01c3624a3de05659dece2b6a60b.camel@us.ibm.com> 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-ORIG-GUID: tZJmi2kOMPcAHo62FBnpWHy6b-d_qgAg X-Proofpoint-GUID: tZJmi2kOMPcAHo62FBnpWHy6b-d_qgAg 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 suspectscore=0 phishscore=0 priorityscore=1501 spamscore=0 mlxlogscore=999 clxscore=1015 bulkscore=0 mlxscore=0 malwarescore=0 impostorscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207180067 X-Spam-Status: No, score=-12.2 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:55:42 -0000 On Mon, 2022-07-18 at 08:40 -0700, Carl Love wrote: > 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. I should qualify that, there is a string comparison in ppc_floatformat_for_type (gdb/ppc-linux-tdep.c) of name with "_Float128" which if true returns floatformats_ieee_quad. The comparison is True in the test case. So clearly GDB set the name field to _Float128 at some point. > 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"} > > > +}