19253 – [3.4/4.0/4.1 regression] bad error message
Description Volker Reichelt 2005-01-04 14:31:07 UTC
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.
Comment 1 Andrew Pinski 2005-01-04 15:46:59 UTC
Confirmed.
Comment 2 Volker Reichelt 2005-01-04 16:45:11 UTC
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.
Comment 4 Mark Mitchell 2005-01-29 02:10:01 UTC
Fixed in GCC 4.0.
Comment 5 Volker Reichelt 2005-02-11 17:12:15 UTC
Mark, the first code snippet in comment #3 still crashes on mainline. So this is not yet fixed on mainline.
Comment 7 Wolfgang Bangerth 2005-02-11 17:50:44 UTC
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.
Comment 8 Volker Reichelt 2005-02-14 15:58:50 UTC
> 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.
Comment 9 Andrew Pinski 2005-07-22 21:13:37 UTC
Moving to 4.0.2 pre Mark.
Comment 10 Mark Mitchell 2005-10-31 02:10:16 UTC
Leaving as P2; we should try to fix this.
Comment 11 Wolfgang Bangerth 2005-10-31 16:10:27 UTC
(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.
Comment 12 Mark Mitchell 2005-11-02 21:34:55 UTC
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
Comment 13 Mark Mitchell 2005-11-02 21:35:52 UTC
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
Comment 14 Mark Mitchell 2005-11-02 21:50:52 UTC
Fixed in 4.0.3.
Comment 15 Volker Reichelt 2005-11-15 19:14:26 UTC
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
Comment 16 Volker Reichelt 2005-11-15 19:19:31 UTC
Now also fixed on the 3.4 branch.
Comment 17 Andrew Pinski 2005-11-21 15:56:49 UTC
*** Bug 24967 has been marked as a duplicate of this bug. ***
Comment 18 Andrew Pinski 2006-01-27 16:31:45 UTC
*** Bug 25997 has been marked as a duplicate of this bug. ***