Discussion:
[Bug libstdc++/39407] New: Parse error in <stack> when user declares template-name c
(too old to reply)
jwakely dot gcc at gmail dot com
2009-03-09 13:02:51 UTC
Permalink
It was just brought to my attention that this fails to compile:

template <typename> void c();
#include <stack>


In file included from
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/stack:67,
from mark.cc:2:
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/bits/stl_stack.h:
In function ‘bool std::operator<(const std::stack<_Tp, _Seq>&, const
std::stack<_Tp, _Seq>&)’:
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/bits/stl_stack.h:257:
error: `.' cannot appear in a constant-expression
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/bits/stl_stack.h:257:
error: parse error in template argument list

The problem is here:

template<typename _Tp, typename _Seq>
inline bool
operator<(const stack<_Tp, _Seq>& __x, const stack<_Tp, _Seq>& __y)
{ return __x.c < __y.c; }

The presence of the template ::c means that "c <" is parsed as the start of a
template-id, which then fails.

I *think* the compiler is doing the right thing here, but that doesn't help
users who've declared a template 'c'. libstdc++ could make it a non-issue by
using parentheses to prevent __x.c being parsed as a template-id:

{ return (__x.c) < __y.c; }

I've only tested it with 4.3.2 but it apparently fails with 3.2 - 4.3.3, and I
assume with 4.4 too.
--
Summary: Parse error in <stack> when user declares template-name
c
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
paolo dot carlini at oracle dot com
2009-03-09 14:00:03 UTC
Permalink
------- Comment #1 from paolo dot carlini at oracle dot com 2009-03-09 14:00 -------
disgusting ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
paolo dot carlini at oracle dot com
2009-03-09 14:02:14 UTC
Permalink
------- Comment #2 from paolo dot carlini at oracle dot com 2009-03-09 14:02 -------
FWIW, if I use v3 together with the Intel C++ compiler, it builds...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
jwakely dot gcc at gmail dot com
2009-03-09 14:25:41 UTC
Permalink
------- Comment #3 from jwakely dot gcc at gmail dot com 2009-03-09 14:25 -------
(In reply to comment #2)
Post by paolo dot carlini at oracle dot com
FWIW, if I use v3 together with the Intel C++ compiler, it builds...
That's interesting, Comeau's online compiler gives a very similar error to gcc
4.3.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
paolo dot carlini at oracle dot com
2009-03-09 15:08:35 UTC
Permalink
------- Comment #4 from paolo dot carlini at oracle dot com 2009-03-09 15:08 -------
Before considering touching the library, I want evidence that at least another
widespread implementation has that operator< somehow different than the obvious
way. Besides, the issue affects <queue> too, of course, and in that case the
Standard is even explicit about implementing exactly as x.c < y.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
jwakely dot gcc at gmail dot com
2009-03-09 15:19:16 UTC
Permalink
------- Comment #5 from jwakely dot gcc at gmail dot com 2009-03-09 15:19 -------
Well, the as-if rule allows (((((x.c)))) < ((y.c)) too of course.

I could be wrong and the compiler should parse it ok, I haven't thought about
it very hard.

The same problem occurs here, although it's only in a GNU extension this time:

template <typename> struct value { };
#include <ext/pod_char_traits.h>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
jwakely dot gcc at gmail dot com
2009-03-09 15:20:32 UTC
Permalink
------- Comment #6 from jwakely dot gcc at gmail dot com 2009-03-09 15:20 -------
(In reply to comment #5)
Post by jwakely dot gcc at gmail dot com
Well, the as-if rule allows (((((x.c)))) < ((y.c)) too of course.
bah - it would allow it if I could type the right number of closing
parentheses!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
rguenth at gcc dot gnu dot org
2009-03-09 15:40:50 UTC
Permalink
------- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-09 15:40 -------
I think this is more likely a C++ frontend issue. At least I cannot believe
this behavior is mandated by the std ;)

Jason?
--
rguenth at gcc dot gnu dot org changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at redhat dot com
Component|libstdc++ |c++
Keywords| |rejects-valid


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
Andrew Thomas Pinski
2009-03-09 15:59:29 UTC
Permalink
Sent from my iPhone
Post by rguenth at gcc dot gnu dot org
------- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-09 15:40 -------
I think this is more likely a C++ frontend issue. At least I cannot believe
this behavior is mandated by the std ;)
Jason?
There is a dup of this bug somewhere also.
Post by rguenth at gcc dot gnu dot org
--
What |Removed |Added
---
---
----------------------------------------------------------------------
CC| |jason at redhat dot com
Component|libstdc++ |c++
Keywords| |rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
hjl dot tools at gmail dot com
2009-03-09 15:58:21 UTC
Permalink
------- Comment #8 from hjl dot tools at gmail dot com 2009-03-09 15:58 -------
Icc 11 has no problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
pinskia at gmail dot com
2009-03-09 15:59:52 UTC
Permalink
------- Comment #9 from pinskia at gmail dot com 2009-03-09 15:59 -------
Subject: Re: Parse error in <stack> when user declares template-name c



Sent from my iPhone

On Mar 9, 2009, at 8:40 AM, "rguenth at gcc dot gnu dot org"
Post by rguenth at gcc dot gnu dot org
------- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-09
15:40 -------
I think this is more likely a C++ frontend issue. At least I cannot
believe
this behavior is mandated by the std ;)
Jason?
There is a dup of this bug somewhere also.
Post by rguenth at gcc dot gnu dot org
--
What |Removed |Added
---
---
----------------------------------------------------------------------
CC| |jason at redhat dot
com
Component|libstdc++ |c++
Keywords| |rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
jwakely dot gcc at gmail dot com
2009-03-09 16:08:44 UTC
Permalink
------- Comment #10 from jwakely dot gcc at gmail dot com 2009-03-09 16:08 -------
reduced:

template <typename> struct x;
template <typename> struct y { int x; };

template<typename T>
bool operator<(const y<T>& l, const y<T>& r) { return l.x < r.x; }


It doesn't happen except in a template context, so it seems that l.x< is parsed
differently depending on whether it's inside a template or not. This is OK:

template <typename> struct x;
struct z { int x; };
bool operator<(const z& l, const z& r) { return l.x < r.x; }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
paolo dot carlini at oracle dot com
2009-03-09 16:19:29 UTC
Permalink
------- Comment #11 from paolo dot carlini at oracle dot com 2009-03-09 16:19 -------
Better... ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
paolo dot carlini at oracle dot com
2009-03-09 16:24:52 UTC
Permalink
------- Comment #12 from paolo dot carlini at oracle dot com 2009-03-09 16:24 -------
Seriously, thanks Jonathan for the reduced C++ snippet. Really, this way of
seeing the issue makes much more sense to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
pinskia at gcc dot gnu dot org
2009-03-09 17:42:37 UTC
Permalink
------- Comment #13 from pinskia at gcc dot gnu dot org 2009-03-09 17:42 -------
This is related to PR 11814 or is the same bug. I thought there was an exact
duplicate of this parsing issue but I cannot find it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
jwakely dot gcc at gmail dot com
2009-03-09 18:13:47 UTC
Permalink
------- Comment #14 from jwakely dot gcc at gmail dot com 2009-03-09 18:13 -------
aha, on PR 11814 you mention PR 20308 which is the same.

Thanks, Andrew!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
pinskia at gcc dot gnu dot org
2009-03-09 18:16:10 UTC
Permalink
------- Comment #15 from pinskia at gcc dot gnu dot org 2009-03-09 18:16 -------


*** This bug has been marked as a duplicate of 10200 ***
--
pinskia at gcc dot gnu dot org changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
Loading...