Created attachment 54865 [details] optimise.ii.orig.xz Had this when building form-4.3.0. Originally reported downstream in Gentoo at https://bugs.gentoo.org/904339. To trigger this, I had to use -U_GLIBCXX_ASSERTIONS as I have it enabled by default for my GCC (Gentoo has it enabled by default for hardened, but not all setups). Obviously this doesn't matter once preprocessed though. Needs a checking build. ``` $ g++ -DHAVE_CONFIG_H -I. -I.. -O2 -Wall -Wextra -Wpadded -Wno-misleading-indentation -Wno-stringop-overflow -U_GLIBCXX_ASSERTIONS -c sources/optimize.cc ‘ during GIMPLE pass: uninit In function ‘void find_Horner_MCTS()’: canonical types differ for identical types ‘UBYTE [7]’ {aka ‘unsigned char [7]’} and ‘unsigned char [7]’ 2208 | void find_Horner_MCTS () { | ^~~~~~~~~~~~~~~~ 0x68ea0a comptypes(tree_node*, tree_node*, int) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/cp/typeck.cc:1710 0x22768b9 cxx_types_compatible_p(tree_node*, tree_node*) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/cp/cp-objcp-common.cc:130 0x11ed84a c_fold_indirect_ref_for_warn /usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/c-family/c-pretty-print.cc:1851 0x11edf79 c_fold_indirect_ref_for_warn /usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/c-family/c-pretty-print.cc:1918 0x11ee249 print_mem_ref /usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/c-family/c-pretty-print.cc:1981 0x7b8b72 expr_to_string(tree_node*) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/cp/error.cc:3315 0x21adbb0 cp_printer /usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/cp/error.cc:4484 0x1a71e85 pp_format(pretty_printer*, text_info*) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/pretty-print.cc:1475 0x1a710c3 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/diagnostic.cc:1592 0x1aef8c9 diagnostic_impl /usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/diagnostic.cc:1756 0x1aef8c9 warning_at(unsigned int, int, char const*, ...) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/diagnostic.cc:1893 0x9eda7e maybe_warn_operand /usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/tree-ssa-uninit.cc:731 0x1d83413 warn_uninitialized_vars /usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/tree-ssa-uninit.cc:1098 0x22271fa execute_late_warn_uninitialized /usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/tree-ssa-uninit.cc:1406 0x22271fa execute /usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/tree-ssa-uninit.cc:1451 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://bugs.gentoo.org/> for instructions. ``` Reduction in progress.
Reduced: ``` struct vector { vector& operator=(vector&& __x) { return *this; } }; struct tree_node { vector childs; unsigned char pad[7]; tree_node(){} }; tree_node mcts_root; void find_Horner_MCTS_expand_tree () { mcts_root = tree_node(); } ``` Compile at -O2 -Wall is enough to reproduce the failure. Note using unsigned short or unsigned int instead of unsigned char allows it to work.
Created attachment 54866 [details] reduced.ii Yours is better formed, I think, but let me attach the results of cvise which just finished for the hell of it.
Bisect says: abb1b6058c09a7c0430d9bf019466ada07ca7b40 is the first bad commit commit abb1b6058c09a7c0430d9bf019466ada07ca7b40 Author: Martin Sebor <msebor@redhat.com> Date: Wed Jan 6 13:44:27 2021 -0700 PR c++/95768 - pretty-printer ICE on -Wuninitialized with allocated storage i.e. r11-6508-gabb1b6058c09a7.
Note that it's also missing the 'internal compiler error' message in the output.
GCC 11.4 is being released, retargeting bugs to GCC 11.5.
So we have two "unsigned char [7]" types. They are the same except that one has TYPE_DEPENDENT_P_VALID set. One of them comes from the C++ FE: grokfield -> grokdeclarator -> create_array_type_for_decl etc. This has TYPE_DEPENDENT_P_VALID set. The other one is created in gimple_fold_builtin_memory_op: 1323 desttype = build_array_type_nelts (unsigned_char_type_node, 1324 tree_to_uhwi (len)); 1325 srctype = desttype; 1326 if (src_align > TYPE_ALIGN (srctype)) 1327 srctype = build_aligned_type (srctype, src_align); 1328 srcvar = fold_build2 (MEM_REF, srctype, src, off0); this also answers the question why the problem only happens with "unsigned char". Later, we warn in maybe_warn_operand: warning_at -> ... -> print_mem_ref which tries to display: MEM <unsigned char[7]> [(char * {ref-all})&D.2870 + 1B] print_mem_ref calls c_fold_indirect_ref_for_warn with this: 1961 tree cop = build3_loc (loc, COMPONENT_REF, TREE_TYPE (field), 1962 op, field, NULL_TREE); 1963 off = off - upos; 1964 if (tree ret = c_fold_indirect_ref_for_warn (loc, type, cop, 1965 off)) 1966 return ret; The type of the MEM_REF is the second type. But COP here is D.2870.pad, and its type is the first one. Comparing those two in same_type_ignoring_top_level_qualifiers_p will crash since they are the same types but their canonical types are not identical. I don't know what the fix would be.