similar to: Compiling R to run natively on Windows x64

Thank, i have posted a mail about that. What i don't understand, is why it only work on x64, it should be more logical that it work only on x86, since most library focus first on working x86 before x64. The function getMethodPointer come from here http://stackoverflow.com/questions/3104389/can-i-bind-an-existing-method-to-a-llvm-function-and-use-it-from-jitted-code they said "that

A long time ago, when I devised the grammar and structure of the Microsoft C++ name mangling scheme (decorated names), the document describing the object model and the name decoration scheme were made publically available. Perhaps this is still available publically, or perhaps Microsoft might be willing to share an up to date definition of the name-decoration grammar, especially in light of the

On 11 July 2015 at 13:14, Caldarale, Charles R <Chuck.Caldarale at unisys.com> wrote: >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Dibyendu Majumdar >> Subject: [LLVMdev] JIT compilation 2-3 times slower in latest LLVM snapshot > >> I updated my clone of the LLVM github mirror today and I am finding >> that

Hi, We have a demangler for the Itanium ABI, but looks like we don't have one for the MSVC-style symbols. Is there any good demangler we can import to LLVM? If there's no suitable demangler, I'd like to write one. Currently, we are using `UnDecorateSymbolName` function, but the function is available only on Windows (which is problematic when you are doing a cross-build), and the

Hi Eric, > From my perspective Win32 is the windows ABI and mingw and cygwin are their own ABIs No. They are using Windows Platform ABI for almost everything (e.g. calling API, C runtime, etc.). At least mingw does. The differences are exactly in unspecified area (e.g. passing / returning structs by value). The only difference is C++, where mingw / cygwin follows Itanium ABI and MSVC - its

Moving this month old RFC to llvmdev. Not sure why I sent this to cfe-dev in the first place... --- Based on code review discussion from John, he thinks filter expressions should be emitted into the body of the function with the try, rather than being outlined by the frontend. Instead of having the frontend create filter functions, we would use labels in place of typeinfo. The IR would look

Jon Harrop wrote: > Can you explain why you would like to generate DLLs on the > customer's computer rather than using LLVM as a JIT > compiler? Customers/clients unhappy with the inefficiency, extra CPU and RAM usage, and performance penalty of JIT. They require a faster, more efficient solution. The solution is to fully compile programs to native code at the time of

Skykill Skyoverside <skyoverside at live.fr> writes: [snip] My guess is that you are hitting a VS C++ ABI missing feature in Clang. Ask in the Clang mailing list for a confirmation, but IIRC there are still missing pieces on either object construction/destrucion, parameter passing, returning classes and C++ exception support.

_WIN32, WIN32, WIN64, and _WIN64 are the wrong definitions to be gating this on in the first place. They aren't at all meant to be x86/x86-64 specific. At best, they're 32-bit/64-bit specific, but that's not the intended use in the code. The correct definitions are _M_IX86 and _M_X64, as Martin said. I sent a patch to this ML that fixed these a few months ago but it was

Hi Reid, I’ve been following your proposal, and I’d be interested in helping out if I can. My main interest right now is in enabling C++ exception handling in clang for native (i.e. not mingw/cygwin) Windows targets (both 32-bit and 64-bit), but if I understand things correctly that will be closely related to your SEH work under the hood. I’m still trying to get up to speed on what is and is

Hi All, I Am new to Wine, and I try to get Office 97 to work, but the M$ Office installer dosen't work yet. Se bug 150 on:

On Jul 16, 2009, at 9:49 PM, Marcel Moolenaar wrote: >> For us to keep IA64 around (and for it to be minimally useful for >> your >> work!), I think that the backend should pass most of the simple >> programs in MultiSource/Benchmarks for example. It does *not* need >> to >> produce amazingly fast code, but the code needs to work. I don't >>

Hi, so yes assertions are enabled by default in Debug from what i could see in the CMakeLists.txt if( uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE" ) option(LLVM_ENABLE_ASSERTIONS "Enable assertions" OFF) else() option(LLVM_ENABLE_ASSERTIONS "Enable assertions" ON) endif() Without assertions enabled, when i'm running the program without the debugger, it

Hi Guys, I hope this is the correct mailing list for this question. I have a dual 1.6 Ghz Itanium with 4 Gb of memory. Yes, a lot of power for Asterisk. I am running SuSE Enterprise Server with the 2.6.5-7.97-default kernel. I have just started to look into Asterisk and I am in the building stage. Now building something on Itanium is almost always a bit of a challange. This is unfortunately

> On Feb 2, 2015, at 6:04 PM, Reid Kleckner <rnk at google.com> wrote: > I actually like the unified intrinsic approach here. The backend already has to know things about the personality function. Until recently we would assume that the personality function wants an Itanium LSDA, for example, and dump that out into a target-specific section. Now on Windows we look at the personality

On Jul 16, 2009, at 5:51 PM, Chris Lattner wrote: > > On Jul 16, 2009, at 2:30 PM, Marcel Moolenaar wrote: > >> >> BTW: I don't run Linux at all, so no Linux/ia64 support. >> I can see how that could be a problem for people. >> >> Anyway: my case is a weak one and I would understand if the >> target get axed without considering my email/request...

Red Hat is pleased to announce the availability of Update 2 for the Red Hat Enterprise Linux 4 family of products, including: - Red Hat Enterprise Linux AS 4 for x86, AMD64/EM64T, Itanium, POWER, S/390 and zSeries - Red Hat Enterprise Linux ES 4 for x86, AMD64/EM64T, Itanium - Red Hat Enterprise Linux WS 4 for x86, AMD64/EM64T, Itanium - Red Hat Desktop 4 for x86 and AMD64/EM64T Craig

Folks, I'm sorry for getting at this again, but this will not be the last discussion on the topic, so let's just get to business. We're about to merge the last critical patch to make EHABI compatible with other EH mechanisms in LLVM (D3079), and that has unearthed a few issues with the function attributes. Logan's blog post [1] contains a proposal to split unwinding from

Hello, I'd like to introduce myself, my company, and our upcoming use of LLVM. My name is John Reagan. I've been working on compilers and assemblers since 1983 (yes, 31 years). Most of that time was spent on compilers for VAX/VMS (later renamed to OpenVMS), then OpenVMS on Alpha, and OpenVMS on Itanium. I've also worked with the HP NonStop platform and was directly involved

Hi Talin, > 1) I'm trying to figure out the relationship between the __cxa_throw > function, and the _Unwind_RaiseException function mentioned in the ABI doc. > My guess is that _Unwind_RaiseException is the language-neutral > implementation of stack unwinding, and __cxa_throw is the C++ exception > semantics that are implemented on top of it. If that is the case, should I >