On Fri, Jul 11, 2025 at 9:59 AM Andi Kleen <a...@linux.intel.com> wrote:
>
> Dimitar Dimitrov <dimi...@dinux.eu> writes:
>
> > A few tests started failing recently on pru-unknown-elf because it uses
> > SJLJ implementation for exceptions:
> > FAIL: g++.dg/ext/musttail3.C -std=c++11 (test for excess errors)
> > .../gcc/gcc/testsuite/g++.dg/ext/musttail3.C:12:34: error: cannot
> > tail-call: caller uses sjlj exceptions
> >
> > Fix by disabling those tests if target uses SJLJ for implementing
> > exceptions.
> >
> > Ensured that test results with and without this patch for
> > x86_64-pc-linux-gnu are the same.
> >
> > Ok for trunk?
>
> I would rather make it XFAIL and also open a PR, after all it is a
> limitation that could (and should) be fixed.
>
> As more and more software uses musttail it will hurt those targets
> eventually.
Actually with SJLJ exceptions there is nothing that can be done here.
```
/* If we are using sjlj exceptions, we may need to add a call to
_Unwind_SjLj_Unregister at exit of the function. Which means
that we cannot do any sibcall transformations. */
if (targetm_common.except_unwind_info (&global_options) == UI_SJLJ
&& current_function_has_exception_handlers ())
{
maybe_error_musttail (call, _("caller uses sjlj exceptions"),
diag_musttail);
return false;
}
```
Well maybe swap the _Unwind_SjLj_Unregister and sibcall function. But
I am not sure it really matters that much for these targets since the
overhead for SJLJ exceptions is huge even if a throw does not happen.
Yes it has a smaller code footprint but the speed cost is not worth
it.
So implementing this movement for sjlj targets is not worth the cost.
Thanks,
Andrew
>
> -Andi
