public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/105636] New: ICE in gen_ctf_array_type, at dwarf2ctf.cc:379
@ 2022-05-17 18:49 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
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: gscfq@t-online.de @ 2022-05-17 18:49 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105636

            Bug ID: 105636
           Summary: ICE in gen_ctf_array_type, at dwarf2ctf.cc:379
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

With file ./gcc/testsuite/gcc.dg/gnu99-const-expr-4.c
and option -gctf or -gbtf, at -O0 :


$ gcc-13-20220515 -c gnu99-const-expr-4.c -gctf
gnu99-const-expr-4.c:29:1: internal compiler error: in gen_ctf_array_type, at
dwarf2ctf.cc:379
   29 | static int (*a7)[] = (__typeof__((int (*)[n])sa + m++))sa; /* {
dg-error "constant" } */
      | ^~~~~~
0x852783 gen_ctf_array_type
        ../../gcc/dwarf2ctf.cc:379
0x852783 gen_ctf_type
        ../../gcc/dwarf2ctf.cc:881
0x852ddd ctf_do_die(die_struct*)
        ../../gcc/dwarf2ctf.cc:973
0x85691b ctf_debug_do_cu
        ../../gcc/dwarf2out.cc:32877
0x8a2461 dwarf2out_early_finish
        ../../gcc/dwarf2out.cc:33006
0x80cbff symbol_table::finalize_compilation_unit()
        ../../gcc/cgraphunit.cc:2525

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug debug/105636] -gctf causes an ICE on some invalid code
  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 ` 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
  2 siblings, 0 replies; 4+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-05-18  7:39 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105636

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibhagat at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org
   Last reconfirmed|                            |2022-05-18
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug debug/105636] -gctf causes an ICE on some invalid code
  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
  2 siblings, 0 replies; 4+ messages in thread
From: ibhagat at gcc dot gnu.org @ 2022-05-19 19:15 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105636

--- Comment #1 from Indu Bhagat <ibhagat at gcc dot gnu.org> ---
Thank you for reporting this.  I can reproduce it, nice and easy :)

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug debug/105636] -gctf causes an ICE on some invalid code
  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
  2 siblings, 0 replies; 4+ messages in thread
From: ibhagat at gcc dot gnu.org @ 2022-05-19 21:31 UTC (permalink / raw)
  To: gcc-bugs

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?

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-05-19 21:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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).