llvm dev - Jul 2013 - [LLVMdev] Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Duncan Sands <baldrick at free.fr> writes:
> On 29/07/13 15:30, Anton Korobeynikov wrote:
>>>> object in place on the stack or at least call its copy
constructor.
>>>
>>>
>>> what does GCC do?
>> Nothing. It does not support MSVC ABI.
>
> Maybe we shouldn't either :)
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?

> 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, so I am
genuinely curious why there is so much effort being spent on the more
esoteric portions of the ABI?

As far as I understand it, the case being considered here is not
supported in COM, which constrains the types of parameter and return
values at ABI boundaries to pointers, simple C types, and some special
cases...

Stephen

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