[boost] Boost.Build and Microsoft C2 clang

[Niall Douglas via Boost]

Can someone who has this working right please tell me how they persuaded
Boost.Build to correctly invoke Microsoft C2 clang as the compiler and
get it to link properly?

My GSoC student has tried:

- Configuring clang-win, this is a no-go, C2 clang comes in GCC
arguments accepting form, not MSVC arguments accepting form. And no
there is no clang-cl program supplied by Microsoft.

- Configuring mingw gcc but with the C2 clang executable, this compiles
code okay but fails at the link stage for some reason, probably it's
trying to invoke the mingw linker and we want the Microsoft linker.

Any help much appreciated.

Niall

[Peter Dimov via Boost]

Post by Niall Douglas via Boost
Can someone who has this working right please tell me how they persuaded
Boost.Build to correctly invoke Microsoft C2 clang as the compiler and get
it to link properly?

This is what I have in my user-config from earlier tests:

using clang : 14.1 :
"C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/ClangC2/14.10.25903/bin/HostX86/clang.exe" :
<linkflags>-v
<linkflags>"-fuse-ld=\"C:\\Program Files (x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25903\\bin\\HostX86\\link.exe\""
;


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

[Tom Westerhout via Boost]

Post by Peter Dimov via Boost
"C:/Program Files (x86)/Microsoft Visual
<linkflags>-v
<linkflags>"-fuse-ld=\"C:\\Program Files (x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25903\\bin\\HostX86\\link.exe\""
;

Somehow clang decides to prepend target to the linker command:

"i686-pc-windows-msvc-C:\\Program Files (x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX86\\x86\\link.exe"

gets called in place of

"C:\\Program Files (x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX86\\x86\\link.exe"

Clang then complains that the program is not executable. Well, obviously,
it is not. Do you know how to work around this issue?


Tom

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

[Peter Dimov via Boost]

Post by Tom Westerhout via Boost

Post by Peter Dimov via Boost
"C:/Program Files (x86)/Microsoft Visual
<linkflags>-v
<linkflags>"-fuse-ld=\"C:\\Program Files (x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25903\\bin\\HostX86\\link.exe\""
;

"i686-pc-windows-msvc-C:\\Program Files (x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX86\\x86\\link.exe"
gets called in place of
"C:\\Program Files (x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX86\\x86\\link.exe"
Clang then complains that the program is not executable. Well, obviously,
it is not. Do you know how to work around this issue?

No idea. I think that this worked before, an update to VS 2017 probably
broke it. I can't find where in Clang's sources is the i686-pc-windows-msvc-
prepended and why, and massaging the path doesn't help. -fuse-ld is handled
here:

https://clang.llvm.org/doxygen/ToolChain_8cpp_source.html#l00375


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

[Niall Douglas via Boost]

Post by Peter Dimov via Boost

Post by Peter Dimov via Boost

Post by Peter Dimov via Boost
"C:/Program Files (x86)/Microsoft Visual

Studio/2017/Community/VC/Tools/ClangC2/14.10.25903/bin/HostX86/clang.exe"

Post by Peter Dimov via Boost
<linkflags>-v
<linkflags>"-fuse-ld=\"C:\\Program Files (x86)\\Microsoft Visual

Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25903\\bin\\HostX86\\link.exe\""

Post by Peter Dimov via Boost
;

"i686-pc-windows-msvc-C:\\Program Files (x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX86\\x86\\link.exe"
gets called in place of
"C:\\Program Files (x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX86\\x86\\link.exe"
Clang then complains that the program is not executable. Well,
obviously, it is not. Do you know how to work around this issue?

No idea. I think that this worked before, an update to VS 2017 probably
broke it. I can't find where in Clang's sources is the
i686-pc-windows-msvc- prepended and why, and massaging the path doesn't
https://clang.llvm.org/doxygen/ToolChain_8cpp_source.html#l00375

Might it have something to do with "address-model=64" being missing from
the b2 command invocation perhaps?

Niall

[Peter Dimov via Boost]

Post by Peter Dimov via Boost
No idea. I think that this worked before, an update to VS 2017 probably
broke it.

The plain -fuse-ld=link.exe kind of works now (it didn't before.) There are
other problems however, exceptions are off for some reason.


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

[Peter Dimov via Boost]

Post by Peter Dimov via Boost
The plain -fuse-ld=link.exe kind of works now (it didn't before.) There
are other problems however, exceptions are off for some reason.

using clang : 14.1 :
"C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/ClangC2/14.10.25903/bin/HostX86/clang.exe" :
<cxxflags>-fexceptions
<linkflags>-fuse-ld=link.exe ;

kind of works. This cannot be considered a serious toolset though. Why not
use the LLVM Clang instead?


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

[Tom Westerhout via Boost]

Post by Peter Dimov via Boost

Post by Peter Dimov via Boost
The plain -fuse-ld=link.exe kind of works now (it didn't before.) There
are other problems however, exceptions are off for some reason.

"C:/Program Files (x86)/Microsoft Visual
<cxxflags>-fexceptions
<linkflags>-fuse-ld=link.exe ;
kind of works. This cannot be considered a serious toolset though. Why not
use the LLVM Clang instead?

Why not? It's just a different front-end, isn't it?

In my case, MSVC doesn't handle constexpr correctly, but Clang does. But
optimisation and code generation are still done by the C2, right? So I can
test now how good MSVC would be able to optimise my code rather than
waiting for the bug to be fixed. I.e. this gives me the ability to
optimise my code now while I don't have much code yet and can refactor
things easily.


Tom

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

[Niall Douglas via Boost]

Post by Peter Dimov via Boost
kind of works. This cannot be considered a serious toolset though. Why

I've been using C2 clang as my daily Windows compiler for over a year
now. Just for the improved warnings and diagnostics alone it is amazing.
I know Microsoft say it's not production ready, but I think they more
are referring to incompleteness rather than quality of output. It does
also ICE quite a bit, but much less than MSVC which Outcome v2 currently
murders despite being a very simple C++ library, much less complex than
Outcome v1 (bug is submitted to Microsoft, they have confirmed it).

Niall

[Stephan T. Lavavej via Boost]

[Niall Douglas]

I've been using C2 clang as my daily Windows compiler for over a year now.
Just for the improved warnings and diagnostics alone it is amazing.
I know Microsoft say it's not production ready

Sorry, but we aren't planning to update Clang/C2 for C++. Clang/C2 3.8 in VS 2017 15.3 (first toolset update) will be the final version supported by our STL. We're now testing our STL with Clang/LLVM 4.0 which will be supported in the second toolset update - unless (depending on release timing) I increase the required version to Clang/LLVM 5.0.

The Clang/LLVM team has been doing amazing work to ensure source and binary compatibility; by "will be supported" I mean that on Microsoft's end, we're running Clang/LLVM in our test harness (against our own test suites, and libc++'s tests with our STL) to find obscure issues and prevent regressions as we change our code and take advantage of new features. For example, Clang/LLVM 4.0 lacked an atomic builtin; the workaround is to include <intrin.h> before <atomic>. In the second toolset update, I do this automatically as a workaround for 4.0 (and will remove this for 5.0). We've also reported a few bugs upstream, which will improve Clang for everyone.

This is much like how Boost supported MSVC for many many years, but now we extensively test it against our development compiler, preventing many bugs from ever appearing.

Stephan T. Lavavej
Principal Software Engineer, Visual C++ Libraries

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

[Peter Dimov via Boost]

Post by Stephan T. Lavavej via Boost
Sorry, but we aren't planning to update Clang/C2 for C++. Clang/C2 3.8 in
VS 2017 15.3 (first toolset update) will be the final version supported by
our STL. We're now testing our STL with Clang/LLVM 4.0 which will be
supported in the second toolset update - unless (depending on release
timing) I increase the required version to Clang/LLVM 5.0.

But Clang/C2 is installed by the Visual Studio installer and can be chosen
as a toolset from the dropdown; will the update install Clang/LLVM instead?


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

[Stephan T. Lavavej via Boost]

[Peter Dimov]

Post by Peter Dimov via Boost
But Clang/C2 is installed by the Visual Studio installer and can be chosen
as a toolset from the dropdown; will the update install Clang/LLVM instead?

At this time, we aren't planning to add Clang/LLVM to the VS installer.

(I should mention that while we're testing Clang/LLVM with our STL and I consider it to be a supported front-end equal to C1XX and EDG, it isn't *officially* supported by Microsoft, and other libraries aren't being tested with it.)

STL

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

[Peter Dimov via Boost]

Post by Stephan T. Lavavej via Boost
[Peter Dimov]

Post by Peter Dimov via Boost
But Clang/C2 is installed by the Visual Studio installer and can be
chosen as a toolset from the dropdown; will the update install
Clang/LLVM instead?

At this time, we aren't planning to add Clang/LLVM to the VS installer.

That's a bit odd; you won't be supporting the one that is being installed
and will be supporting one that isn't.


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

[degski via Boost]

Post by Peter Dimov via Boost
That's a bit odd; you won't be supporting the one that is being installed
and will be supporting one that isn't.

I guess the realisation has come that Clang/C2 is just a waste of time.
And, yeah, it's odd.

degski

[degski via Boost]

Post by Peter Dimov via Boost
kind of works. This cannot be considered a serious toolset though. Why not
use the LLVM Clang instead?

+1

Clang in the front, but VC in the back, it's a transpiler...

degski

[Peter Dimov via Boost]

Post by degski via Boost

Post by Peter Dimov via Boost
kind of works. This cannot be considered a serious toolset though. Why
not use the LLVM Clang instead?

+1
Clang in the front, but VC in the back, it's a transpiler...

To be fair, I was referring to the Boost.Build support (to the extent there
is one) for this toolset, and not to its quality or utility. I also use it
from the VS IDE and it's pretty good for double-checking code or compiling
something which VC can't.

Nevertheless, for those who'd take the advice to use the LLVM one, here's
what I have in user-config from last time:

using clang : 4.0 :
"C:/LLVM-4.0.0-x64/bin/clang.exe" :
<compileflags>-fmsc-version=1910 <linkflags>-fuse-ld=lld ;


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

[Andrey Semashev via Boost]

Post by Peter Dimov via Boost

Post by Peter Dimov via Boost

Post by Peter Dimov via Boost
"C:/Program Files (x86)/Microsoft Visual

Studio/2017/Community/VC/Tools/ClangC2/14.10.25903/bin/HostX86/clang.exe"

Post by Peter Dimov via Boost
<linkflags>-v
<linkflags>"-fuse-ld=\"C:\\Program Files (x86)\\Microsoft Visual

Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25903\\bin\\HostX86\\link.exe\""

Post by Peter Dimov via Boost
;

"i686-pc-windows-msvc-C:\\Program Files (x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX86\\x86\\link.exe"
gets called in place of
"C:\\Program Files (x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX86\\x86\\link.exe"
Clang then complains that the program is not executable. Well,
obviously, it is not. Do you know how to work around this issue?

No idea. I think that this worked before, an update to VS 2017 probably
broke it.

Looks more like it fixed it. Your version seems newer than what Tom quoted.

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

[Tom Westerhout via Boost]

Post by Andrey Semashev via Boost

Post by Peter Dimov via Boost
No idea. I think that this worked before, an update to VS 2017 probably
broke it.

Looks more like it fixed it. Your version seems newer than what Tom quoted.

Indeed, LLVM's code Peter gave a link to looks right too.

Post by Andrey Semashev via Boost
The plain -fuse-ld=link.exe kind of works now (it didn't before.) There
are other problems however, exceptions are off for some reason.

OK, no idea why, but this solves the problem. With ClangC2 I need to call
vcvarsall anyway (Boost.Build doesn't do it, because it thinks we're on
linux), so link.exe is on the PATH.

Thanks a lot!

By the way, should I maybe submit a feature request to Boost.Build to add
a clang-c2.jam? clang.jam currently dispatches between clang-darwin.jam
and clang-linux.jam, so it should be easy to add support for clang-c2.jam.
I don't yet feel competent enough with BB to implement it myself though.
Does anyone else want this functionality?


Tom

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