<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 7, 2015 at 5:24 PM, Craig Rodrigues via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.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 class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Wed, Oct 7, 2015 at 1:23 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</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 class="gmail_extra"><div class="gmail_quote"><div><div>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></div><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? </div></div></div></div></blockquote><div><br></div></div></div><div>There was no note to indicate why GCC thought that this pure virtual function is used.<br></div><div>The only thing I could think of was maybe there was something in the llvm implementation of<br></div><div>std::function that caused this to happen.<br></div><span class=""><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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><br></div></div></div></blockquote><div><br></div></span><div>I added -fpermissive to the command-line, and the compile and link succeeded.<br><br></div><div>If this looks like a GCC bug, I can submit something to them.</div></div></div></div></blockquote><div><br></div><div>Yes, this seems likely to be a GCC bug. </div></div></div></div>