search for: istargetwin32

...etriment 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 Windows + > Mingw + Cygwin Minor correction: currently isTargetWin32 means 32-bits (not "everything"), Windows + Mingw, not Cygwin. So this is actually even more confusing... > - isTargetWin64() is is basically 64-bit version of...

...ble 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 Windows + Mingw + Cygwin - isTargetWin64() is is basically 64-bit version of isTargetWin32(), but strictly speaking is slightly different This naming while being the historical artifact is extremely confusing. For me it seems the best solution w...

...ABI" usually implies "MSVC 32-bit ABI", so > > it's Cygwin and MinGW (that are similar more similar to Itanium ABI > > than to MSVC ABI) that should be exceptions from the general Win32 > > handling code. > > > > That is, > > b) We should add a IsTargetWin32 which is true if the MSVC 32-bit ABI > > is used and false for Cygwin+MinGW. > FTR, there's already such a method but it is (mis?)used only in > lib/Target/X86/X86FrameLowering.cpp for segmented stacks. > Are segmented stacks actually used with MSVC or is it just the > conditi...

...s "MSVC 32-bit ABI", so >> > it's Cygwin and MinGW (that are similar more similar to Itanium ABI >> > than to MSVC ABI) that should be exceptions from the general Win32 >> > handling code. >> > >> > That is, >> > b) We should add a IsTargetWin32 which is true if the MSVC 32-bit ABI >> > is used and false for Cygwin+MinGW. >> FTR, there's already such a method but it is (mis?)used only in >> lib/Target/X86/X86FrameLowering.cpp for segmented stacks. >> Are segmented stacks actually used with MSVC or is it just...

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,

...quot;, so >>> > it's Cygwin and MinGW (that are similar more similar to Itanium ABI >>> > than to MSVC ABI) that should be exceptions from the general Win32 >>> > handling code. >>> > >>> > That is, >>> > b) We should add a IsTargetWin32 which is true if the MSVC 32-bit ABI >>> > is used and false for Cygwin+MinGW. >>> FTR, there's already such a method but it is (mis?)used only in >>> lib/Target/X86/X86FrameLowering.cpp for segmented stacks. >>> Are segmented stacks actually used with MSV...

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 could be > borland for all i care......

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 could be borland for all i care... but perhaps not an as heated...

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

...t; it's Cygwin and MinGW (that are similar more similar to Itanium ABI > >>> > than to MSVC ABI) that should be exceptions from the general Win32 > >>> > handling code. > >>> > > >>> > That is, > >>> > b) We should add a IsTargetWin32 which is true if the MSVC 32-bit ABI > >>> > is used and false for Cygwin+MinGW. > >>> FTR, there's already such a method but it is (mis?)used only in > >>> lib/Target/X86/X86FrameLowering.cpp for segmented stacks. > >>> Are segmented stacks ac...

...ygwin, MinGW and MSVC ABIs. However, "Windows 32-bit ABI" usually implies "MSVC 32-bit ABI", so it's Cygwin and MinGW (that are similar more similar to Itanium ABI than to MSVC ABI) that should be exceptions from the general Win32 handling code. That is, b) We should add a IsTargetWin32 which is true if the MSVC 32-bit ABI is used and false for Cygwin+MinGW. c) We should add CC_X86_Win32_C and CC_X86_Win32_ThisCall and use them only for MSVC 32-bit ABI. d) Cygwin and MinGW should use the CC_X86_32_C This way, Clang takes care of setting the SRet attribute wherever appropriate and...

...etriment 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 Windows + > Mingw + Cygwin > - isTargetWin64() is is basically 64-bit version of isTargetWin32(), > but strictly speaking is slightly different > > This naming while being the historical artifact is extremely > confusing. For me...

...However, "Windows 32-bit ABI" usually implies "MSVC 32-bit ABI", so > it's Cygwin and MinGW (that are similar more similar to Itanium ABI > than to MSVC ABI) that should be exceptions from the general Win32 > handling code. > > That is, > b) We should add a IsTargetWin32 which is true if the MSVC 32-bit ABI > is used and false for Cygwin+MinGW. FTR, there's already such a method but it is (mis?)used only in lib/Target/X86/X86FrameLowering.cpp for segmented stacks. Are segmented stacks actually used with MSVC or is it just the conditions there should use isTa...

How can a frontend tell LLVM to put a function argument on stack/register/etc? On Thu, Oct 4, 2012 at 5:08 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >> Ah, got it. >> Sounds like we might need to introduce CC_X86_Win32_MSVC_ThisCall then?.. > No, we should not. It should be properly expanded in frontend. > > -- > With best regards, Anton Korobeynikov >

> Ah, got it. > Sounds like we might need to introduce CC_X86_Win32_MSVC_ThisCall then?.. No, we should not. It should be properly expanded in frontend. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

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