[LLVMdev] Handling SRet on Windows x86
echristo at google.com
Thu Mar 28 12:52:41 PDT 2013
On Thu, Mar 28, 2013 at 12:19 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> Eric Christopher <echristo at gmail.com> writes:
> > In my opinion none of these are irrelevant. Mingw and cygwin are separate
> > ABIs that deal with some C compatibility (problems mentioned in this
> > are important here too) and give you the ability to work with low level C
> > libraries on windows, but if you want true compatibility with the full
> > platform
> > those ABIs are insufficient.
> What do you mean by "the full platform"? Every propietary extension that
> MS came with along all these years? (From structured exceptions to
> whatever Windows RT requires?)
> MinGW is very well capable of using the Win32 API. There is partial or
> non-existent support for extensions such as COM, but those are not part
> of the "ABI", for sure.
I don't care overly much about COM, but I do care about the C++ abi and
C++ libraries on the system and interacting with those libraries via clang.
> > If you think these are irrelevant points then you need to state why
> > and should back it up with less dismissive language.
> Sorry, but this goes the other way. If you need a lesson in history
please start by investigating what "Borland" was, for instance. As
I'm quite familiar with Borland, thank you.
> already mentioned, for a long time MSVC was considered an inferior
> option and not required in any way for developing on Windows (not even
> for device drivers!) Then Borland and the other vendors were displaced
> by MSVC, but not because it was "the system compiler", nor even because
> it was technically better overall, severely lacking in C++ compliance,
> for instance. It gained market share because several reasons, among them
> because the other vendors had serious management problems and because MS
> marketers convinced the suits that for doing "serious" Windows
> development you need the tool made by MS itself. It is no surprise, but
> irritating nevertheless, that nowadays the fallacy is stablished as a
Honestly it doesn't much matter about history in this case. I understand the
frustration coming from your perspective, but these days running binaries
on windows involves interoperating with things compiled by MSVC. To have
a toolchain that works with as many libraries on the system as possible
interoperability with the tools used to compile those libraries. In this
case it is MSVC and their ABI.
> Sorry if I sound dismissive but it's quite irritating to see how
> authoritativeness is attributed to something that doesn't deserve it
> *to* *the* *detriment* *of* *our* *own* *project*.
How can having an MSVC compatible compiler be to the detriment of clang and
llvm? No one is trying to break mingw here, merely add support for something
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev