[Bug c++/101027] New: Short-circuit behavior not respected with co_await in while head

[alois1--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101027

            Bug ID: 101027
           Summary: Short-circuit behavior not respected with co_await in
                    while head
           Product: gcc
           Version: 11.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: alo...@gmx-topmail.de
  Target Milestone: ---

Created attachment 50983
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50983&action=edit
Reduced preprocessed code

GCC miscompiles the following C++ program:

$ cat test.cpp
#include <coroutine>

struct task
{
        struct promise_type
        {
                task get_return_object() { return
{std::coroutine_handle<promise_type>::from_promise(*this)}; }
                std::suspend_never initial_suspend() { return {}; }
                std::suspend_never final_suspend() noexcept { return {}; }
                void unhandled_exception() {}
                void return_void() {}
        };

        bool await_ready() { return true; }
        void await_suspend(std::coroutine_handle<>) {}
        bool await_resume() { return true; }

        std::coroutine_handle<promise_type> m_handle;
};

extern "C" void exit(int status);

task should_not_execute()
{
        exit(1);
        co_return;
}

task main_task()
{
        while (false && co_await should_not_execute());
}

int main()
{
        main_task();
}

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d,jit
--enable-offload-targets=nvptx-none,amdgcn-amdhsa, --without-cuda-driver
--enable-host-shared --enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/11 --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-11 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-mutex
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.1 20210510 [revision 23855a176609fe8dda6abaf2b21846b4517966eb]
(SUSE Linux) 

$ g++ -std=c++20 test.cpp; ./a.out; echo $?
1

Expected output would be 0, as the && operator should short-circuit, and
should_not_execute therefore should never be started (in particular, the call
to exit should not be reached).

Interestingly, the unexpected behavior only happens in a while head, in an if
head or assignment to a variable the short-circuit behavior seems to be
respected.

For convenience, I have attached a manually reduced version of the preprocessed
code that I have confirmed to exhibit the same behavior.