[LLVMdev] Handling SRet on Windows x86

[Eric Christopher]

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
> thread
> > 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
using
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
> truth.
>

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

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130328/1cc86c78/attachment.html>