Thor 2.0 cmake build error OS X 10.7

[Nexus]

After trying several things, reading masses of stackoverflow topics and recompiling clang for Windows (which worked, but clang++.exe always yielded linker errors -- thanks for not mentioning this in the tutorial), I have finally found a version that works on Windows. It uses the GNU libstdc++ instead of libc++ however (I don't know if the latter has been ported to Windows, by the way I'll never understand why it's not possible to name standard libraries meaningfully). In the command line, clang++ --version outputs the following:

clang version 3.1 (tags/RELEASE_31/final 161181) (llvm/tags/RELEASE_31/final 161243)
Target: i686-w64-mingw32
Thread model: posix

I have tried to compile Thor with it, and the compiler crashed as a result of the SFINAE used in Math/Distribution.hpp. After removing that, everything compiled -- unfortunately. The triangulation code didn't raise any errors, so it's probably really the STL of libc++ which can't handle incomplete types.

For me, that's a little bit unfortunate, because I have no option to reproduce the errors. And the fact that the short code I posted works for your Apple Clang doesn't make it easier to find the source of the issue... :/

[Ceylo]

I don't really know what to say. I also find it weird that Apple's Clang says its version is 4.0 whereas LLVM website claims v3.1 has just been released. Plus the c++11 library doesn't seem to be available on Apple's opensource page.

I can't either help you as I don't understand what's wrong, I mostly do not know C++11 and I can't follow clang's error messages here (too much "redirections").

The best I can do is test other sample codes of yours, or give you SSH access to my laptop so that you can test as much as you want.

[Ceylo]

I found libc++: http://libcxx.llvm.org
However it only supports OS X so you won't be able to test it on your computer.

[Nexus]

Thank you very much for your help. It looks at least like there is some effort to port libc++ on Windows. Hopefully it will be usable one day

Could you test this snippet? Comeau online doesn't compile this code.

#include <list>

struct Triangle;
typedef std::list<Triangle>::iterator Iterator;
 
struct Triangle
{
    Iterator i;
};

int main() {}

By the way, I have looked at your OpenGL code, but I haven't seen the mistake or been able to make it work... But my OpenGL experience is limited, someone else knows probably better

[Hiura]

This code compiles fine with both GCC and Clang.

$ /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc-4.2 --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

$ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang --version
Apple clang version 4.0 (tags/Apple/clang-421.0.60) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.1.0
Thread model: posix

[Ceylo]

This code compiles fine with both GCC and Clang.

Not exactly.

It does compile fine using `clang++ cl.cpp -Wall -std=c++0x` but not with `clang++ cl.cpp -Wall -std=c++0x -stdlib=libc++`:

Code: [Select]

In file included from cl.cpp:1:
/usr/bin/../lib/c++/v1/list:212:9: error: field has incomplete type 'Triangle'
    _Tp __value_;
        ^
/usr/bin/../lib/c++/v1/type_traits:1889:54: note: in instantiation of template class 'std::__1::__list_node<Triangle, void *>' requested here
decltype(_VSTD::move(_Tp(_VSTD::declval<_Args>()...)), true_type())
                                                     ^
/usr/bin/../lib/c++/v1/type_traits:1890:1: note: while substituting deduced template arguments into function template '__is_constructible_test'
      [with _Tp = std::__1::allocator<std::__1::__list_node<Triangle, void *>>, _Args = <no value>]
__is_constructible_test(_Tp&&, _Args&& ...);
^
/usr/bin/../lib/c++/v1/type_traits:1949:14: note: in instantiation of template class 'std::__1::__is_constructible<false,
      std::__1::allocator<std::__1::__list_node<Triangle, void *>>, std::__1::allocator<std::__1::__list_node<Triangle, void *>> &&>' requested
      here
    : public __is_constructible<is_scalar<_Tp>::value || is_reference<_Tp>::value,
             ^
/usr/bin/../lib/c++/v1/type_traits:1975:14: note: in instantiation of template class 'std::__1::__is_constructible_void_check<false,
      std::__1::allocator<std::__1::__list_node<Triangle, void *>>, std::__1::allocator<std::__1::__list_node<Triangle, void *>> &&>' requested
      here
    : public __is_constructible_void_check<__contains_void<_Tp, _Args...>::value
             ^
/usr/bin/../lib/c++/v1/type_traits:2455:34: note: in instantiation of template class
      'std::__1::is_constructible<std::__1::allocator<std::__1::__list_node<Triangle, void *>>,
      std::__1::allocator<std::__1::__list_node<Triangle, void *>> &&>' requested here
    : __is_nothrow_constructible<is_constructible<_Tp, _Args...>::value, _Tp, _Args...>
                                 ^
/usr/bin/../lib/c++/v1/type_traits:2590:14: note: (skipping 1 context in backtrace; use -ftemplate-backtrace-limit=0 to see all)
    : public is_nothrow_constructible<_Tp, typename add_rvalue_reference<_Tp>::type>
             ^
/usr/bin/../lib/c++/v1/memory:2219:20: note: in instantiation of template class
      'std::__1::is_nothrow_move_constructible<std::__1::allocator<std::__1::__list_node<Triangle, void *>>>' requested here
                   is_nothrow_move_constructible<_T2>::value)
                   ^
/usr/bin/../lib/c++/v1/__config:253:34: note: expanded from macro '_NOEXCEPT_'
#  define _NOEXCEPT_(x) noexcept(x)
                                 ^
/usr/bin/../lib/c++/v1/memory:2386:15: note: in instantiation of template class 'std::__1::__libcpp_compressed_pair_imp<unsigned long,
      std::__1::allocator<std::__1::__list_node<Triangle, void *>>, 2>' requested here
    : private __libcpp_compressed_pair_imp<_T1, _T2>
              ^
/usr/bin/../lib/c++/v1/list:513:52: note: in instantiation of template class 'std::__1::__compressed_pair<unsigned long,
      std::__1::allocator<std::__1::__list_node<Triangle, void *>>>' requested here
    __compressed_pair<size_type, __node_allocator> __size_alloc_;
                                                   ^
/usr/bin/../lib/c++/v1/list:770:15: note: in instantiation of template class 'std::__1::__list_imp<Triangle, std::__1::allocator<Triangle>>'
      requested here
    : private __list_imp<_Tp, _Alloc>
              ^
cl.cpp:4:14: note: in instantiation of template class 'std::__1::list<Triangle, std::__1::allocator<Triangle>>' requested here
typedef std::list<Triangle>::iterator Iterator;
             ^
cl.cpp:3:8: note: forward declaration of 'Triangle'
struct Triangle;
       ^
1 error generated.

[Hiura]

Yes, indeed. I was trying to compile thor too and didn't understand why apparently same code didn't work for thor but did for this sample.. Sorry for the false positive. :/

[Ceylo]

What's weird though is it'll build fine with `clang++ cl.cpp -Wall -stdlib=libc++`.

I also noticed that without -stdlib=libc++, when building Thor, clang will complain about the missing type_traits file but replacing

Code: [Select]

#include <type_traits>with

Code: [Select]

#include <tr1/type_traits>allows some errors to be fixed (by also using std::tr1 instead of std:: ). However other names like std::conditional don't seem to be fixable with that way as they're part of C++11.

Edit: note that your first sample code to test clang actually does not compile fine when using -std=c++0x and -stdlib=libc++. It works with one or the other but not both, so it was a false positive too.

[Hiura]

This bug seems to be exactly what we're looking at right now.

And this article states that clang behaviour on this won't be changed. But comment #2 says otherwise. So I'm confused...

Maybe the workaround exposed by Howard Hinnant in comment #3 can be useful.

[Nexus]

Great, finally a reproducable error! Thank you both very much!

It isn't a bug in libc++. According to the C++ standard, the behavior of incomplete types as STL template parameters is undefined. It might also become an issue in other standard libraries as the implementation of C++11 features progresses. So I need to adapt Thor.

The question is just how: An additional indirection (either container of std::unique_ptrs or a custom iterator using Pimpl) is easy to implement, but requires dynamic memory management, which might become expensive if it is used all the time. In another forum someone mentioned Boost's intrusive containers (they allow conversion of pointers to iterators, so I can break the dependency cycle), and although I won't use Boost for Thor, the concept is interesting. But I'll probably stick to the indirection approach, optimizations are still possible.

[Nexus]

I pushed two changes: CMake adaption and Triangulation refactoring. Does the newest Thor revision work?

[Ceylo]

Haha, a little bit better, but now you got Clang to crash

Code: [Select]

[  4%] Building CXX object src/CMakeFiles/thor.dir/Emitter.cpp.o
0  clang             0x00000001010536f2 main + 17107682
1  clang             0x0000000101053b79 main + 17108841
2  libsystem_c.dylib 0x00007fff8881492a _sigtramp + 26
3  libsystem_c.dylib 0x00000000000000a0 _sigtramp + 18446603338225989520
4  clang             0x0000000100156017 main + 1389575
5  clang             0x00000001001555c0 main + 1386928
6  clang             0x00000001005b7c72 main + 5984354
7  clang             0x00000001001558e8 main + 1387736
8  clang             0x00000001005b80db main + 5985483
9  clang             0x00000001005b6a05 main + 5979637
10 clang             0x00000001005b51ec main + 5973468
11 clang             0x00000001005b4b67 main + 5971799
12 clang             0x00000001005bbff6 main + 6001638
13 clang             0x00000001005bbc3a main + 6000682
14 clang             0x00000001007e355a main + 8259914
15 clang             0x00000001005b6008 main + 5977080
16 clang             0x00000001005b4b67 main + 5971799
17 clang             0x000000010015543b main + 1386539
18 clang             0x00000001005b9078 main + 5989480
19 clang             0x00000001005b86f1 main + 5987041
20 clang             0x0000000100159254 main + 1402436
21 clang             0x0000000100158cbd main + 1401005
22 clang             0x0000000100503e83 main + 5247603
23 clang             0x00000001005bc864 main + 6003796
24 clang             0x000000010015851b main + 1399051
25 clang             0x00000001005b9567 main + 5990743
26 clang             0x000000010015559a main + 1386890
27 clang             0x000000010015539a main + 1386378
28 clang             0x000000010014c899 main + 1350793
29 clang             0x000000010014cd8b main + 1352059
30 clang             0x000000010014cc20 main + 1351696
31 clang             0x000000010014c7ca main + 1350586
32 clang             0x00000001005baa88 main + 5996152
33 clang             0x000000010013364b main + 1247803
34 clang             0x00000001005ba8f2 main + 5995746
35 clang             0x0000000100112b37 main + 1113895
36 clang             0x000000010018a627 main + 1604119
37 clang             0x000000010018a3b7 main + 1603495
38 clang             0x000000010018a0bd main + 1602733
39 clang             0x0000000100047606 main + 281078
40 clang             0x0000000100045bbe main + 274350
41 clang             0x0000000100044c01 main + 270321
42 clang             0x0000000100019ae2 main + 93906
43 clang             0x0000000100018748 main + 88888
44 clang             0x0000000100006438 main + 14376
45 clang             0x0000000100002e97 main + 647
46 clang             0x0000000100002c04
Stack dump:
0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-apple-macosx10.8.0 -emit-obj -disable-free -disable-llvm-verifier -main-file-name Emitter.cpp -pic-level 2 -mdisable-fp-elim -relaxed-aliasing -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 133.3 -coverage-file CMakeFiles/thor.dir/Emitter.cpp.o -resource-dir /usr/bin/../lib/clang/4.0 -D thor_EXPORTS -D THOR_EXPORTS -D NDEBUG -I /Users/ceylo/Development/Thor/include -I /Users/ceylo/Development/Thor/extlibs/aurora/include -F/Library/Frameworks -fmodule-cache-path /var/folders/8f/3bhx1ymn6jz6z2xr5hmq841h0000gn/T/clang-module-cache -stdlib=libc++ -O3 -std=c++0x -fdeprecated-macro -fdebug-compilation-dir /Users/ceylo/Development/Thor/src -ferror-limit 19 -fmessage-length 160 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-dispatch-method=mixed -fobjc-default-synthesize-properties -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o CMakeFiles/thor.dir/Emitter.cpp.o -x c++ /Users/ceylo/Development/Thor/src/Emitter.cpp
1. <eof> parser at end of file
2. Per-file LLVM IR generation
3. /Users/ceylo/Development/Thor/include/Thor/Math/Distribution.hpp:62:10: Generating code for declaration 'thor::Distribution<sf::Color>::Distribution'
4. /Users/ceylo/Development/Thor/include/Thor/Math/Distribution.hpp:65:3: LLVM IR generation of compound statement ('{}')
clang: error: unable to execute command: Segmentation fault: 11
clang: error: clang frontend command failed due to signal (use -v to see invocation)
clang: note: diagnostic msg: Please submit a bug report to http://developer.apple.com/bugreporter/ and include command line arguments and all diagnostic information.
clang: note: diagnostic msg: Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /var/folders/8f/3bhx1ymn6jz6z2xr5hmq841h0000gn/T/Emitter-P2fPFg.ii
clang: note: diagnostic msg: /var/folders/8f/3bhx1ymn6jz6z2xr5hmq841h0000gn/T/Emitter-P2fPFg.sh
make[2]: *** [src/CMakeFiles/thor.dir/Emitter.cpp.o] Error 254
make[1]: *** [src/CMakeFiles/thor.dir/all] Error 2
make: *** [all] Error 2

[Nexus]

Okay, but at least I can reproduce this error

and the compiler crashed as a result of the SFINAE used in Math/Distribution.hpp

Let's see if I can find the source of the problem

[Hiura]

Commenting Distribution.hpp:68 prevent clang from crashing. (And it seems that Random.cpp has other issues too.)

I'm currently trying to create a minimal code reproducing the issue. I let you know if I succeed (or failed).

[Nexus]

I have been able to come up with a minimal example:

struct Color {};

struct Distribution
{
        Distribution()
        {
                Color copy;
                auto fn = [copy] () { return copy; };
        }
};

int main()
{
        Distribution x;
}

The issue is not related to SFINAE. It rather looks like a compiler bug concerning lambda expressions that refer to local variables. If copy is a parameter, Clang doesn't crash.