similar to: [LLVMdev] MinGW/MSVC++ uses different ABI for sret

On Fri, Sep 25, 2009 at 2:41 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > I filed a bug yesterday ( http://llvm.org/bugs/show_bug.cgi?id=5046 ) > and Anton kindly explained that LLVM is doing the right thing as per the > ABI (the GCC ABI, I'll add). > >  1. Is there a LLVM way of dealing with this without using separate code >  for VC++ and GCC? I'm not sure what

Hello Eli. Eli Friedman <eli.friedman at gmail.com> writes: > On Fri, Sep 25, 2009 at 2:41 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: >> I filed a bug yesterday ( http://llvm.org/bugs/show_bug.cgi?id=5046 ) >> and Anton kindly explained that LLVM is doing the right thing as per the >> ABI (the GCC ABI, I'll add). >> >>  1. Is there a LLVM way of

Hi, is there any news about this problem? How hart it will be to resolve this compatibility problem with Visual Studio functions ? This is really great problem for my project with should call may different function compiled by Visual Studio!!! Here is also problem that is looking similar. http://llvm.org/bugs/show_bug.cgi?id=5046 -- View this message in context:

Óscar Fuentes <ofv at wanadoo.es> writes: > BTW, it's even worse, as aggregates passed by value are, well... passed > by value, contrary to the 386 unix ABI which uses pointers. I'm afraid > that this has no so easy solution as the sret issue. Is there any LLVM > target where aggregates are "really" passed by value? This is not entirely true. MSVC never uses

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

Hi Eric, > From my perspective Win32 is the windows ABI and mingw and cygwin are their own ABIs No. They are using Windows Platform ABI for almost everything (e.g. calling API, C runtime, etc.). At least mingw does. The differences are exactly in unspecified area (e.g. passing / returning structs by value). The only difference is C++, where mingw / cygwin follows Itanium ABI and MSVC - its

On Thu, Aug 1, 2013 at 1:06 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > * To understand why they chose to work on MS C++ ABI compatibility > instead of other most basic missing features that preclude using > Clang for serious C++ development. I'll be grateful if anyone > involved on the MS C++ ABI comments on this (it was already mentioned > that Wine is

On Wed, Jul 31, 2013 at 5:06 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > prompts me to ask if it is right to submit to the mailing lists patches > implementing a feature that is known to be legally "controversial". > I have no idea what you are talking about, but if you have legal or other questions, or want to discuss 'legal controversies', this isn't the

On Wed, Jul 31, 2013 at 5:06 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > prompts me to ask if it is right to submit to the mailing lists patches > implementing a feature that is known to be legally "controversial". > I have no idea what you are talking about, but if you have legal or other questions, or want to discuss 'legal controversies', this isn't the

On Jul 31, 2013, at 3:13 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Full disclosure: I'm the guy who filled the PR requesting the feature > the OP's is working on and, when someone tried to close it as WONTFIX, I > strongly opposed. Furthermore, MSVC++ is my Windows compiler and my > projects suffer from unwelcome complexity for working around the lack of > this

Chris Lattner <clattner at apple.com> writes: > This thread is odd to me. It seems that the gist of your guys' > argument is that you don't know if we will ever get full support, > therefore we don't welcome progress towards that (very useful) > goal/feature. > > If the specific proposal doesn't make make sense from a design > standpoint, that's one

Chandler Carruth <chandlerc at google.com> writes: >> And here there is no "Windows ABI" here at all. Because every compiler >> (MSVC, gcc / clang, Borland) does its own stuff. This is why I said >> that the proposal naming is confusing. >> > > I don't know anything about Borland, and I don't think that matters. But I > think that the

> 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 Just to make stuff clear: I just wanted proper naming which will be non-confusing. Right now we have: - isTargetWindows() which really means "msvc-compabile" - isTargetWin32() which means "everything on windows", so

Hello Aaron, Anton, LLVM-dev, While working on http://llvm.org/PR13676#c6 I found out that whenever I compile code with class methods returning structures it get generated incompatible with MSVC. Looking at lib/Target/X86/X86CallingConv.td, I found out that CC_X86_32_ThisCall maps SRet to EAX but in fact it should push the address of the return temp on stack. The following patch fixes the issue

On Wed, Mar 27, 2013 at 2:28 PM, Anton Korobeynikov <asl at math.spbu.ru>wrote: > Hi Eric, > > > From my perspective Win32 is the windows ABI and mingw and cygwin are > their own ABIs > No. They are using Windows Platform ABI for almost everything (e.g. > calling API, C runtime, etc.). At least mingw does. The differences > are exactly in unspecified area (e.g.

John Smith <lbalbalba at gmail.com> writes: > Forgive me from intruding here, but ... > > whats wrong with isTargetWin32-MSVC-win32, > isTargetWin32-mingw32-win32, isTargetWin32-borland-win32, > isTargetWin32-cygwin-win32, etc. > > Judging by the responses, there seems to be a need for that. Which > leaves the point of what should be 'the default', which

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

On Thursday, March 28, 2013, Óscar Fuentes wrote: > Chandler Carruth <chandlerc at google.com <javascript:;>> writes: > > >> And here there is no "Windows ABI" here at all. Because every compiler > >> (MSVC, gcc / clang, Borland) does its own stuff. This is why I said > >> that the proposal naming is confusing. > >> > > >

Óscar Fuentes wrote: > Argiris Kirtzidis <akyrtzi at gmail.com> writes: > > >> How does updating the CMake produced VC++ project files work ? >> I mean: >> >> -I have CMake produce VC++ project files >> -Compile the solution >> -Do a svn update and pick up a couple of files >> -Have CMake produce new project files >> -Now, do I have

Joe Groff <arcata at gmail.com> writes: >> MSVC is not the system compiler. Certainly, it is not distributed with >> the system. Actually, MSVC was a secondary player on Windows for a long >> time, with several other C++ ABI-incompatible options available. > > > It isn't shipped with the system, but it's freely available as part of the > Windows SDK,