<div dir="ltr">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 <a href="http://clang.llvm.org/docs/MSVCCompatibility.html">http://clang.llvm.org/docs/MSVCCompatibility.html</a><div>
<br></div><div>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.</div>
<div><br></div><div>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... </div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 27, 2014 at 12:50 PM, James Gregurich <span dir="ltr"><<a href="mailto:bayoubengal@mac.com" target="_blank">bayoubengal@mac.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ok. new topic is being started here...<br>
<br>
On Aug 26, 2014, at 5:46 PM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
<br>
> 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.<br>
><br>
> 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:<br>
> - Plain C Windows SDK headers: windows.h<br>
> - MSVC C++ STL headers: vector, string<br>
> - Templateless COM headers: DirectX etc<br>
> - Template libraries: ATL, WRL<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
thanks for the response!<br>
<br>
I’m aware of difficulties in macro processing. that was mentioned by the boost fellow some time back.<br>
<br>
<br>
you are adding in a few more. Here is the list as I understand it. Please correct it if I am wrong.<br>
<br>
1) problems with template definitions and instantiation<br>
2) calling convention and export/import attributes.<br>
3) IDL support<br>
4) difficulties with macro definition and expansion.<br>
<br>
<br>
Have any of these been fully or partially addressed yet?<br>
<br>
<br>
a related question:<br>
<br>
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?<br>
<br>
-James<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div>