[Bug libstdc++/108974] std::barrier except completion function which is not manifestly noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974 --- Comment #1 from Andrew Pinski --- Created attachment 54558 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54558&action=edit Full testcase
[Bug libstdc++/108974] std::barrier except completion function which is not manifestly noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-02-28 CC||rodgertq at gcc dot gnu.org
[Bug libstdc++/108974] std::barrier except completion function which is not manifestly noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974 --- Comment #2 from Jonathan Wakely --- "is_nothrow_invocable_v shall be true." Failing to meet that requirement is undefined, so we're not required to reject it as ill-formed.
[Bug libstdc++/108974] std::barrier except completion function which is not manifestly noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #3 from Jiang An --- > is_nothrow_invocable_v shall be true. If implementation divergence is not intendedly permitted, I don't think it makes much sense to introduce UB in this way. I guess we should either turn it into a mandating requirement: > Instantiation of barrier is ill-formed > if is_nothrow_invocable_v is not true. Or relax the preconditions: > If any invocation to the completion function throws an exception, > the behavior is undefined. I've mailed to LWG Chair for this...
[Bug libstdc++/108974] std::barrier except completion function which is not manifestly noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974 --- Comment #4 from Thomas Rodgers --- (In reply to Jiang An from comment #3) > > is_nothrow_invocable_v shall be true. > > If implementation divergence is not intendedly permitted, I don't think it > makes much sense to introduce UB in this way. > > I guess we should either turn it into a mandating requirement: > > Instantiation of barrier is ill-formed > > if is_nothrow_invocable_v is not true. > > Or relax the preconditions: > > If any invocation to the completion function throws an exception, > > the behavior is undefined. > > I've mailed to LWG Chair for this... LWG Chair has already weighed in on this thread. libstdc++ and libc++ have essentially the same implementation of std::barrier (libstdc++'s implementation is derived from libc++'s). So that they behave consistently and MSVC is different is not surprising. I don't have a strong opinion on whether this should be UB ore mandated. Raising an LWG issue seems reasonable.
[Bug libstdc++/108974] std::barrier except completion function which is not manifestly noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974 Thomas Rodgers changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rodgertq at gcc dot gnu.org
[Bug libstdc++/108974] std::barrier except completion function which is not manifestly noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974 --- Comment #5 from Jonathan Wakely --- (In reply to Jiang An from comment #3) > I've mailed to LWG Chair for this... Thanks, the new issue will be opened soon.
