This is just a heads up about testing with clang on Windows. The latest clang, when built from the latest source, is now capable on Windows of using the mingw-64/gcc RTL. Furthermore it is no longer necessary to have the mingw/mingw-64 implementation hardcoded or linked from c:\mingw. With the latest clang the executable will look for a mingw/mingw-64 implementation on the PATH, meaning that the if the implementation's 'bin' directory is on the PATH clang will find it and use its RTL. The ability of the latest clang to use mingw-64 means that clang can use the latest gcc-5.1 RTL on Windows. The mingw-64 implementation offers more up to date and better implementations of gcc than mingw. There is one "gotcha" I have found with this setup on Windows when using clang on Windows with gcc-4.9 on up. The gcc intrin.h implementation of mingw-64 for gcc-4.9 on up has a bug where if the gcc version is less than 4.9 a compiler error will occur. I have reported this to mingw-64 on their developer's mailing list but it has been ignored. Unfortunately clang still sets itself to gcc version 4.2.1. But a workaround solves the problem and that workaround is that when using clang you define '__MINGW_FORCE_SYS_INTRINS', which causes the bug in the mingw-64 intrin.h header file to not trigger. Previous versions of clang on Windows ( 3.4, 3.5, 3.6 ) of course still have the limitation of only working with mingw and needing the mingw implementation hardcoded at c:\mingw. But at least with the latest clang built from source this has changed as explained above. The Boost build clang toolset, which on Windows is really clang-linux, should continue to work with this latest change of clang.