Ian Lance Taylor wrote:
> Presumably the insn which doesn't match uses call with some mode other
> than SI. What mode does it use? What generated that insn with some
> other mode?
Well, the internal compiler error message which is thrown looks like this:
---snip---
Processing file 20000120-2.c
20000120-2.c: In function 'foo':
20000120-2.c:13: error: unrecognizable insn:
(call_insn 14 13 15 1 (parallel [
(set:SI (reg:SI 1 r1)
(call (mem:QI (symbol_ref:SI ("odd") [flags 0x3]
<function_decl 0x3ae24700 odd>) [0 S1 A8])
(const_int 8 [0x8])))
(clobber (reg:SI 31 r31))
]) -1 (nil)
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(nil))
20000120-2.c:13: internal compiler error: in extract_insn, at recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
---snap---
By the way, this source code file is from the GCC testsuite. (torture tests)
My corresponding rtl template looks now like following one:
---snip---
;;
;; calls that return int in r1
;;
(define_insn "call_val_internal_return_r1"
[(parallel [(set (reg:SI 1)
(call:SI (match_operand:QI 0 "sym_ref_mem_operand" "")
(match_operand:SI 1 "" "i")))
(clobber (reg:SI 31))])]
""
"jal\\t%S0%("
[(set_attr "type" "jump")
(set_attr "mode" "none")])
---snap---
> Actually, most targets don't use a mode with call, since a call can
> often return multiple modes. But then they don't use a mode for the
> result of the call, either. Look at what other targets do.
Till, now I haven't found a similar template where the return value
which is set is a "reg:SI". I will keep on searching :-)
Regards,
Markus Franke
