On Tue, Apr 16, 2019 at 1:24 AM Richard Biener
<richard.guent...@gmail.com> wrote:
> 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.
Right. Because the "caller" frame no longer exists.
> > > 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)
If you mean a call wrapped in try/catch, that is correct. The
tail-call optimization breaks all exception handlers, so the patch
prevents it if the call can throw and is in an active exception
region.
Jason
