From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id ED40438708AE; Thu, 4 Feb 2021 09:48:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ED40438708AE From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug fortran/27341] [dwarf-5] FAIL: gdb.fortran/function-calls.exp: p derived_types_and_module_calls::pass_cart_nd(c_nd) Date: Thu, 04 Feb 2021 09:48:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: fortran X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 09:48:44 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27341 --- Comment #2 from Tom de Vries --- This is due to missing support for DW_TAG_generic_subrange in read_array_ty= pe. So we have: ... <1>: Abbrev Number: 46 (DW_TAG_array_type) DW_AT_data_location: 2 byte block: 97 6=20=20=20=20 (DW_OP_push_object_address; DW_OP_deref) DW_AT_rank : 6 byte block: 97 23 10 6 37 1a DW_AT_type : <0x139> DW_AT_sibling : <0xe51> <2>: Abbrev Number: 47 (DW_TAG_generic_subrange) DW_AT_lower_bound : 8 byte block: 97 14 48 1e 23 20 22 6=20=20= =20 (DW_OP_push_object_address; DW_OP_over; DW_OP_lit24; DW_OP_mul; DW_OP_plus_uconst: 32; DW_OP_plus; DW_OP_deref) DW_AT_upper_bound : 8 byte block: 97 14 48 1e 23 28 22 6=20=20= =20 (DW_OP_push_object_address; DW_OP_over; DW_OP_lit24; DW_OP_mul; DW_OP_plus_uconst: 40; DW_OP_plus; DW_OP_deref) DW_AT_byte_stride : 11 byte block: 97 14 48 1e 23 18 22 6 8 38 = 1e=20=20 (DW_OP_push_object_address; DW_OP_over; DW_OP_lit24; DW_OP_mul; DW_OP_plus_uconst: 24; DW_OP_plus; DW_OP_deref; DW_OP_const1u: 56; DW_OP_mu= l) ... We start out in read_array_type with: ... type =3D element_type; ... and then iterate over range_types to build up the type further. But there are no DW_TAG_subrange_type children (only one DW_TAG_generic_subrange), so range_types is empty, and type is kept unmodif= ied. Consequently, in set_die_type we apply the DW_AT_data_location to the element_type (the one at 0x139) instead of to the newly build array type. Then we try to print c_nd: ... <2><6e8>: Abbrev Number: 2 (DW_TAG_variable) <6e9> DW_AT_name : (indirect string, offset: 0x218): c_nd <6ed> DW_AT_decl_file : 1 <6ed> DW_AT_decl_line : 198 <6ee> DW_AT_type : <0x139> <6f2> DW_AT_location : 9 byte block: 3 e0 30 60 0 0 0 0 0=20=20=20= =20=20 (DW_OP_addr: 6030e0) ... and find that the type has a data_location property, which when used gives incorrect results. --=20 You are receiving this mail because: You are on the CC list for the bug.=