Bug 15272 - lookup, dependent base
Summary: lookup, dependent base
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.4.1
: P3 normal
Target Milestone: 8.0
Assignee: Nathan Sidwell
Keywords: accepts-invalid, rejects-valid
: 30144 39541 (view as bug list)
Depends on: 2922
Blocks: c++-lookup, c++-name-lookup 43282
  Show dependency treegraph
Reported: 2004-05-03 22:29 UTC by Mikael Kilpeläinen
Modified: 2022-02-01 19:06 UTC (History)
12 users (show)

See Also:
Known to work:
Known to fail: 4.5.3, 4.8.3, 4.9.3, 5.3.0, 6.3.0, 7.0
Last reconfirmed: 2016-03-14 00:00:00


Note You need to log in before you can comment on or make changes to this bug.
Description Mikael Kilpeläinen 2004-05-03 22:29:03 UTC
Following code:

struct X
    void f();

struct Y
    void f();

template <typename Base>
struct A : Base, X {
  virtual void foo()

int main()
    A<Y> t;

gives error message:
j_test.cpp: In member function `void A<Base>::foo() [with Base = Y]':
j_test.cpp:21:   instantiated from here
j_test.cpp:16: error: request for member `f' is ambiguous
j_test.cpp:4: error: candidates are: void X::f()
j_test.cpp:9: error:                 void Y::f() = Y]':

Even though the dependent base should not be considered.
This seems to happen only when foo is virtual and f is found from 
non-dependent base.

Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.1/specs
Configured with: ../gcc/configure --enable-languages=c++,c,f77 
Thread model: posix
gcc version 3.4.1 20040501 (prerelease)
Comment 1 Andrew Pinski 2004-05-03 22:57:28 UTC
I think this is a dup of bug 5660.
Comment 2 Wolfgang Bangerth 2004-05-04 02:07:35 UTC
BTW, even though the last line of the error message in the original report 
seems mangled, this must have been a copy-pasto on behalf of the reporter, 
since I can't reproduce that part. 
Comment 3 Mikael Kilpeläinen 2004-05-04 11:37:15 UTC
Yes, the error message was my fault.. had some problems pasting and pasted it 
twice, seems i was not careful enough to correct it.
Comment 4 Andrew Pinski 2004-08-03 01:47:17 UTC
And this looks related to PR 2922 also.
Comment 5 Andrew Pinski 2006-12-11 08:09:48 UTC
*** Bug 30144 has been marked as a duplicate of this bug. ***
Comment 6 Andrew Pinski 2009-04-16 20:38:28 UTC
*** Bug 39541 has been marked as a duplicate of this bug. ***
Comment 7 Wolfgang Bangerth 2011-10-09 13:36:06 UTC
Still happens with gcc4.5.1.
Comment 8 Petr Tesarik 2013-01-22 07:54:28 UTC
Still present in 4.7.1:

tesarik@azariah:~/src/research/c++> g++ -Wall -c -o pr15272.o pr15272.cc 
pr15272.cc: In instantiation of ‘void A<Base>::foo() [with Base = Y]’:
pr15272.cc:22:1:   required from here
pr15272.cc:15:5: error: request for member ‘f’ is ambiguous
pr15272.cc:3:10: error: candidates are: void X::f()
pr15272.cc:8:10: error:                 void Y::f()

tesarik@azariah:~/src/research/c++> g++ -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.7 --enable-ssp --disable-libssp --disable-libitm --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --program-suffix=-4.7 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=i586-suse-linux
Thread model: posix
gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux)
Comment 9 Jonathan Wakely 2013-04-16 21:08:40 UTC
Jason, we apparently still do lookup in dependent bases inside virtual functions.
Comment 10 Paolo Carlini 2013-05-19 20:33:42 UTC
It seems that when in instantiate_class_template_1 the base classes are tsubst-ed the information about BINFO_DEPENDENT_BASE_P gets lost.
Comment 11 Jonathan Wakely 2014-11-24 23:45:36 UTC
Paolo, did you manage to make any progress on this?
Comment 12 Paolo Carlini 2014-11-25 08:46:54 UTC
Nope, sorry, I told Jason a few days ago.
Comment 13 Martin Sebor 2016-03-15 03:29:34 UTC
Reconfirming as still present in 6.0 (and all prior versions):

$ cat v.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc -B/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -Wextra -Wpedantic -xc++ v.c
struct X { void f (); };
struct Y { void f (); };

template <class T>
struct A: T, X {
  void foo () {
    f ();

template struct A<Y>;
v.c: In instantiation of ‘void A<T>::foo() [with T = Y]’:
v.c:11:17:   required from here
v.c:7:5: error: request for member ‘f’ is ambiguous
     f ();
v.c:1:17: note: candidates are: void X::f()
 struct X { void f (); };
v.c:2:17: note:                 void Y::f()
 struct Y { void f (); };
Comment 14 Martin Sebor 2017-01-13 04:21:30 UTC
No change in 7.0.  Lowering Importance to P3.
Comment 15 Jason Merrill 2017-06-13 20:47:23 UTC
Nathan, do you want to fix this as part of your lookup overhaul?  The problem is that tsubst_baselink does a new lookup rather than preserve the old lookup set.  It would also be good to add a warning for the case when that makes a difference.
Comment 16 Nathan Sidwell 2017-06-14 11:15:08 UTC
sure thing
Comment 17 Nathan Sidwell 2017-12-13 12:41:17 UTC
Author: nathan
Date: Wed Dec 13 12:40:45 2017
New Revision: 255605

URL: https://gcc.gnu.org/viewcvs?rev=255605&root=gcc&view=rev
[PR C++/15272] lookups with ambiguating dependent base

	PR c++/15272
	* pt.c (tsubst_baselink): Don't repeat the lookup for
	non-dependent baselinks.

	PR c++/15272
	* g++.dg/template/pr71826.C: Adjust for 15272 fix.

Comment 18 Nathan Sidwell 2017-12-13 12:41:51 UTC
Fixed r255605.