https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #29 from Dominik Vogt <vogt at linux dot vnet.ibm.com> --- Thanks! > It's necessary to handle all cases correctly. But there is nothing wrong > with using an efficient mechanism when it works, as long as we can correctly > fall back to a more expensive mechanism when it fails. I believe that my > patch does that. I'm fine with that. But couldn't this also happen when copying multiple arguments to the stack? E.g. if you have an array A and call the function with something like defer(foo(A[0], A[1], ... A[N]) gcc could turn that into a loop for a sufficiently large N? This may be also an unlikely case, but a test for this wouldn't hurt either. > If you like, we can incorporate your patch too, as long as it is only an > addition to the existing code. Before calling runtime_callers, we can call > _Unwind_FindEnclosingFunction. Then we need only go on to the > runtime_callers code if _Unwind_FindEnclosingFunction returns NULL, or in the > cases where d->__makefunc_can_recover is true. Given that my patch fails to work with indirect function pointers (Power) that does not seem to be very helpful.
