From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id EgdlN4EPOGRsuCoAWB0awg (envelope-from ) for ; Thu, 13 Apr 2023 10:19:45 -0400 Received: by simark.ca (Postfix, from userid 112) id D5B681E221; Thu, 13 Apr 2023 10:19:45 -0400 (EDT) Authentication-Results: simark.ca; dkim=fail reason="signature verification failed" (768-bit key; unprotected) header.d=tromey.com header.i=@tromey.com header.a=rsa-sha256 header.s=default header.b=TVgtXPt8; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_DNSWL_MED,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 168F31E110 for ; Thu, 13 Apr 2023 10:19:45 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E8D8C3858C1F for ; Thu, 13 Apr 2023 14:19:43 +0000 (GMT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by sourceware.org (Postfix) with ESMTPS id 88BC03858D20 for ; Thu, 13 Apr 2023 14:19:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 88BC03858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com Received: from gproxy2-pub.mail.unifiedlayer.com (unknown [69.89.18.3]) by qproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id B93028027F10 for ; Thu, 13 Apr 2023 14:19:30 +0000 (UTC) Received: from cmgw11.mail.unifiedlayer.com (unknown [10.0.90.126]) by progateway4.mail.pro1.eigbox.com (Postfix) with ESMTP id A4F8510041A43 for ; Thu, 13 Apr 2023 14:19:00 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id mxmupdKW7b9i8mxmupkkXp; Thu, 13 Apr 2023 14:19:00 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=Wd7J12tX c=1 sm=1 tr=0 ts=64380f54 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=dKHAf1wccvYA:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=CCpqsmhAAAAA:8 a=mDV3o1hIAAAA:8 a=0gat5pb2hSIfjsuEluUA:9 a=ul9cdbp4aOFLsgKbc677:22 a=_FVE-zBwftR9WsbkzFJk:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=X1vO7LTacMOIzDl7Phle67zPK+M7ee6oRGGR+/9C/VU=; b=TVgtXPt8l9KS0m7A8akJQAINI2 BYt+RncRTLIJNZmwjC6h6QCpknU4Q4WbqduyxJFzDkOoRZ+fxt2UWH75Ssk990sO9SSh10PJEvH3j VdoarWUQsOKD6KXOr+aSFEV6y; Received: from 71-211-191-82.hlrn.qwest.net ([71.211.191.82]:51482 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pmxmu-0016C2-3U; Thu, 13 Apr 2023 08:19:00 -0600 From: Tom Tromey To: Carl Love via Gdb-patches Cc: Ulrich Weigand , Carl Love , Kevin Buettner Subject: Re: [PATCH ver 2] PowerPC: fix _Float128 type output string References: <184c0edcf067acccdf71d4dcdd66447bb5d93d4c.camel@us.ibm.com> <1b5d214a6208c422963e58c27c98f81af9601628.camel@us.ibm.com> X-Attribution: Tom Date: Thu, 13 Apr 2023 08:18:59 -0600 In-Reply-To: <1b5d214a6208c422963e58c27c98f81af9601628.camel@us.ibm.com> (Carl Love via Gdb-patches's message of "Mon, 10 Apr 2023 09:01:21 -0700") Message-ID: <87fs936f1o.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 71.211.191.82 X-Source-L: No X-Exim-ID: 1pmxmu-0016C2-3U X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 71-211-191-82.hlrn.qwest.net (murgatroyd) [71.211.191.82]:51482 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes 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: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" >>>>> "Carl" == Carl Love via Gdb-patches writes: Carl> PowerPC supports two 128-bit floating point formats, the IBM long double Carl> and IEEE 128-bit float. The issue is the DWARF information does not Carl> distinguish between the two. There have been proposals of how to extend Carl> the DWARF information as discussed in Carl> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194 Carl> but has not been fully implemented. Could it be? I didn't read the issue but it's often better to put in the effort to fix the problem in the compiler. Normally once these workarounds go into gdb, they can never be removed. Carl> This patch fixes 74 regression test failures in Carl> gdb.base/whatis-ptype-typedefs.exp on PowerPC with IEEE float 128 as the Carl> default on GCC. It fixes one regression test failure in Carl> gdb.base/complex-parts.exp. I don't really understand how this patch works. It took me a while to understand that maybe the issue is that the association between a gdb type and a float format is done by name and size, and because this is a typedef, the association is done instead by the underlying type -- which is then wrong. However, doesn't copy_type also copy the TYPE_FLOATFORMAT field? So where would this get reset? Or maybe this isn't the problem at all, but then I don't understand what it would be. Carl> +# The DWARF info currently does not distinquish between IEEE 128-bit floating Carl> +# point values and the IBM 128-bit floating point format. GCC has an internal Carl> +# hack that uses the _Float128 base typdef for IEEE 128-bit float values. The Carl> +# following method is used to "fix" the long double typedef so the _Float128 Carl> +# name is not printed. Carl> +Function( Carl> + comment=""" Carl> +Return true if the typedef record needs to be replaced.". Carl> + Carl> +Return 0 by default""", I think the comment field could be reworded to be more clear. I guess the idea is that some typedefs are replaced by their target type, but given the typedef's name. Carl> +bool Carl> +linux_dwarf2_omit_typedef_p (struct type *target_type, Carl> + const char *producer, const char *name) I think this can be 'static'. Tom