This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: m68k bootstrapping broken
Andreas Schwab wrote:
printf.c:2451: error: insn does not satisfy its constraints:
(insn 1379 542 543 38 (nil) (set (reg:QI 8 %a0)
(mem:QI (plus:SI (reg/f:SI 14 %a6)
(const_int -209 [0xffffff2f])) [0 mode S1 A8])) 37 {*m68k.md:1060} (nil)
(nil))
This tries to move a QImode from memory to an address register. m68k.md
has this pattern for movqi:
(define_expand "movqi"
[(set (match_operand:QI 0 "nonimmediate_operand" "")
(match_operand:QI 1 "general_src_operand" ""))]
""
"")
(define_insn ""
[(set (match_operand:QI 0 "nonimmediate_operand" "=d,*a,m")
(match_operand:QI 1 "general_src_operand" "dmSi*a,di*a,dmSi"))]
"!TARGET_COLDFIRE"
"* return output_move_qimode (operands);")
You meant to quote the TARGET_COLDFIRE version? The ICE happens
with -m5200.
And indeed this combination of operands is not allowed by the constraints.
Shouldn't the define_expand reject this in the first place, or is there
some other mechanism to tell the reload pass not to generate such an insn?
Sorry, I think I don't fully understand how the code generation pass
works. In gccint, I read:
Every RTL insn emitted by a `define_expand' must match some
`define_insn' in the machine description. Otherwise, the compiler will
crash when trying to generate code for the insn or trying to optimize
it.
So it means that once you've defined the "movqi" pattern, you must
provide enough insns to satisfy all possible combinations of operands.
Could we fix it by adding a new insn for TARGET_COLDFIRE with relaxed
constraints, implemented using a longer/slower sequence of m68k
instructions?
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/