[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89571 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Paolo Carlini --- Fixed.
[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89571 --- Comment #11 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Mar 21 01:03:30 2019 New Revision: 269832 URL: https://gcc.gnu.org/viewcvs?rev=269832=gcc=rev Log: /cp 2019-03-21 Paolo Carlini PR c++/89571 * method.c (after_nsdmi_defaulted_late_checks): Avoid passing error_mark_node to comp_except_specs. /testsuite 2019-03-21 Paolo Carlini PR c++/89571 * g++.dg/cpp0x/noexcept37.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/noexcept37.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c trunk/gcc/testsuite/ChangeLog
[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89571 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comment #10 from Paolo Carlini --- For error-recovery sake, I think that we can just skip the functions with eh_spec == error_mark_node and continue the loop: Index: method.c === --- method.c(revision 269783) +++ method.c(working copy) @@ -2274,6 +2274,9 @@ after_nsdmi_defaulted_late_checks (tree t) continue; tree eh_spec = get_defaulted_eh_spec (fn); + if (eh_spec == error_mark_node) + continue; + if (!comp_except_specs (TYPE_RAISES_EXCEPTIONS (TREE_TYPE (fn)), eh_spec, ce_normal)) DECL_DELETED_FN (fn) = true; What do you think, Jason?
[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89571 --- Comment #9 from Paolo Carlini --- The new ICE in Comment #6 is not fixed by Jason's patch, thus we can't close this one, unless we file a separate bug for that.
[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89571 --- Comment #8 from Arseny Solokha --- Should this PR be closed now?
[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89571 --- Comment #7 from Jason Merrill --- Author: jason Date: Sun Mar 17 20:07:26 2019 New Revision: 269746 URL: https://gcc.gnu.org/viewcvs?rev=269746=gcc=rev Log: PR c++/89571 - ICE with ill-formed noexcept on constructor. Earlier changes to defer instantiating a defaulted noexcept-specifier that depends on yet-unparsed default member initializers broke this testcase, where instantiation fails for another reason. In this case there's no reason to defer and try again later, so let's not. * pt.c (maybe_instantiate_noexcept): Only return false if defaulted. (regenerate_decl_from_template): Use it for noexcept-specs. Added: trunk/gcc/testsuite/g++.dg/cpp0x/noexcept36.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89571
Volker Reichelt changed:
What|Removed |Added
CC||reichelt at gcc dot gnu.org
--- Comment #6 from Volker Reichelt ---
Here's a related testcase that ICEs in a different location
(and also regressed in February):
struct A
{
int i = ;
A() noexcept = default;
};
bug.cc:3:9: error: expected primary-expression at end of input
3 | int i = ;
| ^
bug.cc:5:2: internal compiler error: tree check: expected tree_list, have
error_mark in comp_except_specs, at cp/typeck.c:1048
5 | };
| ^
0x7ebe52 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9859
0x6999e0 tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3432
0x6999e0 comp_except_specs(tree_node const*, tree_node const*, int)
../../gcc/gcc/cp/typeck.c:1048
0x990ad6 after_nsdmi_defaulted_late_checks(tree_node*)
../../gcc/gcc/cp/method.c:2277
0x9bf206 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:23611
0x9c038d cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:23652
0x9c038d cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:17397
0x9c12b4 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:14090
0x9c1aa1 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13385
0x9e4590 cp_parser_declaration
../../gcc/gcc/cp/parser.c:13204
0x9e4d0c cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4698
0x9e4d0c c_parse_file()
../../gcc/gcc/cp/parser.c:41148
0xaeb18b c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1156
Please submit a full bug report, [etc.]
[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89571 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|paolo.carlini at oracle dot com| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #5 from Paolo Carlini --- Mine.
[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89571 --- Comment #4 from Paolo Carlini --- Seriously, I spent quite a bit of time today on this issue and, all in all, barring much more invasive changes, I think that not setting *spec_p to error_mark_node when maybe_instantiate_noexcept returns false in process_subob_fn makes for better error recovery. After all, in quite a few places we don't even check the return value of maybe_instantiate_noexcept... If nobody comes up with a better solution, in a few days I will send a message to the mailing list.
[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89571 --- Comment #3 from Paolo Carlini --- I must also add: if we had decided to fix c++/89488 the way I originally proposed https://gcc.gnu.org/ml/gcc-patches/2019-02/txtzrb81mYdom.txt we would not have to fix this one too ;)
[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89571 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comment #2 from Paolo Carlini --- A few notes - I'm not sure I will actually be able to work on this, maybe somebody like Marek wants to beat me to it. If in build_over_call we unconditionally return error_mark_node when mark_used returns false we avoid the ICE. Then, however, we have duplicate diagnostics, because we already emitted the second error while trying to parse a class member access, but when cp_parser_postfix_expression returns error_mark_node in cp_parser_decltype_expr we don't set id_expression_or_member_access_p and try a full expression too.
[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89571 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-04 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r269032 aka PR88368 fix.
[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89571 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |9.0
