[LLVMdev] [cfe-dev] Handling SRet on Windows x86

[Chris Lattner]

On Mar 28, 2013, at 1:35 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:

Oscar, just FYI, your wording is very strong, and that is often not the most productive way to make your point.   That said, to address some of the things you've raised in a couple of threads:

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

These are some pretty broad strokes, but overall this is mostly true.  I agree that the notion of a "system compiler" doesn't particularly exist in the windows domain.  There is a strong notion of the "system APIs" though (including the crazy extensions), and one could reasonably conclude that whatever is required to build against those APIs qualifies as a system compiler.  However, that is just arguing terminology and not the actual interesting point of this thread :)

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

I don't see this.  Support for the *visual studio ABI* in all of its glory is not a detriment to anyone.  It would be detrimental if we *didn't* support the mingw ABI also, but noone is arguing to support VC++ ABI but drop mingw.

> I'm saying that anything that could suggest that MSVC++ is more
> desirable

You cannot argue about desirability as though everyone thinks the same way.  Some people care a lot more about VC++ compatibility (including COM and many other things!) than they do about mingw.  You need to be able to accept that, and the project as a whole is driven by people writing code.  If someone wants to contribute patches to improve VC++ compatibility then we should take them (of course, not if they break mingw).

> than the other compilers is not only unfair, but would go
> against Clang's interest because Clang will sooner get full MinGW
> drop-in capability than MSVC++ drop-in capability.

This doesn't make any sense to me.  In principle, Clang should support both and users can pick whichever one suits their needs best.

If someone wanted to come along and contribute clang language support for some weird COM or WinRT thing, and if their patches were well written and fit into the rest of the compiler properly, we should take them.

I don't think anyone is saying that *you* should stop working on mingw and start implementing VC++ support, but by the same token, you shouldn't tell *them* what they are supposed to care about.

-Chris