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

[Óscar Fuentes]

Charles Davis <cdavis5x at gmail.com> writes:

> 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.)

MFC is just a library and hence unrelated to the C++ ABI. Borland
produced MFC applications without problem. You need to support some
language extensions, but that's all. Oh, and IIRC you need a license for
using MFC with other compiler than MS. If I'm not mistaken, same
requirement applies to key components such as the C++ runtime/stdlib.

>> 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.

Quite the contrary, knowing that Clang's C++ ABI is completely
incompatible with MS is a maintenance *simplification*.

Saying that supporting the MS C++ ABI is an uphill battle is an
understatement (and better say MS C++ ABI*S*, because it evolved over
time and it is known that it will change on future releases.) As far as
I'm concerned, I'll never base my decisions on compiler usage on the
advertisement of MS compatibility by Clang++, becase I *know* that for a
very long time (maybe forever) whatever MS C++ libraries that work with
Clang++ is by luck. That's what happens when you try to implement
compatibility with an undocumented, propietary, complex feature.

> (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, th ere'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.

Of course you are free to work on whatever you wish. I'm not criticizing
your work or anybody else's. However, I'm quite surprised to see how a
great deal of energy is invested on MS C++ ABI compatibility without an
end in sight and with some ticklish areas ahead (MS C++ runtime(s)
support, SEH support, complex LLVM change requirements (this very same
thread)) while Clang++ currently cannot do several basic things on
Windows (which of course are also required for being MS compatible.)
Example: dllexport of C++ classes and templates.

I'm also worried by the damage of claims such as "MS C++ ABI is the
standard on Windows", which conveys the message that until Clang++
supports such ABI it can not be a serious contender on Windows. Which is
blatantly false. Fact is that you need MS C++ ABI compatibility only for
using C++ libraries which lack source code. I doubt that the individuals
and organizations that abide such pitiful state are interested on using
a compiler other than the "industry standard" MSVC++, or that the
success of Clang on Windows depend on them at all.