The following invalid testcase causes an ICE on mainline: ================================= namespace N {} template<typename> struct A { A<typename N::X<int> > a; }; ================================= bug.cc:5: error: 'X' in namespace 'N' does not name a type bug.cc:5: internal compiler error: in make_typename_type, at cp/decl.c:2685 Please submit a full bug report, [etc.] Mark, the ICE was introduced by your patch for PR18738: http://gcc.gnu.org/ml/gcc-cvs/2004-12/msg00592.html Before we got a regression w.r.t. the error message. Right before the ICE we had: bug.cc:5: error: no class template named `X' in `N' bug.cc:5: error: no class template named `X' in `N' bug.cc:5: error: missing `>' to terminate the template argument list bug.cc:5: error: template argument 1 is invalid bug.cc:5: error: no class template named `X' in `N' bug.cc:5: error: no class template named `X' in `N' bug.cc:5: error: missing `>' to terminate the template argument list bug.cc:5: error: template argument 1 is invalid bug.cc:5: error: no class template named `X' in `N' bug.cc:5: error: no class template named `X' in `N' bug.cc:5: error: missing `>' to terminate the template argument list bug.cc:5: error: template argument 1 is invalid bug.cc:5: error: no class template named `X' in `N' bug.cc:5: error: no class template named `X' in `N' bug.cc:5: error: missing `>' to terminate the template argument list bug.cc:5: error: template argument 1 is invalid bug.cc:5: error: `A< <template-parameter-1-1> >' is not a template bug.cc:5: error: no class template named `X' in `N' bug.cc:5: error: no class template named `X' in `N' bug.cc:5: error: expected `(' before '<' token bug.cc:5: error: expected primary-expression before "int" bug.cc:5: error: expected `>' before "int" bug.cc:5: error: missing `>' to terminate the template argument list bug.cc:5: error: expected unqualified-id before '>' token (This is probably a new record, 10 times the same message!) Alexandre, this was introduced by your patch for PR18757: http://gcc.gnu.org/ml/gcc-cvs/2004-12/msg00382.html Before we only had the following error message: bug.cc:5: error: 'X' in namespace 'N' does not name a type bug.cc:5: error: no class template named 'X' in 'N' bug.cc:5: error: missing '>' to terminate the template argument list bug.cc:5: error: template argument 1 is invalid bug.cc:5: error: expected unqualified-id before '>' token which is much better. While the ICE is only present on mainline (because the patch for PR18738 has not been backported yet) the error message regression also affects the 3.4 branch.
Confirmed.
The following example is even worse: ================================= namespace N { struct X; } template<typename> struct A { A<typename N::X x> a; }; ================================= Mainline crashes without emitting an error message first. gcc 3.4.3 and 3.4.4-pre issue the same error messages as above. This is bogus, since N::X is not a template (neither in line 1 nor in line 5). Well, they even error out on the valid code snippet ================================= namespace N { struct X; } template<typename> struct A {}; template<typename> struct B { A<typename N::X> a; }; ================================= Mainline accepts the code thanks to Mark's patch for PR18738. IMHO the right thing to do is to fix the ICE on mainline and backport the fix for PR18738 and the fix for the ICE to the 3.4 branch.
Subject: Bug 19253 CVSROOT: /cvs/gcc Module name: gcc Changes by: mmitchel@gcc.gnu.org 2005-01-29 02:07:19 Modified files: gcc/cp : ChangeLog parser.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: crash33.C Log message: PR c++/19253 * parser.c (cp_parser_diagnose_invalid_type_name): Commit to tentative parses. PR c++/19253 * g++.dg/template/crash33.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4600&r2=1.4601 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.303&r2=1.304 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4952&r2=1.4953 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/crash33.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
Fixed in GCC 4.0.
Mark, the first code snippet in comment #3 still crashes on mainline. So this is not yet fixed on mainline.
Sorry, I meant comment #2, of course.
Volker, you seem to be on a quest to make gcc accept without crashing even the most obnoxious wrong code snippets without ICEing. How do you generate all these snippets? (As a sidenote, even if they are technically regressions, I don't consider such artificial codes really important to fix. There are more important things, and we get this right for gcc 4.6.2, that'll be ok with me as well :-) W.
> Volker, you seem to be on a quest to make gcc accept without crashing even > the most obnoxious wrong code snippets without ICEing. I wouldn't say that they're "obnoxious" ;-) These code snippets are usually only one bug away from valid code. > How do you generate all these snippets? By sheer determination. I pick some topic like pointers-to-members or destructors for example and try to find some bugs. Over time you get a good feeling for GCC's weaknesses (templates for example). Well, okay, maybe those code snippets are "obnoxious". > (As a sidenote, even if they are technically regressions, I don't consider > such artificial codes really important to fix. There are more important > things, and we get this right for gcc 4.6.2, that'll be ok with me as well :-) Of course they are less important than wrong-code, ice-on-valid and rejects-valid bugs. OTOH, it's a matter of QoI. The sheer number of such little bugs makes them a real problem. Two examples: * If you use the compiler in education, you want a bullet-proof compiler and not a compiler that falls flat on its face when being confronted with silly mistakes. * Many people learn programming languages by throwing code at the compiler rather than checking it out first in the standard (which does make sense given the size and readability of the standard). If it doesn't compile one can still look what went wrong (given a good error message). A compiler that accepts invalid code will generate bug reports "this used to compile with gcc x.y.z!" one release later. A compiler that just crashes without sensible error messages isn't very helpful at least. In order to make GCC the best compiler around, we should get rid of these little pesky bugs. The new C++ parser has been merged over two years ago. Most of the dust should have settled by now. So to me the time seems to be right to do some clean-up. > W.
Moving to 4.0.2 pre Mark.
Leaving as P2; we should try to fix this.
(In reply to comment #8) > > How do you generate all these snippets? > > By sheer determination. I pick some topic like pointers-to-members or > destructors for example and try to find some bugs. Over time you get > a good feeling for GCC's weaknesses (templates for example). Well, > okay, maybe those code snippets are "obnoxious". By the way (should have written this a long time ago): My experience with things like this is that you should probably save all the snippets you create, even if they didn't crash the compiler in any interesting way (i.e. worked just fine). If we ever want to have a comprehensive testsuite, then these are the pieces that you would want in there. Of course, getting the gcc folks to accept a thousand small programs that just test small parts of the language is going to be harder than proposing a single testcase that shows that a particular patch fixed a particular bug, but I think it would be worth while. (For example, if we had had testcases that had stresses static template members in all their aspects, we would have had a dozen or so regression reports less lately... :-) W.
Subject: Bug 19253 Author: mmitchel Date: Wed Nov 2 21:34:51 2005 New Revision: 106398 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106398 Log: PR c++/19253 * parser.c (cp_parser_postfix_expression): Use cp_parser_elaborated_type_specifier to handle typename-types in functional casts. (cp_parser_enclosed_argument_list): Skip ahead to the end of the template argument list if the closing ">" is not found. PR c++/19253 * g++.dg/parse/typename8.C: Compile with -w -fpermissive. * g++.dg/parse/typename9.C: New test. * g++/dg/parse/typename10.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/parse/typename10.C trunk/gcc/testsuite/g++.dg/parse/typename9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/typename8.C
Subject: Bug 19253 Author: mmitchel Date: Wed Nov 2 21:35:46 2005 New Revision: 106399 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106399 Log: PR c++/19253 * parser.c (cp_parser_postfix_expression): Use cp_parser_elaborated_type_specifier to handle typename-types in functional casts. (cp_parser_enclosed_argument_list): Skip ahead to the end of the template argument list if the closing ">" is not found. PR c++/19253 * g++.dg/parse/typename8.C: Compile with -w -fpermissive. * g++.dg/parse/typename9.C: New test. * g++/dg/parse/typename10.C: Likewise. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/typename10.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/typename9.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/parser.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/typename8.C
Fixed in 4.0.3.
Subject: Bug 19253 Author: reichelt Date: Tue Nov 15 19:14:21 2005 New Revision: 107037 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107037 Log: PR c++/19253 PR c++/22172 Backport from mainline: 2005-11-02 Mark Mitchell <mark@codesourcery.com> * parser.c (cp_parser_postfix_expression): Use cp_parser_elaborated_type_specifier to handle typename-types in functional casts. (cp_parser_enclosed_argument_list): Skip ahead to the end of the template argument list if the closing ">" is not found. Backport from mainline: 2005-11-02 Mark Mitchell <mark@codesourcery.com> PR c++/19253 * g++.dg/parse/typename10.C: New test. Backport from mainline: 2005-10-08 James A. Morrison <phython@gcc.gnu.org> PR c++/22172 * g++.dg/parse/crash30.C: New test. Added: branches/gcc-3_4-branch/gcc/testsuite/g++.dg/parse/crash30.C branches/gcc-3_4-branch/gcc/testsuite/g++.dg/parse/typename10.C Modified: branches/gcc-3_4-branch/gcc/cp/ChangeLog branches/gcc-3_4-branch/gcc/cp/parser.c branches/gcc-3_4-branch/gcc/testsuite/ChangeLog
Now also fixed on the 3.4 branch.
*** Bug 24967 has been marked as a duplicate of this bug. ***
*** Bug 25997 has been marked as a duplicate of this bug. ***