The attached test case ICEs during parsing with checking enabled: $ g++ t.ii t.ii:52482: internal compiler error: tree check: expected identifier_node, have integer_cst in c_parse_error, at c-common.c:5490
Created attachment 7087 [details] Test case for this bug
// "minimized" testcase :-) class foo { virtual void bar () = __null; };
:-) I think I saw Mark submit a patch maybe a year ago that really required the token "0" to indicate that a function is abstract. I have a hard time understanding why anyone would use anything different anyway, but that may be beyond the point... W.
: Search converges between 2003-12-17-trunk (#430) and 2003-12-18-trunk (#431). Hmm that is the normal date for this ICE :) This only happens with checking turned also.
Anybody has an --enable-checking version of 3.4? I assume the bug is present also there.
Mine.
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01085.html
Giovanni's right: it also ICEs with an --enable-checking'd 3.4: g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c x.cc x.cc:1: internal compiler error: tree check: expected identifier_node, have integer_cst in c_parse_error, at c-common.c:5893 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. Giovanni, you may want to apply your patch there as well. W.
Isn't this just a matter of not filling ridpointers with null_node as done below? Whenever RID_NULL is encountered, we return just null_node anyway, and there are apparently no other places where ridpointers[RID_NULL] is read. I'll test this patch, let's see if this helps. Index: lex.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/cp/lex.c,v retrieving revision 1.343 diff -c -3 -p -r1.343 lex.c *** lex.c 9 Sep 2004 17:11:18 -0000 1.343 --- lex.c 19 Sep 2004 12:20:27 -0000 *************** cxx_init (void) *** 358,364 **** not shared. */ null_node = make_node (INTEGER_CST); TREE_TYPE (null_node) = c_common_type_for_size (POINTER_SIZE, 0); - ridpointers[RID_NULL] = null_node; interface_unknown = 1; --- 358,363 ----
Subject: Re: [3.4/4.0 Regression] ICE with invalid pure specifier steven at gcc dot gnu dot org wrote: > Isn't this just a matter of not filling > ridpointers with null_node as done below? Whenever RID_NULL > is encountered, we return just > null_node anyway, and there are apparently no other places where > ridpointers[RID_NULL] is read. I'll test this patch, let's see if > this helps. Maybe. But cp_parser_error is stil buggy and will ICE on other keywords (e.g. "public"/"protected"/"private") so thinking that is still desirable anyway. I'll get back to this bug later next week when I'm through with the finals. Giovanni Bajo
(In reply to comment #10) > "public"/"protected"/"private") so thinking that is still desirable anyway. ^^^^^^^^ "fixing"
Patch needs update and splitting. The hunks to cp_parser_pure_specifier and to decl.c are safe and can be submitted separately as a way to improve/fix the error message here. The patch to cp_parser_error requires to be rewritten by taking into account how each keywords is identified in source code.
The cp_parser_pure_specifier and decl2.c hunks are OK, and I think will be sufficient to fix the PR. Please apply.
I tested this again and seems fixed on the mainline, is there a reason why it is still marked as 4.0 regression?
Is this fixed or just keeping open for a reason?
Ah, I had forgot about this. Let me retest the approved parts of the patch and apply it.
Subject: Bug 17401 CVSROOT: /cvs/gcc Module name: gcc Changes by: giovannibajo@gcc.gnu.org 2005-02-03 10:26:23 Modified files: gcc/cp : ChangeLog parser.c decl2.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/parse: error25.C Log message: PR c++/17401 * parser.c (cp_parser_pure_specifier): Emit a specific error message with an invalid pure specifier. * decl2.c (grok_function_init): Remove. (grokfield): An initializer for a method is a always a pure specifier. PR c++/17401 * g++.dg/parse/error25.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4614&r2=1.4615 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.310&r2=1.311 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.764&r2=1.765 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4992&r2=1.4993 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/error25.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
I have fixed the diagnostic issue as well. I don't see anything else in this PR which is worth a regression, so I'm closing it.
*** Bug 21252 has been marked as a duplicate of this bug. ***