On 05/26/14 01:38, Alan Modra wrote:
PR61300 shows a need to differentiate between incoming and outgoing
REG_PARM_STACK_SPACE for the PowerPC64 ELFv2 ABI, due to code like
function.c:assign_parm_is_stack_parm determining that a stack home
is available for incoming args if REG_PARM_STACK_SPACE is non-zero.
Background: The ELFv2 ABI requires a parameter save area only when
stack is actually used to pass parameters, and since varargs are
passed on the stack, unprototyped calls must pass both on the stack
and in registers. OK, easy you say, !prototype_p(fun) means a
parameter save area is needed. However, a prototype might not be in
scope when compiling an old K&R style C function body, but this does
*not* mean a parameter save area has necesasrily been allocated. A
caller may well have a prototype in scope at the point of the call.
Ugh. This reminds me a lot of the braindamage we had to deal with in
the original PA abi's handling of FP values.
In the general case, how can any function ever be sure as to whether or
not its prototype was in scope at a call site? Yea, we can know for
things with restricted scope, but if it's externally visible, I don't
see how we're going to know the calling context with absolute certainty.
What am I missing here?
jeff
