------- Comment #4 from zadeck at naturalbridge dot com 2007-06-17 01:23
-------
Subject: Re: libgcc build failure, ICE in cselib_record_set,
at cselib.c:1508
zadeck at naturalbridge dot com wrote:
the new dse code is failing during a call to cselib. However I do not
believe that the new dse is to blame. Here is the issue.
Dse is failing at
#0 fancy_abort (file=0xc3cf76 "../../gcc32335/gcc/cselib.c", line=1508,
function=0xc3d9f0 "cselib_record_set")
at ../../gcc32335/gcc/diagnostic.c:656
#1 0x000000000056e59e in cselib_record_set (dest=0x2b5212d6a4e0,
src_elt=0x1075ca0, dest_addr_elt=0x0) at
../../gcc32335/gcc/cselib.c:1508
which is the only assert in cselib_record_set.
The insn that it is chocking on is a parallel
(jump_insn 268 267 269 6
/n/07/mstein/svn/trunk/libgcc/../gcc/libgcc2.c:566 (parallel [
(set (reg:PSI 8 sp)
(reg:PSI 7 fb))
(set (reg:PSI 7 fb)
(mem:PSI (reg:PSI 8 sp) [0 S4 A8]))
(set (reg:PSI 8 sp)
(plus:PSI (reg:PSI 8 sp)
(const_int 2 [0x2])))
(return)
]) -1 (nil))
$2 = void
i assume that the thing that cselib does not like is the fact that sp is
being set twice in the same insn. I guess on thinking about it, I
really do not like this insn either.
I checked to make sure that this was not auto-inc code on drugs. the
same failure happens with -fno-auto-inc-dec.
I think that dse is hitting this bug, not because the dataflow merge is
doing something stupid but because this port is (and most likely has
been for a long time) doing something stupid and the new dse code is
asking cselib to go where no cselib has gone before.
Comments?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32335
