Bug 2922 - [DR 197] two-stage lookup for unqualified function calls with type-dependent arguments
Summary: [DR 197] two-stage lookup for unqualified function calls with type-dependent ...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.0
: P3 normal
Target Milestone: 4.1.0
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
: 11296 13812 23724 24795 25278 25495 26079 26311 28631 29229 30059 30232 32440 (view as bug list)
Depends on:
Blocks: 5660 15272 24948
  Show dependency treegraph
 
Reported: 2001-05-24 02:06 UTC by Jens Maurer
Modified: 2014-02-16 13:15 UTC (History)
15 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 2.95.3 3.0 3.1 3.3 3.4.0 4.0.0
Last reconfirmed: 2004-07-29 04:45:24


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jens Maurer 2001-05-24 02:06:01 UTC
The program below is supposed to output
f(char)
f(int)
f(char)
f(char)

according to 14.6p9.

gcc (all of 2.95.3, pre-3.0, and 3.1 20010518) outputs
f(int)
f(int)
f(int)
f(char)

Release:
gcc version 3.0 20010521 (prerelease)

Environment:
Linux 2.2.4 with glibc 2.2.3

How-To-Repeat:
// example (slightly adapted) from 14.6p9

#include <iostream>

void f(char)
{
  std::cout << "f(char)" << std::endl;
}

template<class T>
void g(T t)
{
  f(1);        // not dependent
  f(t);        // dependent
}

void f(int)
{
  std::cout << "f(int)" << std::endl;
}

int main()
{
  g(2);    // f(char) followed by f(int)
  g('a');  // two f(char)
}
Comment 1 Martin Sebor 2001-05-24 15:47:15 UTC
From: Martin Sebor <sebor@roguewave.com>
To: Jens.Maurer@gmx.net
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/2922: two-phase name lookup not working
Date: Thu, 24 May 2001 15:47:15 -0600

 Jens.Maurer@gmx.net wrote:
 > 
 > >Number:         2922
 > >Category:       c++
 > >Synopsis:       two-phase name lookup not working
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    unassigned
 > >State:          open
 > >Class:          wrong-code
 > >Submitter-Id:   net
 > >Arrival-Date:   Thu May 24 02:06:01 PDT 2001
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Jens Maurer
 > >Release:        gcc version 3.0 20010521 (prerelease)
 > >Organization:
 > >Environment:
 > Linux 2.2.4 with glibc 2.2.3
 > >Description:
 > The program below is supposed to output
 > f(char)
 > f(int)
 > f(char)
 > f(char)
 > 
 > according to 14.6p9.
 
 But take a look at issue 197 at
 
     http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#197
 
 Not that the issue makes gcc's behavior correct (f(char) should 
 apparently be called in all 4 cases).
 
 Regards
 Martin
 
 > 
 > gcc (all of 2.95.3, pre-3.0, and 3.1 20010518) outputs
 > f(int)
 > f(int)
 > f(int)
 > f(char)
 > >How-To-Repeat:
 > 
 > // example (slightly adapted) from 14.6p9
 > 
 > #include <iostream>
 > 
 > void f(char)
 > {
 >   std::cout << "f(char)" << std::endl;
 > }
 > 
 > template<class T>
 > void g(T t)
 > {
 >   f(1);        // not dependent
 >   f(t);        // dependent
 > }
 > 
 > void f(int)
 > {
 >   std::cout << "f(int)" << std::endl;
 > }
 > 
 > int main()
 > {
 >   g(2);    // f(char) followed by f(int)
 >   g('a');  // two f(char)
 > }
 > 
 > >Fix:
 > 
 > >Release-Note:
 > >Audit-Trail:
 > >Unformatted:

Comment 2 Jens Maurer 2001-05-25 00:44:56 UTC
From: Jens Maurer <Jens.Maurer@gmx.net>
To: Martin Sebor <sebor@roguewave.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/2922: two-phase name lookup not working
Date: Fri, 25 May 2001 00:44:56 +0200

 Martin Sebor wrote:
 > Jens.Maurer@gmx.net wrote:
 > > The program below is supposed to output
 > > f(char)
 > > f(int)
 > > f(char)
 > > f(char)
 
 You're correct, core issue 197 says it should output "f(char)" in all
 cases.
 
 Jens Maurer
 
 
Comment 3 Nathan Sidwell 2001-05-27 09:28:04 UTC
State-Changed-From-To: open->suspended
State-Changed-Why: we know. will be dealt with in the parser rewrite.
Comment 4 Nathan Sidwell 2001-05-27 16:28:04 UTC
From: nathan@gcc.gnu.org
To: Jens.Maurer@gmx.net, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/2922
Date: 27 May 2001 16:28:04 -0000

 Synopsis: two-phase name lookup not working
 
 State-Changed-From-To: open->suspended
 State-Changed-By: nathan
 State-Changed-When: Sun May 27 09:28:04 2001
 State-Changed-Why:
     we know. will be dealt with in the parser rewrite.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2922&database=gcc
Comment 5 Neil Booth 2003-01-02 11:13:02 UTC
State-Changed-From-To: suspended->analyzed
State-Changed-Why: New parser gives:
    
    f(char)
    f(int)
    f(char)
    f(char)
    
    which is better but we still have one f(int), which I understand is wrong according to the DR referenced above.
Comment 6 Giovanni Bajo 2004-04-29 01:52:21 UTC
I'm testing a patch for this.
Comment 7 Giovanni Bajo 2004-04-29 12:15:38 UTC
For reference, the problem is that for unqualified function calls with type-
dependent arguments, we should:

1) do a normal unqualified lookup at parsing time, and preserve the result, 
which is an overload set. (will be done in cp_parser_postfix_expression, case 
CPP_OPEN_PAREN).

2) perform a koenig lookup at instantiation time, merging its result with the 
previous set. (done in tsusbt_copy_and_build, case CALL_EXPR).

3) do overload resolution, etc.

Instead, what happens currently is that both kind of lookups are deferred till 
instantiation time. I'm fixing this, but it is not trivial because I'm doing 
cleanups as I go.
Comment 8 Andrew Pinski 2004-07-29 05:07:05 UTC
*** Bug 13812 has been marked as a duplicate of this bug. ***
Comment 9 Andrew Pinski 2004-07-29 05:16:35 UTC
*** Bug 11296 has been marked as a duplicate of this bug. ***
Comment 10 Giovanni Bajo 2004-07-31 00:21:42 UTC
Not working on this anymore. Andrew closed PR 11296 as a dup of this, but I'm 
not 100% sure. This is the testcase, so that it can be tested and added to the 
testsuite:

-----------------------------------------------------
namespace N {
template <class T> T foo (T) { return T (); }
template <class T> T bar (T t) { return foo (t); }
}

struct S { S (int i = 0): i_ (i) { } int i_; };

namespace N {
/* template <> */ S foo (S) { return S (1); }
}

int main ()
{
     return 1 == N::bar (S ()).i_;
} 
-----------------------------------------------------
(should return 0, but returns 1).
Comment 11 Maxim Egorushkin 2005-04-23 10:55:00 UTC
(In reply to comment #10)
> Not working on this anymore. Andrew closed PR 11296 as a dup of this, 
but I'm 
> not 100% sure. This is the testcase, so that it can be tested and added to 
the 
> testsuite:
> 
> -----------------------------------------------------
> namespace N {
> template <class T> T foo (T) { return T (); }
> template <class T> T bar (T t) { return foo (t); }
> }
> 
> struct S { S (int i = 0): i_ (i) { } int i_; };
> 
> namespace N {
> /* template <> */ S foo (S) { return S (1); }
> }
> 
> int main ()
> {
>      return 1 == N::bar (S ()).i_;
> } 
> -----------------------------------------------------
> (should return 0, but returns 1).
> 

Here is another test case that does compile time two-phase name check. 
Comeau online 4.3.3 BETA August 4, 2003 passes it, gcc 3.4.3 fails. For 
discussion please see http://groups-beta.google.com/group/comp.lang.c++.
moderated/msg/c7227abb97603d15?hl=en

namespace tpl_ {
 
template<class T>
char test(T);
 
template<class T>
struct check
{
    static T const t;
    enum { value = 1 == sizeof(test(t)) };
};
 
double test(int);
 
}
 
bool const two_phase_lookup_supported = tpl_::check<int>::value;
 
int compile_time_assert[two_phase_lookup_supported ? 1 : -1];
Comment 12 CVS Commits 2005-07-21 03:53:12 UTC
Subject: Bug 2922

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	dgregor@gcc.gnu.org	2005-07-21 03:53:08

Modified files:
	gcc/cp         : ChangeLog name-lookup.c semantics.c 

Log message:
	2005-07-20  Douglas Gregor <doug.gregor@gmail.com>
	
	PR c++/2922
	* semantics.c (perform_koenig_lookup): For dependent calls, just
	return the set of functions we've found so far. Later, it will be
	augmented by those found through argument-dependent lookup.
	* name-lookup.c (lookup_arg_dependent):

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4826&r2=1.4827
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcc&r1=1.129&r2=1.130
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcc&r1=1.481&r2=1.482

Comment 13 CVS Commits 2005-07-21 03:56:50 UTC
Subject: Bug 2922

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	dgregor@gcc.gnu.org	2005-07-21 03:56:46

Modified files:
	gcc/testsuite  : ChangeLog 
	gcc/testsuite/g++.dg/template: call3.C crash37.C ptrmem4.C 
	gcc/testsuite/g++.old-deja/g++.other: pmf3.C 
Added files:
	gcc/testsuite/g++.dg/lookup: two-stage2.C two-stage3.C 
	                             two-stage4.C 

Log message:
	2005-07-20  Douglas Gregor <doug.gregor@gmail.com>
	
	PR c++/2922
	* g++.dg/lookup/two-stage2.C: New.
	* g++.dg/lookup/two-stage3.C: New.
	* g++.dg/lookup/two-stage4.C: New. Illustrates how we have not yet
	fixed two-stage name lookup for operators.
	* g++.dg/template/call3.C: Compiler now produces an appropriate
	error message.
	* g++.dg/template/crash37.C: Compiler now describes bla() on line
	14 as a candidate.
	* g++.dg/template/ptrmem4.C: Compiler produces different error
	message.
	* g++.old-deja/g++.other/pmf3.C: Compiler now describes
	connect_to_method as a candidate.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5789&r2=1.5790
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/two-stage2.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/two-stage3.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/two-stage4.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/call3.C.diff?cvsroot=gcc&r1=1.1&r2=1.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/crash37.C.diff?cvsroot=gcc&r1=1.1&r2=1.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/ptrmem4.C.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.other/pmf3.C.diff?cvsroot=gcc&r1=1.3&r2=1.4

Comment 14 Andrew Pinski 2005-07-21 04:51:18 UTC
Fixed.
Comment 15 CVS Commits 2005-07-21 14:19:02 UTC
Subject: Bug 2922

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	dgregor@gcc.gnu.org	2005-07-21 14:18:54

Modified files:
	gcc/cp         : ChangeLog 

Log message:
	Completed this ChangeLog entry:
	
	2005-07-20  Douglas Gregor <doug.gregor@gmail.com>
	
	PR c++/2922
	* semantics.c (perform_koenig_lookup): For dependent calls, just
	return the set of functions we've found so far. Later, it will be
	augmented by those found through argument-dependent lookup.
	* name-lookup.c (lookup_arg_dependent): Implement DR 164 by removing
	the optimization that skips namespaces where the functions were
	originally found.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4828&r2=1.4829

Comment 16 CVS Commits 2005-07-21 15:15:06 UTC
Subject: Bug 2922

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	dgregor@gcc.gnu.org	2005-07-21 15:14:59

Modified files:
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/lookup: two-stage5.C 

Log message:
	2005-07-21  Douglas Gregor  <doug.gregor@gmail.com>
	
	PR c++/2922
	* g++.dg/lookup/two-stage5.C: New test from bug comments.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5796&r2=1.5797
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/two-stage5.C.diff?cvsroot=gcc&r1=NONE&r2=1.1

Comment 17 Martin Sebor 2005-07-21 20:33:13 UTC
(In reply to comment #13)
...
> 	* g++.dg/lookup/two-stage2.C: New.

FWIW, the following comment in this patch is wrong:

+  g(2);    // f(char) followed by f(int)
                       ^^^^^^^^^^^^^^^^^^
The call to g<int>(2) should cause 2 calls to f(char).
Comment 18 Andrew Pinski 2005-09-04 18:15:22 UTC
*** Bug 23724 has been marked as a duplicate of this bug. ***
Comment 19 Andrew Pinski 2005-12-06 19:27:29 UTC
*** Bug 25278 has been marked as a duplicate of this bug. ***
Comment 20 Andrew Pinski 2005-12-19 16:44:25 UTC
*** Bug 25495 has been marked as a duplicate of this bug. ***
Comment 21 Andrew Pinski 2005-12-25 02:14:31 UTC
*** Bug 24795 has been marked as a duplicate of this bug. ***
Comment 22 Andrew Pinski 2006-02-02 18:47:26 UTC
*** Bug 26079 has been marked as a duplicate of this bug. ***
Comment 23 Andrew Pinski 2006-02-16 00:33:11 UTC
*** Bug 26311 has been marked as a duplicate of this bug. ***
Comment 24 Andrew Pinski 2006-08-07 14:50:18 UTC
*** Bug 28631 has been marked as a duplicate of this bug. ***
Comment 25 Andrew Pinski 2006-09-25 22:54:35 UTC
*** Bug 29229 has been marked as a duplicate of this bug. ***
Comment 26 Andrew Pinski 2006-12-03 17:34:17 UTC
*** Bug 30059 has been marked as a duplicate of this bug. ***
Comment 27 Andrew Pinski 2006-12-16 18:34:33 UTC
*** Bug 30232 has been marked as a duplicate of this bug. ***
Comment 28 Andrew Pinski 2007-06-20 21:17:37 UTC
*** Bug 32440 has been marked as a duplicate of this bug. ***
Comment 29 Jackie Rosen 2014-02-16 13:15:50 UTC Comment hidden (spam)