Bug 109618 - [12/13/14/15 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in generic_simplify_CONVERT_EXPR, at generic-match.cc since r12-3278-g823685221de986
Summary: [12/13/14/15 Regression] ICE: tree check: expected class ‘type’, have ‘except...
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 13.0
: P3 normal
Target Milestone: 12.4
Assignee: Not yet assigned to anyone
URL:
Keywords: error-recovery, ice-checking, ice-on-invalid-code
Depends on:
Blocks:
 
Reported: 2023-04-25 05:53 UTC by John X
Modified: 2024-04-26 10:50 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2023-04-25 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John X 2023-04-25 05:53:14 UTC
$ cat test.c 

int foo()
{
  const unsigned int var_1 = 2;
  
  char var_5[var_1];
  
  int var_1[10];
  
  return sizeof(var_5);
}


--------------------------------

$ gcc --version
gcc (GCC) 13.0.1 20230219 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

--------------------------------

$ gcc test.c  
test.c: In function ‘foo’:
test.c:8:7: error: conflicting type qualifiers for ‘var_1’
    8 |   int var_1[10];
      |       ^~~~~
test.c:4:22: note: previous definition of ‘var_1’ with type ‘unsigned int’
    4 |   const unsigned int var_1 = 2;
      |                      ^~~~~
test.c :10:3: internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in generic_simplify_CONVERT_EXPR, at generic-match.cc:28499
   10 |   return sizeof(var_5);
      |   ^~~~~~
0x840637 tree_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*)
	../../gcc-13-20230219/gcc/tree.cc:8959
0x8abac0 tree_class_check(tree_node*, tree_code_class, char const*, int, char const*)
	../../gcc-13-20230219/gcc/tree.h:3653
0x8abac0 generic_simplify_CONVERT_EXPR
	gcc-13-20230219-build/gcc/generic-match.cc:28499
0xbf6848 fold_unary_loc(unsigned int, tree_code, tree_node*, tree_node*)
	../../gcc-13-20230219/gcc/fold-const.cc:9341
0xbf8079 fold_build1_loc(unsigned int, tree_code, tree_node*, tree_node*)
	../../gcc-13-20230219/gcc/fold-const.cc:13778
0x9429bb c_expr_sizeof_expr(unsigned int, c_expr)
	../../gcc-13-20230219/gcc/c/c-typeck.cc:3096
0x97ef46 c_parser_sizeof_expression
	../../gcc-13-20230219/gcc/c/c-parser.cc:8910
0x97ef46 c_parser_unary_expression
	../../gcc-13-20230219/gcc/c/c-parser.cc:8803
0x97fdef c_parser_cast_expression
	../../gcc-13-20230219/gcc/c/c-parser.cc:8672
0x9800df c_parser_binary_expression
	../../gcc-13-20230219/gcc/c/c-parser.cc:8440
0x98154b c_parser_conditional_expression
	../../gcc-13-20230219/gcc/c/c-parser.cc:8138
0x981d24 c_parser_expr_no_commas
	../../gcc-13-20230219/gcc/c/c-parser.cc:8052
0x981fd1 c_parser_expression
	../../gcc-13-20230219/gcc/c/c-parser.cc:11379
0x982717 c_parser_expression_conv
	../../gcc-13-20230219/gcc/c/c-parser.cc:11419
0x97858b c_parser_statement_after_labels
	../../gcc-13-20230219/gcc/c/c-parser.cc:6674
0x9798e4 c_parser_compound_statement_nostart
	../../gcc-13-20230219/gcc/c/c-parser.cc:6296
0x99f164 c_parser_compound_statement
	../../gcc-13-20230219/gcc/c/c-parser.cc:6105
0x9a10cb c_parser_declaration_or_fndef
	../../gcc-13-20230219/gcc/c/c-parser.cc:2841
0x9a8a1b c_parser_external_declaration
	../../gcc-13-20230219/gcc/c/c-parser.cc:1925
0x9a93f3 c_parser_translation_unit
	../../gcc-13-20230219/gcc/c/c-parser.cc:1779
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Comment 1 Richard Biener 2023-04-25 06:37:33 UTC
Confirmed.  We're folding

 <nop_expr 0x7ffff6fdc420
    type <integer_type 0x7ffff6e51000 sizetype public unsigned DI
        size <integer_cst 0x7ffff6e32d98 constant 64>
        unit-size <integer_cst 0x7ffff6e32db0 constant 8>
        align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff6e51000 precision:64 min <integer_cst 0x7ffff6e32dc8 0> max <integer_cst 0x7ffff6e334c0 18446744073709551615>>
    readonly
    arg:0 <var_decl 0x7ffff6e40cf0 var_1 type <error_mark 0x7ffff6e32d80>
        readonly used unsigned read SI t.c:3:22
        size <integer_cst 0x7ffff6e32fd8 constant 32>
        unit-size <integer_cst 0x7ffff6e55000 constant 4>
        align:32 warn_if_not_align:0 context <function_decl 0x7ffff6fe0400 foo> initial <integer_cst 0x7ffff6fe9960 2>>>

to a size_type_node.
Comment 2 Martin Liška 2023-04-27 06:59:43 UTC
Started with r12-3278-g823685221de986.
Comment 3 Andrew Pinski 2024-03-23 20:38:02 UTC
This one seems harder to fix.

We have:
```
(gdb) p debug_tree(value)
 <nop_expr 0x7ffff79ad5c0
    type <integer_type 0x7ffff7822000 sizetype public unsigned DI
        size <integer_cst 0x7ffff7802f48 constant 64>
        unit-size <integer_cst 0x7ffff7802f60 constant 8>
        align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff7822000 precision:64 min <integer_cst 0x7ffff7802f78 0> max <integer_cst 0x7ffff78035e0 18446744073709551615>>
    readonly
    arg:0 <var_decl 0x7ffff7810c60 var_1 type <error_mark 0x7ffff7802f30>
        readonly used unsigned read SI t2.c:3:22
        size <integer_cst 0x7ffff7824198 constant 32>
        unit-size <integer_cst 0x7ffff78241b0 constant 4>
        align:32 warn_if_not_align:0 context <function_decl 0x7ffff79b3600 foo> initial <integer_cst 0x7ffff79bbbe8 2>>>
```

Before calling fold.
So we turn var_1's type to error_mark when merging the 2 decls (after an error).
But then the rest of the front-end/middle-end is still not ready for types all the time to have an error_mark.

Note I don't think we should revert r12-3278 even though it has had a lot of fall out because it produces better error recovery in general.

Note for this simplified testcase we could look through the NOP_EXPR in c_sizeof_alignof but a more complex one which does s/var_5[var_1]/var_5[13 * var_1]/, we can't as we get:
(sizetype) ((unsigned int) var_1 * 13)

And that one ICEs in tree_nonzero_bits.
    CASE_CONVERT:
      return wide_int::from (tree_nonzero_bits (TREE_OPERAND (t, 0)),
                             TYPE_PRECISION (TREE_TYPE (t)),
                             TYPE_SIGN (TREE_TYPE (TREE_OPERAND (t, 0))));