public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "alois1@gmx-topmail.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/101976] New: When constructing object, calling function and performing co_await in same statement, temporary is erroneously moved trivially
Date: Thu, 19 Aug 2021 10:43:07 +0000	[thread overview]
Message-ID: <bug-101976-4@http.gcc.gnu.org/bugzilla/> (raw)

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

            Bug ID: 101976
           Summary: When constructing object, calling function and
                    performing co_await in same statement, temporary is
                    erroneously moved trivially
           Product: gcc
           Version: 11.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: alois1@gmx-topmail.de
  Target Milestone: ---

Created attachment 51324
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51324&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<>) {}
        void await_resume() { }

        std::coroutine_handle<promise_type> m_handle;
};

extern "C" int puts(const char *s);

struct nontrivial_move
{
        nontrivial_move() { puts("nontrivial_move()"); }
        nontrivial_move(nontrivial_move &&) {
puts("nontrivial_move(nontrivial_move &&)"); }
        ~nontrivial_move() { puts("~nontrivial_move()"); }
        char buf[128]{};
};

struct wrapper
{
        nontrivial_move member;
};

task subtask(wrapper)
{
        co_return;
}

task main_task()
{
        co_await subtask({});
}

int main()
{
        main_task();
}

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-11.2.1-20210728/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.1 20210728 (Red Hat 11.2.1-1) (GCC) 

$ g++ -std=c++20 test.cpp; ./a.out
nontrivial_move()
nontrivial_move(nontrivial_move &&)
~nontrivial_move()
~nontrivial_move()
~nontrivial_move()

Examination of the generated assembly code shows that the temporary wrapper
object is erroneously copied under the assumption that it has trivial move
constructor (the large buffer in nontrivial_move is just there to make this
fact obvious).

This behavior does not happen if the construction of the wrapper object or the
co_await happens in a separate statement. Furthermore, the behavior does not
happen if the only argument of subtask is changed to have type nontrivial_move
(the move is elided entirely in this case, which is acceptable as far as I can
tell).

A manually reduced version of the preprocessed code is attached, which I have
confirmed to show the same behavior.

I think that the observed incorrect behavior might be a symptom of the same
underlying issue as one or more of the bugs 99576, 100611, 101243, 101367.

             reply	other threads:[~2021-08-19 10:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-19 10:43 alois1@gmx-topmail.de [this message]
2022-08-11 23:05 ` [Bug c++/101976] " dprokoptsev at gmail dot com
2022-12-04 10:41 ` cvs-commit at gcc dot gnu.org
2024-02-05 14:18 ` redi at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-101976-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).