[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887 Tobias Burnus changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #12 from Tobias Burnus --- I have now pulled the newest GCC trunk version - and bootstrapped into an empty directory. I CANNOT REPRODUCE it any more. Either it was fixed by any of the other commits inbetween or it was an anti-schoedinger bug, an odd interaction doing incremental builds when trying to find the regression - or the latent bug still exists but is now hidden, which I won't rule out as it wasn't robust against modifications of file name and the command line. I currently do not intent to dig into this further by trying whether going back to an older version will bring back this bug.
[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #11 from Jakub Jelinek --- CCing Jason if he has any ideas.
[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887 --- Comment #10 from Tobias Burnus --- (In reply to Tobias Burnus from comment #9) > cp_parser_jump_statement (for RID_RETURN) [...] The tree is already different for cp_parser_identifier (called via <- cp_parser_class_name <- cp_parser_type_name <- cp_parser_simple_type_specifier <- cp_parser_postfix_expression <- ... <- cp_parser_jump_statement). I think I annotated (printf debugging) all code which sets TYPE_BINFO or TYPE_NEEDS_CONSTRUCTING - without seeing a difference. Still, the setting differs for _Res. [Ideas how to debug this best are welcome; as reducing it didn't work, it is easy to get lost.]
[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887 --- Comment #9 from Tobias Burnus --- (In reply to Tobias Burnus from comment #8) > Still debugging. > > I add tons of 'printf' and the first difference which shows up is the > following call: [That's without call to register_symbol, i.e. doesn't influence the debug output.] cp_parser_jump_statement (for RID_RETURN) calls check_return_expr - and here it differs: * Without debug, type_dependent_expression_p (retval) is true and, hence, build_non_dependent_expr (with flag == 2) -> fold_non_dependent_expr -> fold_non_dependent_expr_template is called. * With -g3, type_dependent_expression_p (retval) is false and 'retval' is returned. Now looking at that 'retval'. In gcc-trunk/include/c++/10.0.0/bits/stl_tree.h:2093:18, one has: if (__j == begin()) return _Res(__x, __y); The dump for -g3 has: full-name "_Res" no-binfo use_template=1 interface-unknown ... while -gtoggle has: unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffebd9e0a8 fields ignored decl_6 QI /data/local_users/tobiasb/gcc/gcc-trunk/include/c++/10.0.0/bits/stl_pair.h:207:12 size unit-size align:8 warn_if_not_align:0 offset_align 8 offset bit-offset context chain > context full-name "_Res" needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=1 interface-unknown
[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887 --- Comment #8 from Tobias Burnus --- Still debugging. I add tons of 'printf' and the first difference which shows up is the following call: check_return_expr -> build_non_dependent_expr (with flag == 2) -> fold_non_dependent_expr -> fold_non_dependent_expr_template This call only happens with -g0 and not with -g3. (With -g0 there are 507 and with -g3 487 calls to check_return_expr.) However, as register_symbol-calling is not called, this is not the culprit for the symbol_order difference. The register_symbol-calling change for std::_PCC<, _T1, _T2>::_ConstructiblePair() goes via: #0 symtab_node::register_symbol (this=0x7fffeba9c168) at ../../gcc/symtab.c:379 #1 0x00ba17b9 in cgraph_node::create(tree_node*) () at ../../gcc/cgraph.c:523 #2 0x00ba15e1 in cgraph_node::get_create(tree_node*) () at ../../gcc/cgraph.c:545 #3 0x00af8611 in c_genericize(tree_node*) () at ../../gcc/c-family/c-gimplify.c:152 #4 0x00916ea8 in cp_genericize(tree_node*) () at ../../gcc/cp/cp-gimplify.c:1809 #5 0x00952d82 in finish_function(bool) () at ../../gcc/cp/decl.c:16277 #6 0x00a259a4 in instantiate_decl(tree_node*, bool, bool) () at ../../gcc/cp/pt.c:24810 #7 0x008f8d21 in instantiate_cx_fn_r(tree_node**, int*, void*) () at ../../gcc/cp/constexpr.c:5301 #8 0x01279e55 in walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) () at ../../gcc/tree.c:12151 #9 0x0127a736 in walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) () at ../../gcc/tree.h:3698 #10 0x0127d102 in walk_tree_without_duplicates_1 (tp=tp@entry=0x7fffbc18, func=func@entry=0x8f8af0 , data=data@entry=0x0, lh=0xa7c8f0 >*)>) at ../../gcc/tree.c:12502 #11 0x00903a03 in instantiate_constexpr_fns (t=) at ../../gcc/cp/constexpr.c:5325 #12 cxx_eval_outermost_constant_expr(tree_node*, bool, bool, bool, tree_node*) () at ../../gcc/cp/constexpr.c:5397 #13 0x00907f2a in fold_non_dependent_expr_template(tree_node*, int, bool) () at ../../gcc/cp/constexpr.c:5685 #14 0x0090804f in fold_non_dependent_expr (t=t@entry=0x7fffebaca810, complain=complain@entry=0, manifestly_const_eval=manifestly_const_eval@entry=false) at ../../gcc/cp/constexpr.c:5731 #15 0x00a0616e in build_non_dependent_expr(tree_node*) () at ../../gcc/cp/pt.c:26665 #16 0x00a927d2 in build_x_binary_op(op_location_t const&, tree_code, tree_node*, tree_code, tree_node*, tree_code, tree_node**, int) () at ../../gcc/cp/typeck.c:4188 #17 0x00a19937 in tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) [clone .part.0] () at ../../gcc/tree.h:3698 #18 0x00a26358 in tsubst_copy_and_build (integral_constant_expression_p=true, function_p=false, in_decl=0x0, complain=0, args=, t=0x7fffeba65488) at ../../gcc/cp/pt.c:18261 #19 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) [clone .part.0] () at ../../gcc/cp/pt.c:17937 #20 0x00a2c1d4 in tsubst_expr (integral_constant_expression_p=true, in_decl=, complain=, args=, t=) at ../../gcc/cp/pt.c:17029 #21 tsubst_template_arg (in_decl=, complain=, args=, t=) at ../../gcc/cp/pt.c:11554 #22 tsubst_template_arg (t=, args=, complain=, in_decl=) at ../../gcc/cp/pt.c:11542 #23 0x00a33843 in tsubst_template_args(tree_node*, tree_node*, int, tree_node*) () at ../../gcc/cp/pt.c:12590 #24 0x00a38067 in tsubst_aggr_type(tree_node*, tree_node*, int, tree_node*, int) () at ../../gcc/tree.h:3312 #25 0x00a1fa1e in tsubst(tree_node*, tree_node*, int, tree_node*) () at ../../gcc/cp/pt.c:15032 #26 0x00a46632 in type_unification_real(tree_node*, tree_node*, tree_node*, tree_node* const*, unsigned int, int, unification_kind_t, vec**, bool) () at ../../gcc/tree.h:3312 #27 0x00a47139 in fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool, bool) () at ../../gcc/tree.h:3198 #28 0x008cbd37 in add_template_candidate_real(z_candidate**, tree_node*, tree_node*, tree_node*, tree_node*, vec const*, tree_node*, tree_node*, tree_node*, int, tree_node*, unification_kind_t, int) () at ../../gcc/cp/call.c:3318 #29 0x008cc6bd in add_template_candidate (complain=0, strict=DEDUCE_CALL, flags=1, conversion_path=0x7fffebd58208, access_path=0x7fffebd58208, return_type=0x0, arglist=, first_arg=, explicit_targs=0x0, ctype=0x7fffebd9e0a8, tmpl=, candidates=0x7fffc478) at ../../gcc/cp/call.c:5727 #30 add_candidates(tree_node*, tree_node*, vec const*, tree_node*, tree_node*, bool, tree_node*, tree_node*, int, z_candidate**, int) [clone .part.0] () at
[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887 --- Comment #7 from Jakub Jelinek --- I guess the more interesting are the backtrace frames not shown, why it compiler decided to instantiate it just without (resp. with) -g (or -g3 or whatever you are using) and not the other. Is it some hash table traversal from which it is invoked, or what other reason.
[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887 --- Comment #6 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #5) > Which of those 3, or all of them? At the end, I see changes in all of them - but I am not sure whether all of them in all lines. If I add a 'printf' to gcc/cgraph.h's symbol_table::register_symbol (which bumps 'order' alias symbol_order), the no-debug version has the following 11 additional symbols at some point; the first being: symbol_table::register_symbol: order=3774 name=static constexpr bool std::_PCC<, _T1, _T2>::_ConstructiblePair() [with _U1 = std::_Rb_tree_node_base*; _U2 = std::_Rb_tree_node_base*; bool = true; _T1 = std::_Rb_tree_node_base*; _T2 = std::_Rb_tree_node_base*] This one comes from gcc-trunk/include/c++/10.0.0/bits/stl_pair.h:100:29 and the backtrace is: #0 symtab_node::register_symbol (this=0x7fffeba9b168) at ../../gcc/symtab.c:379 #1 0x00ba00e9 in cgraph_node::create(tree_node*) () at ../../gcc/cgraph.c:523 #2 0x00b9ff11 in cgraph_node::get_create(tree_node*) () at ../../gcc/cgraph.c:545 #3 0x00af6f51 in c_genericize(tree_node*) () at ../../gcc/c-family/c-gimplify.c:152 #4 0x00916498 in cp_genericize(tree_node*) () at ../../gcc/cp/cp-gimplify.c:1809 #5 0x00952312 in finish_function(bool) () at ../../gcc/cp/decl.c:16272 #6 0x00a24cc4 in instantiate_decl(tree_node*, bool, bool) () at ../../gcc/cp/pt.c:24794 #7 0x008f869d in instantiate_cx_fn_r(tree_node**, int*, void*) () at ../../gcc/cp/constexpr.c:5296 A bit later, I see lines for -g3 only, which come in addition for 'std::_Vector_base
[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887 --- Comment #5 from Jakub Jelinek --- (In reply to Tobias Burnus from comment #4) > Looking at the .gdk files, the difference is (only) in the > ;; Function > lines where > funcdef_no=9263, cgraph_uid=3950, symbol_order=5009 > differ in their numeric value. > > (As it depends on this odd library patch and on passing the full path > instead of a relative path, it points to some indirect effect.) Which of those 3, or all of them? For one of them, pick the smallest different values and in the code that assign those counters try to find out where they are assigned differently (different numbers for the fndecl with the same name) and why. If say funcdef_no differs, it might help to add a debugging dump to say stderr in allocate_struct_function when current_function_funcdef_no = get_next_funcdef_no (); is done, printing the fndecl say using dump_generic_stmt and the current_function_funcdef_no that got set. For the other counters similarly, depending on which you'll look at. That would allow you to spot the very first difference in those, then just debug why some function has been created only with -g and not without or vice versa.
[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887 --- Comment #4 from Tobias Burnus --- Looking at the .gdk files, the difference is (only) in the ;; Function lines where funcdef_no=9263, cgraph_uid=3950, symbol_order=5009 differ in their numeric value. (As it depends on this odd library patch and on passing the full path instead of a relative path, it points to some indirect effect.)
[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887 --- Comment #3 from Jonathan Wakely --- If the compiler itself used std::to_string and that function had a bug, I can see how it might cause this, but that function is C++11 so GCC can't use it anyway.
[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Well, libstdc++ can't be the right component, because a -fcompare-debug failure necessarily is a compiler bug. That said, we don't have a reproducer. Can you reproduce with -E -fdirectives-only preprocessing and then compiling that preprocessed source named whatever.C?
[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-06-17 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I can't reproduce that..
[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887 Richard Biener changed: What|Removed |Added Keywords||build Component|other |libstdc++ Target Milestone|--- |10.0
