https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79249
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-01-26
Ever confirmed|0 |1
Known to fail| |4.9.4, 5.4.0, 6.3.0, 7.0
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Confirmed. I think what's happening is that the first call to 'attempt' with a
particular set of template arguments generates a lambda function that has an
implicit noexcept specification, because the FnT argument is a noexcept
function.
On the second call to the same specialization of 'attempt' the same lambda
expression is used, with the same closure type, but this time the FnT type is
not noexcept. When the Fnt function throws it hits the implicit noexcept on the
closure's call operator and terminates.
My theory would seem to be confirmed by the fact that the program works as
expected in C++17 mode on trunk, which will be because the types of 'f_ident'
and 'g' are different, and so they use different specializations of the
'attempt' function template, with different lambda expressions.
I think the bug is that the lambda expression creates a closure with a
non-throwing exception specification when it captures 'f_ident'. The fact that
'f_ident' is noexcept is not part of the type system (in C++14) and so should
not affect the lambda expression.
