Displaying 20 results from an estimated 24 matches for "istargetwindows".
2013 Mar 28
0
[LLVMdev] [cfe-dev] Handling SRet on Windows x86
> 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 art...
2013 Mar 29
2
[LLVMdev] [cfe-dev] Handling SRet on Windows x86
....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 co...
2013 Mar 28
3
[LLVMdev] Handling SRet on Windows x86
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
2013 Mar 28
2
[LLVMdev] [cfe-dev] Handling SRet on Windows x86
...; 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 w...
2013 Mar 21
3
[LLVMdev] [cfe-dev] Handling SRet on Windows x86
...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 shoul...
2013 Mar 21
2
[LLVMdev] [cfe-dev] Handling SRet on Windows x86
...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 I...
2017 Mar 29
3
clang 4.0.0: Invalid code for builtin floating point function with -mfloat-abi=hard -ffast-math (ARM)
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
2010 Jan 10
0
[LLVMdev] Cygwin llvm-gcc regression
...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 job...
2013 Mar 21
0
[LLVMdev] [cfe-dev] Handling SRet on Windows x86
...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
> than...
2013 Mar 27
0
[LLVMdev] [cfe-dev] Handling SRet on Windows x86
...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 m...
2010 Jan 08
3
[LLVMdev] Cygwin llvm-gcc regression
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
2013 Mar 28
6
[LLVMdev] Handling SRet on Windows x86
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
2013 Jan 16
0
[LLVMdev] RFC: auto-linking IR proposal
...)
@@ -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 += "\&qu...
2013 Mar 27
3
[LLVMdev] [cfe-dev] Handling SRet on Windows x86
....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 (th...
2012 Oct 04
0
[LLVMdev] [cfe-dev] Handling SRet on Windows x86
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
>
2012 Oct 04
3
[LLVMdev] [cfe-dev] Handling SRet on Windows x86
> 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
2013 Mar 27
0
[LLVMdev] [cfe-dev] Handling SRet on Windows x86
...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...
2013 Oct 23
2
[LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?
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 this...
2013 Jan 16
2
[LLVMdev] RFC: auto-linking IR proposal
...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 += *...
2013 Jan 15
4
[LLVMdev] RFC: auto-linking IR proposal
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