Hello,
thanks for reply. I was reading and comparing machine description files
from other backends. Now I am using a template like this:
---snip---
(define_insn "call_value"
[(parallel [(set (match_operand 0 "" "")
(call (mem:QI (match_operand:QI 1 sym_ref_mem_operand"
""))
(match_operand:SI 2 "" "")))
(clobber (reg:SI 31))])]
""
"jal\\t%S0%("
[(set_attr "type" "jump")
(set_attr "mode" "none")])
---snap---
This pattern matches for function calls but unfortunately now I get a
segmentation fault during compilation of the following program:
---snip---
int odd(int i)
{
return i & 0x1;
}
int
foo(int i, int j)
{
int a;
a=odd(i+j);
return a;
}
---snap---
The segmentation fault occurs in the last line of the foo()-function.
Any suggestions?
Regards and thanks for any comments,
Markus
Richard Henderson wrote:
> On Thu, Feb 22, 2007 at 11:10:09AM +0100, Markus Franke wrote:
>
>>;; calls that return int in r1
>>;;
>>(define_insn "call_val_internal_return_r1"
>>[(parallel [(set (reg:SI 1)
>> (call (match_operand:QI 0 "sym_ref_mem_operand" "")
>
>
> Why would you have a specific pattern for (reg:SI 1) as
> the return value? I suggest you look at other ports for
> guidence here. Normal is something like
>
>
> (define_insn "*call_value_1"
> [(set (match_operand 0 "" "")
> (call (mem:QI (match_operand:SI 1 "call_insn_operand" "rsm"))
> (match_operand:SI 2 "" "")))]
> ...)
>
> where both the return value and the call have no mode specified.
>
>
>
> r~
>
--
Nichts ist so praktisch wie eine gute Theorie!
