On Mon, May 13, 2019 at 04:29:21PM -0600, Jeff Law wrote: > > That is a serious misunderstanding of what __builtin_eh_return does. > > For the most part, __builtin_eh_return works by forcing all call clobbered > > registers to stack, having that described in the unwind info and having the > > unwinding code modify that saved info when needed. The adjustment of the > > stack is done only on approx. half of the targets where the destination > > stack pointer should be derived from CFA instead of being restored with the > > rest of the call saved registers. You can't do this in assembly, it needs > > to be done in the same function that saves the state etc. > So why not just reject tail calls when we see __builtin_eh_return. It's > not ideal, but that feels better than the currently posted hack.
The problem as has been said in this thread is that crtl->calls_eh_return flag is only set during expansion, so if it is tested when deciding if we should allow the tail call or not, it might be (and in the case of _Unwind_Resume_or_Rethrow it is) too late, because we first expand the call that could be tail call and only afterwards expand the __builtin_eh_return and set crtl->calls_eh_return. In https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00484.html I've posted a patch that would set it earlier (or it could be set during gimplification and propagated during inlining, would need to be in cfun->calls_eh_return instead of crtl->calls_eh_return) and then targets for which we do not want to bother with it or where it is not beneficial to have tail calls in functions that call __builtin_eh_return (as I said in the thread, e.g. on x86_64-linux it is both smaller and faster), the targets which we expect to fail currently or even have a proof of that can just punt. Jakub
