This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
Original-Message-ID: <384DD807.8721FBCC@roguewave.com> Date: Tue, 07 Dec 1999 21:01:11 -0700 This is a report of a g++ 2.95.2 bug. The code below doesn't compile: Thank you Martin $ cat test.cpp template <class T, class U> struct A { static const int n = 0; }; template <class T> struct B { template <class U> void foo (int = A<T, U>::n) { } }; $ g++ -c -v /build/sebor/dev/stdlib2/tests/regress/src/test.cpp Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gcc version 2.95.2 19991024 (release) /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/cpp -lang-c++ -v -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__EXCEPTIONS -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di686 -Dpentiumpro -D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ /build/sebor/dev/stdlib2/tests/regress/src/test.cpp /tmp/ccsxupTb.ii GNU CPP version 2.95.2 19991024 (release) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../../include/g++-3 /usr/local/include /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../../i686-pc-linux-gnu/include /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/include /usr/include End of search list. The following default directories have been omitted from the search path: End of omitted list. /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/cc1plus /tmp/ccsxupTb.ii -quiet -dumpbase test.cc -version -o /tmp/cceGXWld.s GNU C++ version 2.95.2 19991024 (release) (i686-pc-linux-gnu) compiled by GNU C version 2.95.2 19991024 (release). /build/sebor/dev/stdlib2/tests/regress/src/test.cpp:12: parse error before `>' ============================================== Martin Sebor, Lead Software Engineer C++ Standards Group, Rogue Wave Software, Inc. sebor@roguewave.com (303) 545-3287 Release: 2.95.2
State-Changed-From-To: open->analyzed State-Changed-Why: Confirmed as a bug
From: loewis@gcc.gnu.org To: gcc-gnats@gcc.gnu.org, martin@loewis.home.cs.tu-berlin.de, nobody@gcc.gnu.org, sebor@roguewave.com Cc: Subject: Re: c++/57 Date: 9 Mar 2000 07:39:15 -0000 Old Synopsis: [not accepted] templates in default arguments New Synopsis: templates in default arguments State-Changed-From-To: open->analyzed State-Changed-By: loewis State-Changed-When: Wed Mar 8 23:39:15 2000 State-Changed-Why: Confirmed as a bug http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=57&database=gcc
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu> To: nathan@codesourcery.com, <gcc-bugs@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org> Cc: Subject: Re: c++/57: [parser] templates in default arguments Date: Tue, 22 Oct 2002 18:47:32 -0500 (CDT) Nathan, the following code has, if I recall correctly, invalid syntax: --------------------------------------------- template <class T, class U> struct A { static const int n = 0; }; template <class T> struct B { template <class U> void foo (int = A<T, U>::n) { } }; --------------------------------------------- In the default argument parsing, there's a "," not nested inside parentheses. This stops default argument parsing. If you agree, then this report should be closed. Regards Wolfgang ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ticam.utexas.edu www: http://www.ticam.utexas.edu/~bangerth
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu> To: Neil Booth <neil@daikokuya.co.uk> Cc: nathan@codesourcery.com, <gcc-bugs@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org> Subject: Re: c++/57: [parser] templates in default arguments Date: Wed, 23 Oct 2002 20:10:32 -0500 (CDT) > > void foo (int = A<T, U>::n) { } > > --------------------------------------------- > > In the default argument parsing, there's a "," not nested inside > > parentheses. This stops default argument parsing. If you agree, then this > > report should be closed. > > FWIW Comeau accepts it in strict conforming mode. I think I recall there was a defect report about this, but I can't seem to find it anymore, and I also don't recall whether it was resolved either way or other ... Wolfgang ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ticam.utexas.edu www: http://www.ticam.utexas.edu/~bangerth
From: Neil Booth <neil@daikokuya.co.uk> To: Wolfgang Bangerth <bangerth@ticam.utexas.edu> Cc: nathan@codesourcery.com, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: c++/57: [parser] templates in default arguments Date: Wed, 23 Oct 2002 20:31:03 +0100 Wolfgang Bangerth wrote:- > > Nathan, > the following code has, if I recall correctly, invalid syntax: > --------------------------------------------- > template <class T, class U> > struct A { > static const int n = 0; > }; > > template <class T> > struct B > { > template <class U> > void foo (int = A<T, U>::n) { } > }; > --------------------------------------------- > In the default argument parsing, there's a "," not nested inside > parentheses. This stops default argument parsing. If you agree, then this > report should be closed. FWIW Comeau accepts it in strict conforming mode. Neil.
From: Nathan Sidwell <nathan@codesourcery.com> To: Wolfgang Bangerth <bangerth@ticam.utexas.edu> Cc: Neil Booth <neil@daikokuya.co.uk>, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: c++/57: [parser] templates in default arguments Date: Thu, 24 Oct 2002 08:48:36 +0100 Wolfgang Bangerth wrote: >>> void foo (int = A<T, U>::n) { } >>>--------------------------------------------- >>>In the default argument parsing, there's a "," not nested inside >>>parentheses. This stops default argument parsing. If you agree, then this >>>report should be closed. >> >>FWIW Comeau accepts it in strict conforming mode. > > > I think I recall there was a defect report about this, but I can't seem to > find it anymore, and I also don't recall whether it was resolved either > way or other ... 325. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#325 I'm surprised comeau accepts your example, Neil, because I experimented with the EDG frontend too. nathan -- Dr Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC 'But that's a lie.' - 'Yes it is. What's your point?' nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org
From: Neil Booth <neil@daikokuya.co.uk> To: Nathan Sidwell <nathan@codesourcery.com> Cc: Wolfgang Bangerth <bangerth@ticam.utexas.edu>, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: c++/57: [parser] templates in default arguments Date: Thu, 24 Oct 2002 20:43:41 +0100 Nathan Sidwell wrote:- > >I think I recall there was a defect report about this, but I can't seem to > >find it anymore, and I also don't recall whether it was resolved either > >way or other ... > 325. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#325 > I'm surprised comeau accepts your example, Neil, because I experimented > with the EDG frontend too. I just used their on-line compiler. The only compiler I "own" is GCC 8-) Neil.
State-Changed-From-To: analyzed->suspended State-Changed-Why: Let's put this into suspended state, and wait for the new parser and the resolution of the DR.
Note that the new parser is here; this is waiting for the DR resolution.
*** Bug 12531 has been marked as a duplicate of this bug. ***
*** Bug 15201 has been marked as a duplicate of this bug. ***
*** Bug 15217 has been marked as a duplicate of this bug. ***
There is at least one case where this construct is used in the standard (at least in the oldish references I have access to). In <bitset> there is (in the gcc 3.4 include files) the following function: template<class _CharT, class _Traits, class _Alloc> bitset(const basic_string<_CharT, _Traits, _Alloc>& __s, size_t __pos, size_t __n) : _Base() However, according to the SGI documentation this should be: template<class Char, class Traits, class Alloc> explicit bitset(const basic_string<Char,Traits,Alloc>& s, size_t pos = 0, size_t n = basic_string<Char,Traits,Alloc>::npos) which is also what C++PL 3rd Edition shows. The initializer "npos" causes gcc to fail with this bug. FWIW
Subject: Re: [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument How funny, the reference is indeed in the standard, it's the last declaration on page 502, section 23.3.5.1. Maybe someone can see if there is a defect report, though I can't seem to find one if it exists. It's easy to work around, though, by just duplicating the constructor, and having one take the third argument and one not taking it. W. ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ices.utexas.edu www: http://www.ices.utexas.edu/~bangerth/
Subject: Re: [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument "bangerth at ices dot utexas dot edu" <gcc-bugzilla@gcc.gnu.org> writes: > ------- Additional Comments From bangerth at ices dot utexas dot edu 2004-04-30 14:01 ------- > Subject: Re: [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument > > > How funny, the reference is indeed in the standard, it's the last declaration > on page 502, section 23.3.5.1. Maybe someone can see if there is a defect > report, though I can't seem to find one if it exists. > > It's easy to work around, though, by just duplicating the constructor, and > having one take the third argument and one not taking it. [snip] The default argument expression can also be parenthesized: template<class charT, class traits, class Allocator> explicit bitset(const basic_string<charT, traits, Allocator>& str, typename basic_string<charT, traits, Allocator>::size_type pos =0, typename basic_string<charT, traits, Allocator>::size_type n = (basic_string<charT, traits, Allocator>::npos)); ^-extra parentheses--------------------------^ which is perhaps easier.
(In reply to comment #14) > Subject: Re: [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument > > > How funny, the reference is indeed in the standard, it's the last declaration > on page 502, section 23.3.5.1. Sure. That's what the test case was reduced from -- the declaration of the bitset template ctor :) Has there been any progress on the resolution to issue 325? If the CWG is leaning toward the suggested resolution we might want to file a library issue to have the bitset ctor declaration changed. Martin
Bangaerth suggested a workaround by duplicating the constructor, one with and one without the argument. But there's an even easier workaround: somply parenthesize the default value. I'd suggest that gcc should do this - although the lexical text of the default is not the same as in the standard, this solutiion preserves the actual default values required by the standard and compiles without error. Ivan
*** Bug 15980 has been marked as a duplicate of this bug. ***
I'm not sure why this PR was suspended. The problem persists in the new C++ parser. Should the bug be re-opened?
The reason why this is still supsended as it is waiting on the DR report to be resolved.
*** Bug 18688 has been marked as a duplicate of this bug. ***
(In reply to comment #21) > *** Bug 18688 has been marked as a duplicate of this bug. *** Is it really a dupe? The bug I raised only involved a templated argument, the class with the member function is not templated. Besides which, if its invalid as a member function, why is it not invalid stand-alone? And why should typedef's get around it?
(In reply to comment #22) > (In reply to comment #21) > > *** Bug 18688 has been marked as a duplicate of this bug. *** > > Is it really a dupe? yes. > The bug I raised only involved a templated argument, the > class with the member function is not templated. yes > Besides which, if its invalid > as a member function, why is it not invalid stand-alone? because non-member's default args can be parsed immediately, member's default args cannot be. > And why should typedef's get around it? because those do not have commas in them read DR325 for gory details
Created an attachment (id=8545) [edit] proposal patch Modified the function cp_parser_parameter_declaration() in gcc/cp/parser.c. If the parser encounters a ',', it then tentatively starts parsing another parameter. If failed, it considers the ',' is within a template parameter.
Created an attachment (id=8546) [edit] proposal patch Modified the function cp_parser_parameter_declaration() in gcc/cp/parser.c. If the parser encounters a ',', it then tentatively starts parsing another parameter. If failed, it considers the ',' is within a template parameter.
(From update of attachment 8546 [edit]) gcc v3.4.3: gcc/parser.c
(In reply to comment #26) > (From update of attachment 8546 [edit]) > gcc v3.4.3: > gcc/parser.c I should note this bug is suspended. This is because the standard is unclear at what is the correct behavior. See DR 325 for all the details.
*** Bug 21084 has been marked as a duplicate of this bug. ***
*** Bug 24690 has been marked as a duplicate of this bug. ***
*** Bug 27038 has been marked as a duplicate of this bug. ***
*** Bug 29084 has been marked as a duplicate of this bug. ***
*** Bug 30069 has been marked as a duplicate of this bug. ***
*** Bug 30344 has been marked as a duplicate of this bug. ***
*** Bug 33754 has been marked as a duplicate of this bug. ***
Created an attachment (id=14407) [edit] updated patch Here's a cleaned up version of Liu Guanwei's patch that passes regression testing with current 4.3 sources. I've pinged him for a copyright assignment so I can check it in.
Subject: Bug 57 Author: jason Date: Mon Apr 28 20:43:27 2008 New Revision: 134762 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134762 Log: PR c++/57 * parser.c (cp_parser_parameter_declaration): Handle < ambiguity in default arguments. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/g++.old-deja/g++.pt/defarg8.C
I thinks this is fixed and should be closed.
Subject: Re: [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument Sent from my iPhone On Aug 10, 2008, at 9:02, "manu at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org > wrote: > > > ------- Comment #37 from manu at gcc dot gnu dot org 2008-08-10 > 16:02 ------- > I thinks this is fixed and should be closed. It is fixed but the defect report against the C++ standard is still open so ... -- Pinski > > > > -- > > manu at gcc dot gnu dot org changed: > > What |Removed |Added > --- > --- > ---------------------------------------------------------------------- > CC| |manu at gcc dot gnu > dot org > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is.
So then it should be SUSPENDED until the DR is solved.
(In reply to comment #38) > Subject: Re: [DR 325] GCC can't parse a non-parenthesized comma in a > template-id within a default argument > > It is fixed but the defect report against the C++ standard is still > open so ... > -- Pinski > Hello. First, I'm new in gcc. I'm moving our project on gcc and I meet this bug. My code: template <typename T, bool F> struct sp { sp () { } }; struct X { typedef sp <X, true> sp_x; //X (sp_x x = sp_x ()) // OK //X (sp <X, true> x = (sp <X, true> ())) // OK X (sp <X, true> x = sp <X, true> ()) // ERROR { } }; My gcc output: g++ -o /home/zerg/bs/plugins/test.o -c -v -save-temps /home/zerg/bs/plugins/test.cpp Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=i386-redhat-linux Thread model: posix gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) COLLECT_GCC_OPTIONS='-o' '/home/zerg/bs/plugins/test.o' '-c' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic' /usr/libexec/gcc/i386-redhat-linux/4.3.2/cc1plus -E -quiet -v -D_GNU_SOURCE /home/zerg/bs/plugins/test.cpp -mtune=generic -fpch-preprocess -o test.ii ignoring nonexistent directory "/usr/lib/gcc/i386-redhat-linux/4.3.2/include-fixed" ignoring nonexistent directory "/usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../i386-redhat-linux/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2 /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/i386-redhat-linux /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/backward /usr/local/include /usr/lib/gcc/i386-redhat-linux/4.3.2/include /usr/include End of search list. COLLECT_GCC_OPTIONS='-o' '/home/zerg/bs/plugins/test.o' '-c' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic' /usr/libexec/gcc/i386-redhat-linux/4.3.2/cc1plus -fpreprocessed test.ii -quiet -dumpbase test.cpp -mtune=generic -auxbase-strip /home/zerg/bs/plugins/test.o -version -o test.s GNU C++ (GCC) version 4.3.2 20081105 (Red Hat 4.3.2-7) (i386-redhat-linux) compiled by GNU C version 4.3.2 20081105 (Red Hat 4.3.2-7), GMP version 4.2.2, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: a43cbcaee4cf8f26ffea6bb0c2e68739 /home/zerg/bs/plugins/test.cpp:23: error: expected identifier before 'true' /home/zerg/bs/plugins/test.cpp:23: error: expected ',' or '...' before 'true' /home/zerg/bs/plugins/test.cpp:23: error: wrong number of template arguments (1, should be 2) /home/zerg/bs/plugins/test.cpp:4: error: provided for 'template<class T, bool F> struct sp' /home/zerg/bs/plugins/test.cpp:23: error: default argument missing for parameter 2 of 'X::X(sp<X, true>, int)' I read all comments and saw a patch. But I don't know how I can fix my gcc with this patch.
(In reply to comment #40) > I read all comments and saw a patch. But I don't know how I can fix my gcc with > this patch. The easiest way is to wait for gcc 4.4. W.
*** Bug 39426 has been marked as a duplicate of this bug. ***
*** Bug 39948 has been marked as a duplicate of this bug. ***
(In reply to comment #41) > (In reply to comment #40) > > I read all comments and saw a patch. But I don't know how I can fix my gcc with > > this patch. > > The easiest way is to wait for gcc 4.4. > W. > GCC 4.4 came and went. Now what?
(In reply to comment #44) > GCC 4.4 came and went. Now what? Now what what? The issue is fixed for 4.4, and I just double checked myself the original testcase and the one in Comment #40, both compile fine. Comments #38 and #39 explain why technically the PR must remain suspended for now. So?