libcpp.hpp always defines BOOST_NO_CXX11_HDR_ATOMIC
The libc++ config header, libcpp.hpp, always defines BOOST_NO_CXX11_HDR_ATOMIC, but the libc++ that - I presume - ships with "Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)" appears to have a functional <atomic>.
The libc++ config header, libcpp.hpp, always defines BOOST_NO_CXX11_HDR_ATOMIC, but the libc++ that - I presume - ships with "Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)" appears to have a functional <atomic>.
Do you have a patch that identifies when we don't need to set that macro? John.
John Maddock wrote:
The libc++ config header, libcpp.hpp, always defines BOOST_NO_CXX11_HDR_ATOMIC, but the libc++ that - I presume - ships with "Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)" appears to have a functional <atomic>.
Do you have a patch that identifies when we don't need to set that macro?
Unfortunately not. I'm not very up to speed with Clang. I did install LLVM 3.4 for Windows, but it crashes on every nontrivial use of std::cout. :-)
On 2/28/2014 12:32 PM, Peter Dimov wrote:
John Maddock wrote:
The libc++ config header, libcpp.hpp, always defines BOOST_NO_CXX11_HDR_ATOMIC, but the libc++ that - I presume - ships with "Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)" appears to have a functional <atomic>.
Do you have a patch that identifies when we don't need to set that macro?
Unfortunately not. I'm not very up to speed with Clang. I did install LLVM 3.4 for Windows, but it crashes on every nontrivial use of std::cout. :-)
Just a quickie comment <g>. My own attempt to test clang on Windows with Boost show that it is still largely inoperable with most Boost libraries: 1) clang with MingW/gcc RTL - no multi-threading support. 2) clang-cl with VC++ RTL - no exception or RTTI support. These lead to various errors trying to test a number of Boost libraries, starting with config and MPL. Your own attempts may vary. I did add a few simple changes to both config and MPL on 'develop' to try to accomodate just compiling with clang-cl since it is emulating VC++. I did not try to test non-Boost code. I do not think either clang Windows implementations above are really ready for Boost code. The clang developers are fully aware of these issues and are evidently "working" on them, but they have many other priorities. So personally I would wait awhile before seriously trying to get clang on Windows working with Boost if that is your intention.
Edward Diener wrote:
My own attempt to test clang on Windows with Boost show that it is still largely inoperable with most Boost libraries:
1) clang with MingW/gcc RTL - no multi-threading support.
I didn't get that far. std::cout << std::endl crashes. printf works though,
so there's that. Unfortunately, lightweight_test.hpp uses <iostream>, not
On 2/28/2014 7:49 PM, Peter Dimov wrote:
Edward Diener wrote:
My own attempt to test clang on Windows with Boost show that it is still largely inoperable with most Boost libraries:
1) clang with MingW/gcc RTL - no multi-threading support.
I didn't get that far. std::cout << std::endl crashes. printf works though, so there's that. Unfortunately, lightweight_test.hpp uses <iostream>, not
, so I got a crash on each and every test. :-)
Another proof tha clang under Windows is not yet ready for Boost. I did not even try to get that far with the MingW/gcc version. Once it failed some config tests which required multi-threading, and I reported it to clang and was told that multi-threading was not yet implemented on Windows, I stopped. Your lightweight_test is great, no offense to Boost test which is overkill for my testing needs. Of course it uses iostreams and not C stdio.h. If clang MingW/gcc cannot handle iostreams it is not ready for much. Can you create a bug report for that in clang's Bugzilla ?
Edward Diener wrote:
If clang MingW/gcc cannot handle iostreams it is not ready for much. Can you create a bug report for that in clang's Bugzilla ?
I got a response on this ticket; there was an ABI change in the MinGW version of g++, which is why the 3.4 version of LLVM/Clang doesn't work with mingw-g++ 4.8.1. (I actually knew that - the earlier versions crashed on some shared_ptr tests involving virtual base classes, and 4.8 no longer does - but didn't connect the dots.) The suggestion was to switch to Clang 3.5 from SVN, and I tried, but the official MinGW g++ from mingw.org, the one mingw-get installs and that I use, didn't work, due to a missing off_t definition. The other MingGW, mingw-w64, worked. Not out of the box though; see the ticket where I've listed the two trivial fixes that I needed to make. And the resulting clang++.exe does actually compile and pass all smart_ptr tests. It also appears to support threads just fine. The only problem is that clang-linux.jam passes -mthreads to it, whereas the correct option is -pthread. So that's good, on one hand - it's possible to use clang on Windows, if only for testing purposes - and not so good, on another, since this configuration is obviously neither tested nor supported by the Clang developers, or they'd have seen and fixed the build errors. :-)
On 3/3/2014 5:05 PM, Peter Dimov wrote:
I got a response on this ticket; there was an ABI change in the MinGW version of g++, which is why the 3.4 version of LLVM/Clang doesn't work with mingw-g++ 4.8.1. (I actually knew that - the earlier versions crashed on some shared_ptr tests involving virtual base classes, and 4.8 no longer does - but didn't connect the dots.)
The suggestion was to switch to Clang 3.5 from SVN, and I tried, but the official MinGW g++ from mingw.org, the one mingw-get installs and that I use, didn't work, due to a missing off_t definition. The other MingGW, mingw-w64, worked.
Which of the many download options on the MingW-x64 site ( http://mingw-w64.sourceforge.net ) did you use.
Not out of the box though; see the ticket where I've listed the two trivial fixes that I needed to make.
And the resulting clang++.exe does actually compile and pass all smart_ptr tests.
What instructions did you follow to build the latest clang with MingW-x64 ? Was it also "cmake -G "MinGW Makefiles" ..\llvm" mentioned in your bug report ?
It also appears to support threads just fine. The only problem is that clang-linux.jam passes -mthreads to it, whereas the correct option is -pthread.
How did you substitute -mthreads with -pthread for clang-linux.jam ? My technique is to copy the rule setup-threading from gcc.jam to clang-linux.jam, change the windows case to have 'option = -pthread' and invoke 'setup-threading' rather than 'gcc.setup-threading' in the rest of the clang-linux.jam file. But I am not sure if I have to add a 'libs = rt ' as is done in the default case.
So that's good, on one hand - it's possible to use clang on Windows, if only for testing purposes - and not so good, on another, since this configuration is obviously neither tested nor supported by the Clang developers, or they'd have seen and fixed the build errors. :-)
Thanks for the post. I am very interested in getting the latest clang to work on Window so I can use it to test Boost libraries.
Edward Diener wrote: On 3/3/2014 5:05 PM, Peter Dimov wrote:
Which of the many download options on the MingW-x64 site ( http://mingw-w64.sourceforge.net ) did you use.
I downloaded the mingw-builds setup, mingw-builds-install.exe, then chose, somewhat arbitrarily, the default x32 option, x32-4.8.1-posix-dwarf-rev5. Using x64 with SEH could have been a better idea. If you don't have another MinGW in C:\mingw, I'd recommend actually unpacking the mingw-builds installation there instead of using the installer which installs into a x32-4.8.1-posix-dwarf-rev5 subdirectory of whatever you tell it (C:\Program Files (x86)\mingw-builds by default). Clang looks into C:\mingw for the header files and that's apparently hardcoded, so it's best for the MinGW installation to live there.
What instructions did you follow to build the latest clang with MingW-x64 ? Was it also "cmake -G "MinGW Makefiles" ..\llvm" mentioned in your bug report ?
Yes, cmake -G "MinGW Makefiles" ..\llvm. I had to install cmake and Python first. Python isn't actually used during the build, but cmake complained when it couldn't find it. I also used -DCMAKE_BUILD_TYPE=Release in addition to -G, to make a release build.
How did you substitute -mthreads with -pthread for clang-linux.jam ?
I actually didn't, so the two smart_ptr tests that were marked as multithreaded failed. But I did compile them manually using clang++ -pthread to verify that they worked, and they did. I don't know much of boost-build so I had no idea how to make it pass -pthread. Now if only one of the MinGW teams could decide to bundle Clang so that we could skip all this :-)
On 4 Mar 2014 at 19:08, Peter Dimov wrote:
I downloaded the mingw-builds setup, mingw-builds-install.exe, then chose, somewhat arbitrarily, the default x32 option, x32-4.8.1-posix-dwarf-rev5. Using x64 with SEH could have been a better idea.
I would be surprised if GCC + SEH is as reliable as DWARF. http://gcc.gnu.org/wiki/WindowsGCCImprovements says GCC doesn't do Windows SEH at all, but the real reason SEH isn't in mainline GCC is due to patent fears, there has been an implementation for some time. I assume the mingw-w64 developers decided to merge that patch anyway. A big reason clang is moving now on Windows SEH support is because that patent expires very soon now. Soon GCC or especially clang will be perfectly substitutable for MSVC. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Niall Douglas wrote:
I would be surprised if GCC + SEH is as reliable as DWARF. http://gcc.gnu.org/wiki/WindowsGCCImprovements says GCC doesn't do Windows SEH at all, but the real reason SEH isn't in mainline GCC is due to patent fears, there has been an implementation for some time. I assume the mingw-w64 developers decided to merge that patch anyway.
The MinGW-w64 page states that SEH is only patented for x86, not on x64, which is why the 32 bit version only has Dwarf or SJLJ as options. The 64 bit version is SEH or SJLJ.
On Tue, Mar 04, 2014 at 08:27:53PM +0200, Peter Dimov wrote:
Niall Douglas wrote:
I would be surprised if GCC + SEH is as reliable as DWARF. http://gcc.gnu.org/wiki/WindowsGCCImprovements says GCC doesn't do Windows SEH at all, but the real reason SEH isn't in mainline GCC is due to patent fears, there has been an implementation for some time. I assume the mingw-w64 developers decided to merge that patch anyway.
The MinGW-w64 page states that SEH is only patented for x86, not on x64, which is why the 32 bit version only has Dwarf or SJLJ as options. The 64 bit version is SEH or SJLJ.
If you intend to ever post about SEH to the cfe-dev@ (Clang) list, don't bother. All discussion on the subject or even of laying groundwork for SEH or implementing something similiar under a generic name will be immediately shut down and gagged. Somewhat bitterly yours, -- Lars Viklund | zao@acc.umu.se
Lars Viklund wrote:
If you intend to ever post about SEH to the cfe-dev@ (Clang) list, don't bother.
Interesting. So my random choice - x32-dwarf - was actually right. I just tried std::vector<int>().at(0), which should cause from g++'s libstdc++ to throw, and clang++ is able to catch is properly. I assume that it wouldn't have worked if the exception handling didn't match.
On 4 Mar 2014 at 19:38, Lars Viklund wrote:
The MinGW-w64 page states that SEH is only patented for x86, not on x64, which is why the 32 bit version only has Dwarf or SJLJ as options. The 64 bit version is SEH or SJLJ.
If you intend to ever post about SEH to the cfe-dev@ (Clang) list, don't bother.
All discussion on the subject or even of laying groundwork for SEH or implementing something similiar under a generic name will be immediately shut down and gagged.
I'd imagine as soon as the patent expires you'll see much more open discussion about SEH. Until then no one is going to feed the lawyers. Do remember clang is pretty much exclusively developed by large corporate entities, and those engineers know not to worry Legal or it's a whole load of hassle. I speak from experience at BlackBerry where I once worried Legal and very much regretted it for the many months of never ending hassle later. I will say this though: there is a whole ton of incentive for clang to become perfectly substitutable for MSVC. Just think of the Visual Studio annual licensing costs per developer seat, and you're starting to see how much incentive there is. I wouldn't be surprised if such a clang edition sees very rapid progress as soon as legally possible. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Niall Douglas wrote:
I will say this though: there is a whole ton of incentive for clang to become perfectly substitutable for MSVC.
There probably is, which is why we have a 3/4-broken clang-cl instead of a fully working clang-mingw32 (which would have taken a lot less of effort). That's unfortunate, at least for me. I have no immediate or critical need for a perfect substitute for MSVC - we already have two of those. I need Clang on Windows so that I can test for portability and Clang-specific issues.
On 4 Mar 2014 at 20:27, Peter Dimov wrote:
I would be surprised if GCC + SEH is as reliable as DWARF. http://gcc.gnu.org/wiki/WindowsGCCImprovements says GCC doesn't do Windows SEH at all, but the real reason SEH isn't in mainline GCC is due to patent fears, there has been an implementation for some time. I assume the mingw-w64 developers decided to merge that patch anyway.
The MinGW-w64 page states that SEH is only patented for x86, not on x64, which is why the 32 bit version only has Dwarf or SJLJ as options. The 64 bit version is SEH or SJLJ.
I didn't know that. Still, I would assume that the SEH implementation is probably nothing like as heavily tested as the DWARF implementation. Whatever the case, you really don't want SJLJ for sure. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On 3/4/2014 12:08 PM, Peter Dimov wrote:
Edward Diener wrote: On 3/3/2014 5:05 PM, Peter Dimov wrote:
Which of the many download options on the MingW-x64 site ( http://mingw-w64.sourceforge.net ) did you use.
I downloaded the mingw-builds setup, mingw-builds-install.exe, then chose, somewhat arbitrarily, the default x32 option, x32-4.8.1-posix-dwarf-rev5. Using x64 with SEH could have been a better idea.
If you don't have another MinGW in C:\mingw, I'd recommend actually unpacking the mingw-builds installation there instead of using the installer which installs into a x32-4.8.1-posix-dwarf-rev5 subdirectory of whatever you tell it (C:\Program Files (x86)\mingw-builds by default). Clang looks into C:\mingw for the header files and that's apparently hardcoded, so it's best for the MinGW installation to live there.
What instructions did you follow to build the latest clang with MingW-x64 ? Was it also "cmake -G "MinGW Makefiles" ..\llvm" mentioned in your bug report ?
Yes, cmake -G "MinGW Makefiles" ..\llvm. I had to install cmake and Python first. Python isn't actually used during the build, but cmake complained when it couldn't find it.
C:\Programming\VersionControl\bmw64_clang>cmake -DCMAKE_BUILD_TYPE=Release -G "MinGW Makefiles" ..\llvm CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage -- Configuring incomplete, errors occurred! See also "C:/Programming/VersionControl/bmw64_clang/CMakeFiles/CMakeOutput.log". See also "C:/Programming/VersionControl/bmw64_clang/CMakeFiles/CMakeError.log".
I also used -DCMAKE_BUILD_TYPE=Release in addition to -G, to make a release build.
How did you substitute -mthreads with -pthread for clang-linux.jam ?
I actually didn't, so the two smart_ptr tests that were marked as multithreaded failed. But I did compile them manually using clang++ -pthread to verify that they worked, and they did. I don't know much of boost-build so I had no idea how to make it pass -pthread.
Now if only one of the MinGW teams could decide to bundle Clang so that we could skip all this :-)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Edward Diener wrote:
C:\Programming\VersionControl\bmw64_clang>cmake -DCMAKE_BUILD_TYPE=Release -G "MinGW Makefiles" ..\llvm CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
Is the MinGW bin directory in your PATH?
On 3/4/2014 7:01 PM, Peter Dimov wrote:
Edward Diener wrote:
C:\Programming\VersionControl\bmw64_clang>cmake -DCMAKE_BUILD_TYPE=Release -G "MinGW Makefiles" ..\llvm CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
Is the MinGW bin directory in your PATH?
Yes. Is it really failing because it cannot find a MingW installation on my PATH ? The cmake help says that "MinGW Makefiles" is a valid build type but maybe it needs to match something in the llvm CMakeLists.txt. I will ask about this in the cmake mailing list.
On Wed, Mar 05, 2014 at 12:19:55AM -0500, Edward Diener wrote:
On 3/4/2014 7:01 PM, Peter Dimov wrote:
Edward Diener wrote:
C:\Programming\VersionControl\bmw64_clang>cmake -DCMAKE_BUILD_TYPE=Release -G "MinGW Makefiles" ..\llvm CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
Is the MinGW bin directory in your PATH?
Yes. Is it really failing because it cannot find a MingW installation on my PATH ? The cmake help says that "MinGW Makefiles" is a valid build type but maybe it needs to match something in the llvm CMakeLists.txt.
I will ask about this in the cmake mailing list.
The heuristics it has is something along the lines of: "do we have mingw32-make.exe in PATH, but not sh.exe"? [1] The sh.exe test is to avoid having a MSYS or Cygwin in PATH, for which you should instead use the corresponding "MSYS Makefiles" or "Unix Makefiles" generators. [1] It might be accepting an acceptable make.exe too, don't remember. -- Lars Viklund | zao@acc.umu.se
On 28/02/14 18:11, John Maddock wrote:
The libc++ config header, libcpp.hpp, always defines BOOST_NO_CXX11_HDR_ATOMIC, but the libc++ that - I presume - ships with "Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)" appears to have a functional <atomic>.
Do you have a patch that identifies when we don't need to set that macro?
should the macro declare that the header exists, or that the implementation is complete? e.g. gcc/libstdc++ did support atomic<Integral> before fully supporting atomic<>. likewise, clang/libc++ is broken, if the wrapped type is a trivially copyable class [1]. tim [1] http://llvm.org/bugs/show_bug.cgi?id=18097
Do you have a patch that identifies when we don't need to set that macro?
should the macro declare that the header exists, or that the implementation is complete?
That it exists and is reasonably useful. If more "advanced" uses hit bugs then that's probably more of a BOOST_WORKAROUND or possibly a new macro. HTH, John
e.g. gcc/libstdc++ did support atomic<Integral> before fully supporting atomic<>. likewise, clang/libc++ is broken, if the wrapped type is a trivially copyable class [1].
tim
[1] http://llvm.org/bugs/show_bug.cgi?id=18097
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (6)
-
Edward Diener -
John Maddock -
Lars Viklund -
Niall Douglas -
Peter Dimov -
Tim Blechmann