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

[Craig Rodrigues via cfe-dev]

I did the following:

(1)  Filed bug report with GCC:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67888

(2)  In FreeBSD Makefile which compiles libclangbasic, add -fpermissive to
CFLAGS only for GCC:

https://lists.freebsd.org/pipermail/svn-src-all/2015-October/111372.html

--
Craig


On Wed, Oct 7, 2015 at 5:52 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> On Wed, Oct 7, 2015 at 5:24 PM, Craig Rodrigues via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Wed, Oct 7, 2015 at 1:23 PM, Richard Smith <richard at metafoo.co.uk>
>> wrote:
>>
>>> 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?
>>>
>>
>> There was no note to indicate why GCC thought that this pure virtual
>> function is used.
>> The only thing I could think of was maybe there was something in the llvm
>> implementation of
>> std::function that caused this to happen.
>>
>>
>>
>>> 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?
>>>
>>>
>> I added -fpermissive to the command-line, and the compile and link
>> succeeded.
>>
>> If this looks like a GCC bug, I can submit something to them.
>>
>
> Yes, this seems likely to be a GCC bug.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151007/c4a14440/attachment.html>