Re: [boost] [clang][preprocessor] Testing of clang emualting the VC++ preprocessor on Windows

On 31/03/2016 15:27, degski wrote:

Hi,

Is there a (simple) git command-line that gives me a complete "develop" boost source distribution clone, so I could give it a try?

Easiest way is to go to https://github.com/boostorg/preprocessor, and hit the "download" button ;) HTH, John.

Thanks in advance,

degski

On 31 March 2016 at 14:28, Edward Diener wrote:

...

On 3/30/2016 5:05 PM, Edward Diener wrote:

...

I have made local changes in the Boost preprocessor config.hpp on the 'develop' branch to have clang's emulation of the non-standard VC++ preprocessor act like the VC++ preprocessor as far as Boost PP is concerned. Boost PP has a large number of workarounds for VC++ without which Boost PP preprocessor code would not work when compiling using any version of VC++.

I have tested the usual compilers extensively to make sure they are unaffected by these changes as well as the normal clang-linux implementation. Everything remains the same for these compilers with my changes so I am assured the changes will not affect any other compiler implementation.

I was able to test both clang-3.8 and the latest build of clang, which is clang-3.9, by invoking clang-cl. My user-config.jam file for these entries looks like:

using clang-win : 3.8 : SomePath/clang-cl : <compatibility>vc12 using clang-win : 3.9 : SomePath/clang-cl : <compatibility>vc14

By passing toolset=clang-win-3.8 or toolset=clang-win-3.9 I was able to successfully test these implementations against the Boost PP test code.

There are quite a few failures in this clang emulation of the VC++ preprocessor when tested against the preprocessor test code. In fact testing clang emulation of VC++ preprocessor when I don't treat clang as VC++ in Boost PP, but as its normal C++ standard conforming preprocessor, still fails a few cases but far less than when clang is treated as VC++ in Boost PP. Needless to say when invoking clang-linux, which tests the normal clang implementation whether on Windows or Linux, there are no failures in the Boost PP tests.

I am perfectly willing to push my changes to 'develop' for the preprocessor. The changes are essentially just in the Boost PP config.hpp file, which sets macros which control the compiler workarounds in Boost PP. As I have previously stated I am not personally willing to try to figure out or report to clang why their VC++ preprocessor emulation in Boost PP is failing, but others who are interested can do so if they wish. My personal reasons for this is that I think it is a very bad thing to attempt to replicate an already flawed C++ preprocessor in another compiler in general code. I also have spent enough time working with the VC++ preprocessor trying to find workarounds for its non-standard behavior that I do not want to do so for another preprocessor which attempts to be non-standard.

I posted this to alert others to my plans to update Boost PP on 'develop' with this change, in case anybody is greatly opposed to it or wants to discuss it further. The change will not affect any other compiler but clang in VC++ preprocessor emulation mode. Unless I hear objections etc. I plan to push my update within the next day although I will wait awhile for any replies to this post.

I pushed my update to Boost PP on 'develop' so anybody using clang targeting VC++ for Windows can try it out. It is possible that the clang emulating the non-standard VC++ preprocessor errors I see when running the preprocessor tests with clang-win toolset are few but are being propagated in many different cases. However I don't even think there is a way to see, for anybody interested, how clang is expanding macros in its VC++ emulation as opposed to normal clang-linux where macro expansion is shown when clang preprocessor erros are detected.

Note on clang targeting on Windows:

The LLVM 3.8 binary distribution of clang for Windows defaults to clang/clang++ targeting VC++, while all previous LLVM binary distributions of clang for Windows defaulted to clang/clang++ targeting mingw(-64)/gcc.

The clang-cl executable always targets VC++ AFAIK. When you build from source using VC++ on Windows then clang/clang++ targets VC++ by default and when you build from source using mingw(-64)/gcc on Windows then clang/clang++ targets mingw(-64)/gcc by default.

You can always change the targeting of clang through the use of the clang/clang++ '-target' option. It's details are poorly documented at http://clang.llvm.org/docs/CrossCompilation.html#target-triple. I chided clang developers about this incomplete documentation but without effect.

I was given the targets '-target i686-pc-windows-gnu' and '-target x86_64-pc-windows-gnu' as a way of targeting mingw(-64)/gcc for 32-bit and 64-bit clang/clang++ versions respectively, both of which I have tested and do work. I believe the equivalent targets for 32-bit and 64-bit versions of clang/clang++ targeting VC++ are '-target=i686-pc-windows-msvc' and '-target=x86_64-pc-windows-msvc' respectively but I have not tried these out.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost