[Bug c++/114970] New: 32-bit ARM gcc-14.1 new false positive -Wunused-value

Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nilsgladitz at gmail dot com Target Milestone: --- Created attachment 58114 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58114=edit Testcase The attached reduced test case produces the following warn

[Bug c++/114945] New: Sporadic std::vector::resize() -Wstringop-overflow or -Warray-bounds warning with gcc 14

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nilsgladitz at gmail dot com Target Milestone: --- Created attachment 58103 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58103=edit Testcase Initia

[Bug c++/101118] coroutines: unexpected ODR warning for coroutine frame type in LTO builds

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118 --- Comment #3 from Nils Gladitz --- Thanks for looking into this! Any idea what the potential implications are? I assume I can't just ignore the warning as this will likely break code? When I turn off LTO the diagnostic will go away but the

[Bug c++/101118] New: coroutines: unexpected ODR warning for coroutine frame type in LTO builds

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nilsgladitz at gmail dot com Target Milestone: --- Created attachment 51033 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51033=edit Testcase source fi

[Bug c++/100611] coroutines: destructor called too many times for coroutine lambda stored object

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100611 --- Comment #1 from Nils Gladitz --- (In reply to Nils Gladitz from comment #0) > Indicating that "Foo" is constructed more often than it gets destructed. Sorry that of course was supposed to read: Indicating that "Foo" is destructed more

[Bug c++/99576] [coroutines] destructor of a temporary called too early within co_await expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576 --- Comment #2 from Nils Gladitz --- I opened bug 100611 for what I described above; assuming this is related but distinct.

[Bug c++/100611] New: coroutines: destructor called too many times for coroutine lambda stored object

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nilsgladitz at gmail dot com Target Milestone: --- Created attachment 50816 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50816=edit test case Gi

[Bug c++/99576] [coroutines] destructor of a temporary called too early within co_await expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576 Nils Gladitz changed: What|Removed |Added CC||nilsgladitz at gmail dot com --- Comment

[Bug libstdc++/99846] [11 regression] std::variant comparison operator error for recursive type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99846 --- Comment #8 from Nils Gladitz --- (In reply to Jonathan Wakely from comment #5) > Now this is *obviously* wrong. The left < right expression uses the > operator< defined for the std::list base class, which depends on > comparing the list's

[Bug libstdc++/99846] New: [11 regression] std::variant comparison operator error for recursive type

: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: nilsgladitz at gmail dot com Target Milestone: --- Created attachment 50491 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50491=edit Test case source c

[Bug c++/99710] New: coroutines: co_yield and co_await should only be allowed in suspension context

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nilsgladitz at gmail dot com Target Milestone: --- I quite enjoyed seemingly being able to co_await in exception catch handlers but as I am being told by another compiler

[Bug c++/99215] coroutines: debugging with gdb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215 --- Comment #7 from Nils Gladitz --- (In reply to Nils Gladitz from comment #5) > Apparently when the coroutine happens to be a member function (even a static > one) printing *frame_ptr results in "{}". I reported the "{}" issue at the gdb

[Bug c++/98056] ICE tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.c:9862 since r11-2183-g0f66b8486cea8668

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056 --- Comment #4 from Nils Gladitz --- Not sure if this is helpful at all but I think I ran into the same issue and reduced it to the following which is slightly shorter but also keeps the standard C++ includes intact (manually reintroduced them

[Bug c++/99215] coroutines: debugging with gdb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215 --- Comment #5 from Nils Gladitz --- Apparently when the coroutine happens to be a member function (even a static one) printing *frame_ptr results in "{}". Ideally I'd want to have non-static member coroutines and would like to be able to

[Bug c++/99215] coroutines: debugging with gdb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215 --- Comment #4 from Nils Gladitz --- (In reply to Iain Sandoe from comment #3) > ... the essence of the idea [on the mentioned long TODO] is to change the > way in which frame vars are referenced; instead of changing the uses to > point to the

[Bug c++/99215] coroutines: debugging with gdb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215 --- Comment #2 from Nils Gladitz --- (In reply to Iain Sandoe from comment #1) > Can you identify specific key blockers to progress? > (I think the paper cited contained a number of desiderata, but it would be > good to start from the most

[Bug c++/99215] New: coroutines: debugging with gdb

++ Assignee: unassigned at gcc dot gnu.org Reporter: nilsgladitz at gmail dot com Target Milestone: --- I am itching to get into C++20 coroutines (and very grateful for their implementation) but am somewhat put off by the apparent inability to inspect them from within a debugger currently

[Bug libstdc++/86164] std::regex crashes when matching long lines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164 Nils Gladitz changed: What|Removed |Added CC||nilsgladitz at gmail dot com --- Comment