------- Comment #2 from ubizjak at gmail dot com 2007-03-14 13:13 ------- The problem is with TImode *addti3_1 splitter. An immediate is splitted from TImode into double DImode values and these values are passed to add/addc pair:
(define_split [(set (match_operand:TI 0 "nonimmediate_operand" "") (plus:TI (match_operand:TI 1 "nonimmediate_operand" "") (match_operand:TI 2 "general_operand" ""))) (clobber (reg:CC FLAGS_REG))] "TARGET_64BIT && reload_completed" [(parallel [(set (reg:CC FLAGS_REG) (unspec:CC [(match_dup 1) (match_dup 2)] UNSPEC_ADD_CARRY)) (set (match_dup 0) (plus:DI (match_dup 1) (match_dup 2)))]) (parallel [(set (match_dup 3) (plus:DI (plus:DI (ltu:DI (reg:CC FLAGS_REG) (const_int 0)) (match_dup 4)) (match_dup 5))) (clobber (reg:CC FLAGS_REG))])] "split_ti (operands+0, 1, operands+0, operands+3); split_ti (operands+1, 1, operands+1, operands+4); split_ti (operands+2, 1, operands+2, operands+5);") Here lies the problem. when TImode immediate operands[2] is split into DImode, it doesn't satisfy x86_64_general_operand/x86_64_immediate_operand predicate in splitted patterns that expects either 0xffffffffxxxxxxxx or 0x00000000xxxxxxxx. -- ubizjak at gmail dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31167