[LLVMbugs] [Bug 9359] New: Clang thinks unambiguous member lookup is ambiguous (when dependent type is involved)
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Tue Mar 1 12:42:46 PST 2011
http://llvm.org/bugs/show_bug.cgi?id=9359
Summary: Clang thinks unambiguous member lookup is ambiguous
(when dependent type is involved)
Product: clang
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P
Component: Frontend
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: zhanyong.wan at gmail.com
CC: llvmbugs at cs.uiuc.edu
Build clang using configure + make.
$ cat t.cpp
namespace PR5820 {
struct Base {};
struct D1 : public Base {};
struct D2 : public Base {};
struct Derived : public D1, public D2 {
void Inner() {
}
};
}
template<typename T>
struct BaseT {
int Member;
};
template<typename T> struct Derived1T : BaseT<T> { };
template<typename T> struct Derived2T : BaseT<T> { };
template<typename T>
struct DerivedT : public Derived1T<T>, public Derived2T<T> {
void Inner();
};
template<typename T>
void Test(DerivedT<T> d) {
d.template Derived2T<T>::Member = 17;
}
template void Test(DerivedT<int>);
$ Debug+Asserts/bin/clang -cc1 -fsyntax-only t.cpp
t.cpp:27:28: error: non-static member 'Member' found in multiple base-class
subobjects of type 'BaseT<int>':
struct DerivedT<int> -> Derived1T<int> -> BaseT<int>
struct DerivedT<int> -> Derived2T<int> -> BaseT<int>
d.template Derived2T<T>::Member = 17;
^
t.cpp:30:15: note: in instantiation of function template specialization
'Test<int>' requested here
template void Test(DerivedT<int>);
^
t.cpp:14:7: note: member found by ambiguous name lookup
int Member;
^
1 error generated.
Note that this bug is strange in that it's sensitive to the seemingly unrelated
code in the input file (e.g. the code in namespace PR5820). I even found that
it's sensitive to comments.
>From this, I suspect some kind of memory corruption. Unfortunately, running it
under valgrind doesn't reveal much: valgrind complains about some conditional
jump depending on uninitialized values when comparing a default-initialized
SourceLocation (with ID == 0) with another SourceLocation, but I believe the
ctor of SourceLocation has properly initialized the ID field in this case, so
it looks like a valgrind false positive to me.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the llvm-bugs
mailing list