Bug 97323 - [10/11/12 Regression] ICE 'verify_type' failed on arm-linux-gnueabihf
Summary: [10/11/12 Regression] ICE 'verify_type' failed on arm-linux-gnueabihf
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 10.0
: P2 normal
Target Milestone: 10.4
Assignee: Richard Henderson
URL:
Keywords: ice-on-valid-code
: 97368 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-10-07 17:17 UTC by Matthias Klose
Modified: 2021-05-04 12:31 UTC (History)
8 users (show)

See Also:
Host:
Target: arm-linux-gnueabihf
Build:
Known to work: 9.3.1
Known to fail: 10.2.1, 11.0
Last reconfirmed: 2020-10-08 00:00:00


Attachments
rfc patch (567 bytes, patch)
2020-10-30 20:27 UTC, Richard Henderson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Klose 2020-10-07 17:17:37 UTC
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.
Comment 1 Richard Biener 2020-10-08 07:30:59 UTC
works on x86_64-linux
Comment 2 ktkachov 2020-10-08 10:30:18 UTC
confirmed on trunk with the extra checking enabled
Comment 3 Fabio 2020-10-11 14:03:56 UTC
*** Bug 97368 has been marked as a duplicate of this bug. ***
Comment 4 Matthias Klose 2020-10-12 14:19:12 UTC
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.
Comment 5 Fabio 2020-10-14 08:26:51 UTC
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
Comment 6 Matthias Klose 2020-10-20 13:16:50 UTC
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.
Comment 7 Matthias Klose 2020-10-20 13:20:52 UTC
commit 872d5034baa1007606d405e37937908602fbbe51
Comment 8 Maxim Kuvyrkov 2020-10-28 11:56:07 UTC
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 .
Comment 9 Richard Henderson 2020-10-30 19:27:02 UTC
As a data point, this problem can be seen with any
strict-alignment target -- e.g. sparc.
Comment 10 Richard Henderson 2020-10-30 20:27:58 UTC
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.
Comment 11 Richard Biener 2021-04-08 12:02:39 UTC
GCC 10.3 is being released, retargeting bugs to GCC 10.4.