This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/18478] [4.0 Regression] ICE with -funroll-loops
- From: "law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 15 Nov 2004 17:56:04 -0000
- Subject: [Bug tree-optimization/18478] [4.0 Regression] ICE with -funroll-loops
- References: <20041114150907.18478.kazu@cs.umass.edu>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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 +0000, 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