------- 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