I think I encounter a memory leak caused by implementation when using await_transform to turn arbitrary type into awaitable. I track the number of (internally) allocated coroutine frames and expect to see zero as the final figure, one remains unfreed however. cmd line: g++.exe gcc_coro_leak.cpp -std=c++20 -O3 -Wall -Wextra -fcoroutines Platforms tested: avr, x86 Compilation output: returned: 0 Execution output: allocating frame, total count: 1 allocating frame, total count: 2 hello coro-world deleting frame, remaining count: 1 Program returned: 0
Created attachment 49839 [details] preprocessed file that triggers the bug
(In reply to Tomáš Hering from comment #1) > Created attachment 49839 [details] > preprocessed file that triggers the bug please could you attach the un-preprocessed source? I cannot reproduce this with the preprocessed source (I don't have a mingw pc setup available).
Created attachment 50276 [details] unprocessed source
(In reply to Tomáš Hering from comment #3) > Created attachment 50276 [details] > unprocessed source thanks! but ... (on x86_64-linux-gnu and x86_64-darwin16): $ gcc-10-2/bin/g++ -std=c++20 -fcoroutines pr98432.C -o t -O3 -Wall -Wextra $ ./t allocated frames 1 allocated frames 2 allocated frames 3 allocated frames: 2 allocated frames: 1 hello coro-world allocated frames: 0 === same on 10.x and master. [ I will try on some older platforms, and on a 32b host too, later ]. So I'm still a bit stuck - given that coroutines is pretty much a Front End code base, it seems odd that there would be some platform dependence here (I guess there could be a an allocation/deallocation bug). Maybe we could try to find some difference in the initial gimple [-fdump-tree-gimple].
Created attachment 50278 [details] unprocessed original source Oops, seems I uploaded a slightly different code. I apologize. It's strange you can't reproduce the issue, though. Please see the demo with the original code on godbolt (https://godbolt.org/z/Gao919) which is in accordance with my local output. Please note that the behavior now seems correct when setting the trunk version of gcc there. Perhaps it has been fixed in some recent commit.
(In reply to Tomáš Hering from comment #5) > Created attachment 50278 [details] > unprocessed original source > > Oops, seems I uploaded a slightly different code. I apologize. It's strange > you can't reproduce the issue, though. Please see the demo with the original > code on godbolt (https://godbolt.org/z/Gao919) which is in accordance with > my local output. Please note that the behavior now seems correct when > setting the trunk version of gcc there. Perhaps it has been fixed in some > recent commit. From my tests, it is fixed on 10.x and master - (In reply to Tomáš Hering from comment #5) > Created attachment 50278 [details] > unprocessed original source > > Oops, seems I uploaded a slightly different code. I apologize. It's strange > you can't reproduce the issue, though. Please see the demo with the original > code on godbolt (https://godbolt.org/z/Gao919) which is in accordance with > my local output. Please note that the behavior now seems correct when > setting the trunk version of gcc there. Perhaps it has been fixed in some > recent commit. So, even with the original code copied from Compiler Explorer, from my tests, this is fixed on 10.x and master, therefore I think we can close it here (unless you want to make a build of the 10.x branch on your platform to double-check).
I'm a bit lost, which github branch corresponds to 10.x that you mention, please?
(In reply to Tomáš Hering from comment #7) > I'm a bit lost, which github branch corresponds to 10.x that you mention, > please? gcc.gnu.org/git/gcc branch : releases/gcc-10 (currently 10.2.1 - which will become 10.3 at the next release)
(In reply to Iain Sandoe from comment #8) > (In reply to Tomáš Hering from comment #7) > > I'm a bit lost, which github branch corresponds to 10.x that you mention, > > please? > > gcc.gnu.org/git/gcc > > branch : releases/gcc-10 > > (currently 10.2.1 - which will become 10.3 at the next release) https://github.com/gcc-mirror/gcc/tree/releases/gcc-10 (if you're using that)
works on all open branches with coroutines support.