[cfe-dev] Windows headers that are troublesome for clang

[Nikola Smiljanic]

I'm not sure if this has changed since clang-cl was introduced but
resulting clang depends on what you build it with. I'm sure this will go
away at some point if it hasn't already. Compiling clang with mingw
produces a mingw compatible clang that uses libstd++ and ld. Compiling it
with Visual Studio would produce msvc compatible clang that uses msvc stl
and link.exe. I think the main difference comes from the triple where
something like i586-win32-pc defines a different abi from i586-pc-mingw and
passes -fms-extensions -fms-compatibility and some other stuff to indicate
msvc compatibility. Have a look at
http://clang.llvm.org/docs/MSVCCompatibility.html

clang-cl is supposed to be a drop in replacement for cl.exe and as such
accepts same command line options and enables language extensions and/or
bugs :). The same way clang/clang++ are a drop in replacement for gcc/g++.
But there's nothing preventing you from using the compliant version of
clang on windows, it's just a matter of what flags are being passed to the
driver.

Then there's also the idea of the complete clang toolchain on windows
(libc++, lld, lldb) that many people would like to use. But the question of
default ABI for this toolchain still remains. I can't find the thread but I
remember someone pointing out that just because Microsoft owns the platform
it doesn't mean that their compiler's abi should be seen as the default
one. But if Herb's proposal for C++ ABI is accepted it will mean exactly
that, the platform defines the abi...


On Wed, Aug 27, 2014 at 12:50 PM, James Gregurich <bayoubengal at mac.com>
wrote:

> ok. new topic is being started here...
>
> On Aug 26, 2014, at 5:46 PM, Reid Kleckner <rnk at google.com> wrote:
>
> > Your question isn't actually that clear. What kind of brokenness do you
> care about? Are you looking for C++ that clang can't parse, or standard
> library features that behave incompatibly on Windows?  I think you mean the
> former.
> >
> > The answer to that question is complicated. It depends on what you want
> to parse. I'd say there's several classes of stuff in order of increasing
> difficulty to parse:
> > - Plain C Windows SDK headers: windows.h
> > - MSVC C++ STL headers: vector, string
> > - Templateless COM headers: DirectX etc
> > - Template libraries: ATL, WRL
> >
> > The first three classes aren't that hard to parse. When they use
> standard language features, they are mostly well-formed. The difficulty in
> parsing them is that they use lots and lots of language extensions. The
> basic stuff is dllexport and __stdcall, but it gets harder. There are weird
> IDL attributes involving square brackets, for example.
> >
> > The final category is really something all on its own. MSVC's template
> model is drastically different from ours. You could hypothetically hack
> these headers in probably 20 or so places to get them to parse with Clang
> without any compatibility hacks, but you end up fighting an uphill battle.
> This is the category that native GUI apps tend to have, while batch
> processing apps like LLVM can get by with the first three sets.
>
> thanks for the response!
>
> I’m aware of difficulties in macro processing. that was mentioned by the
> boost fellow some time back.
>
>
> you are adding in a few more. Here is the list as I understand it. Please
> correct it if I am wrong.
>
> 1) problems with template definitions and instantiation
> 2) calling convention and export/import attributes.
> 3) IDL support
> 4) difficulties with macro definition and expansion.
>
>
> Have any of these been fully or partially addressed yet?
>
>
> a related question:
>
> as I understand it, if you run clang directly on windows (assuming a win32
> host environment verses as posix one (cygwin etc)), it compiles as it does
> on every other platform but the symbols will be gcc-style…not ms-style. If
> you run it with the clang-cl wrapper, it uses an alternative preprocessor
> that matches that of cl.exe. Is that understanding correct? can one detect
> at compile time what processor he is going to get? Is there a switch to
> pick the desired preprocessor to override what clang-cl might choose by
> default?
>
> -James
>
>
>
>
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140827/9ebf49f4/attachment.html>