Can someone confirm whether the following is a known clang bug? I am having a lot of trouble compiling some old legacy code due to this error. I know "using namespace" is horrible but that doesn't make it illegal (g++ accepts this). The fix is easy but there are just too many instances of this in the legacy code. The following is not from the code I am trying to compile but is derived from an example in the C++11 standard (7.3.4 note 6) foo.cpp: namespace A { extern "C" int g(); extern "C++" int h(); } namespace B { extern "C" int g(); extern "C++" int h(int); } using namespace A; using namespace B; void f() { g(); // okay: name g refers to the same entity h(); // okay: overload resolution selects A::h } foo.cpp:12:5: error: call to 'g' is ambiguous g(); // okay: name g refers to the same entity ^ foo.cpp:2:20: note: candidate function extern "C" int g(); ^ foo.cpp:6:20: note: candidate function extern "C" int g(); ^ 1 error generated. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130919/c7a17be3/attachment.html>
On Thu, Sep 19, 2013 at 11:50:52PM +0000, Riyaz Puthiyapurayil wrote:> Can someone confirm whether the following is a known clang bug?I don't think it is a clang bug. If you really want to force both instances of g to refer to the same function, use asm("g") for one of them. "g++ accepts it" is not a very good measurement for whether something is legal or sensible. Joerg
On Thu, Sep 19, 2013 at 11:50:52PM +0000, Riyaz Puthiyapurayil wrote:> Can someone confirm whether the following is a known clang bug? I am having a lot of trouble compiling some old legacy code due to this error. I know "using namespace" is horrible but that doesn't make it illegal (g++ accepts this). The fix is easy but there are just too many instances of this in the legacy code. The following is not from the code I am trying to compile but is derived from an example in the C++11 standard (7.3.4 note 6) > > foo.cpp: > namespace A { > extern "C" int g(); > extern "C++" int h(); > } > namespace B { > extern "C" int g(); > extern "C++" int h(int); > } > using namespace A; > using namespace B; > void f() { > g(); // okay: name g refers to the same entity > h(); // okay: overload resolution selects A::h > } > > foo.cpp:12:5: error: call to 'g' is ambiguous > g(); // okay: name g refers to the same entity > ^ > foo.cpp:2:20: note: candidate function > extern "C" int g(); > ^ > foo.cpp:6:20: note: candidate function > extern "C" int g(); > ^ > 1 error generated.--- end quoted text --- Hi Riyaz, Based on the example in the C++11 standard at 7.3.4 note 6, which you have literally cut and pasted as your example, it has to be a bug for c++11. The standard asserts "okay: name g refers to the same entity". It's valid code. enjoy, Karen -- Karen Shaeffer Be aware: If you see an obstacle in your path, Neuralscape Services that obstacle is your path. Zen proverb
On 19 September 2013 16:50, Riyaz Puthiyapurayil < Riyaz.Puthiyapurayil at synopsys.com> wrote:> Can someone confirm whether the following is a known clang bug? >Yes, this was just fixed, literally minutes ago in r191064. Nick> I am having a lot of trouble compiling some old legacy code due to this > error. I know “using namespace” is horrible but that doesn’t make it > illegal (g++ accepts this). The fix is easy but there are just too many > instances of this in the legacy code. The following is not from the code I > am trying to compile but is derived from an example in the C++11 standard > (7.3.4 note 6)**** > > ** ** > > *foo.cpp:* > > namespace A {**** > > extern "C" int g();**** > > extern "C++" int h();**** > > }**** > > namespace B {**** > > extern "C" int g();**** > > extern "C++" int h(int);**** > > }**** > > using namespace A;**** > > using namespace B;**** > > void f() {**** > > g(); // okay: name g refers to the same entity**** > > h(); // okay: overload resolution selects A::h**** > > }**** > > ** ** > > foo.cpp:12:5: error: call to 'g' is ambiguous**** > > g(); // okay: name g refers to the same entity**** > > ^**** > > foo.cpp:2:20: note: candidate function**** > > extern "C" int g();**** > > ^**** > > foo.cpp:6:20: note: candidate function**** > > extern "C" int g();**** > > ^**** > > 1 error generated.**** > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130919/079d3271/attachment.html>
Seemingly Similar Threads
- llvm::PointerIntPair -- is this by design or a bug?
- llvm::PointerIntPair -- is this by design or a bug?
- llvm::PointerIntPair -- is this by design or a bug?
- llvm::PointerIntPair -- is this by design or a bug?
- llvm::PointerIntPair -- is this by design or a bug?