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?
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.
Richard.
> jeff
>
> ps. I'm a bit surprised it hasn't been reported until now.
