[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #22 from Martin Jambor jamborm at gcc dot gnu.org 2013-03-12 09:09:12 UTC --- Indeed, bootstrap with BOOT_CFLAGS='-O2 -g -fno-ipa-sra' now finally passes. Thanks!
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #19 from Richard Biener rguenth at gcc dot gnu.org 2013-03-06 09:45:11 UTC --- Ok, with some added debug printing I see Updating SSA: creating PHI node in block #6 for elim_cost$cost creating PHI node in block #17 for elim_cost$cost -creating PHI node in block #19 for cost$cost creating PHI node in block #6 for elim_cost$complexity +creating PHI node in block #19 for cost$cost that's obviously a problem (creating a PHI node involves creating a new SSA name). That's because we insert new PHI nodes for to rename symbols via FOR_EACH_VEC_ELT (symbols_to_rename, i, sym) insert_updated_phi_nodes_for (sym, dfs, blocks_to_update, update_flags); but we need to visit that in UID order ... I have a patch.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #20 from Richard Biener rguenth at gcc dot gnu.org 2013-03-06 11:24:20 UTC --- Author: rguenth Date: Wed Mar 6 11:24:07 2013 New Revision: 196488 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196488 Log: 2013-03-06 Richard Biener rguent...@suse.de PR middle-end/56294 * tree-into-ssa.c (insert_phi_nodes_for): Add dumping. (insert_updated_phi_nodes_compare_uids): New function. (update_ssa): Sort symbols_to_rename after UID before traversing it to insert PHI nodes. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-into-ssa.c
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #21 from Richard Biener rguenth at gcc dot gnu.org 2013-03-06 11:25:04 UTC --- Fixed.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 10:02:41 UTC --- (In reply to comment #15) (In reply to comment #13) A guess is that you end up creating SSA names during code transform in different order - which can result from walking a hashtable to do things (which might be in different order when it doesn't have the same number of entries). I have verified in the debugger that SRA does not create any new SSA names on its own, all of them are created by renaming after the pass finishes (i.e. by TODO_update_ssa). Note that if you process debug stmts _at all_ (thus end up creating new SSA names because of them) then this will break as well. I'm not sure what you mean. SRA does not process debug stmts but it now creates them. The re-namer is apparently clever enough not to create a PHI node and thus a new SSA name because of debug statements, yet it manages to create them in a different order, probably because it sees uses were there are none without debug statements. Can that be the case? Is creating such uses really a bug? Awww. ISTR SRA creates new decls that are renamed by the SSA renamer. SSA rewriting creates those SSA names when visiting definition sites (this is why it doesn't create PHI nodes for debug uses ... hopefully). Renaming is performed in DOM order, but DOM order has DOM children unordered - can you check if rewrite_update_enter_block visits basic-blocks in different order -g vs. -g0?
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294
--- Comment #18 from Martin Jambor jamborm at gcc dot gnu.org 2013-03-05
16:49:29 UTC ---
(In reply to comment #17)
Which is the testcase that still fails? The attached and more reduced ones
pass for me ...
The testcase from comment #10 (called Another unrelated issue) still
fails for me with g++ -O2 -fno-ipa-sra -fcompare-debug. (I use trunk
from yesterday).
(In reply to comment #16)
can you check if rewrite_update_enter_block visits basic-blocks
in different order -g vs. -g0?
No, from the dumps it does not seem so (see below). The dump also
shows that in the -g1 case, the renamer sees elim_cost$complexity much
earlier with debug statements. However, even seeing them only a
little bit earlier (BB 17 as opposed to 18) is enough to trigger the
problem. Perhaps because there is a to-be SSA name definition at the
beginning of BB 18?
-g0:
Updating SSA:
Registering new PHI nodes in block #0
Registering new PHI nodes in block #2
Registering new PHI nodes in block #3
Registering new PHI nodes in block #4
Updating SSA information for statement elim_cost$cost = SR.30;
Updating SSA information for statement elim_cost$complexity = SR.31;
Updating SSA information for statement _22 = elim_cost$cost;
Registering new PHI nodes in block #5
Updating SSA information for statement elim_cost$cost = _24;
Registering new PHI nodes in block #6
Updating SSA information for statement cost$cost = elim_cost$cost;
Updating SSA information for statement _74 = cost$cost;
Registering new PHI nodes in block #7
Registering new PHI nodes in block #8
Registering new PHI nodes in block #9
Registering new PHI nodes in block #10
Registering new PHI nodes in block #11
Registering new PHI nodes in block #12
Registering new PHI nodes in block #13
Registering new PHI nodes in block #14
Registering new PHI nodes in block #15
Registering new PHI nodes in block #16
Updating SSA information for statement _50 = elim_cost$cost;
Updating SSA information for statement elim_cost$cost = _51;
Registering new PHI nodes in block #17
Registering new PHI nodes in block #18
Updating SSA information for statement cost$cost = elim_cost$cost;
Updating SSA information for statement cost$complexity = elim_cost$complexity;
Registering new PHI nodes in block #19
Updating SSA information for statement cost$cost = cost$cost;
Updating SSA information for statement _78 = cost$cost;
Registering new PHI nodes in block #20
Symbols to be put in SSA form
{ D.2850 D.2851 D.2854 D.2855 D.2856 D.2857 D.2858 D.2859 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 21
Number of blocks to update: 20 ( 95%)
Affected blocks: 0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
-g1:
Updating SSA:
Registering new PHI nodes in block #0
Registering new PHI nodes in block #2
Registering new PHI nodes in block #3
Registering new PHI nodes in block #4
Updating SSA information for statement elim_cost$cost = SR.30;
Updating SSA information for statement elim_cost$complexity = SR.31;
Updating SSA information for statement _22 = elim_cost$cost;
Registering new PHI nodes in block #5
Updating SSA information for statement elim_cost$cost = _24;
Registering new PHI nodes in block #6
Updating SSA information for statement cost$cost = elim_cost$cost;
Updating SSA information for statement # DEBUG cost$complexity =
elim_cost$complexity
Updating SSA information for statement _74 = cost$cost;
Registering new PHI nodes in block #7
Registering new PHI nodes in block #8
Registering new PHI nodes in block #9
Registering new PHI nodes in block #10
Registering new PHI nodes in block #11
Registering new PHI nodes in block #12
Registering new PHI nodes in block #13
Registering new PHI nodes in block #14
Registering new PHI nodes in block #15
Registering new PHI nodes in block #16
Updating SSA information for statement _50 = elim_cost$cost;
Updating SSA information for statement elim_cost$cost = _51;
Registering new PHI nodes in block #17
Updating SSA information for statement # DEBUG cost1$cost = elim_cost$cost
Updating SSA information for statement # DEBUG cost1$complexity =
elim_cost$complexity
Registering new PHI nodes in block #18
Updating SSA information for statement cost$cost = elim_cost$cost;
Updating SSA information for statement cost$complexity = elim_cost$complexity;
Registering new PHI nodes in block #19
Updating SSA information for statement cost$cost = cost$cost;
Updating SSA information for statement # DEBUG cost$complexity =
cost$complexity
Updating SSA information for statement _78 = cost$cost;
Registering new PHI nodes in block #20
Symbols to be put in SSA form
{ D.2850 D.2851 D.2854 D.2855 D.2856 D.2857 D.2858 D.2864 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 21
Number of blocks to update: 20 ( 95%)
Affected blocks: 0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #15 from Martin Jambor jamborm at gcc dot gnu.org 2013-03-04 17:15:25 UTC --- (In reply to comment #13) A guess is that you end up creating SSA names during code transform in different order - which can result from walking a hashtable to do things (which might be in different order when it doesn't have the same number of entries). I have verified in the debugger that SRA does not create any new SSA names on its own, all of them are created by renaming after the pass finishes (i.e. by TODO_update_ssa). Note that if you process debug stmts _at all_ (thus end up creating new SSA names because of them) then this will break as well. I'm not sure what you mean. SRA does not process debug stmts but it now creates them. The re-namer is apparently clever enough not to create a PHI node and thus a new SSA name because of debug statements, yet it manages to create them in a different order, probably because it sees uses were there are none without debug statements. Can that be the case? Is creating such uses really a bug?
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01 10:27:50 UTC --- A guess is that you end up creating SSA names during code transform in different order - which can result from walking a hashtable to do things (which might be in different order when it doesn't have the same number of entries). Note that if you process debug stmts _at all_ (thus end up creating new SSA names because of them) then this will break as well.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-01 10:32:34 UTC --- No SSA_NAMEs should be created because of debug stmts. SSA_NAME_VERSION must be identical in between -fvar-tracking-assignments and -fno-var-tracking-assignments, DECL_UIDs might differ, but sorted by DECL_UID the decls must be same if you only consider decls seen with -fno-var-tracking-assignments.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #12 from Martin Jambor jamborm at gcc dot gnu.org 2013-02-28 12:43:42 UTC --- Author: jamborm Date: Thu Feb 28 12:43:33 2013 New Revision: 196340 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196340 Log: 2013-02-28 Martin Jambor mjam...@suse.cz PR tree-optimization/56294 * tree-sra.c (analyze_access_subtree): Create replacement declarations. Adjust dumping. (get_access_replacement): Do not call create_access_replacement. Assert a replacement exists. (get_repl_default_def_ssa_name): Create the replacement declaration itself. testsuite/ * g++.dg/debug/pr56294.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/pr56294.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294
Martin Jambor jamborm at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
AssignedTo|jamborm at gcc dot gnu.org |unassigned at gcc dot
||gnu.org
--- Comment #11 from Martin Jambor jamborm at gcc dot gnu.org 2013-02-27
16:11:02 UTC ---
OK, patch http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01233.html
fixes the testcase from comment #7 and patch
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01235.html should avoid
some further (although apparently not that crucial) differences in SRA
-g and -g0 output. Unfortunately, they do not fix the debug
comparison failure from comment #9.
The problematic difference is:
--- testcase.gkd2013-02-27 16:25:54.036565436 +0100
+++ testcase.gk.gkd 2013-02-27 16:25:54.185565083 +0100
@@ -140,3 +140,3 @@
(insn:TI# 0 0 5 (set (reg/f:DI 6 bp [orig:62 D. ] [62])
-(mem/f:DI (const_int 0 [0]) [ *control_var_27(D)+0 S8 A64]))
testcase.ii:166# {*movdi_internal_rex64}
+(mem/f:DI (const_int 0 [0]) [ *control_var_28(D)+0 S8 A64]))
testcase.ii:166# {*movdi_internal_rex64}
(nil))
and appears for the first time in release_ssa pass. It seems to me
that (right after early SRA), two SSA names simply have a different
order in -g0 and -g compilations:
-SSA_NAME 63: elim_cost$complexity_63
- DEF: elim_cost$complexity_63 = PHI elim_cost$complexity_50(D)(3),
elim_cost$complexity_85(5), elim_cost$complexity_85(4)
+SSA_NAME 63: cost$cost_63
+ DEF: cost$cost_63 = PHI cost$cost_80(D)(17), cost$cost_79(18)
-SSA_NAME 71: cost$cost_71
- DEF: cost$cost_71 = PHI cost$cost_80(D)(17), cost$cost_79(18)
+SSA_NAME 71: elim_cost$complexity_71
+ DEF: elim_cost$complexity_71 = PHI elim_cost$complexity_50(D)(3),
elim_cost$complexity_85(5), elim_cost$complexity_85(4)
Also, if I just do not produce DEBUG statements with
elim_cost$complexity on the RHS, the problem goes away. However, I do
not anything wrong with the statements. Later, just before
release_ssa, three SSA names have different order:
-SSA_NAME 67: .MEM_67
- DEF: comp ={v} {CLOBBER};
+SSA_NAME 63: cost$cost_63
+ DEF: cost$cost_63 = PHI cost$cost_80(D)(12), elim_cost$cost_72(13)
-SSA_NAME 70: control_var_70(D)
- DEF: GIMPLE_NOP
+SSA_NAME 67: .MEM_67
+ DEF: comp ={v} {CLOBBER};
-SSA_NAME 71: cost$cost_71
- DEF: cost$cost_71 = PHI cost$cost_80(D)(12), elim_cost$cost_72(13)
+SSA_NAME 70: control_var_70(D)
+ DEF: GIMPLE_NOP
...and control_var manages to leak to the final dump, causing the
failure.
I'll return to this bug in a few days, but now I need a break from it,
so I'm un-assigning myself.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #9 from Martin Jambor jamborm at gcc dot gnu.org 2013-02-23 11:37:24 UTC --- Created attachment 29528 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29528 A simpler patch to fix issue in comment 7 The patch from comment #8 had problems of its own, mainly it does not take care of the elaborate fancy names that create_access_replacement creates for the user-created aggregates. I think that the SR names that it leaves in the artificial aggregate replacements do not have a high enough value to justify another parameter of get_access_replacement and storing or late-creating fancy names and so on, so if we do not want to create replacements upfront, I'd actually prefer this much simpler patch. However, if we go down this route of creating replacements lazily, that will mean that replacement declarations may be created in different order in -g and -g0 runs (exactly in the cases when patch from comment #8 had to upgrade a debug-only replacement to a real one), which, if I understand it well, may lead to different ordering of decl UIDs which in turn may eventually lead to further code generation differences...
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #10 from Martin Jambor jamborm at gcc dot gnu.org 2013-02-23 11:50:46 UTC --- Created attachment 29529 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29529 Another unrelated issue Irrespective of ho we decide to deal with the first issue, there is another problem that hinders bootstrap with IPA-SRA disabled of compilation of tree-ssa-loop-ivopts.c with -fno-ipa-sra and -fcompare-debug. I have reduced the issue with multidelta to the attached pre-processed form that fails with O2 -fno-ipa-sra -fcompare-debug and started failing with revision 195015: 2013-01-08 Martin Jambor mjam...@suse.cz PR debug/55579 * tree-sra.c (analyze_access_subtree): Return true also after potentially creating a debug-only replacement. As far I can see, dumps begin to diverge in the release_ssa early pass where, in the -g case, a control_var SSA names gets a version number 28 instead of 27 - that is also the problematic difference in the final dump. So far I have not figured out what is the one extra live SSA_NAME that lives in the debug case nor I have observed anything apparently wrong in the behavior of early SRA.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #8 from Martin Jambor jamborm at gcc dot gnu.org 2013-02-19 14:48:39 UTC --- Created attachment 29497 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29497 Patch to fix at least part of the problem This patch fixes Jakub's testcase and the one produced by multidelta too. It adds a new parameter to get_access_replacement alogn the lines of the patch in comment #7 of PR 54971 and makes other provisions as discussed yesterday on IRC. The patch passes bootstrap and testsuite on x86_64-linux, but on its own it does not fix the original problem, i.e. bootstrap with IPA-SRA disabled still fails due to a miscomparison. So I'll defer submitting it until after I figure out what problems are still outstanding and whether we want to deal with them in a single patch or not.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-18
12:15:26 UTC ---
More reduced testcase for -O2 -fno-ipa-sra -fcompare-debug:
struct comp_cost { int cost; unsigned complexity; };
struct cost_pair { struct iv_cand *cand; };
struct iv_use { unsigned n_map_members; cost_pair *cost_map; };
struct iv_cand { unsigned id; };
void
bar (comp_cost, comp_cost)
{
}
void
foo (iv_use *use, iv_cand *cand)
{
unsigned i, s = cand-id (use-n_map_members - 1);
for (i = 0; i s; i++)
if (use-cost_map[i].cand)
goto found;
found:
use-cost_map[i].cand = cand;
comp_cost elim_cost, express_cost, bound_cost;
bar (elim_cost, express_cost);
}
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org 2013-02-15 16:00:43 UTC --- Created attachment 29469 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29469 Reduced testcase Testcase reduced by multidelta that fails with -c -O2 -fno-ipa-sra -fno-exceptions -fcompare-debug -no-inlining or -fdbg-cnt=tree_sra:7 makes the failure go away.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org 2013-02-13 10:56:15 UTC --- With the debug counters I have identified the first function where the difference in behavior of intra-SRA behavior with -g vs -g0 caused the comparison failure but could not spot any differences in non-debug statements. Adding -fno-inline makes the comparison failure go away (-fno-early-inlining does not help) so at this point I suppose it's tree-inline that generates different stuff when there are references to SSA names from debug statements.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-02-12 AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Martin Jambor jamborm at gcc dot gnu.org 2013-02-12 10:46:31 UTC --- Sigh.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-02-12 12:28:28 UTC --- Is it a compare-debug failure?
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org 2013-02-12 18:16:27 UTC --- Yes, compiling the pre-processed source with -c -O2 -fno-ipa-sra -fcompare-debug -fno-exceptions fails too. Time for some debug counters.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2013-02-12 19:43:39 UTC --- Yes, compiling the pre-processed source with -c -O2 -fno-ipa-sra -fcompare-debug -fno-exceptions fails too. Time for some debug counters.
