public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "ibhagat at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-105636-4-ro8J9NIPem@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-105636-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105636 --- Comment #2 from Indu Bhagat <ibhagat at gcc dot gnu.org> --- I found the minimum reproducer to be: $ cat testcase.c static int sa[100]; int n; static int (*a2)[] = (__typeof__(int (*)[n]))sa; I tried to debug this and found out that the likely cause is some invalidity in the DWARF DIE generation. $ gcc -g3 -c testcase.c $ objdump --dwarf=info testcase.o [...] <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 (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_type 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 have 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) = DIE 0: DW_TAG_array_type (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 this type completely as it should ? Am I on the right track?
prev parent reply other threads:[~2022-05-19 21:31 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-17 18:49 [Bug c/105636] New: ICE in gen_ctf_array_type, at dwarf2ctf.cc:379 gscfq@t-online.de 2022-05-18 7:39 ` [Bug debug/105636] -gctf causes an ICE on some invalid code marxin at gcc dot gnu.org 2022-05-19 19:15 ` ibhagat at gcc dot gnu.org 2022-05-19 21:31 ` ibhagat at gcc dot gnu.org [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-105636-4-ro8J9NIPem@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).