------- Additional Comments From steven at gcc dot gnu dot org 2005-01-29
12:34 -------
#1 0x0000000000645c3a in store_bit_field (str_rtx=0x2a9598d7e0, bitsize=29,
bitnum=0,
fieldmode=VOIDmode, value=0x2a9598d6c0) at expmed.c:731
731 gcc_assert (CONSTANT_P (value));
(gdb) l
726 else
727 /* Parse phase is supposed to make VALUE's data type
728 match that of the component reference, which is a type
729 at least as wide as the field; so VALUE should have
730 a mode that corresponds to that type. */
731 gcc_assert (CONSTANT_P (value));
732 }
733
734 /* If this machine's insv insists on a register,
735 get VALUE1 into a register. */
(gdb) p debug_rtx(value)
(reg/v:HI 58 [ j ])
$1 = void
(gdb) bt
#0 fancy_abort (file=0xa73574 "../../mainline/gcc/expmed.c", line=731,
function=0xa73590 "store_bit_field") at diagnostic.c:556
#1 0x0000000000645c3a in store_bit_field (str_rtx=0x2a9598d7e0, bitsize=29,
bitnum=0,
fieldmode=VOIDmode, value=0x2a9598d6c0) at expmed.c:731
#2 0x0000000000645a16 in store_bit_field (str_rtx=0x2a9598d7a0, bitsize=29,
bitnum=0,
fieldmode=VOIDmode, value=0x2a9598d6c0) at expmed.c:667
#3 0x000000000065fc01 in store_field (target=0x2a9598d7a0, bitsize=29,
bitpos=0, mode=VOIDmode,
exp=0x2a95988c30, type=0x2a959888f0, alias_set=0) at expr.c:5270
#4 0x000000000065a23f in expand_assignment (to=0x2a95895870,
from=0x2a95a31000) at expr.c:3876
#5 0x00000000006755e2 in expand_expr_real_1 (exp=0x2a958958c0, target=0x0,
tmode=VOIDmode,
modifier=EXPAND_NORMAL, alt_rtl=0x0) at expr.c:8120
#6 0x0000000000664d4a in expand_expr_real (exp=0x2a958958c0,
target=0x2a95894400, tmode=VOIDmode,
modifier=EXPAND_NORMAL, alt_rtl=0x0) at expr.c:6336
#7 0x00000000008aaff1 in expand_expr (exp=0x2a958958c0, target=0x2a95894400,
mode=VOIDmode,
modifier=EXPAND_NORMAL) at expr.h:482
#8 0x00000000008a3d79 in expand_expr_stmt (exp=0x2a958958c0) at stmt.c:1326
The statement we choque on is "fD.1449.bD.1447 = (<unnamed type>) jD.1450;"
The final_cleanup dumps looks like this:
;; Function foo (foo)
foo (jD.1450)
{
# BLOCK 0
# PRED: ENTRY [100.0%] (fallthru,exec)
# fD.1449_4 = V_MAY_DEF <fD.1449_3>;
fD.1449.bD.1447 = (<unnamed type>) jD.1450;
return;
# SUCC: EXIT [100.0%]
}
(note btw that the virtual operands are still renamed, which is also
a but really... :-/)
The patch that introduced this bug is this one:
http://gcc.gnu.org/ml/gcc-cvs/2005-01/msg01091.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19689
