From patchwork Mon Jan 24 19:34:39 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 50415 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 5399A385802E for ; Mon, 24 Jan 2022 19:35:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5399A385802E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1643052959; bh=QG1tFie0WhH9fSTqT137TMw5j51OicLNKmwsoWXk1lU=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=FFiBpx4QDXqgjiwv4F//uPV0lWdmRlunYn+gBtQwXx0g5f8MD0eRNZu8bqsrM4wDX E2mvwarfVL1rBf+Iv0PPXql6J3+n7CeduhUkbKaDQslaxAC78d2u9zhMTPSHafiJbg diVjYTOZLX3RhvOtYTGD3KQIxwYE3fXfnJhNXpWo= 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 7857C3858D3C for ; Mon, 24 Jan 2022 19:35:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7857C3858D3C 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-287-uuqei-XqMwSWSwenARZEqA-1; Mon, 24 Jan 2022 14:35:24 -0500 X-MC-Unique: uuqei-XqMwSWSwenARZEqA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 77558423C7; Mon, 24 Jan 2022 19:35:23 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.125]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1E178519AA; Mon, 24 Jan 2022 19:34:44 +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 20OJYesU460251 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 24 Jan 2022 20:34:41 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 20OJYdBk460250; Mon, 24 Jan 2022 20:34:39 +0100 Date: Mon, 24 Jan 2022 20:34:39 +0100 To: Jason Merrill Subject: [PATCH] dwarf2out: For ppc64le IEEE quad long double, use DW_ATE_GNU_*float128 [PR104194] Message-ID: <20220124193439.GV2646553@tucnak> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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: Ulrich Weigand , gcc-patches@gcc.gnu.org, Mark Wielaard Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" Hi! As mentioned in the PR, we emit the same .uleb128 0x3 # (DIE (0x42) DW_TAG_base_type) .byte 0x10 # DW_AT_byte_size .byte 0x4 # DW_AT_encoding .4byte .LASF2 # DW_AT_name: "long double" (0x4 is DW_ATE_float) whether we on powerpc64le-linux use -mabi=ibmlongdouble or -mabi=ieeelongdouble. http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2022-January/004859.html lists some options how to handle that and Ulrich mentioned it in his Cauldron talk too: https://slideslive.com/38902369/precise-target-floatingpoint-emulation-in-gdb?ref=account-folder-9307-folders pages 8-16. The following patch uses DW_ATE_GNU_{,complex_}float128 (new extensions equal to corresponding HP extensions) instead of DW_ATE_float, another possibility would be DW_ATE_GNU_precision attribute on the DW_TAG_base_type that would for these multiple 16-byte float cases (or always) emit a precision (113 for binary128, 106 for double double), yet another one is what Ulrich mentions in his slides (DW_AT_GNU_encoding_variant {0,1}). I didn't get any responses to my dwarf discuss mails yet, on IRC Jason preferred a DW_AT_encoding change while Mark prefered DW_AT_GNU_precision. In any case, all of these are just GNU extensions, if/when DWARF standardizes something else, we can use it for -gdwarf-6 or later. Bootstrap/regtest pending on powerpc64le-linux (both defaulting to ibmlongdouble and ieeelongdouble), ok for trunk if it passes? 2022-01-24 Jakub Jelinek PR debug/104194 * dwarf2.def (DW_ATE_GNU_float128, DW_ATE_GNU_complex_float128): New DW_AT_encoding values. * dwarf2out.c (base_type_die): Use DW_ATE_GNU_float128 instead of DW_ATE_float for 16-byte non-composite mode if target supports also composite modes. Similarly use DW_AT_GNU_complex_float128 instead of DW_ATE_complex_float for 32-byte complex mode with non-composite inner mode if target supports also composite modes. Jakub --- include/dwarf2.def.jj 2022-01-11 23:11:23.593273249 +0100 +++ include/dwarf2.def 2022-01-24 17:46:08.699138085 +0100 @@ -732,11 +732,20 @@ DW_ATE (DW_ATE_ASCII, 0x12) DW_ATE_DUP (DW_ATE_lo_user, 0x80) DW_ATE_DUP (DW_ATE_hi_user, 0xff) +/* GNU extensions. */ +DW_ATE (DW_ATE_GNU_float128, 0x82) /* Floating-point (IEEE quad precision if + there are multiple 16-byte floating + formats). */ +DW_ATE (DW_ATE_GNU_complex_float128, 0x83) /* Complex fp + (IEEE quad precision if there + are multiple 16-byte floating + formats). */ + /* HP extensions. */ DW_ATE (DW_ATE_HP_float80, 0x80) /* Floating-point (80 bit). */ DW_ATE (DW_ATE_HP_complex_float80, 0x81) /* Complex floating-point (80 bit). */ -DW_ATE (DW_ATE_HP_float128, 0x82) /* Floating-point (128 bit). */ -DW_ATE (DW_ATE_HP_complex_float128, 0x83) /* Complex fp (128 bit). */ +DW_ATE_DUP (DW_ATE_HP_float128, 0x82) /* Floating-point (128 bit). */ +DW_ATE_DUP (DW_ATE_HP_complex_float128, 0x83) /* Complex fp (128 bit). */ DW_ATE (DW_ATE_HP_floathpintel, 0x84) /* Floating-point (82 bit IA64). */ DW_ATE (DW_ATE_HP_imaginary_float80, 0x85) DW_ATE (DW_ATE_HP_imaginary_float128, 0x86) --- gcc/dwarf2out.cc.jj 2022-01-20 11:58:12.632304188 +0100 +++ gcc/dwarf2out.cc 2022-01-24 18:27:12.862642858 +0100 @@ -13260,7 +13260,23 @@ base_type_die (tree type, bool reverse) encoding = DW_ATE_lo_user; } else - encoding = DW_ATE_float; + { + encoding = DW_ATE_float; + + /* On targets like PowerPC which support both + a double double 16-byte floating mode + (MODE_COMPOSITE_P) and some other 16-byte + floating mode (IEEE quad precision), use + DW_ATE_GNU_float128 instead of DW_ATE_float + for the latter. */ + machine_mode mode; + if (known_eq (GET_MODE_SIZE (TYPE_MODE (type)), 16) + && !MODE_COMPOSITE_P (TYPE_MODE (type))) + FOR_EACH_MODE_IN_CLASS (mode, MODE_FLOAT) + if (known_eq (GET_MODE_SIZE (mode), 16) + && MODE_COMPOSITE_P (mode)) + encoding = DW_ATE_GNU_float128; + } break; case FIXED_POINT_TYPE: @@ -13276,7 +13292,23 @@ base_type_die (tree type, bool reverse) a user defined type for it. */ case COMPLEX_TYPE: if (TREE_CODE (TREE_TYPE (type)) == REAL_TYPE) - encoding = DW_ATE_complex_float; + { + encoding = DW_ATE_complex_float; + + /* On targets like PowerPC which support both + a double double 16-byte floating mode + (MODE_COMPOSITE_P) and some other 16-byte + floating mode (IEEE quad precision), use + DW_ATE_GNU_complex_float128 instead of + DW_ATE_float for the latter. */ + machine_mode mode; + if (known_eq (GET_MODE_SIZE (TYPE_MODE (type)), 32) + && !MODE_COMPOSITE_P (TYPE_MODE (TREE_TYPE (type)))) + FOR_EACH_MODE_IN_CLASS (mode, MODE_FLOAT) + if (known_eq (GET_MODE_SIZE (mode), 16) + && MODE_COMPOSITE_P (mode)) + encoding = DW_ATE_GNU_complex_float128; + } else encoding = DW_ATE_lo_user; break;