[Bug middle-end/19689] [4.0 Regression] ICE in store_bit_field, at expmed.c

[steven at gcc dot gnu dot org]

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