similar to: [LLVMdev] State of Win64 exceptions?

Nobody? Is this basically dead? Won't happen? In progress? :/ On 12 September 2012 18:53, Manu <turkeyman at gmail.com> wrote: > 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? > >

Hi people, Unlike GCC, LLVM has seemingly good support for interoperability with MSVC built windows code. This makes LLVM particularly attractive to my company/project, but it seems LLVM doesn't support writing PDB debug into into it's COFF output. It seems Win64 exception handling has been added recently, which perhaps makes PDB the only outstanding feature for effective use with

On Wed, Sep 12, 2012 at 12:19 PM, Manu <turkeyman at gmail.com> wrote: > On 12 September 2012 20:49, Nathan Jeffords <blunted2night at gmail.com>wrote: > >> >> On Wed, Sep 12, 2012 at 9:46 AM, Manu <turkeyman at gmail.com> wrote: >> >>> /Z7, that's the one. Maybe this approach can be used by LLVM? I presume >>> LLVM is capable of

On Wed, Sep 12, 2012 at 9:46 AM, Manu <turkeyman at gmail.com> wrote: > Oops, I've managed to exclude the list... > > > On 12 September 2012 19:28, Nathan Jeffords <blunted2night at gmail.com>wrote: > >> >> >> On Wed, Sep 12, 2012 at 8:50 AM, Manu <turkeyman at gmail.com> wrote: >> >>> On 12 September 2012 18:19, Nathan

On 12 September 2012 20:49, Nathan Jeffords <blunted2night at gmail.com> wrote: > > On Wed, Sep 12, 2012 at 9:46 AM, Manu <turkeyman at gmail.com> wrote: > >> /Z7, that's the one. Maybe this approach can be used by LLVM? I presume >> LLVM is capable of producing CV info already? Maybe this configuration is >> already possible? >> It'd be

Oops, I've managed to exclude the list... On 12 September 2012 19:28, Nathan Jeffords <blunted2night at gmail.com> wrote: > > > On Wed, Sep 12, 2012 at 8:50 AM, Manu <turkeyman at gmail.com> wrote: > >> On 12 September 2012 18:19, Nathan Jeffords <blunted2night at gmail.com>wrote: >> >>> This project seems to have some ability to convert to

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

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)

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

LLVM3.8 version. https://bugs.llvm.org//show_bug.cgi?id=24233. The example can catch exception. But I use my own code for testing, CustomEHMemoryManager allocated memory address is very large, allocateCodeSection, allocateDataSection assigned address (more than 32 bit address space) is getting smaller and smaller. Cause registerEHFrames to fail. 3.9.1 or 4.0.0 version has been supported on win

Hai Manu, > -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens Manu > Baylac via samba > Verzonden: vrijdag 3 november 2017 20:21 > Aan: samba at lists.samba.org > Onderwerp: Re: [Samba] Unable to upload printer drivers > > Hello Louis and list, > > > Le 03/11/2017 à 10:25, L.P.H. van Belle via samba a écrit :

For help: Llvm generated instruction calls a function (extern), 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

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 Chandler Carruth <chandlerc at google.com>: > > On Tue,

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. Unfortunately this is being reported

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

+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

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

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

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

I have an old conferencing app that uses theora and I'm building it for win64. libthora 1.1 builds just fine, but libtheora 1.0 has errors related to assembly code when building for x64. I've tried using 1.1, but the video does not look right -- the clients all generate their own first 3 packets instead of sending them over the network since they assume they are all on the same version