------- Comment #18 from jakub at gcc dot gnu dot org 2010-07-22 14:58 -------
Sounds like a cprop_hardreg bug. Before that pass we have (after a call_insn):
(insn 264 263 266 2
/vol/gcc/src/hg/trunk/local/libjava/classpath/gnu/javax/print/ipp/attribute/defaults/FinishingsDefault.java:123
(set (reg/f:DI 1 %g1 [332])
(reg:DI 8 %o0)) 60 {*movdi_insn_sp64} (expr_list:REG_NOALIAS (reg/f:DI
1 %g1 [332])
(nil)))
(debug_insn 266 264 267 2
/vol/gcc/src/hg/trunk/local/libjava/classpath/gnu/javax/print/ipp/attribute/defaults/FinishingsDefault.java:123
(var_location:DI this (reg/f:DI 1 %g1 [332])) -1 (nil))
...
(insn 1290 273 274 2
/vol/gcc/src/hg/trunk/local/libjava/classpath/gnu/javax/print/ipp/attribute/defaults/FinishingsDefault.java:199
(set (mem/c:DI (plus:DI (reg/f:DI 30 %fp)
(const_int 2023 [0x7e7])) [53 S8 A64])
(reg:DI 1 %g1)) 60 {*movdi_insn_sp64} (expr_list:REG_DEAD (reg:DI 1
%g1)
(nil)))
but in *.cprop_hardreg:
(insn 264 263 266 2
/vol/gcc/src/hg/trunk/local/libjava/classpath/gnu/javax/print/ipp/attribute/defaults/FinishingsDefault.java:123
(set (reg/f:DI 1 %g1 [332])
(reg:DI 8 %o0)) 60 {*movdi_insn_sp64} (expr_list:REG_NOALIAS (reg/f:DI
1 %g1 [332])
(nil)))
(debug_insn 266 264 267 2
/vol/gcc/src/hg/trunk/local/libjava/classpath/gnu/javax/print/ipp/attribute/defaults/FinishingsDefault.java:123
(var_location:DI this (reg/f:DI 1 %g1 [332])) -1 (nil))
...
(insn 1290 273 274 2
/vol/gcc/src/hg/trunk/local/libjava/classpath/gnu/javax/print/ipp/attribute/defaults/FinishingsDefault.java:199
(set (mem/c:DI (plus:DI (reg/f:DI 30 %fp)
(const_int 2023 [0x7e7])) [53 S8 A64])
(reg:DI 8 %o0 [1])) 60 {*movdi_insn_sp64} (expr_list:REG_DEAD (reg:DI 1
%g1)
(nil)))
The %g1 use in 1290 was the only use of %g1 in real insns, but cprop_hardreg
failed to replace the %g1 uses in debug_insn for some reason. Then in *.dce
the insn 264 is removed as dead, but nothing resets the debug_insns.
Rainer, do you think you could run make check in gcc/ subdir (assuming libjava
was the last unbuilt library and say libstdc++/libgfortran/libgomp are already
built) to see if this can be reproduced even on some C or C++ testcase?
Debugging Java failures with cross isn't fun.
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aoliva at gcc dot gnu dot
| |org
Last reconfirmed|0000-00-00 00:00:00 |2010-07-22 14:58:37
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
