search for: istargetwindow

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

....ru>: >> 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 Windows + > Mingw + Cygwin Minor correction: currently isTargetWin32 means 32-bits (not "everything"), Windows + Mingw, not Cygwin. So this is actually even more c...

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

...; wrote: >> 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 Windows + > Mingw + Cygwin > - isTargetWin64() is is basically 64-bit version of isTargetWin32(), > but strictly speaking is slightly different > > This naming...

...a few times, so you should probably look at the llvmdev archives. It all starts here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-October/053961.html ] So I've decided to make a new attempt to fix this issue. We've discussed my patches with Eric and came up with the following idea: a) IsTargetWindows should be true for all the targets that execute on the Windows kernel, including Cygwin, 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 shou...

...t; > It all starts here: > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-October/053961.html ] > > > > So I've decided to make a new attempt to fix this issue. > > > > We've discussed my patches with Eric and came up with the following idea: > > a) IsTargetWindows should be true for all the targets that execute on > > the Windows kernel, including Cygwin, 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...

On 29 March 2017 at 02:33, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > sin/cos are libm functions, and so a libcall to those need to honour the > floating point ABI requests. The calling convention to be followed there > should match `-mfloat-abi` (that is, -mfloat-abi=hard => AAPCS/VFP, > -mfloat-abi=soft => AAPCS). Exactly, but they're not, and that's

...orking copy) >> @@ -169,7 +169,7 @@ >> p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:128:128-n8:16:32:64"; >> else if (isTargetDarwin()) >> p = "e-p:32:32-f64:32:64-i64:32:64-f80:128:128-n8:16:32"; >> - else if (isTargetCygMing() || isTargetWindows()) >> + else if (isTargetWindows()) >> p = "e-p:32:32-f64:64:64-i64:64:64-f80:128:128-n8:16:32"; >> else >> p = "e-p:32:32-f64:32:64-i64:32:64-f80:32:32-n8:16:32"; >> > > Yep ! Thanks a lot Duncan, obviously not doing my jo...

...ly look at the llvmdev archives. > It all starts here: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-October/053961.html ] > > So I've decided to make a new attempt to fix this issue. > > We've discussed my patches with Eric and came up with the following idea: > a) IsTargetWindows should be true for all the targets that execute on > the Windows kernel, including Cygwin, 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 > tha...

...gt; http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-October/053961.html ] >> > >> > So I've decided to make a new attempt to fix this issue. >> > >> > We've discussed my patches with Eric and came up with the following >> > idea: >> > a) IsTargetWindows should be true for all the targets that execute on >> > the Windows kernel, including Cygwin, MinGW and MSVC ABIs. >> > >> > However, "Windows 32-bit ABI" usually implies "MSVC 32-bit ABI", so >> > it's Cygwin and MinGW (that are similar...

I am getting an assertion firing while building TOT llvm-gcc on Cygwin in libgcc2.c :- /home/ang/build/llvm-gcc/./gcc/xgcc -B/home/ang/build/llvm-gcc/./gcc/ -B/home/an g/llvm-gcc/i686-pc-cygwin/bin/ -B/home/ang/llvm-gcc/i686-pc-cygwin/lib/ -isystem /home/ang/llvm-gcc/i686-pc-cygwin/include -isystem /home/ang/llvm-gcc/i686-pc-c ygwin/sys-include -O2

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

...) @@ -641,6 +641,19 @@ const TargetLoweringObjectFileCOFF &TLOFCOFF = static_cast<const TargetLoweringObjectFileCOFF&>(getObjFileLowering()); + // Output linker support code for #pragma comment(lib, ...) on Windows + if (M.lib_size() > 0 && Subtarget->isTargetWindows()) { + OutStreamer.SwitchSection(TLOFCOFF.getDrectveSection()); + SmallString<128> name; + for (Module::lib_iterator I = M.lib_begin(), E = M.lib_end(); + I != E; ++I) { + name = " /DEFAULTLIB:\""; + name += *I; + name += "\&q...

....edu/pipermail/llvmdev/2012-October/053961.html ] >>> > >>> > So I've decided to make a new attempt to fix this issue. >>> > >>> > We've discussed my patches with Eric and came up with the following >>> > idea: >>> > a) IsTargetWindows should be true for all the targets that execute on >>> > the Windows kernel, including Cygwin, MinGW and MSVC ABIs. >>> > >>> > However, "Windows 32-bit ABI" usually implies "MSVC 32-bit ABI", so >>> > it's Cygwin and MinGW (t...

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

...ctober/053961.html] > >>> > > >>> > So I've decided to make a new attempt to fix this issue. > >>> > > >>> > We've discussed my patches with Eric and came up with the following > >>> > idea: > >>> > a) IsTargetWindows should be true for all the targets that execute on > >>> > the Windows kernel, including Cygwin, MinGW and MSVC ABIs. > >>> > > >>> > However, "Windows 32-bit ABI" usually implies "MSVC 32-bit ABI", so > >>> > it's...

If it's a Windows-only thing the correct tests would be: if (NumBytes >= 4096 && STI.isOSWindows()) { and if (Subtarget->isTargetWindows()) where bool isOSWindows() const { return TargetTriple.isOSWindows(); } Yaron 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > Glad that helped! As I understand it __chkstk is always required on > Windows regardless of output type, I had meant to file a bug about thi...

...const TargetLoweringObjectFileCOFF &TLOFCOFF = > static_cast<const > TargetLoweringObjectFileCOFF&>(getObjFileLowering()); > > + // Output linker support code for #pragma comment(lib, ...) on Windows > + if (M.lib_size() > 0 && Subtarget->isTargetWindows()) { > + OutStreamer.SwitchSection(TLOFCOFF.getDrectveSection()); > + SmallString<128> name; > + for (Module::lib_iterator I = M.lib_begin(), E = M.lib_end(); > + I != E; ++I) { > + name = " /DEFAULTLIB:\""; > + name +=...

Hi all, We plan to add some auto-linking support for Mach-O, and need a scheme for encoding this information in the LLVM IR. We would like the same scheme to be able to support Microsoft's #pragma comment(lib,...) and #pragma comment(library, ...) features eventually. The current proposal is as follows: -- #1. Extend module-level metadata flags (llvm.module.flags) to support two new