From patchwork Tue Jan 25 11:02:02 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 50427 Return-Path: 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 48ECE3857C74 for ; Tue, 25 Jan 2022 11:02:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 48ECE3857C74 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1643108562; bh=/9NJzQirsU8oP5v6DDKIesHhDEM6i1JFhoV/sOsXi+M=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=Hf1foxnvTrB9w9XmbJkNZ7QWYs7Tte4zAoCsQTL4vqrDauX5ovG+2WumJ/iwQBoZv wPwCVRAVg74pR7+/erdx+3GqHYJ+zxiYbflVfOvwweok3XePZ5wULMCJn9uR/+BFrU OGe2/kRYvzOO8yNPekRc641/KXsakuhvRBowDb+Q= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 6B5563858030 for ; Tue, 25 Jan 2022 11:02:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6B5563858030 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-153-VvOmPHj0OZWdm73LD8jayg-1; Tue, 25 Jan 2022 06:02:09 -0500 X-MC-Unique: VvOmPHj0OZWdm73LD8jayg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 94BF919251A0; Tue, 25 Jan 2022 11:02:08 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.125]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2B14B7CADB; Tue, 25 Jan 2022 11:02:06 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 20PB23Ms469914 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 25 Jan 2022 12:02:03 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 20PB22nG469913; Tue, 25 Jan 2022 12:02:02 +0100 Date: Tue, 25 Jan 2022 12:02:02 +0100 To: Jason Merrill , Mark Wielaard , Ulrich Weigand Subject: [PATCH] dwarf2out: For ppc64le IEEE quad long double, emit DW_TAG_typedef to _Float128 [PR104194] Message-ID: <20220125110202.GE2646553@tucnak> References: <20220124193439.GV2646553@tucnak> <20220124222627.GB2646553@tucnak> MIME-Version: 1.0 In-Reply-To: <20220124222627.GB2646553@tucnak> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Jakub Jelinek via Gcc-patches From: Jakub Jelinek Reply-To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" On Mon, Jan 24, 2022 at 11:26:27PM +0100, Jakub Jelinek via Gcc-patches wrote: > Yet another short term solution might be not use DW_TAG_base_type > for the IEEE quad long double, but instead pretend it is a DW_TAG_typedef > with DW_AT_name "long double" to __float128 DW_TAG_base_type. > I bet gdb would even handle it without any changes, but of course, it would > be larger than the other proposed changes. Here it is implemented. Testcases I've played with are e.g.: __ibm128 a; long double b; _Complex long double c; static __attribute__((noinline)) int foo (long double d) { long double e = d + 1.0L; return 0; } int main () { a = 1.0; b = 2.0; c = 5.0 + 6.0i; return foo (7.0L); } and real(kind=16) :: a complex(kind=16) :: b a = 1.0 b = 2.0 end Printing the values of the variables works well, p &b or p &c shows pointer to the correct type, just ptype b or ptype c prints _Float128 instead of long double or complex _Float128 instead of complex long double. Even worse in fortran where obviously _Float128 or complex _Float128 aren't valid types, but as GDB knows them by name, it is just ptype that is weird. Is this ok for trunk until we get an agreement on which extension to use (different DW_ATE_*, or DW_AT_GNU_precision or DW_ATE_GNU_encoding_variant)? 2022-01-25 Jakub Jelinek PR debug/104194 * dwarf2out.cc (long_double_as_float128): New function. (modified_type_die): For powerpc64le IEEE 754 quad long double and complex long double emit those as DW_TAG_typedef to _Float128 or complex _Float128 base type. Jakub --- gcc/dwarf2out.cc.jj 2022-01-25 05:47:53.987454934 +0100 +++ gcc/dwarf2out.cc 2022-01-25 11:54:25.100522089 +0100 @@ -13568,6 +13568,47 @@ qualified_die_p (dw_die_ref die, int *ma return type; } +/* If TYPE is long double or complex long double that + should be emitted as artificial typedef to _Float128 or + complex _Float128, return the type it should be emitted as. + This is done in case the target already supports 16-byte + composite floating point type (ibm_extended_format). */ + +static tree +long_double_as_float128 (tree type) +{ + if (type != long_double_type_node + && type != complex_long_double_type_node) + return NULL_TREE; + + machine_mode mode, fmode; + if (TREE_CODE (type) == COMPLEX_TYPE) + mode = TYPE_MODE (TREE_TYPE (type)); + else + mode = TYPE_MODE (type); + if (known_eq (GET_MODE_SIZE (mode), 16) && !MODE_COMPOSITE_P (mode)) + FOR_EACH_MODE_IN_CLASS (fmode, MODE_FLOAT) + if (known_eq (GET_MODE_SIZE (fmode), 16) + && MODE_COMPOSITE_P (fmode)) + { + if (type == long_double_type_node) + { + if (float128_type_node + && (TYPE_MODE (float128_type_node) + == TYPE_MODE (type))) + return float128_type_node; + return NULL_TREE; + } + for (int i = 0; i < NUM_FLOATN_NX_TYPES; i++) + if (COMPLEX_FLOATN_NX_TYPE_NODE (i) != NULL_TREE + && (TYPE_MODE (COMPLEX_FLOATN_NX_TYPE_NODE (i)) + == TYPE_MODE (type))) + return COMPLEX_FLOATN_NX_TYPE_NODE (i); + } + + return NULL_TREE; +} + /* Given a pointer to an arbitrary ..._TYPE tree node, return a debugging entry that chains the modifiers specified by CV_QUALS in front of the given type. REVERSE is true if the type is to be interpreted in the @@ -13848,7 +13889,32 @@ modified_type_die (tree type, int cv_qua } else if (is_base_type (type)) { - mod_type_die = base_type_die (type, reverse); + /* If a target supports long double as different floating point + modes with the same 16-byte size, use normal DW_TAG_base_type + only for the composite (ibm_extended_real_format) type and + for the other for the time being emit instead a "_Float128" + or "complex _Float128" DW_TAG_base_type and a "long double" + or "complex long double" typedef to it. */ + if (tree other_type = long_double_as_float128 (type)) + { + dw_die_ref other_die; + if (TYPE_NAME (other_type)) + other_die + = modified_type_die (other_type, TYPE_UNQUALIFIED, reverse, + context_die); + else + { + other_die = base_type_die (type, reverse); + add_child_die (comp_unit_die (), other_die); + add_name_attribute (other_die, + TREE_CODE (type) == COMPLEX_TYPE + ? "complex _Float128" : "_Float128"); + } + mod_type_die = new_die_raw (DW_TAG_typedef); + add_AT_die_ref (mod_type_die, DW_AT_type, other_die); + } + else + mod_type_die = base_type_die (type, reverse); /* The DIE with DW_AT_endianity is placed right after the naked DIE. */ if (reverse_base_type)