Back then, I must've missed that INCOMING_REGNO / OUTGOING_REGNO are
used to map return-value-register/s too. Fixes:
FAIL: gcc.dg/builtin-apply4.c execution test
...
FAIL: gcc.dg/builtin-return-1.c execution test
...
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O0 execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O1 execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O3 -fomit-frame-pointer
execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O3 -g execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -Os execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none execution tes\
t
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O0 execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O1 execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O3 -fomit-frame-pointer
execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O3 -g execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -Os execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none execution te\
st
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects execution test
Committed.
* config/mmix/mmix.c (mmix_opposite_regno): Handle the
return-value register too.
--- gcc/config/mmix/mmix.c.prev 2012-10-09 02:00:51.000000000 +0200
+++ gcc/config/mmix/mmix.c 2012-10-14 00:59:54.000000000 +0200
@@ -392,15 +392,33 @@ mmix_conditional_register_usage (void)
/* INCOMING_REGNO and OUTGOING_REGNO worker function.
Those two macros must only be applied to function argument
- registers. FIXME: for their current use in gcc, it'd be better
- with an explicit specific additional FUNCTION_INCOMING_ARG_REGNO_P
- a'la TARGET_FUNCTION_ARG / TARGET_FUNCTION_INCOMING_ARG instead of
+ registers and the function return value register for the opposite
+ use. FIXME: for their current use in gcc, it'd be better with an
+ explicit specific additional FUNCTION_INCOMING_ARG_REGNO_P a'la
+ TARGET_FUNCTION_ARG / TARGET_FUNCTION_INCOMING_ARG instead of
forcing the target to commit to a fixed mapping and for any
- unspecified register use. */
+ unspecified register use. Particularly when thinking about the
+ return-value, it is better to imagine INCOMING_REGNO and
+ OUTGOING_REGNO as named CALLEE_TO_CALLER_REGNO and INNER_REGNO as
+ named CALLER_TO_CALLEE_REGNO because the direction. The "incoming"
+ and "outgoing" is from the perspective of the parameter-registers,
+ but the same macro is (must be, lacking an alternative like
+ suggested above) used to map the return-value-register from the
+ same perspective. To make directions even more confusing, the macro
+ MMIX_OUTGOING_RETURN_VALUE_REGNUM holds the number of the register
+ in which to return a value, i.e. INCOMING_REGNO for the return-value-
+ register as received from a called function; the return-value on the
+ way out. */
int
mmix_opposite_regno (int regno, int incoming)
{
+ if (incoming && regno == MMIX_OUTGOING_RETURN_VALUE_REGNUM)
+ return MMIX_RETURN_VALUE_REGNUM;
+
+ if (!incoming && regno == MMIX_RETURN_VALUE_REGNUM)
+ return MMIX_OUTGOING_RETURN_VALUE_REGNUM;
+
if (!mmix_function_arg_regno_p (regno, incoming))
return regno;
brgds, H-P
