[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #51 from Jakub Jelinek --- Author: jakub Date: Fri Apr 15 14:51:06 2016 New Revision: 235033 URL: https://gcc.gnu.org/viewcvs?rev=235033=gcc=rev Log: PR c++/70594 * constexpr.c (constexpr_call_table): Preserve in GC.

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #49 from Jakub Jelinek --- Author: jakub Date: Thu Apr 14 19:21:31 2016 New Revision: 234987 URL: https://gcc.gnu.org/viewcvs?rev=234987=gcc=rev Log: PR c++/70594 * ipa-utils.h (polymorphic_ctor_dtor_p): New

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #48 from Jakub Jelinek --- Created attachment 38271 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38271=edit gcc6-pr70594.patch Untested fix. So the other issue is that noncall_stmt_may_be_vtbl_ptr_store looks for BLOCKs

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #47 from Jakub Jelinek --- Ok, found one bug in the unused block pruning: --- gcc/ipa-polymorphic-call.c.jj 2016-03-30 16:00:17.0 +0200 +++ gcc/ipa-polymorphic-call.c 2016-04-14 16:45:45.407754387 +0200 @@ -479,16

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #46 from Jakub Jelinek --- So, it seems the ctor BLOCKs are preserved, but others are removed. So, with -g we get: (gdb) p debug_generic_stmt (block_ultimate_origin ($29)) BLOCK #0 SUPERCONTEXT: assign (gdb) p debug_generic_stmt

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 Nathan Sidwell changed: What|Removed |Added Assignee|nathan at gcc dot gnu.org |rguenth at gcc dot gnu.org ---

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #44 from Richard Biener --- Index: gcc/ipa-polymorphic-call.c === --- gcc/ipa-polymorphic-call.c (revision 234971) +++ gcc/ipa-polymorphic-call.c (working copy) @@

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #43 from Richard Biener --- Same walking of BLOCKs in noncall_stmt_may_be_vtbl_ptr_store.

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #42 from Jakub Jelinek --- I see a difference when tree-ssa-pre.c calls context.get_dynamic_type (instance, OBJ_TYPE_REF_OBJECT (fn), otr_type, stmt); in get_dynamic_type, right after the first walk_aliased_vdefs in there, in one

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #41 from Richard Biener --- Maybe decl_maybe_in_construction_p using BLOCKs. I suppose it should restrict itself to inlined_function_outer_scope_p ()s which we surely preserve. for (tree block = gimple_block (call); block &&

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #40 from Jakub Jelinek --- So, some further printf debugging shows that the first difference is that in one of the possible_polymorphic_call_targets calls (which creates the node->order == 4151 __builtin_unreachable in one with -g2

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #39 from Jakub Jelinek --- Sorry, error on my part. There is actually #1 0x00b3e9d6 in symbol_table::release_symbol (this=0x715a10a8, node=, uid=0) at ../../gcc/cgraph.h:2514 #2 0x00b3972a in

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #38 from Jakub Jelinek --- Surprisingly, the actual problem is with __builtin_unreachable. I've instrumented symbol_table::register_symbol, so that it logs this->order and node->name () after assigning node->order, and get:

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #36 from Jakub Jelinek --- Tobias said he still sees some -fcompare-debug issue even with both of these patches, so not closing this yet.

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #35 from Jakub Jelinek --- Author: jakub Date: Wed Apr 13 20:35:59 2016 New Revision: 234961 URL: https://gcc.gnu.org/viewcvs?rev=234961=gcc=rev Log: PR c++/70594 * tree-sra.c (create_access_replacement,

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #34 from Jason Merrill --- (In reply to Jakub Jelinek from comment #33) > (pop_labels): During named_labels traversal, just push the slot > pointers into a vector, then qsort it by DECL_UID and only then > call

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #33 from Jakub Jelinek --- Author: jakub Date: Wed Apr 13 14:45:46 2016 New Revision: 234942 URL: https://gcc.gnu.org/viewcvs?rev=234942=gcc=rev Log: PR c++/70594 * decl.c (pop_labels_1): Removed.

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #32 from Jakub Jelinek --- Created attachment 38251 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38251=edit gcc6-pr70594.patch Alternate patch for the SRA fancy names in -fdump-final-insns= dumps (and other TDF_NOUID dumps).

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #31 from Jakub Jelinek --- Created attachment 38249 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38249=edit gcc6-pr70594-labels.patch Only the first spot is problematic IMHO, the latter is only for diagnostics, and I think

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #30 from Jakub Jelinek --- Ah, the reason is clear, hash_table *x_named_labels; hashes based on DECL_UID (that is fine), and adds the labels during hash table traversal (which is not fine). Both: static void pop_labels (tree block)

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #29 from Jakub Jelinek --- The different order of copy_node_stat happens during tree_function_versioning -> remap_blocks -> remap_block -> remap_decls -> remap_decl -> copy_decl_no_change -> copy_node_stat, and the BLOCK_VARS are

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #28 from Jakub Jelinek --- For the #c0 difference with the #c20 instrumentation there is: /tmp/uids:"yynewstate" label_decl 101636 0 3 /tmp/uids:"yyabortlab" label_decl 101638 0 3 /tmp/uids:"yyacceptlab" label_decl 101639 0 3

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #27 from Nathan Sidwell --- (In reply to Jason Merrill from comment #26) > With this patch gengtype seems to assign gt_ggc_mx(tree&) to cp/constexpr.o, > breaking cc1 link. I'm not going to try to fix that now, though someone >

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #26 from Jason Merrill --- (In reply to Jason Merrill from comment #25) > Created attachment 38245 [details] > Patch to not discard copies > > This seems like a minimal fix; does it in fact fix the bug? With this patch gengtype

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #25 from Jason Merrill --- Created attachment 38245 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38245=edit Patch to not discard copies This seems like a minimal fix; does it in fact fix the bug?

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #24 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #18) > For the testcases in this PR probably: [...[ > [...] would be enough [...] But the #c0 report suggests this affects > more than that, but only Tobias has the

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #23 from Jakub Jelinek --- 2016-04-12 Jakub Jelinek PR c++/70594 * tree-sra.c (make_fancy_decl_name): Don't add DECL_UID into the fancy names if -fdump-final-insns=. ---

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #22 from Richard Biener --- The make_fancy_decl_name change is desirable but decls made by SRA should be DECL_IGNORED and thus not end up anywhere in debug info. Allocating or not allocating DECL_UIDs based on GC is a recipie for

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #21 from Jakub Jelinek --- Or by adding another printout (say { FILE *f = fopen ("/tmp/uids", "a"); fprintf (f, "===\n"); fclose (f); } somehwere to toplev.c (main) early on, so that you can run it all from the

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #20 from Jakub Jelinek --- Tobias, could you try your to reproduce your #c0 issue, with a debugging patch like: --- gcc/tree.c.jj 2016-03-11 17:37:42.0 +0100 +++ gcc/tree.c 2016-04-12 10:43:10.463675009 +0200 @@

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #19 from Nathan Sidwell --- (In reply to Jason Merrill from comment #17) > I still don't understand why/how this is causing problems, if > -fcompare-debug only cares about the order of decls. The copied decls > shouldn't appear

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #18 from Jakub Jelinek --- For the testcases in this PR probably: --- gcc/tree-sra.c 2016-04-09 13:21:06.111510703 +0200 +++ gcc/tree-sra.c 2016-04-11 23:11:41.253126047 +0200 @@ -1537,17 +1537,12 @@

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #17 from Jason Merrill --- I still don't understand why/how this is causing problems, if -fcompare-debug only cares about the order of decls. The copied decls shouldn't appear anywhere in the output, and other decls should still

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #16 from Patrick Palka --- Success, compiling dwarf2out.c with "-O2 -fcompare-debug --param ggc-min-expand=3 --param ggc-min-heapsize=3 -save-temps" managed to trigger the compare-debug failure while leaving behind a bunch of temp

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #15 from Patrick Palka --- I tried building latest gcc with BOOT_CFLAGS="-O2 -fcompare-debug" and the build fails with an -fcompare-debug error while compiling dwarf2out.c. The failure doesn't go away if I make the

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #14 from Nathan Sidwell --- (In reply to Jakub Jelinek from comment #13) > If you remove the deletableness, then I'd say it is really important to > empty the whole freelist at least at the end of parsing, so that when GIMPLE >

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #13 from Jakub Jelinek --- (In reply to Nathan Sidwell from comment #11) > Patrick's original patch did 2 things AFAICT > 1) make constexpr_call_table GC deletable > 2) add the fundef_copies_table etc. > > The failure we're

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #12 from Nathan Sidwell --- (In reply to Patrick Palka from comment #9) > The decls belonging to a copy of a function must have new UIDs though > because their uids are used to track their mutable values (within the >

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #11 from Nathan Sidwell --- Patrick's original patch did 2 things AFAICT 1) make constexpr_call_table GC deletable 2) add the fundef_copies_table etc. The failure we're observing is of constexpr_call_table losing information, which

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #10 from Patrick Palka --- (In reply to Jakub Jelinek from comment #8) > (In reply to Nathan Sidwell from comment #7) > > copy_node_stat allocates a new UID for decls. so despite its name > > 'copy_decl_no_change' does cause a

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #9 from Patrick Palka --- (In reply to Nathan Sidwell from comment #7) > The change in debug generation causes purtabations in when GC happens. > Such that in onecase we find a cached result, and in the other case we do > not.

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #8

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 Nathan Sidwell changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 Jakub Jelinek changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #5 from Patrick Palka --- (In reply to Tobias Burnus from comment #4) > Created attachment 38225 [details] > test.ii test case (g++ -O1 -fcompare-debug) > > (In reply to Jakub Jelinek from comment #1) > > Without the testcase it is

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #4 from Tobias Burnus --- Created attachment 38225 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38225=edit test.ii test case (g++ -O1 -fcompare-debug) (In reply to Jakub Jelinek from comment #1) > Without the testcase it is

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #3 from Patrick Palka --- (In reply to Jakub Jelinek from comment #1) > Without the testcase it is hard to guess. > But one guess is that if in case of GC the cache is wiped and recreating it > may create something -fcompare-debug

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #2 from Jakub Jelinek --- Perhaps a way to reduce this (though not as a -fcompare-debug failure) would be to see if on the original testcase you get different code generation or different -fdump-final-insns= dump between normal GC

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1

[Bug c++/70594] [6 Regression] -fcompare-debug failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 Tobias Burnus changed: What|Removed |Added Target Milestone|--- |6.0