similar to: [LLVMdev] host triple for Win64?

Great! Are there other issues I should be aware of? Félix Le 2010-11-25 à 07:43:23, Anton Korobeynikov a écrit : > Hello Felix > >> I have a project in mind that involves using the JIT for a few targets (x86 >> and x86_64 processors on Mac OS, Linux and Windows). However, there is an >> open bug that says LLVM generates incorrect code for Win64. >> Eli's last

Hi, sorry, in my last mail, I didn't check in time that HTML e-mails would be turned off. So, checking out llvm/clang yesterday under Win32, building it, and running the "check"-project using MS Visual Studio yielded 177 unexpected failures, many of which happen because of the different registers used in passing arguments under Win64 and everybody else on x86-64. I would be

On 5/18/2011 1:47 AM, Eric Christopher wrote: > On May 17, 2011, at 2:50 AM, Eric Niebler wrote: >> On 5/17/2011 2:58 AM, Eric Christopher wrote: >>> On May 14, 2011, at 3:08 AM, Eric Niebler wrote: >>> >>>> Just a heads up that the llvm build appears to be broken on cygwin. I >>>> haven't investigated, but here's the failures:

Dirk, I am working on tests/win32(s) too. I can let all tests pass on msvc10 and cygming with my patches, thought, my patches are incomplete (several of them hide potential problems) Please see threads below in llvm-commits. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100927/109077.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20101004/109271.html If you are

Hi Chandler, There were five SEH releated patches posted in two threads in the last days. Two different patches in Martell e-mail starting this thread: the win64 seh (llvm) and the register names Three more related SEH patches in another thread: one for win64 seh clang, one for MinGW toolchain and another for unreachable prologue. To clarify and allow proper reviews for the different patches I

Felix, > Great! Are there other issues I should be aware of? There might be some issues wrt tailcalls, but I'd not expect anything else to be major broken. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On 5/17/2011 2:58 AM, Eric Christopher wrote: > On May 14, 2011, at 3:08 AM, Eric Niebler wrote: > >> Just a heads up that the llvm build appears to be broken on cygwin. I >> haven't investigated, but here's the failures: >> >> llvm[3]: Compiling X86ISelDAGToDAG.cpp for Release+Asserts build >>

Just a heads up that the llvm build appears to be broken on cygwin. I haven't investigated, but here's the failures: llvm[3]: Compiling X86ISelDAGToDAG.cpp for Release+Asserts build /home/Eric/boost/consulting/svn/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:1487: error: ‘LOCK_OR8mi’ is not a member of ‘llvm::X86’ /home/Eric/boost/consulting/svn/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:1488:

Hello, I wanted to recompile syslinux64.exe (windows 64bit binary) on ubuntu. The default ./find-mingw64.sh script failed to locate mingw64 on ubuntu, even after root at htpc:~# apt-get install gcc-mingw-w64 So I had to patch the script to let it find mingw64 on ubuntu as well. Patch is below, please apply to syslinux sources: --- syslinux-4.05/win64/find-mingw64.sh.orig 2012-08-28

git://git.zytor.com/users/genec/syslinux.git Branch win64-mingw32-ubuntu-for-hpa This adds the compiler prefix used in Debian/Ubuntu to the list (amd64-mingw32msvc-). Too bad /bin/sh doesn't support brace expansion. -- -Gene

In summary we have no less than six patches required to support Win64 SEH MinGW. The first five could be committed after review and LGTM but the last one also requires Ray Donnelly approval. Please comment in the Phabricator so the comments would be kept in context. 'unreachable' trap http://reviews.llvm.org/D3417 Win64 SEH (LLVM) http://reviews.llvm.org/D3418 Win64 SEH (clang)

On May 17, 2011, at 2:50 AM, Eric Niebler wrote: > On 5/17/2011 2:58 AM, Eric Christopher wrote: >> On May 14, 2011, at 3:08 AM, Eric Niebler wrote: >> >>> Just a heads up that the llvm build appears to be broken on cygwin. I >>> haven't investigated, but here's the failures: >>> >>> llvm[3]: Compiling X86ISelDAGToDAG.cpp for

Hi Jonathan, This looks a bit odd. Any reason for the unknown->none conflating in this way? For most (all) of the ports unknown-elf works the same as none-elf. I'm also not sure if someone decided to have, arm-codesourcery-elf that this would still work with the patch. Thoughts? -eric On Tue, Jun 24, 2014 at 7:35 AM, Amara Emerson <amara.emerson at gmail.com> wrote: > Hi Jon,

Hi, I just did a "make install" on Win7x64 using Mingw64 and it dropped off the files in "C:\Program Files (x86)\LLVM". That's almost right, but nicer would be if the 64-bit build was dropped off in "C:\Program Files\LLVM". I am fairly confident that it is me who is doing something wrong because I simply do this: (retrieve trunk version of LLVM, Clang,

Chen, see http://llvm.org/docs/GettingStarted.html#pf_12 ...Takumi ps. Excuse me, PE+ (aka pep) means "Executable file format for WIndows x64". 2011/5/16 陈晓宇 <xychen0921 at gmail.com>: > The stack trace: > > Starting program: > C:\MinGW\msys\1.0\home\xchen\llvm-obj\lib\Target\CellSPU/../.. > /../Debug/bin/tblgen.exe -I

I was building llvm2.9 using MinGW64 on windows, msys was 32 bit so I specified --host option for a cross compiling. Following are my configure options: ../llvm2.9/configure --prefix=/home/AutoESL/llvm-obj --host=x86_64-w64-mingw32 --disable-multilib The error: make[1]: Entering directory `/home/AutoESL/llvm-obj/lib/VMCore' make[1]: ***

(sorry for the cross post, but this issue effects lots of people) Takumi diagnosed a problem when Zach switched LLVM to use compile-time multithreading, but it actually has little to do with the multithreading decisions. LLVM is rapidly moving to use more C++11 library features and more multithreading features. I think this is a good thing. However, we're hitting a specific issue on cygwin

Hi, I've encountered a problem invoking LLVM-generated x86_64 code on Windows from MSVC-compiled code. There seems to be disagreement between the two compilers over the calling convention for passing a 12 or 16 byte structure by value. e.g. struct aggregate { int a; int b; int c; int d; }; int test(aggregate byVal) { ... } LLVM chooses to pass byVal with a and b packed into rcx

I've modified the "$RHOME/bin/R" and "$RHOME/cmd/filename" so that you can use the same directories for multiple machines. That is, machines running various flavors of UNIX can access the same directories. The modified structure adds the directories $RHOME/bin/$OSTYPE/ $RHOME/lib/$OSTYPE/ to hold the machine specific binaries. For instance, here the $RHOME directory

I've modified the "$RHOME/bin/R" and "$RHOME/cmd/filename" so that you can use the same directories for multiple machines. That is, machines running various flavors of UNIX can access the same directories. The modified structure adds the directories $RHOME/bin/$OSTYPE/ $RHOME/lib/$OSTYPE/ to hold the machine specific binaries. For instance, here the $RHOME directory