This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/23376] ICE on GCC 4.x with -O1 -funroll-loops -fvariable-expansion-in-unroller
- From: "steven at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 14 Aug 2005 12:55:06 -0000
- Subject: [Bug target/23376] ICE on GCC 4.x with -O1 -funroll-loops -fvariable-expansion-in-unroller
- References: <20050813144850.23376.drab@kepler.fjfi.cvut.cz>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From steven at gcc dot gnu dot org 2005-08-14 12:55 -------
This patch is a bit paradoxical: There is an insn that we want to expand in
the unroller, so we know that have_insn_for *should* return true if the MD is
sane. But the MD can't be sane for an insane ISA combination like x87/mmx.
So indeed, the insn that src comes from is valid but the insn does not exist
according to have_insn_for. This happens because have_insn_for checks that
there is an optab for this combination of operation and mode. The patch is
obviously suboptimal (Uros' patch would fix the problem for real, someone
review it please! :-) but probably this kind of precaution is a good idea
anyway...
Index: loop-unroll.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/loop-unroll.c,v
retrieving revision 1.37
diff -u -3 -p -r1.37 loop-unroll.c
--- loop-unroll.c 3 Aug 2005 13:34:35 -0000 1.37
+++ loop-unroll.c 14 Aug 2005 12:51:16 -0000
@@ -1574,6 +1574,9 @@ analyze_insn_to_expand_var (struct loop
&& GET_CODE (src) != MINUS
&& GET_CODE (src) != MULT)
return NULL;
+
+ if (!have_insn_for (GET_CODE (src), GET_MODE (src)))
+ return NULL;
if (!XEXP (src, 0))
return NULL;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23376