seen on the gcc-10 branch and trunk 20201003 on arm-linux-gnueabihf. Omitting -g works around the issue. $ cat signal.i typedef int a __attribute__((aligned(2))); a b[1]; $ gcc -c -g -O0 signal.i signal.i:2:1: error: 'TYPE_CANONICAL' is not compatible 2 | a b[1]; | ^ <array_type 0xf751d7e0 type <integer_type 0xf7a4f3c0 int public SI size <integer_cst 0xf7426e58 constant 32> unit-size <integer_cst 0xf7426e70 constant 4> align:32 warn_if_not_align:0 symtab:-144899760 alias-set -1 canonical-type 0xf7a4f3c0 precision:32 min <integer_cst 0xf74370a8 -2147483648> max <integer_cst 0xf74370c0 2147483647> pointer_to_this <pointer_type 0xf7a4ff00>> SI size <integer_cst 0xf7426e58 32> unit-size <integer_cst 0xf7426e70 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf751d7e0 domain <integer_type 0xf751d6c0 type <integer_type 0xf7a4f060 sizetype public unsigned SI size <integer_cst 0xf7426e58 32> unit-size <integer_cst 0xf7426e70 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf7a4f060 precision:32 min <integer_cst 0xf7426e88 0> max <integer_cst 0xf7426000 4294967295>> SI size <integer_cst 0xf7426e58 32> unit-size <integer_cst 0xf7426e70 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf751d6c0 precision:32 min <integer_cst 0xf7426e88 0> max <integer_cst 0xf7426e88 0>>> signal.i:2:1: error: 'TYPE_MODE' of 'TYPE_CANONICAL' is not compatible <array_type 0xf751d7e0 type <integer_type 0xf7a4f3c0 int public SI size <integer_cst 0xf7426e58 constant 32> unit-size <integer_cst 0xf7426e70 constant 4> align:32 warn_if_not_align:0 symtab:-144899760 alias-set -1 canonical-type 0xf7a4f3c0 precision:32 min <integer_cst 0xf74370a8 -2147483648> max <integer_cst 0xf74370c0 2147483647> pointer_to_this <pointer_type 0xf7a4ff00>> SI size <integer_cst 0xf7426e58 32> unit-size <integer_cst 0xf7426e70 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf751d7e0 domain <integer_type 0xf751d6c0 type <integer_type 0xf7a4f060 sizetype public unsigned SI size <integer_cst 0xf7426e58 32> unit-size <integer_cst 0xf7426e70 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf7a4f060 precision:32 min <integer_cst 0xf7426e88 0> max <integer_cst 0xf7426000 4294967295>> SI size <integer_cst 0xf7426e58 32> unit-size <integer_cst 0xf7426e70 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf751d6c0 precision:32 min <integer_cst 0xf7426e88 0> max <integer_cst 0xf7426e88 0>>> <array_type 0xf751d600 type <integer_type 0xf751d660 a SI size <integer_cst 0xf7426e58 constant 32> unit-size <integer_cst 0xf7426e70 constant 4> user align:16 warn_if_not_align:0 symtab:-144899808 alias-set -1 canonical-type 0xf7a4f3c0 precision:32 min <integer_cst 0xf74370a8 -2147483648> max <integer_cst 0xf74370c0 2147483647>> no-force-blk BLK size <integer_cst 0xf7426e58 32> unit-size <integer_cst 0xf7426e70 4> user align:16 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf751d7e0 domain <integer_type 0xf751d6c0 type <integer_type 0xf7a4f060 sizetype public unsigned SI size <integer_cst 0xf7426e58 32> unit-size <integer_cst 0xf7426e70 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf7a4f060 precision:32 min <integer_cst 0xf7426e88 0> max <integer_cst 0xf7426000 4294967295>> SI size <integer_cst 0xf7426e58 32> unit-size <integer_cst 0xf7426e70 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf751d6c0 precision:32 min <integer_cst 0xf7426e88 0> max <integer_cst 0xf7426e88 0>>> signal.i:2:1: internal compiler error: 'verify_type' failed 0x980721 verify_type(tree_node const*) ../../src/gcc/tree.c:14727 0x3969e3 gen_type_die_with_usage ../../src/gcc/dwarf2out.c:25498 0x397fe9 gen_type_die ../../src/gcc/dwarf2out.c:25728 0x393fd5 gen_decl_die ../../src/gcc/dwarf2out.c:26399 0x394aed dwarf2out_decl ../../src/gcc/dwarf2out.c:26908 0x394f8f dwarf2out_early_global_decl ../../src/gcc/dwarf2out.c:26565 0x1c59b1 finish_decl(tree_node*, unsigned int, tree_node*, tree_node*, tree_node*) ../../src/gcc/c/c-decl.c:5453 0x223611 c_parser_declaration_or_fndef ../../src/gcc/c/c-parser.c:2336 0x22bbdf c_parser_external_declaration ../../src/gcc/c/c-parser.c:1745 0x22c451 c_parser_translation_unit ../../src/gcc/c/c-parser.c:1618 0x22c451 c_parse_file() ../../src/gcc/c/c-parser.c:21752 0x279abd c_common_parse_file() ../../src/gcc/c-family/c-opts.c:1190 Please submit a full bug report, with preprocessed source if appropriate. gcc is configured with --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --enable-checking=yes,extra,rtl --enable-default-pie a gcc configured with --enable-checking=release doesn't show this, however segfaults in an unreproducible way in other places.
works on x86_64-linux
confirmed on trunk with the extra checking enabled
*** Bug 97368 has been marked as a duplicate of this bug. ***
this started with a regression hunt in-between with GCC 9 and GCC 10. However the test case with a compiler configured with the extra and rtl checking already produces this ICE with 2018-01-01 and 2019-01-01 builds.
This issue is reproducible (but more rarely) also when using -g0 , see the full build log here: https://launchpadlibrarian.net/501972023/buildlog_ubuntu-groovy-armhf.mesa_20.3~git2010140730.775866~oibaf~g_BUILDING.txt.gz
this is triggered by: 2015-05-19 Jan Hubicka <hubicka@ucw.cz> * tree.c (verify_type_variant): Fix #undef. (gimple_canonical_types_compatible_p): Move here from lto.c (verify_type): Verify TYPE_CANONICAL compatibility. * tree.h (gimple_canonical_types_compatible_p): Declare.
commit 872d5034baa1007606d405e37937908602fbbe51
Hi Richard, Interested in checking out this bug? The original testcase is from QEMU source: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972789 .
As a data point, this problem can be seen with any strict-alignment target -- e.g. sparc.
Created attachment 49473 [details] rfc patch The following fixes the ICE. It seems like a hack, done at the wrong level. Should we have in fact set TYPE_STRUCTURAL_EQUALITY_P all the way back on the unaligned 'a' type, before we even try to create an array of 'a'? If so, that would have properly triggered the test here in build_array_type_1 that would have bypassed the problem.
GCC 10.3 is being released, retargeting bugs to GCC 10.4.
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
GCC 10 branch is being closed.
*** Bug 112791 has been marked as a duplicate of this bug. ***
GCC 11 branch is being closed.