On Mon, Apr 15, 2019 at 7:09 PM Andrew Pinski <pins...@gmail.com> wrote:
>
> 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.
Hmm, OK, so essentially a tail-call cannot be represented in the CFI
program.
> >
> > 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.
With dg-additional-sources and registering a custom std::terminate
it should work I guess (or by catching SIGABRT).
The patch and the bug also suggests that an internally
throwing function cannot be tail-called either (can't find a testcase
we'd mark as tail-call here)
Richard.
> Thanks,
> Andrew Pinski
>
> >
> > Richard.
> >
> > > jeff
> > >
> > > ps. I'm a bit surprised it hasn't been reported until now.
