Don't allow sibcalls on nested functions
Mon Apr 28 10:48:00 GMT 2003
Some additional input follows, with comments for questions asked by various
persons. Thanks for the provided feedback, btw :)
Olivier Hainque wrote:
> > When, exactly, are argument areas "shared" between caller and callee?
> From direct recollection, the "sharing" issue was related to expand_call:
> /* The argument block when performing a sibling call is the
> incoming argument block. */
> I'm just rebuilding with the current sources with the patch removed to see
> if it reproduces.
The problem is indeed still visible on sparc-solaris, and the same assembly
output obervations apply.
Back to previous comments:
o Richard Kenner mentioned:
> [...] check whether this can happen in the case of a
> pointer to the nested function, since that would be harder to fix.
I don't see why it could not happen, though only on a very limited number
of targets because indirect sibcalls are rarely supported. They used
to be inconditionally forbidden, and still are in 3.2 and 3.3, which
is why the issue did not show up before. I'm still unclear how to deal
o Dale Johannesen wrote:
> Isn't this what check_sibcall_argument_overlap is supposed to be
My understanding is that check_sibcall_argument_overlap looks for
references inside the _caller_'s code, but the conflicting references
are in the _callee_'s code here.
o Zack Weinberg wrote:
> What about nesting deeper than one level?
I don't see how this could happen, for visibility reaons. Maybe I just
misunderstand what you have in mind. Could you please enlighten ?
Thanks again for all the input. Call expansion is a fairly complex piece of
code, IMHO, so I may well still be missing something here.
More information about the Gcc-patches