public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/94817] ICE in add_stmt, at cp/semantics.c:392 since r10-6063-g49789fd08378e3ff
Date: Sat, 06 Jun 2020 16:51:11 +0000	[thread overview]
Message-ID: <bug-94817-4-Mje4BzNICT@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-94817-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

https://gcc.gnu.org/g:03da87235697eab344cde609d81d3f405f450c42

commit r10-8259-g03da87235697eab344cde609d81d3f405f450c42
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Sat Jun 6 09:48:31 2020 +0100

    coroutines: Improve error recovery [PR94817, PR94829, PR95087].

    When we have completely missing key information (e.g. the
    coroutine_traits) or a partially transformed function body, we
    need to try and balance returning useful information about
    failures with the possibility that some part of the diagnostics
    machinery or following code will not be able to handle the
    state.

    The PRs (and revised testcase) point to cases where that processing
    has failed.

    This revises the process to avoid special handling for the
    ramp, and falls back on the same code used for regular function
    fails.

    There are test-cases (in addition to the ones for the PRs) that now
    cover all early exit points [where the transforms are considered
    to have failed in a manner that does not allow compilation to
    continue].

    Diagnosing bad uses of 'return' in coroutines is somewhat
    tricky, since the user can use the keyword before we know
    that the function is a coroutine (where such returns are not
    permitted).  At present, we are just doing a check for any
    use of 'return' and erroring on that.  However, we can't then
    pass the function body on, since it will contain unlowered
    coroutine trees.

    This avoids the issue by dropping the entire function body
    under that circumstance.

            Backport c7100843831147a034fe37d231c54ac53ceace45 and
a1bb808504643e6c3c0df0fdd68a941ed2a64c7f0

    gcc/cp/ChangeLog:

            PR c++/94817
            PR c++/94829
            PR c++/95087
            * coroutines.cc (morph_fn_to_coro): Set unformed outline
            functions to error_mark_node.  For early error returns suppress
            warnings about missing ramp return values.  Fix reinstatement
            of the function body on pre-existing initial error.  If we see
            an early fatal error, drop the erroneous function body.
            * decl.c (finish_function): Use the normal error path for fails
            in the ramp function, do not try to compile the helpers if the
            transform fails.

    gcc/testsuite/ChangeLog:

            PR c++/94817
            PR c++/94829
            PR c++/95087
            * g++.dg/coroutines/coro-missing-final-suspend.C: New test.
            * g++.dg/coroutines/coro-missing-initial-suspend.C: New test.
            * g++.dg/coroutines/coro-missing-promise-yield.C: Check for
            continuation of compilation.
            * g++.dg/coroutines/coro-missing-promise.C: Likewise.
            * g++.dg/coroutines/coro-missing-ret-value.C: Likewise
            * g++.dg/coroutines/coro-missing-ret-void.C: Likewise
            * g++.dg/coroutines/coro-missing-ueh-3.C: Likewise
            * g++.dg/coroutines/pr94817.C: New test.
            * g++.dg/coroutines/pr94829.C: New test.
            * g++.dg/coroutines/co-return-syntax-08-bad-return.C:
            Adjust the testcase to do the compile (rather than an
            -fsyntax-only parse).
            * g++.dg/coroutines/coro1-ret-int-yield-int.h
            (MISSING_INITIAL_SUSPEND, MISSING_FINAL_SUSPEND): New.

  parent reply	other threads:[~2020-06-06 16:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28 12:35 [Bug c++/94817] New: ICE in add_stmt, at cp/semantics.c:392 asolokha at gmx dot com
2020-04-28 14:16 ` [Bug c++/94817] ICE in add_stmt, at cp/semantics.c:392 since r10-6063-g49789fd08378e3ff marxin at gcc dot gnu.org
2020-04-29 10:56 ` iains at gcc dot gnu.org
2020-05-07 11:56 ` jakub at gcc dot gnu.org
2020-05-07 20:07 ` cvs-commit at gcc dot gnu.org
2020-06-06 16:51 ` cvs-commit at gcc dot gnu.org [this message]
2020-06-06 18:41 ` iains 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-94817-4-Mje4BzNICT@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).