On 25/03/2016 20:02, Steven Watanabe wrote:

AMDG

On 03/25/2016 01:35 PM, John Maddock wrote:

...

What's the correct way to configure clang on windows with current Boost.Build?

clang-win.jam isn't up-to-date for vc14. Try the attached patch.

Then the clang command disappears altogether and bjam tries to invoke: /DEBUG /subsystem:console /out:"..\..\..\bin.v2\libs\config\test\config_info.test\clang-vc14-win-3.9.0\debug\config_info.exe" @"..\..\..\bin.v2\libs\config\test\config_info.test\clang-vc14-win-3.9.0\debug\config_info.exe.rsp" Plus the response file contains: "config_info.cpp" -Fo"..\..\..\bin.v2\libs\config\test\config_info.test\clang-vc14-win-3.9.0\debug\config_info.obj" -TP /Od /Ob0 /W3 /GR /MDd /EHs -c -DBOOST_ALL_NO_LIB=1 "-I..\..\.." And I don't think those command line options are supported by clang? John.

On 26/03/2016 13:13, Peter Dimov wrote:

John Maddock wrote:

...

Plus the response file contains:

"config_info.cpp" -Fo"..\..\..\bin.v2\libs\config\test\config_info.test\clang-vc14-win-3.9.0\debug\config_info.obj" -TP /Od /Ob0 /W3 /GR /MDd /EHs -c -DBOOST_ALL_NO_LIB=1 "-I..\..\.."

And I don't think those command line options are supported by clang?

clang-cl.exe is option-compatible with cl.exe, clang.exe is not.

There is no clang-cl shipped with msvc. John.

That should be calling link.exe, not clang. If you're getting here, it means that compiling succeeded.

Not so fast.... the actual command line generated is: compile-c-c++ ..\..\..\bin.v2\libs\config\test\config_info.test\clang-vc14-win-3 .9.0\debug\config_info.obj @"..\..\..\bin.v2\libs\config\test\config_info.test\clang-vc14-win-3.9.0\debug\config_info.obj.rsp" So the @ causes the line to be ignored I think?

This seems like msvc.configure-version-specific is getting skipped. What does --debug-configuration say?

notice: will use 'C:/Progra~2/MICROS~4.0/VC/Clang 3.7/bin/x86/clang.exe' for clang-win, condition <toolset>clang-win-3.7-vc14 notice: [clang-cfg] condition: '<toolset>clang-win-3.7-vc14/<architecture>/<address-model>', setup: 'call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86 > nul' notice: [clang-cfg] condition: '<toolset>clang-win-3.7-vc14/<architecture>/<address-model>32', setup: 'call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86 > nul' notice: [clang-cfg] condition: '<toolset>clang-win-3.7-vc14/<architecture>x86/<address-model>', setup: 'call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86 > nul' notice: [clang-cfg] condition: '<toolset>clang-win-3.7-vc14/<architecture>x86/<address-model>32', setup: 'call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86 > nul' notice: [clang-cfg] condition: '<toolset>clang-win-3.7-vc14/<architecture>/<address-model>64', setup: 'call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86_amd64 > nul' And user-config.jam has: using clang-win : 3.7 : "C:/Progra~2/MICROS~4.0/VC/Clang 3.7/bin/x86/clang.exe" : <cxxflags>-std=c++11 <compatibility>vc14 ; Thanks, John.

Hi, I have an interest in this thread. It seems (to me, but I might be wrong) not everybody is talking about the same thing. There are two usable versions of clang targetting VC, the (main) difference is in the back-ends, one has the LLVM back-end (http://llvm.org/builds/), the other the C2 back-end ( https://blogs.msdn.microsoft.com/vcblog/2016/01/20/clang-with-microsoft-code...). The Clang/LLVM compilers Clang-Cl.exe, Clang.exe and Clang++.exe are al just copies of the same file. It's unclear to me why M$ doesn't stick the C1 front-end to the LLVM back-end instead (as LLVM seems to consistently produce faster code), but it's M$, so what to expect. Both integrate into the IDE, Clang/C2 better than Clang/LLVM. Clang/C2 is Clang version 3.7.0, while Clang/LLVM is a (roughly weekly) snapshot build, currently at 3.9.0. Passing commands to Clang/LLVM in the IDE requires the use of -Xclang to precede the parameter passed to the (Clang/LLVM) compiler (directly in the command lines options). Although this is not the normal way to use the IDE, it is actually pretty handy, and gives good control. It seems that the VC14-STL-headers (and obviously only these) are sufficiently cleaned up to be handled by Clang/LLVM. The compatibility mode works fine, but with Clang/LLVM, they will be signalled out as microsoft-extensions. This does not happen when using the M$-STL (the one included with VC14!!!), so they seem good (unless things are happening in the background, I'm not aware about). I said earlier I was using Clang/LLVM/VS2015, but I use boost compiled with VC14. There are issues I've noted in another thread, there are undoubtedly more, but one can only use (and therefore test) so much of boost. Most of the compiled libraries libraries, I use, won't benefit much from clang compilation, f.e. filesystem, so I'm happy sticking with a VC-build. Others, like random (headers only for the important stuff), gets a huge boost :-) ) being compiled with the LLVM back-end. My point being (sorry for the windiness) that fixing the use (as a user) of boost headers in the setup of Clang/LLVM and VC14 should IMHO be first priority. This comes down to making Clang act as Clang (with clang-win) and not a mish-mash of VC and Clang. Clang and Cl (and the M$-STL) are moving towards each other, but it's still an ongoing process, and therefore a moving target. The promiss by STL (Steven, this time), is that in the end all will be good (a commitment to full adoption and adherence to the standards uptill and including C++17), but definitely not before VC15 (at the earliest). It would be great if some boost-vc-testers could also target Clang/LLVM/VC14. What could I do to make that happen? I admit I have little impetus to use clang on Windows targeting VC++ or

even the clang compatibility mode in the VC++ 14 IDE. Until the preprocessor problem is solved ( maybe it has been )

I don't really get what this means, could you please elaborate? What does "to use" and "the clang compatibility mode in the VC++ 14 IDE" mean. And what is "the preprocessor problem"? A good day to ya all, degski -- (\___/) (+'.'+) (")_(") This is Bunny. Copy and paste Bunny into your signature to help him gain world domination!

Hi Edward, First of, thanks for your elaborate answer, explaining the extent of the issues. The clang build which targets VC++ on Windows, as opposed to the clang

build which targets mingw(-64)/gcc on Windows, 'emulates' the non-standard VC++ preprocessor so it can compile Windows API headers and VC++ header files.

Do you imply here that the preprocessors of both Clang/LLVM and Clang/C2 work exactly the same way? For all I know clang targeting VC++ may indeed work with those libraries if

the libraries pretend that clang targeting VC++ is VC++ for the intention of those libraries.

Isn't that the way to go then, to make boost act as if Clang/LLVM is VC14. When using Clang/LLVM with the M$-STL there are no issues, so it must do a reasonable job AFAICS. Clang/LLVM definitely flags quite a few of the non-confirming issues your own code might have, which implies that the VC14-STL does not have those kind of issues anymore. Getting some of my older projects to compile (with Clang) at all is quite a hassle (looks like a different C++).

I made a suggestion to the clang developers that there 'emulation' of the non-standard VC++ preprocessor in their clang targeting VC++ implementation should be configurable so that when the compiler is not dealing with Windows API and VC++ header files it can be turned off and clang would then be the same C++ standard conforming preprocessor as it is with clang targeting mingw(-64)/gcc and clang on Linux and on the Mac. The suggestion was rejected. After that my interest in running clang targeting VC++ on Windows ended.

Again, why fight the Clang developers, go with the flow, Clang/LLVM wants to emulate VC++ perfectly, fine, should make your life easier no?

...which 'emulates' the VC++ preprocessor in various unknown ways...

With the above position taken, those unknown ways would then hopefully be identified and emulated by the Clang team... M$ is in the loop as well, as far I understand, so it's not exactly reverse-engineering. Have a good day, degski -- (\___/) (+'.'+) (")_(") This is Bunny. Copy and paste Bunny into your signature to help him gain world domination!

Hi Edward, I don't know what you mean by Clang/LLVM and Clang/C2. I wrote this earlier: "There are two usable versions of clang targetting VC, the (main) difference is in the back-ends, one has the LLVM back-end ( http://llvm.org/builds/), the other the C2 back-end ( https://blogs.msdn.microsoft.com/vcblog/2016/01/20/clang-with-microsoft-code...). The Clang/LLVM compilers Clang-Cl.exe, Clang.exe and Clang++.exe are al just copies of the same file." If you read John top-post you'll see he also refers to those two different compilers. By "targeting" on Windows I mean that clang is built to use either the gcc

RTL or the VC++ RTL. The version which targets the VC++ RTL has a VC++ conforming non-standard C++ preprocessor while the one targeting the gcc RTL has a C++ standard conforming preprocessor.

Targeting Windows and GCC (RTL) are two mutually exclusive notions. I guess you are referring to MinGW. although it works, one can hardly call it targeting windows, it's a usefull workaround for things that won't work otherwise ((like compiling OpenBlas.lib f.e., as there is no free native Fortran compiler on Windows, but this has issues, like obligatory dll's instead of static libs). They are two distinctly different implementations.

Sure.

No !!! Why should Boost support a non-conforming C++ preprocessor when a perfectly good conforming preprocessor is available from clang for anything which does not target VC++.

Boost is already supporting the non-conforming C++ preprocessor.

Try running Boost PP with a VC++ conformant preprocessor without the VC++ workarounds in Boost PP and you will find more issues than you can imagine.

Sure, but there's no compelling reason to try and do that. Your logic does not follow.

What I'm trying to get across is that Clang/LLVM treats the VC14-STL as bog-standard C++ (and it works, so it must be conforming). I know this, because it also assumes my own code is standard conforming and protests if it doesn't. It flags issues in Intel's Thread Building Blocks as well f.e.. Clang is used on Linux, Mac, and Windows and maybe a few other OSs I don't

know about. It only emulates VC++ when it is built for Windows targeting VC++. You still don't seem to understand that in the vast majority of its uses clang has a C++ standard conforming preprocessor while in a single one of its uses clang has a VC++ emulated non-standard C++ preprocessor.

Yes, I do understand that it's different. But boost is already supporting this different PP, as it is already supporting VC. The Clang team is doing the work here. I get your frustration, but in practice I don't see an issue. Feel free to offer "workarounds" in Boost PP and Boost VMD to deal with the

clang targeting VC++ 'emulation' because I know I will not be doing anything to get that 'emulation' working in those libraries. I have already been down that path with VC++ itself and will not be repeating that experience with another broken C++ preprocessor.

I've been looking at the approach John takes in the top-post and got a bit futher than he did. I'll answer to his post with my findings. Have a good day, degski

Hi Edward, An executable built with mingw(-64)/gcc runs natively on Windows, so your

comment above makes no sense.

Yes, I use plenty of those (mingw) executables all the time. But executables, I download, libraries (like boost) I use to create (my own) executables. It's hard enough supporting the non-conforming VC++ preprocessor. I

personally have no intention of supporting another non-conforming implementation of the C++ preprocessor in clang's 'emulation' of VC++ in Boost PP or Boost VMD. If you or someone else wants to do it, go ahead.

The clang-team has as one of its objectives to be compatible with VC, and they encourage you to report differences/problems with compiler switches (lost the link). You write: "...I personally have no intention...". That's fine, the world doesn't revolve around you alone, I (and John Maddock (the OP) amongst others) would like it to work, and work correctly. The issue is the huge amount of work involved in supporting a

non-conforming C++ preprocessor such as VC++ in Boost PP and Boost VMD. The answer to that is not to create another different non-conforming C++ preprocessor.

No, I get that, the answer should be that the clang-team should emulate VC++ perfectly (their intention, so help them), so YOU don't have any issues. I'm getting the impression you are getting religious about this "it's not the same issue". Yes it's not the same, but at the same time M$ has committed to be/get more (even fully?) compliant, and the clang-team works hard to bridge the gaps as well (and as far as I understood with help of M$). This is my last post on this particular issue, I'd rather concentrate on getting boost (compiled with whatever compiler (VC14 is fine)). Static boost libs linked to a static vc-runtime is my requirement) to work with clang as a user of boost libraries. This is for now a problem, issues in typeof and type_traits prevent this (and maybe others, but we won't know untill the typeof and type_traits issues are fixed, as they propagate). I hope you found some easter-eggs this morning, if you didn't, I wish you a good day anyway and here's my easter-bunny for comfort: (\___/) (+'.'+) (")_(") degski

Edward Diener wrote:

Then you and whoever would like to have Boost PP and/or Boost VMD work with clang emulating VC++ can make the changes in those libraries to support what you want as far as I am personally concerned.

The point is that no changes need to be made to Boost PP/VMD. You just make sure you're using the VC++ code instead of the conforming code, and if that doesn't work, the ball is in Clang's court, because it was their decision to be bug compatible.

Edward Diener wrote:

I need to know what are the preprocessor defines being set by clang when it is in the mode that supports VC++. Is both __clang__ and _MSC_VER defined in all cases ?

They are, although I'm not sure whether _MSC_VER is enabled by -fms-compatibility, or just by -fms-extensions. If the latter, it won't be possible to reliably detect the former. I also don't know which of those flags enables the broken preprocessor.

On 3/28/2016 7:17 AM, Peter Dimov wrote:

Edward Diener wrote:

...

I need to know what are the preprocessor defines being set by clang when it is in the mode that supports VC++. Is both __clang__ and _MSC_VER defined in all cases ?

They are, although I'm not sure whether _MSC_VER is enabled by -fms-compatibility, or just by -fms-extensions. If the latter, it won't be possible to reliably detect the former. I also don't know which of those flags enables the broken preprocessor.

According to what I was able to find out in the clang developers mailing list the presence of _MSC_VER being predefined along of course with __clang__ being predefined means that clang is implementing the emulation of the VC++ non-standard preprocessor. Also, aside from clang-cl, the clang or clang++ executables can also cause this emulation of the VC++ non-standard preprocessor whenever it is targeting an MSVC environment. I did not find out all the command line switches by which clang/clang++ is targeting an MSVC environment but I was given the switch '--target=x86_64-windows-msvc' as an instance of this targeting of an MSVC environment from clang/clang++ directly. I am currently testing changes to my local Boost PP develop /boost/preprocessor/config/config.hpp file which enables clang with _MSC_VER being defined to act like VC++. This file controls certain general compiler identification both for Boost PP and Boost VMD, which makes compiler workarounds in both libraries possible. If I have any trouble testing clang-cl, given the messages in this thread, I will post back asking for further help. Once I finish local testing I will update the develop branch with my changes. Afterwards if they are any problems with clang's emulation of the VC++ preprocessor for library developers whose libraries use Boost PP and who want to test with clang targeting VC++ I would expect those developers to report such problems to clang. As I realize I have been perhaps too adamant in saying I do not want to be taxed with the problem of figuring out a possible problem in clang's emulation of VC++ preprocessor in Boost PP or Boost VMD when the VC++ workaround itself does not have the same problem. But if this actually happens others are welcome to fix such issues if they occur or create PRs for them, as well as reporting the issue to clang if that's what they want to do. Hopefully no such problems will come up, but as someone who has encountered VC++ preprocessor quirks in Boost PP and Boost VMD I will be a bit amazed if the clang developers, as good as they are, have emulated all of them, whatever actually causes them, correctly.

On 3/27/2016 6:15 PM, Niall Douglas wrote:

On 26 Mar 2016 at 6:52, Edward Diener wrote:

...

The clang build which targets VC++ on Windows, as opposed to the clang build which targets mingw(-64)/gcc on Windows, 'emulates' the non-standard VC++ preprocessor so it can compile Windows API headers and VC++ header files. Exactly what VC++ preprocessor 'bugs' it emulates and how successful this emulation is I do not know, but I know it is done because I was told of it in the clang developer forum and I encountered a clang targeting VC++ preprocessor 'bug' which was explained to me as an emulation of VC++.

As of VS2015 Update 2 RC, the MSVCRT, STL and Windows SDK headers supplied no longer require clang to act in MSVC compatibility mode to compile. I am compiling AFIO v2 for windows using LLVM clang with these options:

clang.exe -fpic "stdafx.h" -fmsc-version="1900" -std=c++1y "x64\Debug clang\" -Wall -fstrict-aliasing -I "../include" -g2 -gdwarf-2 -O0 -x c++-header -U "__STDC__" -D "WIN32" -D "_DEBUG" -D "_WINDOWS" -D "_USRDLL" -D "BOOST_AFIO_EXPORTS" -D "_UNICODE" -D "UNICODE" -D "UNICODE=1" -D "_UNICODE=1" -D "AFIO_STANDALONE=1" -frtti -fno-omit-frame-pointer -fno-ms-compatibility -fexceptions -o "x64\Debug clang\%(filename).obj" -fms-extensions -fno-short-enums

The key improvement with VS2015 Update 2 is the -fno-ms-compatibility is now possible even when using the Dinkumware STL, the Parallel Patterns Library or the Windows SDK. This means that clang treats your code as strictly as normal, and it is *very* useful for linting your code (the complete C++ 14 language support is also very handy).

Note that I cannot get MSVCRT-as-a-dll working with this configuration, for that you still need -fms-compatibility. MSVCRT-as-a-static-library is working. I assuming this is a RC related problem which will be fixed soon, the cause is the char16_t and char32_t support misdetection.

I am not using any preprocessor tricks which are incompatible with MSVC, so I cannot say if the broken preprocessor emulation is still present with -fno-ms-compatibility. I would suspect not. -fms-extensions are things like declspec markup support, I am not aware of it changing any parsing behaviour.

I do not have any idea any longer which versions/implementations of clang 'emulate' the VC++ preprocessor currently. There now appear to be standalone versions of llvm/clang as always and versions of clang which are part of a VC++ release, whic allow clang to be used as the backend compiler. I haven't kept up with the different manifestations of clang on Windows lately. My point is simply that a version of clang for Windows has existed targeting VC++ which specifically 'emulates' the non-standard VC++ preprocessor. The non-standard VC++ preprocessor gets special treatment in quite a few cases in Boost PP and Boost VMD or else it will simply fail using much of those libraries. Therefore if versions of clang which 'emulate' the VC++ preprocessor attempt to use Boost PP and Boost VMD it too will fail in a large number of cases. I have no idea whether AFIO v2 uses Boost PP. I am perfectly willing to set clang targeting VC++ on Windows which 'emulates' the VC++ preprocessor to essentially act like the VC++ preprocessor in Boost PP and Boost VMD if I can unequivocally identify this version at preprocessor time. Then if it fails to compile parts of Boost PP and Boost VMD it will be a problem for the clang developers to solve, because I have no interest in trying to workaround such problems in Boost PP and Boost VMD for yet another non-conformant C++ preprocessor. I also want to point out that the normal standard conformant clang preprocessor is different enough from the clang 'emulation' of VC++ preprocessor that it is imperative to identify each one or else Boost PP and Boost VMD will not work in large parts of their implementation. Of course if a Boost library does not use Boost PP ( or Boost VMD which no Boost libraries of which I am aware currently use ), or uses a very small part of Boost PP not affected by the many VC++ workarounds in Boost PP, it is possible it will not run into problems with clang 'emulating' VC++. But I would not count on such lucky behavior.

On 02/04/2016 21:36, Adam Merz wrote:

FWIW, here are the changes I made to Boost.Config to get Clang/C2 working on a project of mine that only uses header-only libs from Boost: https://gist.github.com/dodheim/918e9dc480fe39e590c3af2ceb706e1b

The `BOOST_HAS_` additions are for parity with visualc.hpp and are of lesser importance.

I think most of those are in develop already, the multiprecision one has just been committed, I suggest you file a PR for the ASIO one. Thanks, John.