[Bug c++/95505] [coroutines] ICE assert with get_return_object_on_allocation_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505 --- Comment #7 from Iain Sandoe --- (In reply to Michael Bruck from comment #6) > Is it possible to point the user to include here like other parts of > gcc do for standard library functions? > i.e. name-lookup.c missing_std_header That's also a possibility (we do that for a missing include already).
[Bug c++/95505] [coroutines] ICE assert with get_return_object_on_allocation_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505 --- Comment #6 from Michael Bruck --- Is it possible to point the user to include here like other parts of gcc do for standard library functions? i.e. name-lookup.c missing_std_header
[Bug c++/95505] [coroutines] ICE assert with get_return_object_on_allocation_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Iain Sandoe --- fixed for master and 10.2.
[Bug c++/95505] [coroutines] ICE assert with get_return_object_on_allocation_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:a59a15bcd27fa626b2b0912a1d7abd6df4f3d6cf commit r10-8334-ga59a15bcd27fa626b2b0912a1d7abd6df4f3d6cf Author: Iain Sandoe Date: Sun Jun 21 19:11:23 2020 +0100 coroutines: Update handling and failure for g-r-o-o-a-f [PR95505] The actual issue is that (in the testcase) std::nothrow is not available. So update the handling of the get-return-on-alloc-fail to include the possibility that std::nothrow might not be available. gcc/cp/ChangeLog: PR c++/95505 * coroutines.cc (morph_fn_to_coro): Update handling of get-return-object-on-allocation-fail and diagnose missing std::nothrow. gcc/testsuite/ChangeLog: PR c++/95505 * g++.dg/coroutines/pr95505.C: New test. (cherry picked from commit 445d8da5fbd10e32f8ea470bd9ac02faba8fd718)
[Bug c++/95505] [coroutines] ICE assert with get_return_object_on_allocation_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505 --- Comment #3 from Iain Sandoe --- we're also discussing whether there's a good way to make this available automatically. clang's current implementation includes unconditionally, which is a possible solution - I'm not thrilled about blanket inclusion of other library headers (especially when they are not actually directly used by the including one). It's a somewhat odd situation - neither nor (quite likely) the user's code necessarily overly needs "" .. it's an indirect requirement. So another possibility is to make the std::no throw_t type available and just construct a temporary object of that type when doing the lookup. So the ICE is fixed by diagnosing the issue, and making things 'easier' is on the TODO (but not part of this PR).
[Bug c++/95505] [coroutines] ICE assert with get_return_object_on_allocation_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:445d8da5fbd10e32f8ea470bd9ac02faba8fd718 commit r11-1572-g445d8da5fbd10e32f8ea470bd9ac02faba8fd718 Author: Iain Sandoe Date: Sat Jun 20 14:01:21 2020 +0100 coroutines: Update handling and failure for g-r-o-o-a-f [PR95505] The actual issue is that (in the testcase) std::nothrow is not available. So update the handling of the get-return-on-alloc-fail to include the possibility that std::nothrow might not be available. gcc/cp/ChangeLog: PR c++/95505 * coroutines.cc (morph_fn_to_coro): Update handling of get-return-object-on-allocation-fail and diagnose missing std::nothrow. gcc/testsuite/ChangeLog: PR c++/95505 * g++.dg/coroutines/pr95505.C: New test.
[Bug c++/95505] [coroutines] ICE assert with get_return_object_on_allocation_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505 Iain Sandoe changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |10.2 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-06-04 --- Comment #1 from Iain Sandoe --- thanks for the report.
