User account creation filtered due to spam.

Bug 19253 - [3.4/4.0/4.1 regression] bad error message / ICE for invalid template parameter
Summary: [3.4/4.0/4.1 regression] bad error message / ICE for invalid template parameter
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 3.4.5
Assignee: Mark Mitchell
URL:
Keywords: diagnostic, ice-on-invalid-code
: 24967 25997 (view as bug list)
Depends on: 18738
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-04 14:31 UTC by Volker Reichelt
Modified: 2006-01-27 16:31 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work: 3.4.5 4.0.3 4.1.0 4.2.0 3.3.3
Known to fail: 4.0.1 3.4.0 3.4.4
Last reconfirmed: 2005-09-10 02:30:56


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 3 CVS Commits 2005-01-29 02:07:36 UTC
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

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 6 Volker Reichelt 2005-02-11 17:13:09 UTC
Sorry, I meant comment #2, of course.
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. ***