Bug 10200 - Weird clash with same names in different scopes
Summary: Weird clash with same names in different scopes
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: monitored, rejects-valid
: 20308 32408 39407 51664 56516 63414 65878 (view as bug list)
Depends on:
Blocks: 12944 20679
  Show dependency treegraph
 
Reported: 2003-03-24 16:56 UTC by sturgill
Modified: 2015-06-23 22:21 UTC (History)
17 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-10-21 21:32:49


Attachments
driver.ii.bz2 (77.50 KB, application/octet-stream)
2003-05-21 15:17 UTC, sturgill
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sturgill 2003-03-24 16:56:00 UTC
Problem parsing the < operator inside a template class with an inner struct containing some anonymous fields.  If I reorder the expression to use > instead, seems to compile just fine.  Older version of the compiler complains about the closing ) on the offending line, but the 3.2 version complains about a ;.

Command Line:
g++ -v -save-temps driver.cpp

Compiler Output:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux --with-system-zlib --enable-__cxa_atexit
Thread model: posix
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
 /usr/lib/gcc-lib/i386-redhat-linux/3.2/cpp0 -lang-c++ -D__GNUG__=3 -D__DEPRECATED -D__EXCEPTIONS -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=0 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix -D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_GNU_SOURCE -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i386__ driver.cpp driver.ii
GNU CPP version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) (cpplib) (i386 Linux/ELF)ignoring nonexistent directory "/usr/i386-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/3.2
 /usr/include/c++/3.2/i386-redhat-linux
 /usr/include/c++/3.2/backward
 /usr/local/include
 /usr/lib/gcc-lib/i386-redhat-linux/3.2/include
 /usr/include
End of search list.
 /usr/lib/gcc-lib/i386-redhat-linux/3.2/cc1plus -fpreprocessed driver.ii -quiet
-dumpbase driver.cpp -version -o driver.s
GNU CPP version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) (cpplib) (i386 Linux/ELF)GNU C++ version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) (i386-redhat-linux)
        compiled by GNU C version 3.2 20020903 (Red Hat Linux 8.0 3.2-7).
In file included from driver.cpp:4:
RangeMap.h: In member function `void RangeMap<T>::insert(const T&,
   RangeMap<T>::Node*&, double*, double*)':
RangeMap.h:72: parse error before `;' token

Release:
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

Environment:
Red Hat 8.0
Comment 1 Wolfgang Bangerth 2003-03-24 17:26:13 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed. A very weird error:
    ------------------
    template<typename> void foo() {}
    
    template <typename T>
    struct X {
        struct { int foo; } node;
    
        bool bar() {
          return (node.foo < 5);
        }
    };
    template struct X<int>;
    --------------------------
    
    Note that template function and member variable have to
    have the same name, to get this from 3.2.3pre and 3.3pre:
    
    g/x> /home/bangerth/bin/gcc-3.2.3-pre/bin/c++ -c x.cc
    x.cc: In member function `bool X<T>::bar()':
    x.cc:8: parse error before `;' token
    
    Present mainline gives
    g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c x.cc
    x.cc: In member function `bool X<T>::bar() [with T = int]':
    x.cc:11:   instantiated from here
    x.cc:8: error: invalid use of `foo()'
    
    This is just as wrong.
    
    W.
Comment 2 Andrew Pinski 2003-06-07 16:43:06 UTC
Still happens on the mainline (20030607).
Comment 3 Andrew Pinski 2003-07-17 00:10:58 UTC
With the small testcase, we now ICE on the mainline (20030716):
pr10200.cc: In member function `bool X<T>::bar() [with T = int]':
pr10200.cc:12:   instantiated from here
pr10200.cc:9: internal compiler error: in lookup_member, at cp/search.c:1219
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Comment 4 Volker Reichelt 2003-08-08 00:07:56 UTC
Maybe related to PR 11814.
Comment 5 Andrew Pinski 2003-08-23 17:05:22 UTC
The ICE is a regression.
Comment 6 Kriang Lerdsuwanakij 2003-11-23 11:02:40 UTC
With my patch to PR12924, the ICE is gone.  We still
get an incorrect error message however.
Comment 7 Kriang Lerdsuwanakij 2003-11-23 11:38:10 UTC
Keywords updated to remove the ICE.  Will look at this issue.
Comment 8 Kriang Lerdsuwanakij 2003-11-23 11:54:18 UTC
It's no longer a regression.
Comment 9 Mark Mitchell 2003-12-17 17:05:27 UTC
Since this is no longer a regression, I've removed the 3.4 target milestone.
Comment 10 Andrew Pinski 2004-08-04 06:12:27 UTC
It is even worse now on the mainline:
pr10200.cc: In member function `bool X<T>::bar()':
pr10200.cc:8: error: missing `>' to terminate the template argument list
pr10200.cc: In member function `bool X<T>::bar() [with T = int]':
pr10200.cc:11:   instantiated from here
pr10200.cc:8: error: `foo' is not a member template function
Comment 11 Kriang Lerdsuwanakij 2004-10-13 14:50:47 UTC
It's parser bug.  Not working on it anymore.
Comment 12 Mark Mitchell 2005-04-05 06:03:01 UTC
This is almost the same as the case discussed in DR 141.

In particular, we must determine whether "node.foo <" is the start of a
template, or not.  [basic.lookup.classref] says that we look in the class of the
object expression, i.e., X<T>::node.  However, that's a dependent type.  So, we
don't actually try to lookup there.  Thus, we then go on to do lookup in the
scope of the containing postfix-expression, which finds the global template
function.  DR 141 suggests that we should not do the second lookup.  However,
this DR is still in the "open" state; the committee has taken no action as of yet.

However, independently of that, [temp.names] says that when the object has a
dependent type (as it does in this case), then the name is a template only if
the template keyword is explicitly used.  So, the compiler is definitely wrong
in this case.
Comment 13 Andrew Pinski 2007-06-19 23:10:48 UTC
*** Bug 32408 has been marked as a duplicate of this bug. ***
Comment 14 Andrew Pinski 2008-09-20 02:56:40 UTC
*** Bug 20308 has been marked as a duplicate of this bug. ***
Comment 15 Andrew Pinski 2009-03-09 18:16:09 UTC
*** Bug 39407 has been marked as a duplicate of this bug. ***
Comment 16 Jay Foad 2011-05-24 09:17:21 UTC
> This is almost the same as the case discussed in DR 141.
> 
> In particular, we must determine whether "node.foo <" is the start of a
> template, or not.  [basic.lookup.classref] says that we look in the class of the
> object expression, i.e., X<T>::node.  However, that's a dependent type.  So, we
> don't actually try to lookup there.  Thus, we then go on to do lookup in the
> scope of the containing postfix-expression, which finds the global template
> function.  DR 141 suggests that we should not do the second lookup.  However,
> this DR is still in the "open" state; the committee has taken no action as of yet.

DR 141 was resolved in CD1:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#141

It seems like we should still do the second lookup.
Comment 17 Wolfgang Bangerth 2011-10-09 13:34:27 UTC
Still happens with gcc 4.5.1.
Comment 18 Manuel López-Ibáñez 2011-10-19 22:29:28 UTC
This still happens in trunk (GCC 4.7 rev 180166).
Comment 19 Andrew Pinski 2011-12-23 18:56:42 UTC
*** Bug 51664 has been marked as a duplicate of this bug. ***
Comment 20 Matt Giuca 2012-05-30 00:05:47 UTC
I think this is the same bug in Clang: http://llvm.org/bugs/show_bug.cgi?id=11856
It was fixed in March: http://llvm.org/viewvc/llvm-project?view=rev&revision=152520
Comment 21 Paolo Carlini 2012-08-23 10:14:16 UTC
Jason, noticed this very, very old issue which however clang too fixed only this March. Wondered if you have tips, believe it would be easy to fix in our front-end too, what else...
Comment 22 Paolo Carlini 2013-03-04 10:09:01 UTC
*** Bug 56516 has been marked as a duplicate of this bug. ***
Comment 23 Paolo Carlini 2013-10-10 20:42:02 UTC
Mine.
Comment 24 Andrew Pinski 2014-09-30 12:22:17 UTC
*** Bug 63414 has been marked as a duplicate of this bug. ***
Comment 25 Paolo Carlini 2015-06-23 15:03:03 UTC
*** Bug 65878 has been marked as a duplicate of this bug. ***
Comment 26 Colin MacKenzie 2015-06-23 22:19:29 UTC
Had this one today. Strange that it compiles fine in 4.4.6 but not in 4.8.2.

error: parse error in template argument list
Ex: assert(block.begin < block.end);

works when I parenthesize the block.begin
Ex. assert( (block.begin) < block.end);
Comment 27 Paolo Carlini 2015-06-23 22:21:28 UTC
This should be fixed ASAP, but I'm not actively working on it at the moment.