[cfe-dev] Problems compiling clang 3.7.0 with gcc 4.9

Richard Smith via cfe-dev cfe-dev at lists.llvm.org
Wed Oct 7 13:23:40 PDT 2015


On Wed, Oct 7, 2015 at 4:47 AM, Craig Rodrigues <rodrigc at freebsd.org> wrote:

> Hi,
>
> I recently tried to compile clang 3.7.0 with gcc 4.9
> under FreeBSD.  I reproduced the problem with gcc 5.0.
>
> The full build error is here:
> https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/617/console
>
> The error of interest is:
>
>
> --- Module.o ---
> /usr/local/bin/x86_64-portbld-freebsd10.1-g++
> -isystem
> /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include
> -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib
> --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp
> -B/usr/local/x86_64-freebsd/bin/
> -I/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1
> -std=gnu++11
> -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/../lib/libc++
> --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp
> -B/usr/local/x86_64-freebsd/bin/  -O2 -pipe
> -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/include
> -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include
> -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic
> -I.
> -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/../../lib/clang/include
> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
> -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT
> -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\"
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\"
> -fstack-protector-strong  -std=c++11 -fno-exceptions -fno-rtti  -c
> /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Module.cpp
> -o Module.o
> In file included from
> /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/SourceLocation.h:22:0,
>                  from
>                  /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/Module.h:18,
>                  from
>                  /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Module.cpp:15:
> /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1/functional:1322:17:
> error: '_Rp std::__1::__function::__base<_Rp(_ArgTypes
> ...)>::operator()(_ArgTypes&& ...) [with _Rp = void; _ArgTypes =
> {clang::VisibleModuleSet::setVisible(clang::Module*, clang::SourceLocation,
> clang::VisibleModuleSet::VisibleCallback,
> clang::VisibleModuleSet::ConflictCallback)::Visiting}]', declared
> using local type 'clang::VisibleModuleSet::setVisible(clang::Module*,
> clang::SourceLocation, clang::VisibleModuleSet::VisibleCallback,
> clang::VisibleModuleSet::ConflictCallback)::Visiting', is used but
> never defined [-fpermissive]
>      virtual _Rp operator()(_ArgTypes&& ...) = 0;
>                  ^
>
> 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.

One more thing that's worth checking: if you build with -fpermissive, does
the compile and link succeed?

This setup (using gcc + libc++ to compile clang) is likely not something we
tested as part of our release validation.

> *** [Module.o] Error code 1
>
>
> I investigated this problem, and found that I could
> completely eliminate the compilation failure
> by moving "struct Visiting" outside of VisibleModuleSet::setVisible()
>
> with this patch:
>
>
>
> Index: tools/clang/lib/Basic/Module.cpp
> ===================================================================
> --- tools/clang/lib/Basic/Module.cpp    (revision 288962)
> +++ tools/clang/lib/Basic/Module.cpp    (working copy)
> @@ -480,6 +480,12 @@
>    print(llvm::errs());
>  }
>
> +struct Visiting {
> +    Module *M;
> +    Visiting *ExportedBy;
> +};
> +
> +
>  void VisibleModuleSet::setVisible(Module *M, SourceLocation Loc,
>                                    VisibleCallback Vis, ConflictCallback Cb) {
>    if (isVisible(M))
> @@ -487,11 +493,6 @@
>
>    ++Generation;
>
> -  struct Visiting {
> -    Module *M;
> -    Visiting *ExportedBy;
> -  };
> -
>    std::function<void(Visiting)> VisitModule = [&](Visiting V) {
>      // Modules that aren't available cannot be made visible.
>      if (!V.M->isAvailable())
>
>
>
>
> Is this a valid fix, or is there a bug in gcc that
>
> needs to be reported to them?
>
> I don't know C++ enough to know.
>
> Thanks.
>
>
> --
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151007/711876c3/attachment.html>


More information about the cfe-dev mailing list