From: Martin Sebor <sebor@roguewave.com>
To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
Cc: bangerth@dealii.org, gcc-gnats@gcc.gnu.org
Subject: Re: c++/9549: [3.4 regression] [New parser] ICE in regenerate_decl_from_template
Date: Mon, 03 Feb 2003 12:37:26 -0700

 Wolfgang Bangerth wrote:
 >>>    This is not a bug. You need to write
 >>>      m.template do_it<T>();
 >>
 >>This is incorrect, as is your previous analysis in PR #9510:
 >>http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9510
 >>
 >>This syntax is required only if the right hand side of the
                                        ^^^^^^^^^^^^^^^
 
 I meant left hand side here, not right hand side. Sorry.
 
 >>dot operator depends on a template parameter, otherwise it
 >>is optional. Please read 14.2, p4 for more.
 > 
 > 
 > Ehm, but in m.do_it<T>, the rhs of the dot operator _is_ template 
 > dependent, no? 14.2.4 has almost the same example and says that you need 
 > the template keyword -- what am I missing here?
 
 If the left hand side does not depend on a template parameter,
 there is no reason to use the template prefix since the name
 to the right of the dot is known to either be a template or
 not at the point of parsing the "surrounding" template and
 there is no possibility of an ambiguity with the less than
 operator. Otherwise it may or may not be a template, and the
 first "<" may or may not be a less than operator, depending
 on any specializations of the template to the left of the
 dot operator.
 
 For instance, in the example below, the declaration
 
          enum { e = A<I - 1>::B<J - 1>::e + 1 };
 
 is parsed as
 
          enum { e = (A<I - 1>::B) < (J - 1) > (::e + 1) };
                       ^^^^^^^     ^         ^
                       |           |         +- operator>()
                       |           +- operator<()
                       +-template argument list
 
 without the template keword because at the point of
 definition of the primary template A it's not known
 whether B is or is not a template. With the template
 keyword, A<I - 1>::template B<J - 1> would be parsed
 as the type name of the template B. The same logic
 applies to the dot operator as well as to operator->
 
 enum { e };
 
 template <int I>
 struct A {
      template <int J>
      struct B {
          enum { e = A<I - 1>::B<J - 1>::e + 1 };
      };
 };
 
 template<>
 struct A<0> {
      enum { B };
 };
 
 int main ()
 {
      return A<1>::B<1>::e;
 }
 
 Martin
 

From: Martin Sebor <sebor@roguewave.com>
To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: c++/9549: [3.4 regression] [New parser] ICE in regenerate_decl_from_template
Date: Mon, 03 Feb 2003 12:55:36 -0700

 Wolfgang Bangerth wrote:
 ...
 >=20
 >=20
 > I understand the reasoning for the necessity of the "template" keyword=20
 > here.
 >=20
 > This is 14.2.4 text and example from the 1997 draft I use:
 >   When  the name of a member template specialization appears after .  o=
 r
 >   -> in a postfix-expression, or after :: in a qualified-id that explic=
 -
 >   itly  depends on a template-argument (_temp.dep_), the member templat=
 e
 >   name must be prefixed by the keyword template.  Otherwise the name  i=
 s
 >   assumed to name a non-template.  [Example:
 >           class X {
 >           public:
 >                   template<size_t> X* alloc();
 >           };
 >           void f(X* p)
 >           {
 >                   X* p1 =3D p->alloc<200>();
 >                           // ill-formed: < means less than
 >=20
 >                   X* p2 =3D p->template alloc<200>();
 >                           // fine: < starts explicit qualification
 >           }
 >    --end example]
 >=20
 > Clearly, the lhs is not template-dependent. Has this been changed=20
 > afterwards? That might explain our mismatch!?
 
 I believe so. Here's what's in the final text:
 
    -4-  When the name of a member template specialization
         appears after . or =AD> in a postfix-expression, or after
         nested-name-specifier in a qualified-id, and the
         postfix-expression or qualified-id explicitly depends on
         a template-parameter (14.6.2), the member template name
         must be prefixed by the keyword template.
         Otherwise the name is assumed to name a non-template.
         [Example:
 
 class X {
 public:
      template<size_t> X* alloc();
      template<size_t> static X* adjust();
 };
 
 template<class T> void f(T* p)
 {
      T* p1 =3D p->alloc<200>();
      // ill-formed: < means less than
 
      T* p2 =3D p->template alloc<200>();
      // OK: < starts template argument list
 
      T::adjust<100>();
      // ill-formed: < means less than
 
      T::template adjust<100>();
      // OK: < starts explicit qualification
 }
 
 --end example]
 
 
 Martin
 

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Martin Sebor <sebor@roguewave.com>
Cc: bangerth@dealii.org, <gcc-gnats@gcc.gnu.org>
Subject: Re: c++/9549: [3.4 regression] [New parser] ICE in regenerate_decl_from_template
Date: Mon, 3 Feb 2003 13:21:53 -0600 (CST)

 > >     This is not a bug. You need to write
 > >       m.template do_it<T>();
 > 
 > This is incorrect, as is your previous analysis in PR #9510:
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9510
 > 
 > This syntax is required only if the right hand side of the
 > dot operator depends on a template parameter, otherwise it
 > is optional. Please read 14.2, p4 for more.
 
 Ehm, but in m.do_it<T>, the rhs of the dot operator _is_ template 
 dependent, no? 14.2.4 has almost the same example and says that you need 
 the template keyword -- what am I missing here?
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Gabriel Dos Reis <gdr@integrable-solutions.net>
Cc: gcc-gnats@gcc.gnu.org, <gcc-bugs@gcc.gnu.org>
Subject: Re: c++/9549: [3.4 regression] [New parser] ICE in regenerate_decl_from_template
Date: Mon, 3 Feb 2003 13:40:41 -0600 (CST)

 On 3 Feb 2003, Gabriel Dos Reis wrote:
 > 
 > |  > >     This is not a bug. You need to write
 > |  > >       m.template do_it<T>();
 > |  > 
 > |  > This is incorrect, as is your previous analysis in PR #9510:
 > 
 > I agree with Martin.
 
 I am willing to learn :-)
 
 > |  > This syntax is required only if the right hand side of the
 > |  > dot operator depends on a template parameter, otherwise it
 > |  > is optional. Please read 14.2, p4 for more.
 > |  
 > |  Ehm, but in m.do_it<T>, the rhs of the dot operator _is_ template 
 > |  dependent, no?
 > 
 > Sure.  But that is irrelevant here. Because the lhs is -not- dependent.
 
 It's just that 14.2.4 does not speak about the lhs at all. It reads 
 (itemization by me):
 
   When the name of a member template specialization appears 
   - after . or -> in a postfix-expression, or 
   - after :: in a qualified-id that explicitly depends on a template
     argument,
   the member template name must be prefixed by the keyword "template".
 
 In the example given in the standard, the lhs is not template dependent.
 
 So please enlighten me...
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Martin Sebor <sebor@roguewave.com>
Cc: gcc-gnats@gcc.gnu.org, <gcc-bugs@gcc.gnu.org>
Subject: Re: c++/9549: [3.4 regression] [New parser] ICE in regenerate_decl_from_template
Date: Mon, 3 Feb 2003 13:46:33 -0600 (CST)

 > >>This syntax is required only if the right hand side of the
 >                                        ^^^^^^^^^^^^^^^
 > 
 > I meant left hand side here, not right hand side. Sorry.
 > 
 > >>dot operator depends on a template parameter, otherwise it
 > >>is optional. Please read 14.2, p4 for more.
 > > 
 > > 
 > > Ehm, but in m.do_it<T>, the rhs of the dot operator _is_ template 
 > > dependent, no? 14.2.4 has almost the same example and says that you need 
 > > the template keyword -- what am I missing here?
 > 
 > If the left hand side does not depend on a template parameter,
 > there is no reason to use the template prefix since the name
 > to the right of the dot is known to either be a template or
 > not at the point of parsing the "surrounding" template and
 > there is no possibility of an ambiguity with the less than
 > operator. Otherwise it may or may not be a template, and the
 > first "<" may or may not be a less than operator, depending
 > on any specializations of the template to the left of the
 > dot operator.
 > 
 > For instance, [...]
 
 I understand the reasoning for the necessity of the "template" keyword 
 here.
 
 This is 14.2.4 text and example from the 1997 draft I use:
   When  the name of a member template specialization appears after .  or
   -> in a postfix-expression, or after :: in a qualified-id that explic-
   itly  depends on a template-argument (_temp.dep_), the member template
   name must be prefixed by the keyword template.  Otherwise the name  is
   assumed to name a non-template.  [Example:
           class X {
           public:
                   template<size_t> X* alloc();
           };
           void f(X* p)
           {
                   X* p1 = p->alloc<200>();
                           // ill-formed: < means less than
 
                   X* p2 = p->template alloc<200>();
                           // fine: < starts explicit qualification
           }
    --end example]
 
 Clearly, the lhs is not template-dependent. Has this been changed 
 afterwards? That might explain our mismatch!?
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Martin Sebor <sebor@roguewave.com>
Cc: gcc-gnats@gcc.gnu.org, <gcc-bugs@gcc.gnu.org>
Subject: Re: c++/9549: [3.4 regression] [New parser] ICE in regenerate_decl_from_template
Date: Mon, 3 Feb 2003 14:02:08 -0600 (CST)

 > I believe so. Here's what's in the final text:
 
 OK, that explains the confusion. Thanks for pointing this out. (It also 
 makes a lot more sense that the lhs must be template-dependent.)
 
 I'll also review the other report you pointed me to.
 
 
 So as a summary -- there are two bugs:
 - the code of this report shows an ICE, which is a regression
 - even without the ICE, the code is well-formed, but rejected by
   all versions of gcc since at least 2.95.
 
 Thanks for your assistance
   W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 

	g++ fails to compile the code; complains about syntax error

Release:
3.2.2 20030131 (Debian prerelease) (Debian testing/unstable)

Environment:
System: Linux feynman 2.4.20 #3 Sam Jan 4 17:10:36 CET 2003 i686 unknown unknown GNU/Linux
Architecture: i686

	
host: i386-pc-linux-gnu
build: i386-pc-linux-gnu
target: i386-pc-linux-gnu
configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,pascal,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --disable-__cxa_atexit --enable-java-gc=boehm --enable-objc-gc i386-linux

How-To-Repeat:
	compile the example code:
	------------------------

struct maxi {
    template<class T>
    void do_it() { }
};

template<class T>
struct mini {
    void do_something( maxi& m )
        { m.do_it<T>(); } /* ERROR: syntax error before `;' token */
};

int main()
{
  maxi ma;
  mini<int> mi;
  mi.do_something( ma );
  return 0;
}
	------------------------

Fix:
	no generally applicable work-around or fix known

State-Changed-From-To: open->analyzed
State-Changed-Why: This is not a bug. You need to write
      m.template do_it<T>();
    
    Incidentially, however, the code you give triggers an 
    ICE in the new parser, so I keep it open as a regression
    and change the synopsis. Here's a simplified piece of
    code for the ICE:
    -----------------------------
    struct X {
        template<typename> void foo() { }
    };
    
    template <typename T> void bar ()
    { X().template foo<T>(); }
    
    template void bar<int> ();
    -------------------------------------
    
    tmp/g> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c x.cc
    x.cc: In member function `void X::foo()':
    x.cc:2:   instantiated from `void X::foo() [with {template default argument error} = T]'
    x.cc:6:   instantiated from `void bar() [with T = int]'
    x.cc:8:   instantiated from here
    x.cc:2: internal compiler error: in regenerate_decl_from_template, at cp/pt.c:
       10533
    Please submit a full bug report,

From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/9549: [3.4 regression] [New parser] ICE in regenerate_decl_from_template
Date: 03 Feb 2003 20:34:05 +0100

 Wolfgang Bangerth <bangerth@ticam.utexas.edu> writes:
 
 |  > >     This is not a bug. You need to write
 |  > >       m.template do_it<T>();
 |  > 
 |  > This is incorrect, as is your previous analysis in PR #9510:
 
 I agree with Martin.
 
 |  > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9510
 |  > 
 |  > This syntax is required only if the right hand side of the
 |  > dot operator depends on a template parameter, otherwise it
 |  > is optional. Please read 14.2, p4 for more.
 |  
 |  Ehm, but in m.do_it<T>, the rhs of the dot operator _is_ template 
 |  dependent, no?
 
 Sure.  But that is irrelevant here. Because the lhs is -not- dependent.
 
 -- Gaby

State-Changed-From-To: analyzed->closed
State-Changed-Why: Fixed in 3.4 CVS 20030430.

This is in fact a duplicate of PR 9488.

Reopening ...

to mark as a dup of bug 9488.

*** This bug has been marked as a duplicate of 9488 ***