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++/94751] [9/10/11 Regression] ICE on invalid code in maybe_instantiate_noexcept Date: Thu, 25 Mar 2021 20:13:41 +0000 [thread overview] Message-ID: <bug-94751-4-tMSxvtUw9x@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-94751-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94751 --- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>: https://gcc.gnu.org/g:d4e0bdbc036644401f9de49f594b2bb16b287381 commit r11-7835-gd4e0bdbc036644401f9de49f594b2bb16b287381 Author: Marek Polacek <polacek@redhat.com> Date: Fri Mar 5 15:46:50 2021 -0500 c++: ICE on invalid with inheriting constructors [PR94751] This is an ICE on invalid where we crash because since r269032 we keep error_mark_node around instead of using noexcept_false_spec when things go wrong; see the walk_field_subobs hunk. We crash in deduce_inheriting_ctor which calls synthesized_method_walk to deduce the exception-specification, but fails to do so in this case, because the testcase is invalid so get_nsdmi returns error_mark_node for the member 'c', and per r269032 the error_mark_node propagates back to deduce_inheriting_ctor which subsequently calls build_exception_variant whereon we crash. I think we should return early if the deduction fails and I decided to call mark_used to get an error right away instead of hoping that it would get called later. My worry is that we could forget that there was an error and think that we just deduced noexcept(false). And then I noticed that the test still crashes in C++98. Here again we failed to deduce the exception-specification in implicitly_declare_fn, but nothing reported an error between synthesized_method_walk and the assert. Well, not much we can do except calling synthesized_method_walk again, this time in the verbose mode and making sure that we did get an error. gcc/cp/ChangeLog: PR c++/94751 * call.c (build_over_call): Maybe call mark_used in case deduce_inheriting_ctor fails and return error_mark_node. * cp-tree.h (deduce_inheriting_ctor): Adjust declaration. * method.c (deduce_inheriting_ctor): Return bool if the deduction fails. (implicitly_declare_fn): If raises is error_mark_node, call synthesized_method_walk with diag being true. gcc/testsuite/ChangeLog: PR c++/94751 * g++.dg/cpp0x/inh-ctor37.C: New test.
next prev parent reply other threads:[~2021-03-25 20:13 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-24 18:52 [Bug c++/94751] New: [9/10] " sss@li-snyder.org 2020-04-24 22:29 ` [Bug c++/94751] " mpolacek at gcc dot gnu.org 2020-04-24 22:44 ` [Bug c++/94751] [9/10 Regression] " mpolacek at gcc dot gnu.org 2021-01-14 8:39 ` [Bug c++/94751] [9/10/11 " rguenth at gcc dot gnu.org 2021-01-19 15:35 ` dcb314 at hotmail dot com 2021-01-19 20:52 ` mpolacek at gcc dot gnu.org 2021-01-19 20:54 ` mpolacek at gcc dot gnu.org 2021-03-12 0:49 ` mpolacek at gcc dot gnu.org 2021-03-25 20:13 ` cvs-commit at gcc dot gnu.org [this message] 2021-03-25 20:15 ` mpolacek 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-94751-4-tMSxvtUw9x@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: linkBe 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).