On Sun, Apr 14, 2019 at 11:50 PM Richard Biener
<richard.guent...@gmail.com> wrote:
>
> On Sat, Apr 13, 2019 at 12:34 AM Jeff Law <l...@redhat.com> wrote:
> >
> > On 4/12/19 3:24 PM, Jason Merrill wrote:
> > > If a noexcept function calls a function that might throw, doing the tail
> > > call optimization means that an exception thrown in the called function
> > > will propagate out, breaking the noexcept specification. So we need to
> > > prevent the optimization in that case.
> > >
> > > Tested x86_64-pc-linux-gnu. OK for trunk or hold for GCC 10? This isn't
> > > a
> > > regression, but it is a straightforward fix for a wrong-code bug.
> > >
> > > * tree-tailcall.c (find_tail_calls): Don't turn a call from a
> > > nothrow function to a might-throw function into a tail call.
> > I'd go on the trunk. It's a wrong-code issue, what we're doing is just
> > plain wrong. One could even make a case for backporting to the branches.
>
> Hmm, how's this different from adding another indirection? That is,
> I don't understand why the tailcall is the issue here, shouldn't unwind
> still stop at the noexcept caller? Thus, isn't this wrong CFI instead?
noexcept caller is no longer on the stack so the unwinder does not see it.
It is not the tail call from a normal function to a noexcept that is
an issue but rather inside a noexcept caller to a normal function.
>
> Of course I know to little about this.
>
> Btw, doesn't your check also prevent tail/sibling calls when
> the caller wraps it into a try { } catch (...) {}? Or does unwind
> not work in that case either?
>
> Btw, I'd like to see a runtime testcase that fails.
There is one in the bug report. Though it would not work for the
testsuite. It should not be hard to change it to be one that works
for the testsuite.
Thanks,
Andrew Pinski
>
> Richard.
>
> > jeff
> >
> > ps. I'm a bit surprised it hasn't been reported until now.
