[boost] [build] How to use with clang on windows?

[John Maddock]

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

If I use:

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 ;

to configure the clang that ships with VC14 I see:

compile-c-c++
..\..\..\bin.v2\libs\smart_ptr\test\shared_ptr_basic_test.test\clang-vc14-win-3.7\debug\shared_ptr_basic_test.obj
clang.exe: error: no such file or directory: '/Od'
clang.exe: error: no such file or directory: '/Ob0'
clang.exe: error: no such file or directory: '/W3'
clang.exe: error: no such file or directory: '/GR'
clang.exe: error: no such file or directory: '/MDd'
clang.exe: error: no such file or directory: '/Zc:forScope'
clang.exe: error: no such file or directory: '/Zc:wchar_t'
clang.exe: error: no such file or directory: '/wd4675'
clang.exe: error: no such file or directory: '/EHs'

Same errors with the llvm clang-3.9.

On the other hand if I initialize with:

using clang : : "C:/Progra~2/LLVM/bin/clang.exe" : <cxxflags>-std=c++14
<compatibility>vc14 <cxxflags>-fms-compatibility-version=19.00.22609 ;

Then this sort of works for llvm clang, but not the msvc one (can't find
c2.exe), but the compiler is identified as "clang-linux" and I see:

LINK : warning LNK4044: unrecognized option '/-start-group'; ignored
LINK : warning LNK4044: unrecognized option '/Bstatic'; ignored
LINK : warning LNK4044: unrecognized option '/Bdynamic'; ignored
LINK : warning LNK4044: unrecognized option '/-end-group'; ignored

Plus some linker errors such as:

yield_k_test.obj : error LNK2019: unresolved external symbol __mm_pause
referenced in function "void __cdecl boost::detail::yield(unsigned int)"
(?yield@detail@boost@@YAXI@Z)

Ideas?

Thanks, John.


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

[Steven Watanabe]

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?
>
> If I use:
>
> 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 ;
>
> to configure the clang that ships with VC14 I see:
>
> compile-c-c++
> ..\..\..\bin.v2\libs\smart_ptr\test\shared_ptr_basic_test.test\clang-vc14-win-3.7\debug\shared_ptr_basic_test.obj
>
> clang.exe: error: no such file or directory: '/Od'

> <snip>
>

What is the command line that Boost.Build
generates for clang?

In Christ,
Steven Watanabe

[Steven Watanabe]

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.

> If I use:
>
> 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 ;
>

In Christ,
Steven Watanabe

[Peter Dimov]

John Maddock wrote:
> What's the correct way to configure clang on windows with current
> Boost.Build?
>
> If I use:
>
> 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 ;

Shouldn't you be using clang-cl.exe?

[Edward Diener]

If you look at clang.jam you will see that it means clang-linux when
not being used on the Mac. I have gotten clang-linux, meaning clang
targeting gcc, to work on Windows with mingw(64)/gcc. It works fine
compiling code but has occasional errors in linking because clang's name
mangling/visibility does not match that of gcc and it is using the gcc
linker.

Previously I had gotten clang targeting VC++ to work on Windows by
changing my local copy of clang.jam to invoke clang-win instead of
clang-linux with a toolset line like:

using clang : : MyPath/clang++.exe : <compatibility>vc12 ;

This was with the previous version of VC++.

However I stopped experimenting with this when I realized that clang
targeting VC++ was intent on duplicating the broken VC++ preprocessor
not only for Windows and VC++ headers, where it might be necessary, but
all other header files also.

At one time I wanted to get the clang.jam to be able to distinguish
between clang targeting mingw(64)/gcc and clang targeting VC++ on
Windows, but because I am not a jam programmer, except for very simple
things, I could not figure out how this could be done. I don't think any
of the Boost build experts wanted to spend time figuring this out either
so I just dropped it.

I hope some of this information helps. 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 can't see the point but I can understand that many others
feel different.

[degski]

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-codegen-january-2016-released/).
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!

[Edward Diener]

On 3/26/2016 12:58 AM, degski wrote:
> Hi,

>
>
> 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"?

The VC++ preprocessor is not a C++ standard conforming preprocessor.
Both Boost PP and Boost VMD perform various tricks to get the VC++
preprocessor to mostly work with those heavily macro based Boost
libraries. This working with VC++ in Boost PP and Boost VMD depends on
identifying the VC++ compiler. Many other Boost libraries use Boost PP
so using those other libraries with VC++ are affected by all the
workarounds in Boost PP to get the non-standard VC++ preprocessor to be
workable with Boost PP constructs.

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++.

It was hard enough work for Paul Mensonides to get the VC++ preprocessor
to work with Boost PP and it was hard enough work for me to get the VC++
preprocessor to work with Boost VMD that neither I nor, I assume, Paul
wants to go back and figure out another set of preprocessor 'bugs' to
get clang targeting VC++ to work with those libraries. 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. Since I have been basically taking care of Boost PP and
since I am the author of Boost VMD I have not tried clang targeting VC++
as VC++ in those libraries since I do not want to be tasked with fixing
another set on non-standard C++ preprocessor bugs for another compiler
if it does not work.

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.

Unless you have dealt with it personally you cannot know how difficult
it is doing the sort of preprocessor programming which Boost PP does and
Boost VMD does with the VC++ preprocessor. Being asked to work with
another preprocessor which 'emulates' the VC++ preprocessor in various
unknown ways is not a task I wish on anybody.

I fully understand why the clang developers in their efforts to have
clang on Windows work with VC++ had to 'emulate' the non-standard C++
preprocessor to work with Windows API and VC++ header files, since
enough quirks in those header files have depended on the non-standard
VC++ preprocessor. But propagating that non-standard preprocessor
behavior to all preprocessor processing is IMO a major mistake,
especially as the normal clang preprocessor is very good and C++
standard comnforming.

[John Maddock]

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?

[Peter Dimov]

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.

http://clang.llvm.org/docs/UsersManual.html#clang-cl

[degski]

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!

[Steven Watanabe]

AMDG

On 03/26/2016 07:08 AM, John Maddock wrote:
>
> On 25/03/2016 20:02, Steven Watanabe wrote:
>>
>> 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"
>

That should be calling link.exe, not clang.
If you're getting here, it means that compiling
succeeded. I don't have clang installed at
the moment, but when I run with -n, the command
line looks right.

file
bin.v2\libs\config\test\config_info.test\clang-vc14-win-3.7\debug\config_info.obj.rsp
"libs\config\test\config_info.cpp"
-Fo"bin.v2\libs\config\test\config_info.test\clang-vc14-win-3.7\debug\config_info.obj"
-TP /Od /Ob0 /W3 /GR /MDd /Zc:forScope /Zc:wchar_t
-fmsc-version=1900 /wd4675 /EHs -c
-DBOOST_ALL_NO_LIB=1
"-I."
compile-c-c++
bin.v2\libs\config\test\config_info.test\clang-vc14-win-3.7\debug\config_info.obj

call "C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\vcvarsall.bat"
x86 > nul
"clang.exe"
@"bin.v2\libs\config\test\config_info.test\clang-vc14-win-3.7\debug\config_info.obj.rsp"

clang-win.link
bin.v2\libs\config\test\config_info.test\clang-vc14-win-3.7\debug\config_info.exe

call "C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\vcvarsall.bat" x86 > nul
link /nologo /DEBUG /MACHINE:X86 /MANIFEST /subsystem:console
/out:"bin.v2\libs\config\test\config_info.test\clang-vc14-win-3.7\debug\config_info.exe"

@"bin.v2\libs\config\test\config_info.test\clang-vc14-win-3.7\debug\config_info.exe.rsp"
if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL%

>
> 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?
>

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

In Christ,
Steven Watanabe

[Edward Diener]

On 3/26/2016 10:38 AM, degski wrote:
> 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?

I don't know what you mean by Clang/LLVM and Clang/C2. But the normal
clang preprocessor and the clang preprocessor which works when clang is
built for Windows targeting VC++ are two different things. 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. They are two distinctly
different implementations.

>
> 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.

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++.

> When using Clang/LLVM with the M$-STL there are no issues, so it must do a
> reasonable job AFAICS.

What makes you think there are no issues ? 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.

> 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.

Your logic does not follow.

> 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?

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. There is a big difference between these
implementations. How would you propose supporting clang in preprocessor
code considering these differences ?

>
>
>> ...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.

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.

[John Maddock]

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.

[John Maddock]

> 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.

[Steven Watanabe]

AMDG

On 03/26/2016 11:24 AM, John Maddock wrote:
>
>> 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?
>

That makes a bit more sense. Somehow
everything from clang-win is getting dropped.

>> 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'

Unless you reformatted this it looks wrong. There should be a
new line before the last '

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
'

> <snip>

>
> 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 ;
>

I pasted this into my user-config.jam, and commented out
everything else, and I still can't reproduce the problem.

$ b2 -v
Boost.Jam Version 2015.07. OS=NT.

I tried develop:
$ git log
commit 37ba13295cbed023c41a677b0fa57f9f59696b8e
Author: Steven Watanabe <ste...@providere-consulting.com>
Date: Wed Mar 23 18:04:24 2016 -0600

Remove wrong if. This case is already handled correctly by the next
else if

and master:
commit e83838da44f46bbe1f9e07c61dd8d96d13be55df
Merge: b3ed07b 8b9dbbe
Author: Vladimir Prus <vladim...@gmail.com>
Date: Thu Mar 10 10:06:17 2016 +0300

Merge remote-tracking branch 'origin/develop'

The only local change to Boost.Build is
the patch that I sent.

I just installed clang with microsoft codegen,
and now I'm getting your original error:

"clang.exe: error: no such file or directory: '/Od'"

I suspect that the problems that you're getting
are caused by something other than my patch.
If you revert it, do you go back to the original
problem? My only guess at this point is that
you're initializing multiple versions of clang,
and they're interfering with each other.

In Christ,
Steven Watanabe

[degski]

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-codegen-january-2016-released/).
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

[degski]

Hi John,

An after-thought.

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 ;
>

Getting Clang/C2 to compile boost seems to be a waist of time, as the
back-end will still be VCXX (C2). VCXX (C1/C2) already compiles boost, so
what's the gain?

degski

[Edward Diener]

On 3/27/2016 6:50 AM, degski wrote:
> 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-codegen-january-2016-released/).
> 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

An executable built with mingw(-64)/gcc runs natively on Windows, so
your comment above makes no sense.

>, 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.

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.

>
>
>> 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.

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, which you then want to be supported in Boost PP and Boost
VMD, but to have organizations like Microsoft and clang adhere to the
C++ rules for preprocessing code. Clang actually does follow the C++
rules for preprocessing code in all respects except when it 'emulates'
VC++. Microsoft has never conformed to the C++ rules for preprocessing code.

[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]

[THIS IS MY SECOND TRY SENDING THIS EMAIL]

Hi John,

Been looking a bit into what you were trying, and found the following:

using clang : : "C:/Progra~2/LLVM/bin/clang.exe" : <cxxflags>-std=c++14
> <compatibility>vc14 <cxxflags>-fms-compatibility-version=19.00.22609 ;
>

clang.jam (for the moment) dispatches to linux by default (this is easily
changed) or invoke with clang-win instead of clang. Then clang.exe needs to
be clang-cl.exe (clang-win.jam has this hardcoded). The different binaries
(although simple copies) behave differently depending on the file name, it
seems, f.e. "clang-cl.exe /?" works, while "clang-cl.exe -help" does not
work, this is the opposite for clang.exe, clang++.exe. There's also a
cl.exe in the binaries, again a copy, but does it work the same? Would be
nice if the clang people could clarify this.

I've applied Steven's patch to the RC2. And I've used this:

using clang-win : 3.9 : "C:/PROGRA~2/LLVM/bin/clang-cl.exe" :
<compatibility>vc14 ;

Then I run:

bjam cxxflags="-Xclang -std=c++14 -Xclang -O2 -fms-compatibility
-fmsc-version=1900" "-sZLIB_SOURCE=%HOME%\zlib-1.2.8"
"-sBZIP2_SOURCE=%HOME%\bzip2-1.0.6" variant=release instruction-set=haswell
threading=multi link=static runtime-link=static
--stagedir=stage64_static_release address-model=64 architecture=x86
--without-python --without-mpi --disable-filesystem2 install >
msvc_log_install.log

This is not exactly how it should work IMHO, -Xclang -O2 should be /O2, but
that doesn't work. Above features haswell, but should be broadwell (don't
exist).

This gets me 15 libs (including bzip, zlib and nowide, so actually 12) out
of an expected 36:

libboost_atomic-39-mt-s-1_61.lib
libboost_bzip2-39-mt-s-1_61.lib
libboost_chrono-39-mt-s-1_61.lib
libboost_container-39-mt-s-1_61.lib
libboost_date_time-39-mt-s-1_61.lib
libboost_exception-39-mt-s-1_61.lib
libboost_filesystem-39-mt-s-1_61.lib
libboost_iostreams-39-mt-s-1_61.lib
libboost_nowide-39-mt-s-1_61.lib
libboost_program_options-39-mt-s-1_61.lib
libboost_random-39-mt-s-1_61.lib
libboost_regex-39-mt-s-1_61.lib
libboost_system-39-mt-s-1_61.lib
libboost_timer-39-mt-s-1_61.lib
libboost_zlib-39-mt-s-1_61.lib

There is an issue with the toolset variable, the file-names come out as
f.e. libboost_regex-39-mt-s-1_61.lib.

I'll attach the build log, some libraries don't compile because of the
issues raised by me in the other thread (typeof and type_traits). Some
options that don't belong to clang-cl.exe (see clang-cl.exe /?) get
presented to it, f.e. clang-cl.exe: warning: unknown argument ignored in
clang-cl: '-ftemplate-depth-1024'.

[SCRAP THAT, ATTACHEMENT REJECTED BY THE MODERATOR, 1MB (WTF) IS TOO MUCH]

Let me know if you're interested in the build log (I can send it to your
gmail-account if you would like that),

degski

[Edward Diener]

On 3/27/2016 10:56 AM, degski wrote:
> 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.

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. Paul
Mensonides, who is the author of Boost PP, may feel differently but it's
up to him to say what he wants for Boost PP in that regard.

Good luck !

[Peter Dimov]

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.

[Niall Douglas]

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.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/
http://ie.linkedin.com/in/nialldouglas/

[Edward Diener]

On 3/27/2016 1:19 PM, Peter Dimov wrote:
> 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.

In order to use VC++ code in PP and VMD the clang compiler supporting
VC++ has to be identified and set to use the VC++ workarounds. That code
for both PP and VMD is in /boost/preprocessor/config/config.hpp. 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 ?

[Edward Diener]

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.

[Peter Dimov]

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.

[Edward Diener]

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.

Thanks ! I have asked about this on the clang developer's mailing list.

[Edward Diener]

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.

[Adam Merz]

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.

Regards,
Adam (aka ildjarn aka Dodheim)

[John Maddock]

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.