>>> ...and of course, now I can't recreate that issue at all and the >>> ptr_vector_*_type use work fine now. Strange! ...so ok, changed. >>> Maybe the behavior changed since my PR106017 fix went in??? >> >> That is my best guess as well. But, how did that help this test? > > It didn't. :-) During my bootstrap, I hit the gimple verification issue > I mentioned seeing earlier. My problem was I thought I hit it with the > test case, but it was exposed on a different test case in the testsuite. > Here's what I'm seeing, which only happens when using -O0 -flto: > > rain6p1% gcc -O0 -mcpu=power10 -flto pr102347.c > lto1: internal compiler error: in gimple_canonical_types_compatible_p, at > tree.cc:13677 > 0x11930a97 gimple_canonical_types_compatible_p(tree_node const*, tree_node > const*, bool) > /home/bergner/gcc/gcc-fsf-mainline-pr101322/gcc/tree.cc:13677 > 0x1192f1ab verify_type_variant > /home/bergner/gcc/gcc-fsf-mainline-pr101322/gcc/tree.cc:13377 > 0x11930beb verify_type(tree_node const*) > /home/bergner/gcc/gcc-fsf-mainline-pr101322/gcc/tree.cc:13700 > 0x106bbd37 lto_fixup_state > /home/bergner/gcc/gcc-fsf-mainline-pr101322/gcc/lto/lto-common.cc:2629 > 0x106bbff3 lto_fixup_decls > /home/bergner/gcc/gcc-fsf-mainline-pr101322/gcc/lto/lto-common.cc:2660 > 0x106bce13 read_cgraph_and_symbols(unsigned int, char const**) > /home/bergner/gcc/gcc-fsf-mainline-pr101322/gcc/lto/lto-common.cc:2901 > 0x1067bcbf lto_main() > /home/bergner/gcc/gcc-fsf-mainline-pr101322/gcc/lto/lto.cc:656 > 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. > lto-wrapper: fatal error: > /home/bergner/gcc/build/gcc-fsf-mainline-pr101322-debug/gcc/xgcc returned 1 > exit status > compilation terminated. > /home/bergner/binutils/install/binutils-power10/bin/ld: error: lto-wrapper > failed > collect2: error: ld returned 1 exit status > > The problem goes away if I use use -O1 or above, I drop -flto or I use > the code I originally posted without the ptr_vector_*_type > > The assert in gimple_canonical_types_compatible_p() we're hitting is: > 13673 default: > 13674 /* Consider all types with language specific trees in them > mutually > 13675 compatible. This is executed only from verify_type and false > 13676 positives can be tolerated. */ > 13677 gcc_assert (!in_lto_p); > 13678 return true; > > I have no idea why ptr_vector_*_type would behave differently here than > build_pointer_type (vector_*_type_node). Using the build_pointer_type() > fixed it for me, so that's why I went with it. :-) Maybe this is a bug > in lto???
Thanks for your time to reproduce this! The only difference is that ptr_vector_*_type are built from the qualified_type based on vector_*_type_node, instead of directly from vector_*_type_node. I'm interested to have a further look at this later. BR, Kewen
