<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 7, 2015 at 4:47 AM, Craig Rodrigues <span dir="ltr"><<a href="mailto:rodrigc@freebsd.org" target="_blank">rodrigc@freebsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi,<br><br></div>I recently tried to compile clang 3.7.0 with gcc 4.9<br></div>under FreeBSD. I reproduced the problem with gcc 5.0.<br><br></div>The full build error is here:<br><a href="https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/617/console" target="_blank">https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/617/console</a><br><br></div>The error of interest is:<br><br></div><br><pre>--- Module.o ---<br>/usr/local/bin/x86_64-portbld-freebsd10.1-g++<br>-isystem<br>/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include<br>-L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib<br>--sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp<br>-B/usr/local/x86_64-freebsd/bin/<br>-I/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1<br>-std=gnu++11<br>-L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/../lib/libc++<br>--sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp<br>-B/usr/local/x86_64-freebsd/bin/ -O2 -pipe<br>-I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/include<br>-I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include<br>-I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic<br>-I.<br>-I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/../../lib/clang/include<br>-DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS<br>-D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT<br>-DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing<br>-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\"<br>-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\"<br>-fstack-protector-strong -std=c++11 -fno-exceptions -fno-rtti -c<br>/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Module.cpp<br>-o Module.o<br>In file included from <br>/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/SourceLocation.h:22:0,<br> from <br> /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/Module.h:18,<br> from<br> /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Module.cpp:15:<br>/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1/functional:1322:17:<br>error: '_Rp std::__1::__function::__base<_Rp(_ArgTypes<br>...)>::operator()(_ArgTypes&& ...) [with _Rp = void; _ArgTypes =<br>{clang::VisibleModuleSet::setVisible(clang::Module*, clang::SourceLocation,<br>clang::VisibleModuleSet::VisibleCallback,<br>clang::VisibleModuleSet::ConflictCallback)::Visiting}]', declared<br>using local type 'clang::VisibleModuleSet::setVisible(clang::Module*,<br>clang::SourceLocation, clang::VisibleModuleSet::VisibleCallback,<br>clang::VisibleModuleSet::ConflictCallback)::Visiting', is used but<br>never defined [-fpermissive]<br> virtual _Rp operator()(_ArgTypes&& ...) = 0;<br> ^</pre></div></blockquote><div>This looks like a GCC bug. I'm not sure why it imagines that this pure virtual function is used; did it produce any note indicating that? In any case, given that the link succeeds if you move the struct definition outside of the function (so it's not able to detect the problem during compilation any more), this function is very likely not actually used, and thus the diagnostic here is wrong.</div><div><br></div><div>One more thing that's worth checking: if you build with -fpermissive, does the compile and link succeed?</div><div><br></div><div>This setup (using gcc + libc++ to compile clang) is likely not something we tested as part of our release validation.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><pre>*** [Module.o] Error code 1<br><br><br></pre><pre>I investigated this problem, and found that I could<br>completely eliminate the compilation failure<br>by moving "struct Visiting" outside of VisibleModuleSet::setVisible()<br></pre><pre>with this patch:<br></pre><br><pre><br>Index: tools/clang/lib/Basic/Module.cpp<br>===================================================================<br>--- tools/clang/lib/Basic/Module.cpp (revision 288962)<br>+++ tools/clang/lib/Basic/Module.cpp (working copy)<br>@@ -480,6 +480,12 @@<br> print(llvm::errs());<br> }<br> <br>+struct Visiting {<br>+ Module *M;<br>+ Visiting *ExportedBy;<br>+};<br>+<br>+<br> void VisibleModuleSet::setVisible(Module *M, SourceLocation Loc,<br> VisibleCallback Vis, ConflictCallback Cb) {<br> if (isVisible(M))<br>@@ -487,11 +493,6 @@<br> <br> ++Generation;<br> <br>- struct Visiting {<br>- Module *M;<br>- Visiting *ExportedBy;<br>- };<br>-<br> std::function<void(Visiting)> VisitModule = [&](Visiting V) {<br> // Modules that aren't available cannot be made visible.<br> if (!V.M->isAvailable())<br><br><br> <br><br></pre><pre>Is this a valid fix, or is there a bug in gcc that<br></pre><pre>needs to be reported to them?<br><br></pre><pre>I don't know C++ enough to know.<br><br></pre><pre>Thanks.<br></pre><pre><br>--<br></pre></div>
</blockquote></div><br></div></div>