public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c++/8772: Segmentation fault on 3 lines of template code
@ 2002-12-03  8:16 Gabriel Dos Reis
  0 siblings, 0 replies; 9+ messages in thread
From: Gabriel Dos Reis @ 2002-12-03  8:16 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR c++/8772; it has been noted by GNATS.

From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
Cc: gcc-bugs@gcc.gnu.org, <zack@codesourcery.com>, <pcarlini@unitus.it>,
   <sneechy@hotmail.com>, <gcc-gnats@gcc.gnu.org>
Subject: Re: c++/8772: Segmentation fault on 3 lines of template code
Date: 03 Dec 2002 17:06:38 +0100

 Wolfgang Bangerth <bangerth@ticam.utexas.edu> writes:
 
 | > |     However, just for the record: I fail to see how this can be
 | > |     made legal: when you write A<n>::B to denote the template
 | > |     type, B is a template dependent type, and one would think
 | > |     one has to write a "typename" somewhere. But then we have
 | > |       typename A<n>::B
 | > |     which is not the name of a type, but of a template. I don't
 | > |     know what the standard says here, but I don't see a way to
 | > |     make it legal in any case.
 | > 
 | > This case seems to be forgotten by the standard.  I think the
 | > following should make GCC happy.
 | > 
 | >   template<int n>
 | >      struct D  {
 | >        enum { 
 | >          v = C<A<n>::template B>::v
 | >        };
 | >      };
 | > 
 | > Note the "template" keyword in front of B.
 | 
 | Right, it does.
 | 
 | 
 | > The closest you can find in the standard is 14.2/
 | > 
 | >     4
 | >       When the name of a member template specialization appears after . or
 |                                            ^^^^^^^^^^^^^^
 | I think this is why you said it seems to have been forgotten? After all it 
 | speaks about a specialization, which it is not in the code you posted.
 
 Right.
 
 | If you are sure that this is an oversight,
 
 I didn't intend to speak for the committee -- I can't and I don't want
 to.
 
 But I find the above wording overly restrictive.
 
 | why don't you bring it up with 
 | the ISO committee?
 
 Already done ;-)
 
 -- Gaby


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: c++/8772: Segmentation fault on 3 lines of template code
@ 2003-01-20  9:46 Volker Reichelt
  0 siblings, 0 replies; 9+ messages in thread
From: Volker Reichelt @ 2003-01-20  9:46 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR c++/8772; it has been noted by GNATS.

From: Volker Reichelt <reichelt@igpm.rwth-aachen.de>
To: gdr@integrable-solutions.net
Cc: bangerth@ticam.utexas.edu, gcc-gnats@gcc.gnu.org, sneechy@hotmail.com,
        gcc-bugs@gcc.gnu.org
Subject: Re: c++/8772: Segmentation fault on 3 lines of template code
Date: Mon, 20 Jan 2003 11:41:42 +0100

 On 18 Jan, Gabriel Dos Reis wrote:
 
 > Well, the diagnostic is still incorrect; I believe we should rephrase
 > teh synopsis to indicate that
 
 Done.
 
 FYI, a short summary of the audit-trail:
 
 GCC issues:
 * The code is illegal, and caused an ICE since gcc 2.95.x.
 * The ICE was fixed with the new parser, but the error message which
   is issued now, is misleading:
 
 PR8772.cc:3: error: type/value mismatch at argument 1 in template parameter 
    list for `template<template<int <anonymous> > class F> struct C'
 PR8772.cc:3: error:   expected a type, got `A<<anonymous> >::B'
 
   (We do expect a template - not a type.) So we still have a bug.
 
 ISO-Standard issues:
 * There seems to be no way to make the code legal according to the
   standard. This was reported to the committee by Gaby. The proposed
   solution - using C<A<n>::template B> - is already accepted since
   gcc 3.1.
 
 Regards,
 Volker
 
 


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: c++/8772: Segmentation fault on 3 lines of template code
@ 2003-01-18  9:36 Gabriel Dos Reis
  0 siblings, 0 replies; 9+ messages in thread
From: Gabriel Dos Reis @ 2003-01-18  9:36 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR c++/8772; it has been noted by GNATS.

From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
Cc: Volker Reichelt <reichelt@igpm.rwth-aachen.de>, gcc-gnats@gcc.gnu.org,
   <sneechy@hotmail.com>, <gcc-bugs@gcc.gnu.org>
Subject: Re: c++/8772: Segmentation fault on 3 lines of template code
Date: 18 Jan 2003 10:28:18 +0100

 Wolfgang Bangerth <bangerth@ticam.utexas.edu> writes:
 
 | > What are we going to do with the PR w.r.t. the how-to-make-to-code-legal
 | > issue? Leave it open, close it, suspend it, open a new PR?
 | 
 | Good question. Just to recall this briefly: this code
 | ---------------
 | template <int> struct A {
 |     template <int> struct B { enum { v = 1 }; };
 | };
 | 
 | template <template <int> class F> struct C {
 |     enum { v = F<1>::v || 2 };
 | };
 | 
 | template <int n> struct D {
 |     enum { v = C<A<n>::B>::v };
 | };
 | -----------------------
 | generated an ICE (now errors), and the question was: is in the last line
 |   C<A<n>::B> 
 | something meaningful? Wouldn't we have to write
 |   C<typename A<n>::B>
 | ? This doesn't compile either presently. 
 | 
 | Gaby's suggestion was that this needs to be further disambiguated as
 |   C<typename A<n>::template B>
 
 Actually I suggeted:
 
   C<A<n>::template B>
 
 | which would not be covered by the standard (the oversight Gaby spoke of), 
 | but be reasonable. However, this still doesn't compile presently:
 |   g/a> /home/bangerth/bin/gcc-3.4-pre/bin/gcc -c x.cc
 |   x.cc:10: error: template argument 1 is invalid
 | 
 | What does compile is (also with icc7, by the way)
 |   C<A<n>::template B>
 | 
 | Gaby, is the latter the syntax you had in mind to be legal, i.e. put 
 | differently: no need for "typename"?
 
 Yes, that is what I talking about.  Incidently, as I said, Iraised the
 issue ad John Spicer (EDG) tolad me that he already came across the
 same issue, made a (revised) suggestion that matches mine, see
 
    http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/papers/2000/n1231.html
 
 | 
 | If yes, then I would say gcc presently does its best and we should close 
 | the report.
 
 Well, the diagnostic is still incorrect; I believe we should rephrase
 teh synopsis to indicate that
 
 | If the inquire Gaby did with the ISO committee finds some 
 | other solution, then this will be put into a DR anyway, and there is no 
 | need to keep the report open presently anyway.
 
 This is already reported to committee and there seems to be agreement
 that the code should be made work with 'template' prefix.
 
 -- Gaby


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: c++/8772: Segmentation fault on 3 lines of template code
@ 2003-01-17 15:56 Wolfgang Bangerth
  0 siblings, 0 replies; 9+ messages in thread
From: Wolfgang Bangerth @ 2003-01-17 15:56 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR c++/8772; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Volker Reichelt <reichelt@igpm.rwth-aachen.de>
Cc: gcc-gnats@gcc.gnu.org, <sneechy@hotmail.com>, <gcc-bugs@gcc.gnu.org>,
   <gdr@integrable-solutions.net>
Subject: Re: c++/8772: Segmentation fault on 3 lines of template code
Date: Fri, 17 Jan 2003 09:46:45 -0600 (CST)

 > What are we going to do with the PR w.r.t. the how-to-make-to-code-legal
 > issue? Leave it open, close it, suspend it, open a new PR?
 
 Good question. Just to recall this briefly: this code
 ---------------
 template <int> struct A {
     template <int> struct B { enum { v = 1 }; };
 };
 
 template <template <int> class F> struct C {
     enum { v = F<1>::v || 2 };
 };
 
 template <int n> struct D {
     enum { v = C<A<n>::B>::v };
 };
 -----------------------
 generated an ICE (now errors), and the question was: is in the last line
   C<A<n>::B> 
 something meaningful? Wouldn't we have to write
   C<typename A<n>::B>
 ? This doesn't compile either presently. 
 
 Gaby's suggestion was that this needs to be further disambiguated as
   C<typename A<n>::template B>
 which would not be covered by the standard (the oversight Gaby spoke of), 
 but be reasonable. However, this still doesn't compile presently:
   g/a> /home/bangerth/bin/gcc-3.4-pre/bin/gcc -c x.cc
   x.cc:10: error: template argument 1 is invalid
 
 What does compile is (also with icc7, by the way)
   C<A<n>::template B>
 
 Gaby, is the latter the syntax you had in mind to be legal, i.e. put 
 differently: no need for "typename"?
 
 
 If yes, then I would say gcc presently does its best and we should close 
 the report. If the inquire Gaby did with the ISO committee finds some 
 other solution, then this will be put into a DR anyway, and there is no 
 need to keep the report open presently anyway.
 
 Regards
   Wolfgang
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: c++/8772: Segmentation fault on 3 lines of template code
@ 2003-01-17 14:56 Volker Reichelt
  0 siblings, 0 replies; 9+ messages in thread
From: Volker Reichelt @ 2003-01-17 14:56 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR c++/8772; it has been noted by GNATS.

From: Volker Reichelt <reichelt@igpm.rwth-aachen.de>
To: gcc-gnats@gcc.gnu.org, sneechy@hotmail.com, gcc-bugs@gcc.gnu.org,
        gdr@integrable-solutions.net, bangerth@ticam.utexas.edu
Cc:  
Subject: Re: c++/8772: Segmentation fault on 3 lines of template code
Date: Fri, 17 Jan 2003 16:48:56 +0100

 The ICE is fixed with the new parser.
 I now get:
 
 PR8772.cc:7: error: type/value mismatch at argument 1 in template parameter 
    list for `template<template<int <anonymous> > class F> struct C'
 PR8772.cc:7: error:   expected a type, got `A<<anonymous> >::B'
 
 (Testcase in preparation.)
 
 
 What are we going to do with the PR w.r.t. the how-to-make-to-code-legal issue?
 Leave it open, close it, suspend it, open a new PR?
 Any suggestions, Gaby, Wolfgang?
 
 Regards,
 Volker
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8772
 
 


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: c++/8772: Segmentation fault on 3 lines of template code
@ 2002-12-03  8:06 Wolfgang Bangerth
  0 siblings, 0 replies; 9+ messages in thread
From: Wolfgang Bangerth @ 2002-12-03  8:06 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR c++/8772; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Gabriel Dos Reis <gdr@integrable-solutions.net>
Cc: gcc-bugs@gcc.gnu.org, <zack@codesourcery.com>, <pcarlini@unitus.it>,
   <sneechy@hotmail.com>, <gcc-gnats@gcc.gnu.org>
Subject: Re: c++/8772: Segmentation fault on 3 lines of template code
Date: Tue, 3 Dec 2002 09:53:58 -0600 (CST)

 > |     However, just for the record: I fail to see how this can be
 > |     made legal: when you write A<n>::B to denote the template
 > |     type, B is a template dependent type, and one would think
 > |     one has to write a "typename" somewhere. But then we have
 > |       typename A<n>::B
 > |     which is not the name of a type, but of a template. I don't
 > |     know what the standard says here, but I don't see a way to
 > |     make it legal in any case.
 > 
 > This case seems to be forgotten by the standard.  I think the
 > following should make GCC happy.
 > 
 >   template<int n>
 >      struct D  {
 >        enum { 
 >          v = C<A<n>::template B>::v
 >        };
 >      };
 > 
 > Note the "template" keyword in front of B.
 
 Right, it does.
 
 
 > The closest you can find in the standard is 14.2/
 > 
 >     4
 >       When the name of a member template specialization appears after . or
                                            ^^^^^^^^^^^^^^
 I think this is why you said it seems to have been forgotten? After all it 
 speaks about a specialization, which it is not in the code you posted.
 
 If you are sure that this is an oversight, why don't you bring it up with 
 the ISO committee?
 
 Thanks for the clarification
   Wolfgang
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth
 
 


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: c++/8772: Segmentation fault on 3 lines of template code
@ 2002-12-02 14:56 Gabriel Dos Reis
  0 siblings, 0 replies; 9+ messages in thread
From: Gabriel Dos Reis @ 2002-12-02 14:56 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR c++/8772; it has been noted by GNATS.

From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: bangerth@dealii.org
Cc: gcc-bugs@gcc.gnu.org, zack@codesourcery.com, pcarlini@unitus.it,
   sneechy@hotmail.com, gcc-gnats@gcc.gnu.org
Subject: Re: c++/8772: Segmentation fault on 3 lines of template code
Date: 02 Dec 2002 23:49:28 +0100

 bangerth@dealii.org writes:
 
 | Synopsis: Segmentation fault on 3 lines of template code
 | 
 | State-Changed-From-To: open->analyzed
 | State-Changed-By: bangerth
 | State-Changed-When: Mon Dec  2 12:45:29 2002
 | State-Changed-Why:
 |     Others have confirmed this already.
 |     
 |     However, just for the record: I fail to see how this can be
 |     made legal: when you write A<n>::B to denote the template
 |     type, B is a template dependent type, and one would think
 |     one has to write a "typename" somewhere. But then we have
 |       typename A<n>::B
 |     which is not the name of a type, but of a template. I don't
 |     know what the standard says here, but I don't see a way to
 |     make it legal in any case.
 
 This case seems to be forgotten by the standard.  I think the
 following should make GCC happy.
 
   template<int n>
      struct D  {
        enum { 
          v = C<A<n>::template B>::v
        };
      };
 
 Note the "template" keyword in front of B.
 
 The closest you can find in the standard is 14.2/
 
     4
       When the name of a member template specialization appears after . or
       -> 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 not reproduced ]
 
     5
       If a name prefixed by the keyword template is not the name of a
       member template, the program is ill-formed.
 
 -- Gaby


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: c++/8772: Segmentation fault on 3 lines of template code
@ 2002-12-02 12:45 bangerth
  0 siblings, 0 replies; 9+ messages in thread
From: bangerth @ 2002-12-02 12:45 UTC (permalink / raw)
  To: gcc-bugs, gcc-prs, nobody, sneechy

Synopsis: Segmentation fault on 3 lines of template code

State-Changed-From-To: open->analyzed
State-Changed-By: bangerth
State-Changed-When: Mon Dec  2 12:45:29 2002
State-Changed-Why:
    Others have confirmed this already.
    
    However, just for the record: I fail to see how this can be
    made legal: when you write A<n>::B to denote the template
    type, B is a template dependent type, and one would think
    one has to write a "typename" somewhere. But then we have
      typename A<n>::B
    which is not the name of a type, but of a template. I don't
    know what the standard says here, but I don't see a way to
    make it legal in any case.
    
    More reference: icc7 also rejects the code, both with
    and without the "typename".

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8772


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: c++/8772: Segmentation fault on 3 lines of template code
@ 2002-12-01  1:46 Paolo Carlini
  0 siblings, 0 replies; 9+ messages in thread
From: Paolo Carlini @ 2002-12-01  1:46 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR c++/8772; it has been noted by GNATS.

From: Paolo Carlini <pcarlini@unitus.it>
To: gcc-gnats@gcc.gnu.org,  gcc-prs@gcc.gnu.org,  sneechy@hotmail.com, 
 gcc-bugs@gcc.gnu.org,  nobody@gcc.gnu.org, 
 Zack Weinberg <zack@codesourcery.com>
Cc:  
Subject: Re: c++/8772: Segmentation fault on 3 lines of template code
Date: Sun, 01 Dec 2002 10:38:59 +0100

 Most probably illegal. EDG-based compilers emit:
 
 
 "8772.cc", line 3: error: nontype "A<<unnamed>>::B [with <unnamed>=n]" is not
            a class template
    template <int n> struct D { enum { v = C<A<n>::B>::v }; };
                                             ^
 
 "8772.cc", line 2: error: incomplete type is not allowed
    template <template <int> class F> struct C { enum { v = F<1>::v || 2 }; };
                                                            ^
            detected during instantiation of class "C<F> [with F=<error>]" at
                      line 3
 
 2 errors detected in the compilation of "8772.cc".
 
 
 Ciao,
 Paolo.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8772
 


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2003-01-20  9:46 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-03  8:16 c++/8772: Segmentation fault on 3 lines of template code Gabriel Dos Reis
  -- strict thread matches above, loose matches on Subject: below --
2003-01-20  9:46 Volker Reichelt
2003-01-18  9:36 Gabriel Dos Reis
2003-01-17 15:56 Wolfgang Bangerth
2003-01-17 14:56 Volker Reichelt
2002-12-03  8:06 Wolfgang Bangerth
2002-12-02 14:56 Gabriel Dos Reis
2002-12-02 12:45 bangerth
2002-12-01  1:46 Paolo Carlini

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).