[Bug target/42536] [4.4/4.5/4.6 regression] ICE in spill_failure, at reload1.c:2141
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42536 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #5 from Jeffrey A. Law 2010-11-29 20:33:14 UTC --- I guess it would be possible for reload to split an insn in some circumstances, particularly when there's complex addressing modes and multiple registers dying within the insn. As you know, I've been poking at range splitting and we might be able to model this case too. Right now I split based on unallocated pseudos and expect to split ranges based on pseudos getting the wrong kind of register in the future. However, there's a couple areas were we still want to split ranges and we may be able to come up with a generic way to express the other ranges we want to split: -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bug-42536-5724-vfzft5f...@http.gcc.gnu.org/bugzilla/
[Bug target/26415] [4.3/4.4/4.5 regression] m68k-linux bootstrap error during stage2
--- Comment #18 from law at redhat dot com 2010-02-24 21:49 --- Fixed by: 2007-09-18 Roman Zippel * config/m68k/m68k.md (beq, bne, bgt, blt, bge, ble, bordered, bunordered, buneq, bunge, bungt, bunle, bunlt, bltgt, beq_rev, bne_rev, bgt_rev, blt_rev, bge_rev, ble_rev, bordered_rev, bunordered_rev, buneq_rev, bunge_rev, bungt_rev, bunle_rev, bunlt_rev, bltgt_rev): Replace all fbcc with fjcc. -- law at redhat dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26415 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100224214942.8081.qm...@sourceware.org
[Bug tree-optimization/27087] [4.1/4.2 regression] ICE in merge_alias_info
--- Comment #3 from law at redhat dot com 2006-04-11 05:41 --- The problem is that may_propagate_copy and merge_alias_info are inconsistent. ie, DOM properly calls may_propagate_copy to determine if a particular copy propagation is valid. may_propagate_copy returns true indicating the copy propagation is valid. However, when the copy propagation is performed and we reach merge_alias_info, merge_alias_info has an additional sanity check that causes it to fail. This really isn't a DOM problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27087 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug tree-optimization/27087] [4.1/4.2 regression] ICE in merge_alias_info
--- Comment #4 from law at redhat dot com 2006-04-11 05:56 --- Subject: Re: [4.1/4.2 regression] ICE in merge_alias_info On Sat, 2006-04-08 at 23:16 +, pinskia at gcc dot gnu dot org wrote: > > --- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-08 23:16 > --- > Confirmed, the ICE is during DOM. As I mentioned in the PR notes, the problem is tree-ssa-copy.c::may_propagate_copy allows copy propagations which are rejected by merge_alias_info. Specifically it allows copy propagating when the flow-sensitive alias information is not compatible. I'm not entirely sure the compatibility check in may_propagate_copy and merge_alias_info is correct. It seems to me that we want to verify that one is a subset of the other, not just that the two objects have intersecting flow sensitive information. Someone more familiar with this code should follow-up on that issue. My patch merely makes the two routines consistent in how they handle flow-sensitive alias information for copy propagations. Bootstrapped and regression tested on i686-pc-linux-gnu. --- Comment #5 from law at redhat dot com 2006-04-11 05:56 --- Created an attachment (id=11241) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11241&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27087 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug tree-optimization/27087] [4.1/4.2 regression] ICE in merge_alias_info
--- Comment #6 from law at redhat dot com 2006-04-13 16:38 --- Fixed a couple days ago. -- law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27087 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug tree-optimization/27087] [4.1 regression] ICE in merge_alias_info
--- Comment #8 from law at redhat dot com 2006-04-13 17:05 --- Subject: Re: [4.1 regression] ICE in merge_alias_info On Thu, 2006-04-13 at 16:51 +, pinskia at gcc dot gnu dot org wrote: > > --- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-13 16:51 > --- > But only fixed on the mainline for 4.2 and not for 4.1. Feel free to backport the patch to 4.1; I'm not likely to get to it. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27087 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug tree-optimization/27087] [4.1 regression] ICE in merge_alias_info
-- law at redhat dot com changed: What|Removed |Added CC|law at redhat dot com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27087 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug tree-optimization/27087] [4.1 regression] ICE in merge_alias_info
--- Comment #10 from law at redhat dot com 2006-04-18 17:24 --- Patch installed on 4.1 branch too. -- law at redhat dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27087 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug middle-end/25328] [4.0/4.1 regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1453
--- Comment #4 from law at redhat dot com 2005-12-20 21:33 --- I've been unable to reproduce this with the gcc-4.1 branch sources. IT's going to be awful difficult to fix if I can't reproduce the problem. At the very least I'll need the before-dom dumps and some analysis of whatever transformation is causing the problem. Note that a failure to fold is more likely a symptom of a problem elsewhere, like mucked up types and such -- which may also explain why this has been reported as front-end specific. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25328 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug middle-end/25328] [4.0/4.1 regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1453
--- Comment #5 from law at redhat dot com 2005-12-21 04:33 --- Was able to reproduce with gcc-4.0 branch sources. Investigating, looks like we might have a type botch somewhere... Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25328 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug middle-end/25328] [4.0/4.1 regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1453
--- Comment #6 from law at redhat dot com 2005-12-21 04:44 ---
Definitely a type problem. The Obj-C front-end is playing it too lose with
types.
main (argc, argv)
{
char msg[100];
int status;
const unsigned char D.1189;
char * msg.0;
# BLOCK 0
# PRED: ENTRY (fallthru)
# msg_3 = V_MUST_DEF ;
msg = "";
msg.0_4 = &msg; /* Mis-matched types here */
# VUSE ;
D.1189_5 = *msg.0_4; /* And again here. */
return;
# SUCC: EXIT
}
I *think* the right code is that msg.0 should have type
const unsigned char *. In the assignment to msg.0_4 the
RHS should be casted to const unsigned char *
This is a front-end problem as far as I can tell.
Jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25328
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug bootstrap/59770] [4.9 Regression] bootstrap failure for arm-linux-gnueabi targeting armv4t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59770 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |DUPLICATE --- Comment #2 from Jeffrey A. Law --- Tracking this via the older 59595 *** This bug has been marked as a duplicate of bug 59595 *** -- You are receiving this mail because: You are on the CC list for the bug. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bug-59770-5724-h3eqfgq...@http.gcc.gnu.org/bugzilla/
Bug#187564: [Bug target/10692] [3.3/3.4/4.0 regression] [m68k] miscompilation of perl with -O2 -fPIC
--- Additional Comments From law at redhat dot com 2004-12-02 04:53 --- I haven't done a ton of analysis on this PR, but from the looks of it, I would hazard a guess the problem is in the reload inheritance code inside choose_reload_regs. Which happens to be code I'm not terribly familiar with. You might see if you can get Joern to look at it since he worked heavily in that code through the years. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10692 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-09 16:20 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Thu, 2004-12-09 at 02:51 +, kazu at cs dot umass dot edu wrote: > --- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 > 02:51 --- > Here are the PHI nodes that I am getting at L2 in thread_across_edge > called on edge L23 -> L2. > > TMT.0_24 = PHI ; > ivtmp14_6 = PHI <0(1), ivtmp14_14(5)>; > d_5 = PHI ; <- defined > tmp_4 = PHI ; <- used > d23_3 = PHI ; > > Note that d_5 is defined *and* used. > At this point, it's not safe to use SSA_NAME_VALUE for d_5. Presumably these PHIs are at the start of a loop? (Otherwise we have a use that is not dominated by its def). It shouldn't be terribly hard to build a map of the PHI defs and if we see a use, then record nothing into our tables. But I'd like to sit down and rethink that code a little -- the way it handles loops is, err STUPID. The nice thing is fixing how it handles loops would go a long way towards the long standing need to improve the selection code for jump threading. I'm deep inside revamping tree-ssa-alias.c to make it do sane things for 15855. But I'll try to put those changes on hold and deal with 18694 since 18694 represents a mis-compilation. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-09 16:47 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Thu, 2004-12-09 at 14:19 +, schwab at suse dot de wrote: > --- Additional Comments From schwab at suse dot de 2004-12-09 14:19 > --- > The patch does no good on ia64, it causes the stage2 compiler to be > miscompiled. Any chance you could do a little analysis on this? All Kazu's change does is cause us to ignore certain (bogus) equivalences. If that's causing stage2 to be mis-compiled, then, well we've clearly got deeper problems. Having at least a rough idea of the root cause of the ia64 failure would be good as I can keep that issue in mind as a rethink how the jump thread selection code ought to work when dealing with loops. You might be able to at least get some idea of the failure mode by looking at what jumps are threaded by DOM before/after Kazu's patch. That may be faster than actually sitting down with the debugger to figure out what's being mis-compiled. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-09 17:38 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Thu, 2004-12-09 at 16:58 +, kazu at cs dot umass dot edu wrote: > --- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 > 16:58 --- > With my old patch (conservative-dom), stmt.c was miscompiled on my machine. > stage2/cc1 crashes on compiling crtstuff.c. > Replacing stmt.o with stage1/stmt.o worked for me. I'll work from that. It ought to be enough for me to to see if one of my theories about ignoring equivalences applies. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-09 18:12 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Thu, 2004-12-09 at 16:57 +, kazu at cs dot umass dot edu wrote: > --- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 > 16:57 --- > Created an attachment (id=7714) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7714&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7714&action=view) > a new patch > > I think this new patch is conceptually more correct. > See the comments in the patch. I certainly agree it's conceptually more correct. However, I still want to have a clear understanding of why the first patch produced failures. I'll be poking at the first patch shortly. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-09 19:52 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Thu, 2004-12-09 at 19:22 +, kazu at cs dot umass dot edu wrote: > --- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 > 19:22 --- > Jeff, > > With my new patch, stmt.i gets one fewer jump threading opportunities > (compared to what the vanilla mainline produces). > So it's very plausible that we are miscompiling stmt.c quietly. Certainly possible. > > This difference comes from DOM1 while compiling stmt.c:expand_asm_operands. > > I hope this helps. It does. I'm just now getting started and knowing the routine in question certainly narrows the search field. > > With my old patch, I got one more jump threading opportunity > (compared to what the vanilla mainline produces). > It was one of loop.i, stmt.i, and predict.i. > > Since my old patch gives less information to lookup routines, > the increase in the number of opportunity seems very strange. Not really if you know the history of this code :( The selection code (thread_across_edge) dates from before the SSA updating code could handle threading through a block with side effects that needed to be preserved. So the selection code would go through some "interesting" contortions to prove that statements in the block were just nops. So for example given X_10 = We would lookup in the hash tables. If we got a hit and the result was X_n, then we would consult the current definition of X. If the current definition of X was X_n, then the statement above is really just X_10 = X_n Which is the same as X = X Which is a nop and thus can be ignored. Now if we look at your change: tree src = PHI_ARG_DEF_FROM_EDGE (phi, e); tree dst = PHI_RESULT (phi); + if (TREE_CODE (src) == SSA_NAME + && TREE_CODE (SSA_NAME_DEF_STMT (src)) == PHI_NODE + && bb_for_stmt (SSA_NAME_DEF_STMT (src)) == e->dest) + continue; record_const_or_copy (dst, src); register_new_def (dst, &block_defs_stack); We see that when the IF's condition holds we continue the loop, meaning that we don't record a new definition for the LHS of the PHI -- which means we don't update the current definition for the PHI_RESULT's underlying variable. The net result is that we have the wrong current definition for some objects. This in turn could lead to (incorrectly) threading a jump that was not threadable before. It may be enough to remove the "continue" and instead move the call to record_const_or_copy into the IF statement's THEN clause. That prevents recording the bogus equivalence, but still keeps the current definition of each variable up-to-date. This is all speculation at this point. I'm going to dig into this code under the control of the debugger to see what's going on when we compile stmt.c > > If you want, I can find out which of DOM[123] is causing this problem > on which function in which file for you. No need. I suspect it'll be pretty obvious given that we thread jumps differently in loop.i, stmt.i and predict.i. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-09 23:23 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Thu, 2004-12-09 at 20:02 +, kazu at cs dot umass dot edu wrote: > --- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 > 20:02 --- > Created an attachment (id=7715) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7715&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7715&action=view) > a new patch > > This patch is basically the same as the last patch except that > I've added a fast path for common cases. > > I am testing this with submission to gcc-patches@ in mind. I believe your fast-path check is effectively equivalent to if ((e->flags & EDGE_DFS_BACK) == 0) Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-10 18:10 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Thu, 2004-12-09 at 20:02 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu 2004-12-09
> 20:02 ---
> Created an attachment (id=7715)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7715&action=view)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7715&action=view)
> a new patch
>
> This patch is basically the same as the last patch except that
> I've added a fast path for common cases.
>
> I am testing this with submission to gcc-patches@ in mind.
BTW, here's the analysis of why the first patch didn't work.
First, as I mentioned earlier, we're failing to register a
definition with the original patch you submitted. This can
lead to different (and incorrect jump threading).
Second, the comment at the start of the code is somewhat misleading,
particularly in the case where we're threading the back edge in a
loop.
When dealing with a backedge in a loop, we may have already recorded
a value for the result of the PHI node. The PHI node may record a
new (and different) value for the result of the PHI node. Failure
to note that can result in extracting the old (and now invalid) value.
A great example would be this code extracted from stmt.c (yes, I know
this uses uninitialized variables and such. I was too lazy to turn
those variables into parameters -- and it doesn't matter for the
sake of this analysis.
union tree_node;
typedef union tree_node *tree;
struct tree_common
{
tree chain;
};
union tree_node
{
struct tree_common common;
};
static unsigned char
check_operand_nalternatives (tree outputs, tree inputs)
{
tree next, tmp;
while (tmp)
{
if (((tmp)->common.chain))
tmp = next, next = 0;
}
}
# BLOCK 0
# PRED: ENTRY (fallthru)
goto ();
# SUCC: 3 (fallthru)
# BLOCK 1
# PRED: 3 (true)
:;
# VUSE ;
D.1130_5 = tmp_1->common.chain;
if (D.1130_5 != 0B) goto ; else goto ;
# SUCC: 2 (true) 3 (dfs_back,false)
# BLOCK 2
# PRED: 1 (true)
:;
tmp_6 = next_2;
next_7 = 0B;
# SUCC: 3 (fallthru,dfs_back)
# BLOCK 3
# PRED: 0 (fallthru) 1 (dfs_back,false) 2 (fallthru,dfs_back)
# next_2 = PHI ;
# tmp_1 = PHI ;
:;
if (tmp_1 != 0B) goto ; else goto ;
# SUCC: 1 (true) 4 (false)
# BLOCK 4
# PRED: 3 (false)
:;
return;
# SUCC: EXIT
}
One possible ordering of blocks for the DOM walker would be
0, 3, 1, 2, ...
Traversing the edge 3->1 will record true = (tmp_1 != 0) into our
hash tables. When we're done processing block #2, we try to thread
the edge from 2->3.
Note carefully the PHIs at the start of block #3. If we simply don't
record anything for tmp_1 because it's argument references next_2 from
the previous PHI, then when we hit the tmp_1 != 0B conditional again,
we will assume that it's true (it was true when we traversed from 3->1
and we failed to record that tmp_1's value changed).
Note that recording tmp_1 = next_2 isn't particularly good either since
tmp_1 really isn't equivalent to next_2. It's equivalent to the
previous valueof n next_2, which was next_3. ugh. Anyway, I'll verify
that Kazu's patch handles this correctly.
I'll add this to my list of nasty things related to following backedges
in the threader. More than once I've pondered not threading back edges.
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-10 18:11 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Thu, 2004-12-09 at 05:24 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu 2004-12-09
> 05:24 ---
> Updated the testcase like so:
>
> /* PR tree-optimization/18694
>
>The dominator optimization didn't take the PHI evaluation order
>into account when threading an edge. */
>
> extern void abort (void) __attribute__((noreturn));
> extern void exit (int) __attribute__((noreturn));
>
> void __attribute__((noinline))
> foo (int i)
> {
> int next_n = 1;
> int j = 0;
>
> for (; i != 0; i--)
> {
> int n;
>
> for (n = next_n; j < n; j++)
> next_n++;
>
> if (j != n)
> abort ();
> }
> }
>
> int
> main (void)
> {
> foo (2);
> exit (0);
> }
>
>
Can you go ahead and install this into the testsuite? No need to xfail
since we ought to have a patch installed for the problem soon.
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-10 18:24 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Fri, 2004-12-10 at 00:28 +, kazu at cs dot umass dot edu wrote: > --- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 > 00:28 --- > Subject: Re: [4.0 regression] loop > miscompilation at -O1 (-ftree-ch) > > Hi Jeff, > > > I believe your fast-path check is effectively equivalent to > > > > if ((e->flags & EDGE_DFS_BACK) == 0) > > I see that we call mark_dfs_back_edges at the beginning of > tree_ssa_dominator_optimize. Now, after we call cleanup_tree_cfg, can > we trust EDGE_DFS_BACK? > > No pass in cleanup_tree_cfg really adds an edge. All we do is either > remove or redirect edges, so the real question is "Do we ever get a > new back edge without a EDGE_DFS_BACK mark as a result of edge > redirection?" If we have a forwarder block BB flowing into the loop > header, BB's sole successor edge may be marked with a EDGE_DFS_BACK, > but its incoming edges may not be. When we call > cleanup_forwarder_blocks, the edges that will survive are BB's > incoming edges, not the edge going out of BB, so we may end up with a > back edge without a EDGE_DFS_BACK mark. Hmm, I think you're right. > I think we should call mark_dfs_back_edges at the beginning of every > iteration That might be advisable -- we use EDGE_DFS_BACK to avoid creating irreducible loops as a result of jump threading IIRC. > or simply use dominated_by_p, which is not too expensive - > only a couple of "if" statements, assuming the dominator infomatino is > available. EDGE_DFS_BACK would have been more efficient. But I don't think it's 100% safe right now. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-10 19:18 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Fri, 2004-12-10 at 19:08 +, kazu at cs dot umass dot edu wrote: > I think so. :-) I don't. :( I think it'll record tmp_1 = next_2, which is actually wrong, even though it doesn't actually cause problems with this testcase. > What thread_across_edge is really trying to do is "What would these > statements in E->dest look like if they appeared at the end of > E->src?" Then the question is reduced to whether each statement in > E->dest is translated correctly. To do the translation, we use > SSA_NAME_VALUE, but note that we don't use it iteratively. In other > words, given a SSA_NAME variable VAR, we don't do this > > while (TREE_CODE (var) == SSA_NAME >&& SSA_NAME_VALUE (var) != NULL_TREE) > var = SSA_NAME_VALUE (var); And the reason we don't do that is we can actually get into a loop due to equivalences created by equality tests. > p.s. > By the way, I am now wondering how many times we succeed in threading > a back edge. It does happen, but I don't know how often. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-10 19:44 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Fri, 2004-12-10 at 19:08 +, kazu at cs dot umass dot edu wrote: > By the way, I am now wondering how many times we succeed in threading > a back edge. I just put in some instrumentation. It happens relatively often. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-10 20:00 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Fri, 2004-12-10 at 19:08 +, kazu at cs dot umass dot edu wrote: > --- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 > 19:08 --- > Subject: Re: [4.0 regression] loop > miscompilation at -O1 (-ftree-ch) > > Hi Jeff, > > > Note that recording tmp_1 = next_2 isn't particularly good either since > > tmp_1 really isn't equivalent to next_2. It's equivalent to the > > previous valueof n next_2, which was next_3. ugh. Anyway, I'll verify > > that Kazu's patch handles this correctly. > > I think so. :-) > > What thread_across_edge is really trying to do is "What would these > statements in E->dest look like if they appeared at the end of > E->src?" Then the question is reduced to whether each statement in > E->dest is translated correctly. To do the translation, we use > SSA_NAME_VALUE, but note that we don't use it iteratively. In other > words, given a SSA_NAME variable VAR, we don't do this > > while (TREE_CODE (var) == SSA_NAME >&& SSA_NAME_VALUE (var) != NULL_TREE) > var = SSA_NAME_VALUE (var); > > because SSA_NAME_VALUE is supposed to be closed so that you won't need > to iterate. So when we follow "copy-of" relation from tmp_1 to next_2 > using SSA_NAME_VALUE, we don't follow next_2 to something else. > > Note also that lookup_avail_expr does not translate the expression in > hash table using SSA_NAME_VALUE. What we translate is the expression > that we look up. BTW, I may have a nice clean way to deal with this problem which doesn't depend on us not walking the SSA_NAME_VALUE chain. I'm looking into it now... jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-10 20:12 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Fri, 2004-12-10 at 19:57 +, kazu at cs dot umass dot edu wrote: > --- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 > 19:57 --- > Subject: Re: [4.0 regression] loop > miscompilation at -O1 (-ftree-ch) > > Hi Jeff, > > > > I think so. :-) > > I don't. :( I think it'll record tmp_1 = next_2, which is actually > > wrong, even though it doesn't actually cause problems with this > > testcase. > > IMHO, you should really think of it as tmp_1 -> next_2 or "tmp_1 is a > copy-of next_2". It is a one-way relation, not an equivalence because > it is not symmetric. Err, no. You're totally warping how the the equivalency code is meant to work. It's a symmetric relationship and it's your patch that is making it asymmetric. > Let me also think hard to see if I can prove my patch is correct or > come up with a counterexample. I certainly don't intend to push my > patch blindly. Don't bother. The patch is wrong.There's a couple of very simple ways to fix this problem that I'm evaluating. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-10 20:52 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Fri, 2004-12-10 at 19:08 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu 2004-12-10
> 19:08 ---
> Subject: Re: [4.0 regression] loop
> miscompilation at -O1 (-ftree-ch)
>
> Hi Jeff,
>
> > Note that recording tmp_1 = next_2 isn't particularly good either since
> > tmp_1 really isn't equivalent to next_2. It's equivalent to the
> > previous valueof n next_2, which was next_3. ugh. Anyway, I'll verify
> > that Kazu's patch handles this correctly.
>
> I think so. :-)
So as I mentioned in a message a short while ago, there are some very
simple solutions to this problem.
1. The simplest would be to disable jump threading on for backedges in
loops. Based on some simple instrumentation, that would be bad as
it would inhibit a large number of threading opportunities (at least
two hundred within GCC's cc1 .i files).
2. Disable threading only if we find a PHI argument which was set
by a PHI the same block. This still disables a lot of threading
opportunities. However, we can do much better with a trivial
improvement
3. Given a PHI node like x_2 = (..., x_2, ...); if we want the x_2
alternative, then there's no need to inhibit jump threading since
x_2 is always trivially equivalent to itself.
Option #3 only prevents two valid jump threading opportunities in the
tests I ran. And it's implementation is pretty trivial:
/* Each PHI creates a temporary equivalence, record them. */
for (phi = phi_nodes (e->dest); phi; phi = PHI_CHAIN (phi))
{
tree src = PHI_ARG_DEF_FROM_EDGE (phi, e);
tree dst = PHI_RESULT (phi);
/* If the desired argument is not the same as this PHI's result
and it is set by a PHI in this block, then we can not thread
through this block. */
if (src != dst
&& TREE_CODE (src) == SSA_NAME
&& TREE_CODE (SSA_NAME_DEF_STMT (src)) == PHI_NODE
&& bb_for_stmt (SSA_NAME_DEF_STMT (src)) == e->dest)
return;
record_const_or_copy (dst, src);
register_new_def (dst, &block_defs_stack);
}
A final approach would be to turn that code into something like this:
/* Each PHI creates a temporary equivalence, record them. */
for (phi = phi_nodes (e->dest); phi; phi = PHI_CHAIN (phi))
{
tree src = PHI_ARG_DEF_FROM_EDGE (phi, e);
tree dst = PHI_RESULT (phi);
/* If the desired argument is not the same as this PHI's result
and it is set by a PHI in this block, then we can not thread
through this block. */
if (src != dst
&& TREE_CODE (src) == SSA_NAME
&& TREE_CODE (SSA_NAME_DEF_STMT (src)) == PHI_NODE
&& bb_for_stmt (SSA_NAME_DEF_STMT (src)) == e->dest)
{
src = make_ssa_name (SSA_NAME_VAR (dst), build_empty_stmt());
}
record_const_or_copy (dst, src);
register_new_def (dst, &block_defs_stack);
}
Which would allow us to do full jump threading. What I don't like about
this approach is we have to add some code to track the SSA_NAMEs we
generate in that loop so that we can release them. Ugh. It doesn't
seem worth the headache.
Jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-10 21:42 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Fri, 2004-12-10 at 21:31 +, kazu at cs dot umass dot edu wrote: > Can you come up with a hypothetical scenario? No need. It's fundamentally broken in that it's recording an invalid equivalence. It's recording that tmp_1 = next_2 which is totally bogus. The only reason it works is because we don't walk through all the SSA_NAME_VALUEs back to the oldest. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-13 20:36 --- Should be fixed with today's checkin to tree-ssa-dom.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
-- What|Removed |Added BugsThisDependsOn|18241 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
-- What|Removed |Added OtherBugsDependingO|1 | nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
