[llvm-bugs] [Bug 45321] New: [coroutines] Bad codegen that causes a coroutine to resume at the wrong suspend-point under -O2 and above

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=45321

            Bug ID: 45321
           Summary: [coroutines] Bad codegen that causes a coroutine to
                    resume at the wrong suspend-point under -O2 and above
           Product: clang
           Version: 10.0
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: lewissbaker at gmail.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

The following godbolt contains a sample that shows correct output under clang
10 with -O1 but incorrect output under -O2 (also observed under -O3).

https://godbolt.org/z/dUn2-p

Note that the issue does not seem to occur under current clang trunk so may
have already been fixed. Reporting here in case a fix needs to be backported to
clang 10 branch. Feel free to close if a backport to clang 10 is not required.


The code generated for the coroutine:

immediate_task task() {
    awaitable a(0);
    awaitable b(1);
    std::printf("Expected 0: %i\n", co_await a);
    std::printf("Expected 1: %i\n", co_await b);
}

When compiled with: -std=c++2a -stdlib=libc++ -O2

Suspends first at `co_await a', writing its coroutine_handle to a global var
which is then used to resume it.
However, when it suspends at `co_await b` and is subsequently resumed it
resumes at the `co_await a` expression instead of the `co_await b` expression.

Note that minor changes to the code can make it generate the correct output.
eg. changing immediate_task::promise_type::final_suspend() to return
suspend_never instead of returning an awaitable that calls .destroy() inside
the await_suspend() method.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200326/04c0bb03/attachment.html>