http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |rakdver at gcc dot gnu.org
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-02
08:24:34 UTC ---
I wonder if that isn't unnecessarily pessimizing, plus it won't catch all cases
anyway, steps can be added etc. afterwards, in the extend_mode/comp_mode.
The following fixes the ICE for me too, the second hunk is supposedly not
enough, because in some places afterwards we e.g. count inc from iv0.step and
iv1.step directly, plus for say comp_mode SImode and mode QImode with iv0.step
256 we supposedly want to bail out early (infinite loop or zero iterations).
--- gcc/loop-iv.c.jj 2012-10-22 08:42:25.000000000 +0200
+++ gcc/loop-iv.c 2013-01-02 09:17:42.215591646 +0100
@@ -2406,6 +2406,9 @@ iv_number_of_iterations (struct loop *lo
iv1.step = const0_rtx;
}
+ iv0.step = lowpart_subreg (mode, iv0.step, comp_mode);
+ iv1.step = lowpart_subreg (mode, iv1.step, comp_mode);
+
/* This is either infinite loop or the one that ends immediately, depending
on initial values. Unswitching should remove this kind of conditions.
*/
if (iv0.step == const0_rtx && iv1.step == const0_rtx)
@@ -2516,6 +2519,7 @@ iv_number_of_iterations (struct loop *lo
step = simplify_gen_unary (NEG, comp_mode, iv1.step, comp_mode);
else
step = iv0.step;
+ step = lowpart_subreg (mode, step, comp_mode);
delta = simplify_gen_binary (MINUS, comp_mode, iv1.base, iv0.base);
delta = lowpart_subreg (mode, delta, comp_mode);
delta = simplify_gen_binary (UMOD, mode, delta, step);
