[Bug target/32335] libgcc build failure, ICE in cselib_record_set, at cselib.c:1508

["zadeck at naturalbridge dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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