[Bug tree-optimization/18478] [4.0 Regression] ICE with -funroll-loops
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-18 12:51 --- Fixed by Jeff's patch http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg00823.html -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18478
[Bug tree-optimization/18478] [4.0 Regression] ICE with -funroll-loops
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-16 13:54 --- *** Bug 18521 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||micis at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18478
[Bug tree-optimization/18478] [4.0 Regression] ICE with -funroll-loops
--- Additional Comments From law at redhat dot com 2004-11-15 17:01 --- Subject: Re: [4.0 Regression] ICE with -funroll-loops On Sun, 2004-11-14 at 15:47 +, kazu at cs dot umass dot edu wrote: --- Additional Comments From kazu at cs dot umass dot edu 2004-11-14 15:47 --- I am doing a binary search right now, but it's probably Jeff's patch that causes this bug. With his patch, GCC shares some CASE_LABEL_EXPR within one SWITCH_EXPR. When a basic block is copied, I don't think these shared CASE_LABEL_EXPR are properly updated. Specifically, it's possible that one CASE_LABEL_EXPR points to another CASE_LABEL_EXPR of another SWITCH_EXPR. I'll take a look. It shouldn't be terribly hard to make sure the right thing happens when we copy SWITCH_EXPRs. [ This does make me wonder about any copying we do during inlining as well. I'll look at that too. ] jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18478
[Bug tree-optimization/18478] [4.0 Regression] ICE with -funroll-loops
--- Additional Comments From law at redhat dot com 2004-11-15 17:56 --- Subject: Re: [4.0 Regression] ICE with -funroll-loops On Sun, 2004-11-14 at 17:50 +, giovannibajo at libero dot it wrote: --- Additional Comments From giovannibajo at libero dot it 2004-11-14 17:49 --- Well, if unshare_expr is invalid for SWITCH_EXPRs, I guess you should either do your check within unshare_expr itself, or at least add a gcc_assert() to unshare_expr so that we check that it is never called with a SWITCH_EXPR. I would go for the former, so that the users don't have to do the same check externally. Well, this is a bloody interesting can of worms. I hadn't pondered someone copying a SWITCH_EXPR when I made my changes. My bad. The bad news is I don't really like any of the options to fix this problem as they're going to involve special casing SWITCH_EXPR in the copying/unsharing code in one form or another. I'm seriously considering reverting those changes. Losing the case leader concept isn't as terrible as you might think once we have the hash table available in tree_redirect_edge_and_branch. Having a case leader means we don't have to walk the set of equivalent cases to update their labels. [ Note we'll just be walking equivalent labels, not the entire vector. ] Alternately, we hack up the copying/unsharing code to deal with this wart. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18478
[Bug tree-optimization/18478] [4.0 Regression] ICE with -funroll-loops
--- Additional Comments From law at redhat dot com 2004-11-16 04:25 --- Subject: Re: [4.0 Regression] ICE with -funroll-loops On Sun, 2004-11-14 at 17:50 +, giovannibajo at libero dot it wrote: --- Additional Comments From giovannibajo at libero dot it 2004-11-14 17:49 --- Well, if unshare_expr is invalid for SWITCH_EXPRs, I guess you should either do your check within unshare_expr itself, or at least add a gcc_assert() to unshare_expr so that we check that it is never called with a SWITCH_EXPR. I would go for the former, so that the users don't have to do the same check externally. After poking at this in various ways today, I think we're going to be best off losing the CASE_LEADER idea for now. I couldn't come up with anything I liked in terms of changes to the node copying code. I'm testing changes to introduce using the edge to cases hash table during thread_jumps and split_critical_edges which ought to keep us from regressing on 15524 when I remove the CASE_LEADER code. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18478
[Bug tree-optimization/18478] [4.0 Regression] ICE with -funroll-loops
-- What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Known to fail||4.0.0 Last reconfirmed|-00-00 00:00:00 |2004-11-14 15:20:43 date|| Summary|ICE with -funroll-loops |[4.0 Regression] ICE with - ||funroll-loops Target Milestone|--- |4.0.0 Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18478
[Bug tree-optimization/18478] [4.0 Regression] ICE with -funroll-loops
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-14 15:33 --- This is also a recent regression, like PR18475. Jeff, I suspect that your patch http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg00596.html is responsible for the regression(s), but I haven't checked that yet. -- What|Removed |Added CC||law at gcc dot gnu dot org, ||reichelt at gcc dot gnu dot ||org Keywords||monitored http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18478
[Bug tree-optimization/18478] [4.0 Regression] ICE with -funroll-loops
--- Additional Comments From kazu at cs dot umass dot edu 2004-11-14 15:47 --- I am doing a binary search right now, but it's probably Jeff's patch that causes this bug. With his patch, GCC shares some CASE_LABEL_EXPR within one SWITCH_EXPR. When a basic block is copied, I don't think these shared CASE_LABEL_EXPR are properly updated. Specifically, it's possible that one CASE_LABEL_EXPR points to another CASE_LABEL_EXPR of another SWITCH_EXPR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18478
[Bug tree-optimization/18478] [4.0 Regression] ICE with -funroll-loops
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-14 17:06 --- Even though they might not be dups, they are related bugs. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org BugsThisDependsOn||18475 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18478
[Bug tree-optimization/18478] [4.0 Regression] ICE with -funroll-loops
--- Additional Comments From kazu at cs dot umass dot edu 2004-11-14 17:30 --- *** Bug 18475 has been marked as a duplicate of this bug. *** -- What|Removed |Added Bug 18478 depends on bug 18475, which changed state. Bug 18475 Summary: [4.0 Regression] ICE Segmentation fault in tree_verify_flow_info with -funswitch-loops http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18475 What|Old Value |New Value Status|NEW |RESOLVED Resolution||DUPLICATEBug 18478 depends on bug 18475, which changed state. Bug 18475 Summary: [4.0 Regression] ICE Segmentation fault in tree_verify_flow_info with -funswitch-loops http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18475 What|Old Value |New Value Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18478
[Bug tree-optimization/18478] [4.0 Regression] ICE with -funroll-loops
--- Additional Comments From giovannibajo at libero dot it 2004-11-14 17:49 --- Well, if unshare_expr is invalid for SWITCH_EXPRs, I guess you should either do your check within unshare_expr itself, or at least add a gcc_assert() to unshare_expr so that we check that it is never called with a SWITCH_EXPR. I would go for the former, so that the users don't have to do the same check externally. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18478
