[cfe-dev] Question about an interesting blog

[Robinson, Paul]

> -----Original Message-----
> From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu]
> On Behalf Of Kai Tietz
> Sent: Friday, September 06, 2013 7:25 AM
> To: cfe-dev at cs.uiuc.edu
> Subject: [cfe-dev] Question about an interesting blog
> 
> Hello,
> 
> I was recently reading in the blog at
> http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html
> 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

> 
> 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev