Question about an interesting blog

Clang Frontend
1

Hello,

I was recently reading in the blog at

that clang/llvm made big progress in supporting native Windows as
target. This actually sounds pretty promising, but this blog raised
some questions you might be able to answer.

First, it seems to us that within that blog, the author often
mistakenly implying Windows is MSVC. In general, I assume that he
meant "Visual Studio Compatible" instead of the term "Windows". But I
am not sure if I got this right.

Next, the Visual Studio plugin is indeed a cool thing, but why should
I want to use a different compiler for native Windows-code in Visual
Studio Professional (required for plugin support), as the OP already
has a fully compatible, C++ bug-per-bug compatible non-free compiler
available (msvc)?

The news that now an application can be built with clang/llvm for
Windows native isn't actual something really new. This works together
with mingw-w64's runtime/header now for more than a year.
Nevertheless our community at mingw-w64 stopped working on llvm/clang
support as there were some major bugs, which made it impossible to
build more complex applications by clang/llvm for Windows. Btw this
was true for C and C++ languages.

Does clang/llvm support now dllimport/dllexport semantics? As far as
I can see this is still an open issue. Therefore the compiler is
still not usable for more serious applications.

As claimed by this article, the PSDK can be used now directly as
provided by MS, I would be interested to learn if the disable/enable
warning functionality by numbers is supported? Are the
sal-annotations supported? Is the pragma comment(lib, ...) & co
supported? Does clang/llvm supports the .metadata intializers for
DCOM? Is native TLS supported by it? Is the C++-name-mangling
compatible to VC implemented? Is the C __try/__except/__finally
supported?

Especially the missing dllimport/dllexport (on class and
variable/function-base) was the reason for mingw-w64's community to
stop to improve further support of clang/llvm. Furthermore there were
some issues about ABI. For 64-bit floating-point, variadic, and some
SEH-exception-mechanism were road-blocks, and for 32-bit & 64-bit
Windows the debug-information quality, and the missing support for
dllimport/dllexport/selectany (and some other) attributes were real
blockers.

If things have changed here, it would be great to read about that in
more detail in feature lists too. It would be great if you could
reply to us - mingw-w64 community and developers.

Thanks in advance,
Kai

2

From: cfe-dev-bounces@cs.uiuc.edu [mailto:cfe-dev-bounces@cs.uiuc.edu]
On Behalf Of Kai Tietz
Sent: Friday, September 06, 2013 7:25 AM
To: cfe-dev@cs.uiuc.edu
Subject: [cfe-dev] Question about an interesting blog

Hello,

I was recently reading in the blog at
A path forward for an LLVM toolchain on Windows - The LLVM Project Blog
that clang/llvm made big progress in supporting native Windows as
target. This actually sounds pretty promising, but this blog raised
some questions you might be able to answer.

First, it seems to us that within that blog, the author often
mistakenly implying Windows is MSVC. In general, I assume that he
meant "Visual Studio Compatible" instead of the term "Windows". But I
am not sure if I got this right.

Next, the Visual Studio plugin is indeed a cool thing, but why should
I want to use a different compiler for native Windows-code in Visual
Studio Professional (required for plugin support), as the OP already
has a fully compatible, C++ bug-per-bug compatible non-free compiler
available (msvc)?

I don't know about Chandler's motivation, but here's ours...

My users ask for this because there is value in using the same compiler
across platforms; it reduces porting costs because you are not fighting
with the compiler to produce consistently behaving code all the time.
Last I heard, MSVC did not support any other platforms, certainly not
any my users care about, while Clang/LLVM does.

There are other reasons to wish for a non-MSVC Windows-capable compiler
(e.g., Clang is doing better at keeping up with the C++ standards).
But consistency across platforms is what my guys mostly want.
--paulr

3

Hello Kai,

Kai Tietz <ktietz70@googlemail.com> writes:

I was recently reading in the blog at
A path forward for an LLVM toolchain on Windows - The LLVM Project Blog
that clang/llvm made big progress in supporting native Windows as
target. This actually sounds pretty promising, but this blog raised
some questions you might be able to answer.

First, it seems to us that within that blog, the author often
mistakenly implying Windows is MSVC. In general, I assume that he
meant "Visual Studio Compatible" instead of the term "Windows". But I
am not sure if I got this right.

You got it right. There is a group of high-profile developers here that
insist on expressions like "Windows support", "Windows native" etc to
mean "MSVC++ drop-in." I've figthed this blatant misrepresentation to no
avail. I've also noted that the effort invested on MSVC++ compatibility
so far would be enough to turn Clang++ into a fully working C++ compiler
for Windows development, but that was also dismissed, when not asked to
shut up. BTW, I've warned that this attitude of "MSVC++ is the real
thing, other options are not native" could create hostility on other
developer communities, but it seems that this is not considered a
problem here, as if the users who would look at Clang++ are not the same
who know and appreciate MinGW(-64).

I don't know if those people are on a show of blissful ignorance or if
there are obscure reasons for sneaking those misrepresentations into the
Clang community.

So right now there is work going on into implementing parts of the
MSVC++ C++ ABI (with no end on sight) while at the same time a patch for
fixing the dllexport support submitted by a "foreign" developer was
bluntly dismissed. I don't know what to make of this.

As a Windows C++ developer I see Clang++ on Windows as a lost cause.
Fortunately, there is MinGW-64 (and MinGW) which provides a great
alternative to MSVC++. It might be true that some of the newer,
specialized APIs are missing (something that you quickly fix once
noticed) but your toolchain works now, as it worked for more than 15
years.

[snip]