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

[Óscar Fuentes]

Chris Lattner <clattner at apple.com> writes:

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

I don't think that my wording was so strong to raise offense on anyone.
On other communities were I participate, "strong wording" is used for
conveying determination and energy, never be taken as a personal attack.

But my English is not as good as I would like and too often I miss
nuances on words and phrasings that could be misinterpreted by some
readers. Certainly you are a better English speaker than me, so I'll
take your advice and apologize if someone got the impression that I was
being offensive or arrogant.

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

My English is really bad, because you interpreted my message on a way
that has no relation at all with my position :-)

I said that Clang++ will be compatible (*) with MinGW sooner than with
MSVC++ because much of the work for MinGW compatibility is already done
(since Clang aimed at compatibility with gcc since day 1) and for what
is left you have descriptive documentation and/or examples of
implementation. That's not true for MSVC++ and, contrary to MinGW's
case, nobody is in a position of saying "with X months of effort the
work could be completed, modulo bugs." I think it is totally reasonable
to think that Clang will take a long time to be compatible (*) with
MSVC++.

That's why I say that any message that puts any other compiler on an
inferior status to MSVC++ is not only unfair, but prejudicial to Clang
too.

If we refer to MSVC++ on our mailing lists and source code as the
"Windows system compiler", not only are we being factually wrong and
dismissive of other vendors' work, but we would be picturing Clang as if
the best thing it could ever achieve on Windows is some level of
compatibility with the "system compiler." As someone who is developing
Windows software using C++ for 20 years, I can categorically say that it
is a very damaging and completely false message: Clang can be a better
Windows C++ compiler than MSVC++ even if it does not follow its C++ ABI
(+).

LLVM/Clang mailing lists are read by lots of current and new developers
and its source examined by lots of future compiler engineers. We should
take care about not propagating false beliefs, and extra care when they
damage us.

* Compatible as in "usable enough with the runtimes and SDKs distributed
  with such compiler for compiling standard C++ sources that uses the
  Win32 API."

+ I'm all for adding MSVC++ ABI support to Clang.