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 2B629385780D for ; Tue, 26 Apr 2022 17:24:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2B629385780D Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 23QGNN8a023674; Tue, 26 Apr 2022 17:24:16 GMT Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3fpm7e15w7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Apr 2022 17:24:16 +0000 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 23QHCPZi024603; Tue, 26 Apr 2022 17:24:15 GMT Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by ppma04wdc.us.ibm.com with ESMTP id 3fm939pk0d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Apr 2022 17:24:15 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 23QHODgU21102892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 26 Apr 2022 17:24:13 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8A90578066; Tue, 26 Apr 2022 17:24:13 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 323217805E; Tue, 26 Apr 2022 17:24:13 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.163.7.164]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Tue, 26 Apr 2022 17:24:13 +0000 (GMT) Message-ID: Subject: Re: [PATCH V2] Powerpc: Update expected floating point output for gdb.arch/altivec-regs.exp and gdb.arch/vsx-regs.exp From: Carl Love To: Ulrich Weigand , "gdb-patches@sourceware.org" , "will_schmidt_vnet.ibm.com" Cc: Rogerio Alves Cardoso , "tromey@adacore.com" Date: Tue, 26 Apr 2022 10:24:12 -0700 In-Reply-To: References: <22d2e1a1c83cb00ffccc28e381aa9726ee6fc924.camel@vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: JQGOTmBD7GWoXPXWuOEZy4XH_3fRaj2K X-Proofpoint-GUID: JQGOTmBD7GWoXPXWuOEZy4XH_3fRaj2K X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-04-26_05,2022-04-26_02,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 priorityscore=1501 suspectscore=0 mlxscore=0 spamscore=0 mlxlogscore=814 adultscore=0 lowpriorityscore=0 phishscore=0 impostorscore=0 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204260109 X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, SPF_HELO_NONE, SPF_NONE, TXREP 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: 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: Tue, 26 Apr 2022 17:24:20 -0000 Ulrich: I had similar thoughts to your comments below. The output now seems a bit redundant. I didn't want to try and address that in this patch. I have committed the patch as is. I have created an internal to do for us to look at cleaning up the output on Power per your comments. Thanks. Carl On Tue, 2022-04-26 at 14:28 +0000, Ulrich Weigand wrote: > Carl Love wrote: > > > PowerPC: Update expected floating point output for > > gdb.arch/altivec- > > regs.exp and gdb.arch/vsx-regs.exp > > This patch is OK. > > As additional comment, I'm wondering whether the display of vector > registers via the union we're using is actually useful when in > hexadecimal mode. The intent of the union is that it should be easy > to > interpret the register contents in various ways, in particular both > as > integer and as floating-point value, as we may not know what type is > currently being held in the register. > > However, with the new way of printing floating-point values when /x > is > in effect, it seems that the contents of v4_float will now always be > identical to v4_int32, and similar for the other floating-point union > members. > > So maybe it would be better to always show the floating-point members > as actual floating-point, even when the rest of the union is printed > via /x. However, that may be a more invasive change, so I think you > should go ahead and commit the patch as-is now, to improve the > testsuite results. > > Bye, > Ulrich >