Bug 15272 - lookup, dependent base
Summary: lookup, dependent base
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.4.1
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: accepts-invalid, rejects-valid
: 30144 39541 (view as bug list)
Depends on: 2922
Blocks: 12944 43282
  Show dependency treegraph
 
Reported: 2004-05-03 22:29 UTC by Mikael Kilpeläinen
Modified: 2016-03-15 03:29 UTC (History)
9 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.5.3, 4.8.3, 4.9.3, 5.3.0, 6.0
Last reconfirmed: 2016-03-14 00:00:00


Attachments

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()
  {
    f();
  }
};

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.

Using:
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.1/specs
Configured with: ../gcc/configure --enable-languages=c++,c,f77 
--enable-threads=posix
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
Confirmed.  
 
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. 
 
W. 
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.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-suse-linux/4.7/lto-wrapper
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 (); };
                 ^