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&root=gcc&view=rev
Log:
PR c++/70594
* constexpr.c (constexpr_call_table): Preser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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&root=gcc&view=rev
Log:
PR c++/70594
* ipa-utils.h (polymorphic_ctor_dtor_p): New
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&action=edit
gcc6-pr70594.patch
Untested fix.
So the other issue is that noncall_stmt_may_be_vtbl_ptr_store looks for BLOC
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 +479,
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 (b
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
---
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)
@@ -485
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.
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
invo
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 && TREE_
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 on
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 cgraph_node::re
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:
/tmp/orde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #
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.
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&root=gcc&view=rev
Log:
PR c++/70594
* tree-sra.c (create_access_replacement,
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 pop_l
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&root=gcc&view=rev
Log:
PR c++/70594
* decl.c (pop_labels_1): Removed.
(n
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&action=edit
gcc6-pr70594.patch
Alternate patch for the SRA fancy names in -fdump-final-insns= dumps (and other
TDF_NOUID d
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&action=edit
gcc6-pr70594-labels.patch
Only the first spot is problematic IMHO, the latter is only for diagnostics,
and I t
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)
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 alre
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
/tmp/uid
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
> else
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 seem
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&action=edit
Patch to not discard copies
This seems like a minimal fix; does it in fact fix the bug?
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 re
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=.
--- gcc/tree-sra.c.jj 2016-04-12 11:0
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 des
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
dri
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
@@ -981,6
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 anywh
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 @@ compare_access_positions
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 have
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 fil
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 constexpr_call_tab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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
> optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
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 observing
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
> constexpr_ctx::
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 t
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 chan
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. Wh
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594
Nathan Sidwell changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594
Jakub Jelinek changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #
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
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&action=edit
test.ii test case (g++ -O1 -fcompare-debug)
(In reply to Jakub Jelinek from comment #1)
> Without the testcase
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 car
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 par
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594
Tobias Burnus changed:
What|Removed |Added
Target Milestone|--- |6.0
54 matches
Mail list logo
