Bug 11987 - [4.3/4.4/4.5 regression] Accepts-invalid with inherited nested type
Summary: [4.3/4.4/4.5 regression] Accepts-invalid with inherited nested type
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.4.0
: P4 minor
Target Milestone: 4.5.0
Assignee: Jason Merrill
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords: accepts-invalid, monitored
Depends on:
Blocks:
 
Reported: 2003-08-19 22:51 UTC by Wolfgang Bangerth
Modified: 2009-11-13 14:42 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.0.4
Last reconfirmed: 2009-11-13 05:26:40


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Bangerth 2003-08-19 22:51:03 UTC
This piece of invalid code 
---------------------------------------- 
template <int dim> struct X { 
    struct I { I(); }; 
}; 
 
template <int dim> struct Y : X<dim> { 
    typedef typename X<dim>::I I; 
}; 
 
template <int dim> 
Y<dim>::I::I () {}  // note: I is nested type in X, not Y! 
 
template struct Y<1>; 
------------------------------------------------ 
ICEs everything up to and including 3.3: 
parameter-estimation/libparest> /ices/bangerth/bin/gcc-3.3/bin/g++ -c x.cc 
x.cc:10: internal compiler error: Segmentation fault 
Please submit a full bug report, 
with preprocessed source if appropriate. 
 
On the other hand, present mainline accepts it, which I think is spurious. So 
we traded an ICE for an accepts-invalid. 
 
W.
Comment 1 Andrew Pinski 2003-08-19 23:13:35 UTC
I can confirm this on the mainline (20030819).  GCC stopped ICEing when the new parser came in
Comment 2 Dara Hazeghi 2003-08-23 01:23:24 UTC
I'd say that qualifies as a regression....
Comment 3 Kriang Lerdsuwanakij 2003-10-24 14:51:54 UTC
Update bug summary since it's only accepts-invalid in 3.4.
Comment 4 Giovanni Bajo 2004-02-03 14:06:32 UTC
Wolfgang, I'm revisiting this bug.

Y<dim>::I is a typedef for X<dim>::I. The standard does not explicitally 
forbids the use of typedef-names as qualifying scope in a constructor 
definition, and they are generally allowed for member functions. For instance, 
the following is trivially valid:

struct C { C(); };
typedef C D;
D::C() {}

The only limitation I see is [comp.ctor]/3, which says that "a typedef-name
that names a class shall not be used as the identifier in the declarator for a 
constructor declaration." but it is referring to the identifier itself, not to 
the qualified-id.

Do you agree?

I'm positive that your testcase is indeed valid. 
Comment 5 Wolfgang Bangerth 2004-02-03 14:34:11 UTC
Your knowledge in this area is certainly better than mine, so 
I trust your judgment. 
 
As one datapoint, though, here is what icc says about my testcase: 
g/x> icc -c x.cc -Xc -ansi 
x.cc(10): error: "Y<dim>::I" is not a class template 
  Y<dim>::I::I () {}  // note: I is nested type in X, not Y!  
  ^ 
 
W. 
Comment 6 Mark Mitchell 2004-02-28 02:31:55 UTC
This is a regression, but not very easy to fix, and not terribly harmful.

Therefore, I've pushed the target milestone back to 3.4.1.
Comment 7 Mark Mitchell 2004-06-12 21:53:36 UTC
Postponed until GCC 3.5.0; I doubt there is an easy fix.
Comment 8 Mark Mitchell 2005-09-27 20:58:03 UTC
We're not sure if this is valid or not.

See:

http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01732.html
Comment 9 Mark Mitchell 2005-10-30 22:07:24 UTC
I've talked about this with EDG.  The reason they reject the test case is that Y<dim>::I might or might not be X<dim>::I, depending on whether or not there are specializations of Y in play.  I agree with this logic, so the test case is indeed an accepts-invalid.

However, as indicated in the audit trail, this is not a particular critical regression; downgraded to P4.
Comment 10 Uttam Pawar 2006-01-23 19:20:24 UTC
Just for the information. I tested this bug against following branches, 

gcc-3.2.3 - causes an ICE

gcc-3.4.0 - no ICE
gcc-3.4.2 - no ICE
gcc-3.4.3 - no ICE
gcc-4.0.0 - no ICE
gcc-4.1.0 - no ICE
gcc-4.0.2 - no ICE
gcc-4.2.0 20060123 - no ICE
Comment 11 Gabriel Dos Reis 2007-01-18 02:39:18 UTC
Not to be fixed in GCC-4.0.x
Comment 12 Joseph S. Myers 2008-07-04 16:29:42 UTC
Closing 4.1 branch.
Comment 13 Joseph S. Myers 2009-03-31 16:12:52 UTC
Closing 4.2 branch.
Comment 14 Richard Biener 2009-08-04 12:25:55 UTC
GCC 4.3.4 is being released, adjusting target milestone.
Comment 15 Jason Merrill 2009-11-13 14:40:31 UTC
Subject: Bug 11987

Author: jason
Date: Fri Nov 13 14:40:13 2009
New Revision: 154149

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154149
Log:
	PR c++/11987
	* parser.c (cp_parser_direct_declarator): Give helpful error about
	trying to define member of a dependent typedef.
	* pt.c (resolve_typename_type): Don't resolve a typedef typename.
	* tree.c (typedef_variant_p): New.
	* cp-tree.h: Declare it.

Added:
    trunk/gcc/testsuite/g++.dg/parse/typename11.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/cp-tree.h
    trunk/gcc/cp/parser.c
    trunk/gcc/cp/pt.c
    trunk/gcc/cp/tree.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/template/crash48.C

Comment 16 Jason Merrill 2009-11-13 14:41:25 UTC
Fixed for 4.5.
Comment 17 Jason Merrill 2009-11-13 14:42:25 UTC
.