
Bringing Clang to Windows - intrepidsoldier
http://blogs.msdn.com/b/vcblog/archive/2015/05/01/bringing-clang-to-windows.aspx
======
DannyBee
I agree with folks who think this is a bit confusing.

This blog post is announcing:

1\. Using clang as a frontend.

2\. Using C2 (MS compiler) as a backend.

What the LLVM community (IE not MS so far, but participation is of course,
welcome)) has been building:

1\. Using clang as a frontend

2\. Using llvm as a backend

and even more specifically

1\. Using MS Headers + MS Libraries

2\. Using clang as a frontend

3\. Using llvm as a backend.

(see blog.llvm.org/2014/07/clangllvm-on-windows-update.html for a 9 month old
view)

Some of the mingw32 folks have been working on replacing #1 with non-ms stuff,
but let's put that aside for the sake of this description )

Using clang as a frontend is where almost all of the ABI compatibility happens
anyway (and where various developers have been focusing), so you end up with
VC++ ABI compatible binaries whether you use C2 or not, if you/they use the
pre-existing clang stuff.

Whether they are doing that (and then lowering llvm ir to c2 ir) , or if
they've built an alternative IR generation with clang (IE generating c2 ir
directly from clang), that they haven't released, is not clear.

If they've built something that generates C2 IR from clang, they would have
had to write their own ABI compat, which would mean it may be different than
the binaries clang would build.

(exception handling is also codegen'd by llvm, so exception handling could end
up different, though of course, compatibility is the goal)

~~~
spongo2
Hi DannyBee, sorry if we didn't get the message out clearly. Jim Radigan gives
a deeper technical explanation in the build talk he did yesterday.
[http://channel9.msdn.com/events/Build/2015/3-610](http://channel9.msdn.com/events/Build/2015/3-610)
It's translating LLVM IR to C2 IR. We know that the Clang/LLVM community is
hard at work on implementing the MS-ABI and we've reached out to a few
developers working on ABI stuff as well as symbols support. We intend to
engage with that community more openly now that we've announced but of course
shipping the code will be our top priority. One important contribution of the
Clang/C2 approach is that we will have full native VS debugger support. This
is just the first step in a longer journey. Thanks, Steve, VC Dev Mgr

~~~
BruceM
Hello! Is there any chance that this would work with other language front-ends
that generate LLVM IR?

~~~
spongo2
see Jim Radigan's build talk on compiling Objective-C for windows for more
info on this :)

------
revelation
I'm a bit confused about how this will work exactly. If I have Clang and VC++
compiled code trying to interop with each other, what happens if Clang decided
to use a different memory layout for std::string (or any other type really)
than VC++? What compiler is doing which task in the pipeline here exactly?

I mean, the reason everyone does interop strictly in C is that there are zero
standards for how a compiler implements the C++ features exactly down-low.

~~~
cokernel_hacker
Clang has, for some time now, supported the MSVC ABI.

Here is their implementation of name mangling: [http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/AST/Micros...](http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?revision=235831&view=markup)

Here is their implementation of record layout: [http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/AST/Record...](http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/AST/RecordLayoutBuilder.cpp?revision=235680&view=markup#l2075)

Here is their implementation of vtable generation:
[http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/AST/VTable...](http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/AST/VTableBuilder.cpp?revision=236355&view=markup#l2384)

Here is their implementation of RTTI: [http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/CodeGen/Mi...](http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp?revision=236161&view=markup#l2919)

Here is their implementation of C++ throw metadata:
[http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/CodeGen/Mi...](http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp?revision=236161&view=markup#l3644)

~~~
bla2
But none of that was written by Microsoft employees, so I'm a bit confused
about what exactly this blog post is announcing. It feels a bit like they're
taking credit for the work done by the clang community.

~~~
spongo2
We are announcing that we will ship a hybrid compiler that combines the clang
frontend with the c2 existing backend. We will fully support that for building
portable code within Visual Studio for Windows. We definitely don't want to
take credit for the clang community's work. We have a ton of respect for those
developers. We intend to make contributions back to the community and we've
started to reach out to some of the relevant parties. Thanks, Steve, VC Dev
Mgr

------
phkahler
I'm starting to see a strategy here. I've been wondering how Microsoft can
make money from all.this open source activity. Their platform is becoming
obsolete, but is being replaced by OSX, iOS, and android. That makes
developers unhappy because of the multiple OSes they need to support. But MS
can step in and bring their own platform as an abstraction over these others
and make developers happy. Build once, target everything. I'm betting key
pieces will not become open source, they want to have control over the new
platform. That is the midterm goal - regain control (even a little bit) of a
dominant platform.

~~~
PeteJacobs23
Windows is not becoming obsolete. Quite the opposite. In the enterprise
Windows will stay for a long time. I'm working at company > 500000 employees
and our IT will be very happy when they can replace the iOS devices with
Windows equivalents. And certainly the Desktops aren't going to be replaced by
OSX. Even more with Windows 10 around.

MS strategy is much more straight forward. Simply offer reasons and make it
easier for customers to use their products. Mainly the cloud and mobile
services. They're just smart enough to understand where Google and Facebook
make their money with - not by selling OS.

~~~
Demiurge
I agree. We've been using OpenLDAP for 3 years now, and it has been a very
scary, black magic experience, just trying to get basic stuff like DNS, NFS,
mac, windows clients, working. Hoping to move to Windows AD as soon as
possible.

------
istvan__
Hell yeah! Microsoft just became one of the viable platforms this week in the
cheap segment with reasonable licensing.

~~~
yarrel
Still not in the free as in speech and beer segment though.

------
brentshields
"So, any minor divergence in features of Clang and Visual C++ will cause you
as a developer to have to worry about these compiler differences or limit you
to using the smallest subset of the two compiler features"

In other words, the set of vc++ features.

~~~
intrepidsoldier
Yes. We know we are behind on conformance.

------
malkia
Wow! Microsoft! Wow! You should've had Satya Nadella as CEO ages ago!
Congrats!

------
nerraga
At approx. 26min he mentions four processors that their code generator has to
target: ARM32, x86, x64, and a new one coming out in the fall. What would that
be? ARM64? *edit - never mind. Last five seconds they hint at it as arm64. MS
is definitely doing some interesting stuff these days.

------
mwcampbell
If the Windows team at MS thinks of c2 and the MS linker as part of the
Windows ABI, then I guess the MinGW toolchain (and a hypothetical clang
toolchain where LLVM generates the native code) will always be second class,
and therefore best avoided by developers who want to target Windows, even for
classic Win32 desktop apps.

~~~
coliveira
It all depends on how cutting edge you want to be in the windows platform. If
you want access to the latest technology, MS tools will always be the
necessary choice -- Borland learned this lesson after a lot of hard work. But
if you want to create products using the stable version of the windows API,
gcc is already a very good choice.

~~~
spiralpolitik
I kind of disagree here. Compilers reached commodity status a long time ago.
Nobody makes money off them compared to how it was in the 90s and the list of
ex-compiler makers is as long as your arm (Watcom, Metrowerks etc).

'clang' is probably approaching the point that its good enough so the question
for Microsoft is do they still see any value in continuing the develop their
own compiler or should they just switch to 'clang' ?

I think this is the big shift we are seeing in MS this year. Instead trying to
owning everything, they seem to be shifting their focus to owning the parts
that have value and commoditizing the rest. The strategy was successful for
Apple so its unsurprising that Microsoft is looking to a similar strategy as
part of their salvation.

~~~
coliveira
I think they want compatibility with other compilers, but unless they move
alway from Windows, there is a lot of their APIs that require close
compiler/library support: COM, DCOM+, .NET, etc. They will probably need at
least to maintain VC++ for a long time.

~~~
intrepidsoldier
Add WinRT to that list and you have a set that is somehow reason enough for
Visual C++ compiler front-end to stay relevant.

------
__Joker
The broader stroke is MS to be relevant in the platforms side of the story.
Sometime people will argue that windows is used extensively in enterprises,
but obviously the today startup which will be tomorrows enterprises are using
almost no MS eco system.

------
twoodfin
Where does C2 come in on the stack? Is it compiling/translating LLVM IR?

~~~
intrepidsoldier
The latter.

------
Phlow
What's the situation with SEH these days in Clang?

~~~
spongo2
[http://clang.llvm.org/docs/MSVCCompatibility.html](http://clang.llvm.org/docs/MSVCCompatibility.html)
says minimal. Note that this is about cross-plat conformant c++ code. SEH is
windows specific.

~~~
cokernel_hacker
That document is out of date. SEH works OK for 64-bit X86, 32-bit X86 is
ongoing. Catching C++ exceptions has been implemented for 64-bit X86 but isn't
ready for prime time.

------
davidgerard
> and is fast becoming the preferred C++ compiler for non-Windows platforms.

They wish. Microsoft still hates GNU.

~~~
ComputerGuru
It is, though. And Microsoft isn't alone in hating GNU - FreeBSD no longer
ships with or uses GCC; the entire FreeBSD kernel and userland is built with
Clang these days. And, of course, Apple's the one that started this whole
stampede away from GCC in the first place. LLVM/Clang really and truly have
hit GCC hard - and definitely for the best. Look at the improvements to GCC
spurred by newer features in the Clang build toolchain.

EDIT:

In reply to davidgerard's comment below:

> I will not believe this falsifiable claim without numbers. FreeBSD has
> almost no users compared to Linux.

Non-Windows does not mean Linux.

And what falsifiable claim? They didn't say Clang _is_ the most popular - they
said it's becoming. But if that's really the game you want to play, then it's
_Linux_ that has almost no users compared to the number of
iPhones/iPads/iWatches/MacBooks out there - Clang/LLVM-powered, each and every
one of them.

~~~
istvan__
There are several reasons why FreeBSD is ditching GCC, one of them is
licensing. I am wondering what are the technical reasons though...

~~~
jlarocco
There was a Stack Exchange question answering exactly this question:

[http://unix.stackexchange.com/questions/49906/why-is-
freebsd...](http://unix.stackexchange.com/questions/49906/why-is-freebsd-
deprecating-gcc-in-favor-of-clang-llvm/49970#49970)

Another contributing factor may be momentum. Clang is easier to work with than
GCC, and doesn't have the baggage of GCC, so more and more people and
companies are starting to use it, fund it, and commit code to it. It's been
improving in leaps and bounds, and still rapidly improving. It's only a matter
of time before it's all around better than GCC.

