From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F36853839C50; Thu, 19 May 2022 21:31:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F36853839C50 From: "ibhagat at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/105636] -gctf causes an ICE on some invalid code Date: Thu, 19 May 2022 21:31:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: ice-on-invalid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: ibhagat at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.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://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2022 21:31:09 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105636 --- Comment #2 from Indu Bhagat --- I found the minimum reproducer to be: $ cat testcase.c=20 static int sa[100]; int n; static int (*a2)[] =3D (__typeof__(int (*)[n]))sa; I tried to debug this and found out that the likely cause is some invalidit= y in the DWARF DIE generation. $ gcc -g3 -c testcase.c=20 $ objdump --dwarf=3Dinfo testcase.o=20 [...] <1><39>: Abbrev Number: 6 (DW_TAG_base_type) <3a> DW_AT_byte_size : 4 <3b> DW_AT_encoding : 5 (signed) <3c> DW_AT_name : int <1><40>: Abbrev Number: 2 (DW_TAG_variable) <41> DW_AT_name : sa <44> DW_AT_decl_file : 1 <44> DW_AT_decl_line : 1 <45> DW_AT_decl_column : 12 <46> DW_AT_type : <0x22> <4a> DW_AT_location : 9 byte block: 3 20 0 0 0 0 0 0 0=20=20=20=20= =20=20=20=20 (DW_OP_addr: 20) <1><54>: Abbrev Number: 7 (DW_TAG_variable) <55> DW_AT_name : n <57> DW_AT_decl_file : 1 <58> DW_AT_decl_line : 2 <59> DW_AT_decl_column : 5 <5a> DW_AT_type : <0x39> <5e> DW_AT_external : 1 <5e> DW_AT_location : 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr= : 0) <1><68>: Abbrev Number: 8 (DW_TAG_array_type) <69> DW_AT_type : <0x39> <1><6d>: Abbrev Number: 1 (DW_TAG_array_type) <6e> DW_AT_type : <0x39> <72> DW_AT_sibling : <0x78> <2><76>: Abbrev Number: 9 (DW_TAG_subrange_type) <2><77>: Abbrev Number: 0 <1><78>: Abbrev Number: 2 (DW_TAG_variable) <79> DW_AT_name : a2 <7c> DW_AT_decl_file : 1 <7c> DW_AT_decl_line : 3 <7d> DW_AT_decl_column : 14 <7e> DW_AT_type : <0x8c> <82> DW_AT_location : 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr= : 0) <1><8c>: Abbrev Number: 10 (DW_TAG_pointer_type) <8d> DW_AT_byte_size : 8 <8e> DW_AT_type : <0x6d> <1><92>: Abbrev Number: 0 The dwarf2ctf functionality relies on the presence of a child DIE for a die= of type DW_TAG_array_type, where the child is either of type DW_TAG_subrange_t= ype or DW_TAG_enumeration_type. I believe that this is a sound assumption. The DWARF5 manual specifies the same. Notice how the DIE <1><68>: Abbrev Number: 8 (DW_TAG_array_type) does not h= ave any child. I see that add_subscipt_info () did add the DW_TAG_subrange_type with some information: 1: debug_dwarf_die((dw_die_ref)0x7fffea2f15a0) =3D DIE 0: DW_TAG_array_t= ype (0x7fffea2f15a0) abbrev id: 0 offset: 0 mark: 2 DW_AT_type: die -> 0 (0x7fffea2f1410) DIE 0: DW_TAG_subrange_type (0x7fffea2f15f0) abbrev id: 0 offset: 0 mark: 0 DW_AT_type: die -> 0 (0x7fffea2f13c0) DW_AT_upper_bound: location descriptor: (0x7fffea2f17d0) DW_OP_addr address, 0 (0x7fffea2f1820) DW_OP_deref_size 4, 0 (0x7fffea2f1870) DW_OP_lit1 1, 0 (0x7fffea2f18c0) DW_OP_minus 0, 0 But looks like the dwarf2out::prune_unused_types () was not able to prune t= his type completely as it should ? Am I on the right track?=