public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/43135]  New: Possible bug in name resolution during template instantiation
@ 2010-02-22  2:50 uwe at netbsd dot org
  2010-02-22  2:52 ` [Bug c++/43135] " uwe at netbsd dot org
                   ` (5 more replies)
  0 siblings, 6 replies; 7+ messages in thread
From: uwe at netbsd dot org @ 2010-02-22  2:50 UTC (permalink / raw)
  To: gcc-bugs

I'm reporting this against my system compiler (4.1.2 on NetBSD/macppc), but I
can reproduce it using all versions from 3.4 (when two-stage name lookup was
introduced) to 4.4 - which I was able to test on a linux/amd64 machine with a
large collection of compilers installed.

The following code (minimized test case) is rejected with

$ g++ -S bug_p.cpp
bug_p.cpp: In member function 'bool Node::FooOpNode<_Op>::f() [with _Op = X]':
bug_p.cpp:63:   instantiated from here
bug_p.cpp:54: error: cannot call member function 'bool Node::test(int)' without
object

If offending call to "test" is qualified as "Node::test", compiler accepts it
happily.

Yes, I read http://gcc.gnu.org/onlinedocs/gcc/Name-lookup.html#Name-lookup


----8<--------8<----
struct X {
    int i;
};


class Node {
public:
    template <typename _Op> class OpNode;
    template <typename _Op> class FooOpNode;
    class FooNode;

    Node() {}
    virtual ~Node() {}

    bool test(int i) { return true; }

    virtual bool f() { return true; }
};


template <typename _Op>
class Node::OpNode
  : public Node
{
  public:
    typedef OpNode<_Op> OpNodeBase;

    _Op &op;

    OpNode(_Op &op) : Node(), op(op) {}

    // "test" call ok here
    virtual bool f() { return !test(op.i); }
};


template <typename _Op>
class Node::FooOpNode
  : public OpNode<_Op>
{
  public:
    typedef OpNode<_Op> OpNodeBase;
    using OpNodeBase::op;

    typedef FooOpNode<_Op> FooOpNodeBase;

    FooOpNode(_Op &op) : OpNodeBase(op) {}

    // "test" call marked as error here
    // unless qualified as Node::test()
    virtual bool f() {
        return
            // Node::
            test(op.i);
    }
};


class Node::FooNode
  : public FooOpNode<X>
{
  public:
    FooNode(X &x) : FooOpNodeBase(x) {}
};
----8<--------8<----


-- 
           Summary: Possible bug in name resolution during template
                    instantiation
           Product: gcc
           Version: 4.1.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: uwe at netbsd dot org
 GCC build triplet: powerpc--netbsd
  GCC host triplet: powerpc--netbsd
GCC target triplet: powerpc--netbsd


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


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

* [Bug c++/43135] Possible bug in name resolution during template instantiation
  2010-02-22  2:50 [Bug c++/43135] New: Possible bug in name resolution during template instantiation uwe at netbsd dot org
@ 2010-02-22  2:52 ` uwe at netbsd dot org
  2010-02-22  3:56 ` bangerth at gmail dot com
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: uwe at netbsd dot org @ 2010-02-22  2:52 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from uwe at netbsd dot org  2010-02-22 02:51 -------
Created an attachment (id=19932)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19932&action=view)
Test case


-- 


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


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

* [Bug c++/43135] Possible bug in name resolution during template instantiation
  2010-02-22  2:50 [Bug c++/43135] New: Possible bug in name resolution during template instantiation uwe at netbsd dot org
  2010-02-22  2:52 ` [Bug c++/43135] " uwe at netbsd dot org
@ 2010-02-22  3:56 ` bangerth at gmail dot com
  2010-02-22  4:08 ` uwe at netbsd dot org
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: bangerth at gmail dot com @ 2010-02-22  3:56 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from bangerth at gmail dot com  2010-02-22 03:56 -------
This is not a bug. Because the base class of Node::OpNode does not
depend on template arguments, the members of the base class are
visible in Node::OpNode::f(). On the other hand, since the base
class of Node::FooOpNode depends on template arguments, the members
of the base class are not visible during parsing and before template
arguments are substituted.

You need to write the call to test as
  this->test(op.i)

W.


-- 

bangerth at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bangerth at gmail dot com
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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


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

* [Bug c++/43135] Possible bug in name resolution during template instantiation
  2010-02-22  2:50 [Bug c++/43135] New: Possible bug in name resolution during template instantiation uwe at netbsd dot org
  2010-02-22  2:52 ` [Bug c++/43135] " uwe at netbsd dot org
  2010-02-22  3:56 ` bangerth at gmail dot com
@ 2010-02-22  4:08 ` uwe at netbsd dot org
  2010-02-22  4:29 ` bangerth at gmail dot com
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: uwe at netbsd dot org @ 2010-02-22  4:08 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #3 from uwe at netbsd dot org  2010-02-22 04:08 -------
(In reply to comment #2)
> This is not a bug. Because the base class of Node::OpNode does not
> depend on template arguments, the members of the base class are
> visible in Node::OpNode::f(). On the other hand, since the base
> class of Node::FooOpNode depends on template arguments, the members
> of the base class are not visible during parsing and before template
> arguments are substituted.

But doesn't this error happens during instantiation as the error message
indicates?  If definition of Node::FooNode is commented out, the templates
themselves are accepted.

Also, if the nested classes are un-nested out of Node, the code compiles w/out
errors too.


-- 


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


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

* [Bug c++/43135] Possible bug in name resolution during template instantiation
  2010-02-22  2:50 [Bug c++/43135] New: Possible bug in name resolution during template instantiation uwe at netbsd dot org
                   ` (2 preceding siblings ...)
  2010-02-22  4:08 ` uwe at netbsd dot org
@ 2010-02-22  4:29 ` bangerth at gmail dot com
  2010-02-22  4:46 ` uwe at netbsd dot org
  2010-02-22  4:48 ` uwe at netbsd dot org
  5 siblings, 0 replies; 7+ messages in thread
From: bangerth at gmail dot com @ 2010-02-22  4:29 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #4 from bangerth at gmail dot com  2010-02-22 04:29 -------
(In reply to comment #3)
> But doesn't this error happens during instantiation as the error message
> indicates?  If definition of Node::FooNode is commented out, the templates
> themselves are accepted.

What I meant to say is this: during parsing, it doesn't see Node::test as
a member of the base class, but it sees it as a member of the enclosing
class in the same way as S::I::f() in
  struct S {
    int i;
    struct I {
      int f() { return i; }
    };
  }
would see S::i -- since they are both members of the same enclosing class S.
I.e., Node::FooOpNode::f() sees Node::test() as a sibling, not a member
of the base class, and so the call is registered as a function call, not
a call of a member function with this as argument.

W.


-- 


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


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

* [Bug c++/43135] Possible bug in name resolution during template instantiation
  2010-02-22  2:50 [Bug c++/43135] New: Possible bug in name resolution during template instantiation uwe at netbsd dot org
                   ` (3 preceding siblings ...)
  2010-02-22  4:29 ` bangerth at gmail dot com
@ 2010-02-22  4:46 ` uwe at netbsd dot org
  2010-02-22  4:48 ` uwe at netbsd dot org
  5 siblings, 0 replies; 7+ messages in thread
From: uwe at netbsd dot org @ 2010-02-22  4:46 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #5 from uwe at netbsd dot org  2010-02-22 04:45 -------
(In reply to comment #4)

> What I meant to say is this: during parsing ...

So do I get this right (knowing nothing about g++ internals) that in the first
phase ("during parsing") the call to "test" is resolved to sibling because it's
a dependent name with a declaration in-scope.  Then during instantiation time
that sibling call is flagged as invalid?

What confuses me is that explictly qualifying the offending call as

  Node::test(op.i)

makes it compile correctly.


-- 


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


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

* [Bug c++/43135] Possible bug in name resolution during template instantiation
  2010-02-22  2:50 [Bug c++/43135] New: Possible bug in name resolution during template instantiation uwe at netbsd dot org
                   ` (4 preceding siblings ...)
  2010-02-22  4:46 ` uwe at netbsd dot org
@ 2010-02-22  4:48 ` uwe at netbsd dot org
  5 siblings, 0 replies; 7+ messages in thread
From: uwe at netbsd dot org @ 2010-02-22  4:48 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #6 from uwe at netbsd dot org  2010-02-22 04:47 -------
(In reply to comment #5)
> What confuses me is that explictly qualifying the offending call as
> 
>   Node::test(op.i)
> 
> makes it compile correctly.

I mean as far as I understand Node::test should resolve to the same sibling, so
your explanation of why the original fails should still be applicable.  Yet it
works.


-- 


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


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

end of thread, other threads:[~2010-02-22  4:48 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-02-22  2:50 [Bug c++/43135] New: Possible bug in name resolution during template instantiation uwe at netbsd dot org
2010-02-22  2:52 ` [Bug c++/43135] " uwe at netbsd dot org
2010-02-22  3:56 ` bangerth at gmail dot com
2010-02-22  4:08 ` uwe at netbsd dot org
2010-02-22  4:29 ` bangerth at gmail dot com
2010-02-22  4:46 ` uwe at netbsd dot org
2010-02-22  4:48 ` uwe at netbsd dot org

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).