search for: win64

...t; unused results, but not of unused objects. Maybe that's an incorrect > recollection or maybe it's ancient history, however. I got no warnings with the patch on Debian 8 + MinGW-w64. Here's the relevant compilation excerpt: make[3]: Entering directory '/usr/src/syslinux/bios/win64' x86_64-w64-mingw32-gcc -Wno-sign-compare -Os -fomit-frame-pointer -D_FILE_OFFSET_BITS=64 -I/usr/src/syslinux/win64 -I/usr/src/syslinux/win64/.. -I/usr/src/syslinux/win64/../win -I/usr/src/syslinux/bios -I/usr/src/syslinux/win64/../libfat -I/usr/src/syslinux/win64/../libinstaller -I/usr/...

This is release 0.9.23 of Wine, a free implementation of Windows on Unix. What's new in this release: - Massive update of printf formats for Win64 compatibility. - Dynamic drive support on MacOSX. - Still more MSI fixes and improvements. - Lots of bug fixes. Because of lags created by using mirrors, this message may reach you before the release is available at the public sites. The sources will be available from the following locations...

The variable 'ok' is never used and generates a warning. Remove it. Also ntfssect.c is designed to be compiled in non Unicode mode when using MSVC compilers, so remove all ambiguity about it (LPCTSTR -> LPCSTR, use of 'A' API calls) so that it doesn't break when compiled in Unicode mode, which is what Rufus uses with MSVC. -------------- next part --------------

Hello! I am updating to the R-devel version as of 2/28 and recompiling with OpenBLAS. I got that to compile nicely. I am now updating a package that uses the OpenBLAS and the PGI compiler, which has changed too. I just changed the path names in Makevars. Here is the Makevars file. FC= d:/PGI/win64/18.10/bin/pgf90 F77= d:/PGI/win64/18.10/bin/pgf90 CC = d:/PGI/win64/18.10/bin/pgcc FFLAGS= -Ld:/PGI/win64/18.10/bin/pgf90.dll -Ld:/PGI/win64/18.10/bin/pgc14.dll FLIBS= -Ld:/PGI/win64/18.10/bin/pgf90.dll -Ld:/PGI/win64/18.10/bin/pgc14.dll PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) MPI_FFLAGS= -...

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 opened reviews for four of them (the fifth got LGTM in the dis...

I am having problems with my program decoding .ogg files on the Win64 platform and am wondering if this is a known issue or not. I have tried using the prebuilt .dll's, the static .lib's and building from source (1.1.3) and I get the same results. My program is being compiled on a win32 platform, but the decoder fails if I run it on a win64 system. Unfortu...

Hi all, In my MSVC-compiled project I am using MCJIT to run some generated code. I faced that in case of Win64 ('x86_64-pc-win32-elf') __try/__except block doesn't work - the stack can not be unwound. I have found that the only way to fix it is implementing my own *registerEHFrames* function of the Memory Manager (but I'm not sure this helps). Maybe someone had a success solving the same pr...

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.or...

Hello! I've just tried generating Win64 code and the result is not that good. First of all, XMM registers are saved without reason to do so. Not only this slows the performance but leads to random crashes too. XMMs are stored to the stack with MOVAPS instruction which requires 16-byte alignment which is not always the case. lli.exe (bui...

...and smaller. Cause registerEHFrames to fail. 3.9.1 or 4.0.0 version has been supported on win x64? Or how to solve this problem? haifeng.qin at wellintech.com 发件人： haifeng.qin at wellintech.com 发送时间： 2017-02-17 10:38 收件人： llvm-dev 主题： 回复: How to catch EXCEPTION_ACCESS_VIOLATION exceptions on win64 I'm sorry。 I make mistakes. SE can be catched. haifeng.qin at wellintech.com 发件人： haifeng.qin at wellintech.com 发送时间： 2017-02-16 17:48 收件人： llvm-dev 主题： How to catch EXCEPTION_ACCESS_VIOLATION exceptions on win64 For help: Llvm generated instruction calls a function (extern), the function...

...1-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 comment on the bug, however, says that it appears to be fixed. >> I don't have a Win64 box to test it. Can someone confirm that it now works >> (or still doesn't)? > Yes, this particular issue was workarounded, so stuff works fine on ToT. > > -...

Hi Chandler, Kai contributed the WIN64 SEH patch some time ago on llvm-commits: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131118/196105.html it was never completed. Kai also responded in this thread. I opened a phabricator for the patch http://reviews.llvm.org/D3418 Yaron 2014-04-18 12:31 GMT+03:00 Chandle...

On Thu, Jul 30, 2009 at 5:32 PM, Peter Shugalev<peter at shugalev.com> wrote: > Hello! > > I've just tried generating Win64 code and the result is not that good. > > First of all, XMM registers are saved without reason to do so. Not only > this slows the performance but leads to random crashes too. XMMs are > stored to the stack with MOVAPS instruction which requires 16-byte > alignment which is not alway...

Hello > I don't know. I feel reluctant to generate different IRs for Win32 and > for Win64. Unfortunately, you should. Think about differences and between _Complex type and struct {double, double}. >From LLVM's point of view these are same types, however many ABIs have special rules for passing / returning _Complex, this is possible to handle in frontend only. > Since the C ca...

Hello guys, 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 comment on the bug, however, says that it appears to be fixed. I don't have a Win64 box to test it. Can someone confirm that it now works (or still doesn't)? Félix -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pi...

Hi again, Can anyone tell me about the state of Win64 exceptions? I've noticed that there are a good few related patches since the release of 3.1. Is it working now? Is it likely 3.2 will support Win64 exceptions? Cheers. - Manu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llv...

...xtern), the function will have a SEH exception (EXCEPTION_ACCESS_VIOLATION), But JIT can not capture the exception of the EXCEPTION_ACCESS_VIOLATION. I saw Bug 24233. EXCEPTION_ACCESS_VIOLATION exception cannot be captured after modification. How to catch EXCEPTION_ACCESS_VIOLATION exceptions on win64 ? haifeng.qin at wellintech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170216/d3e7098f/attachment-0001.html>

+LLVMdev On Aug 4, 2012, at 9:45 AM, João Matos wrote: > Charles Davis did a lot of work on Win64 SEH support in LLVM, check commits r131652-r132880. > > As I haven't tested it yet, what exactly is broken? It's not finished yet. All the stuff for assembly code that uses Win64 EH is done, but not the code-gen-side stuff (cf. Win64Exception class in CodeGen). I was about to finish...

...s the fallback method of saving and restoring registers on the stack, which does work correctly with alignment. If I recall correctly it also doesn't save any registers unnecessarily, but I could be wrong about that. Anyway, it's hack, but if all you want for now is to be able to work with Win64 and use SSE this might offer a solution. I wasn't aware of the second bug you're describing, but the one in your latest e-mail about not being able to have more than four arguments I'm experiencing as well. I'm afraid I haven't found any workaround for that yet. Cheers, Nicol...

Hello, I think I've found a bug in the calling convention support for X86-64/ Win64. It doesn't correctly save and restore the XMM registers in the function prolog/epilog. (The problem only exists on Win64, since Linux and Mac OS use calling convention in which these registers are volatile and not callee-saved.) X86RegisterInfo::getCalleeSavedRegs() when called for a...