On 9 Apr 2016 at 8:32, degski wrote:
Sergey suggested I'd run regression tests, in the "other thread". I was hesitant at first, mostly due to the luke warm reception.
It's only apparently a luke warm reception due to the volume from those with various axes to grind about winclang's historical decisions. I very much doubt if the majority here isn't very excited about an officially Microsoft supported clang built into Visual Studio, and the fact we finally can write fully standards conforming C++ 14 (sans preprocessor) for the MSVC target. All it requires is someone to raise the target on the Boost regression testing infrastructure and that should bring eyeballs to any compatibility problems. I thank you for investing the effort to make this happen.
This was a test-run (testing the testing), with VC14U2. Assuming the above can get sorted, I would in reality like to test Clang/LLVM (with VC14U2). I would like to ask (Niall Douglas in particular, I guess) what the suggested parameters to run.py should be for this combo.
I am afraid I don't know. I have ... fairly eccentric views regarding Boost in that I'd like my libraries into Boost, but to otherwise have no mandatory dependencies on Boost whatsoever. To that end, I make very little use of Boost anything, especially recently with the post peer review AFIO v2 rewrite which only requires Bjarne's GSL as a mandatory dependency. (gsl-lite is actually the variant I use, Microsoft GSL is a bit heavy. span<T> is amazing, AFIO v2's design is utterly based on span<T> and wouldn't be possible without).
Should I target clang.exe or clang-cl.exe, develop or master. What about Clang/C2?
I can say much more useful about this. I would test BOTH because they are quite different in behaviour once you get into using them in anger. As a general hand waving sweeping generalisation, LLVM clang 3.8 targeting MSVC is the superior tool relative to C2 clang 3.7. It's more stable, it generates better code, it doesn't ICE anything like as much. It does not, however, generate much useful debug info, only line numbers whereas C2 clang generates mostly accurate debug info. I wouldn't bother with LLVM clang before 3.8 for the MSVC target. Previous versions ICEd a lot when you have RTTI and exceptions turned on. Finally, be aware that --analyze works perfectly on winclang, and it will find quite a few problems that Microsoft's /analyze does not.
How to reduce disk-space usage?
Look into the /Z7 debug flag for MSVC. Generates only line number debug info, it's vastly smaller than /Zi. If Boost is turning on /ZI (capital i), then it ought to change to /Zi (small i) as the Edit and Continue feature is excessive on disc space. Finally passing pch=off to b2.exe might help reduce disk space, but slow builds. Good luck and best speed with your efforts. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/