[LLVMdev] Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

[Charles Davis]

On Jul 30, 2013, at 12:41 PM, Stephen Lin wrote:

>> Right. What's the point of all the effort devoted to MSVC++ ABI
>> compatibility when Clang doesn't need it for being a top-notch C++
>> compiler on Windows?
> 
> I brought up a similar point a little bit earlier, too....
> 
> It seems like the only necessary condition for being a first-class
> native-code development tool on Windows is to support the platform C
> ABI and the subset of the C++ ABI required by COM, and that is the
> most that any non-MS compiler on Windows tries to do,
Huh? Intel CC supports the MSVC++ ABI. Zortech (Digital Mars) supports it, too (though the guy who wrote it isn't too proud of that fact--or the fact that he even wrote that compiler to begin with). Heck, even CodeWarrior supported it (as Howard Hinnant might well remember), before Metrowerks sold off their x86 compiler backend. In fact, other than GCC, only Borland and Watcom don't support it, and that's only because they originally developed theirs during the DOS era, before MSVC++ became the de facto standard compiler. (But Watcom also used to support MFC development on Windows, so they might have supported it at one point, too.)
> so I am
> genuinely curious why there is so much effort being spent on the more
> esoteric portions of the ABI?
Because the sad truth is, the Microsoft ABI is the de facto standard on Windows--just as the Itanium ABI is the de facto standard on Linux and Mac OS. Many a third-party DLL was compiled against it, and so were a few first-party ones, like the aforementioned MFC. Not everyone (sadly) has the luxury of recompiling their DLLs to work with an alternative C++ ABI--and I'd imagine it'd be a support nightmare for those that do to have multiple binaries out there in the wild (Welcome to DLL Hell!! :). Seriously, I think they've had enough trouble with multiple versions; I don't think they want to deal with multiple C++ ABIs, too. (Naturally, open source software does not have the first problem, because they *can* just recompile their DLLs to work with GCC/Clang--which they often do. But still, there's a lot of legacy proprietary code out there on Windows, and the fact that open source code can be recompiled does little for the DLL Hell problem.)

The fact that more than one C++ ABI isn't quite compatible with MSVC (not even enough to support COM, in some cases) is the reason Wine (for example) doesn't allow C++ code. (And yes, some of their DLLs really do need to conform to the Microsoft C++ ABI, beyond just COM.) In fact, that was the whole reason that *I* started this little subproject (supporting the MSVC ABI) in the first place. (Though I imagine that at least some of this might have taken place even without me. ;)

You're right that we don't need it to be a great C++ compiler. But we do need it to attract people who'd otherwise use MSVC (if for no other reason than ABI compatibility) to our top-notch compiler.

Chip