similar to: COFF::IMAGE_REL_AMD64_REL32 relocation overflow when compiling for x86_64

Thanks Andy, helpful as always! 1 is a possibility, but not ideal for us. Could you elaborate a little on 3? I don't really know what a jump stub is, but am guessing it's a kind of "alternative symbol" which would just act as a middle man to invoke the "real" symbol in the static library. If that's the case, I can think of a way to implement it for specific

First of all, thanks very much to Lang for fixing the BSS section bug; works like a charm! I’ve been unable to reproduce the 32 bit relocation on 64 bit code (I’ll let you know if I do). However, I’m still having issues with resolving the 64 bit symbol relocations. In case it’s relevant, the specific symbol my program is tripping up on is IID_IOleObject, where TargetAddress is dereferenced

That's great news, thanks! If I can be of any help, let me know. :) I'll see if I can reduce the example for the relocation issue whilst you're at it. Regards, Joshua -- Joshua Gerrard JUCE Software Developer *ROLI’s **award-winning* <http://www.telegraph.co.uk/luxury/design/31520/the-seaboard-grand-piano-wins-designs-of-the-year-2014-award.html>* Seaboard GRAND, celebrated

Oops, sorry for the spam. That last comment was incorrect. It’s IMAGE_REL_AMD64_REL32 not _5 > On 5 Oct 2015, at 17:26, Joshua Gerrard <joshua.gerrard at roli.com> wrote: > > Additional info: when the relocation issue does occur the relocation type is IMAGE_REL_AMD64_REL32_5 > >> On 5 Oct 2015, at 17:16, Joshua Gerrard <joshua.gerrard at roli.com> wrote: >>

It’s pretty intermittent at the moment…sometimes I get the relocation overflow issue, sometimes I get another issue about BSS sections having no contents. The source code to reproduce either is simple: #include <iostream> int main (int argc, char* argv[]) { } I’ve managed to reproduce the BSS section issue in clang consistently, and since that comes before terms of where it happens in

Thanks for the link! There’s some code there that looks extremely relevant to say the least. > On 1 Oct 2015, at 19:00, Hayden Livingston <halivingston at gmail.com> wrote: > > Maybe looking at their code might help: > > https://github.com/dotnet/llilc/blob/dd12743f9cdb5418f1c39b2cd756da1e8396a922/lib/Jit/LLILCJit.cpp#L299 > > On Thu, Oct 1, 2015 at 10:45 AM, David

OK, so, if I understand, the tag is at 3.8.1, but there is no source drop available for download? Del From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Tuesday, July 5, 2016 4:12 PM To: Del Myers <delmyers at microsoft.com> Cc: LLVM Dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] llvm 3.8.1 Release Hi Del, Yes, the tag is for the latest stable release. It's

We just wanted to check to see if they are real bugs first. We will report them if they are not already fixed. Thanks. Del From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Wednesday, July 6, 2016 12:07 AM To: Del Myers <delmyers at microsoft.com> Cc: LLVM Dev <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] llvm 3.8.1 Release Did you report the bugs? It would be a

I started to implement inlining of the stack probe function based on Microsoft's inlined stack probes in https://github.com/Microsoft/llvm/tree/MS. Do we know why the stack pointer cannot be updated in a loop (which results in ideal code)? I noticed that was commented in Microsoft's code. I suspect this is due to debug or unwinding information, since it is allowed on Windows x86-32. I

Hi, First off, I'm new to this mailing list so please forgive me if I'm posting to the wrong one. I have a quick question about the llvm 3.8.1 release. http://llvm.org/ indicates that 3.8.1 was released on June 15, but there is no download link for it? Also, when you sync to the 3.8.0 tag, in svn or the git mirror, it seems that there are commits passed the 3.8.0 release. Does that mean

Dear dev team, I was sorry to see the announcement of Duncan about his retirement from maintaining the R Windows build and Rtools. Duncan, thank you incredibly much for your 15 years of devotion and your impressive contribution to the R community as a whole. Thinking about the future, I wondered whether there were plans for the succession of Duncan. Is it the intention to continue providing

?library Cheers, Bert Bert Gunter "The trouble with having an open mind is that people keep coming along and sticking things into it." -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) On Mon, Oct 23, 2017 at 11:36 AM, Rene J Suarez-Soto < rene.j.suarez at gmail.com> wrote: > I installed R 3.4.2 (Windows) and noticed that 30 folders are under my

I installed R 3.4.2 (Windows) and noticed that 30 folders are under my R_HOME/library folder. I assume all of these are R base packages. Is this correct? Where can I see a list of current R base packages? Also; are R base packages also in CRAN? and are these packages updated only when a new version of R is released or can the be updated at a different time? Thanks [[alternative HTML version

We used a similar thing in the phx compiler. We called it "ExternalMemoryTag". It was a name for "all the program state that doesn't have another name", and in phx (unlike LLVM) it was easy to define what "has another name" meant since we kept an explicit universe of names in our alias metadata. The inferences were flipped the other way, though; being able to

HI Stefan, CC'ing Reid Kleckner, who might have some insight here, and llvm-dev as this may be of interest to other windows JIT users. I am facing the issue that C++ dynamic_cast doesn't work for types > loaded from object files with RuntimeDyLd. <snip> Do you think it is possible that RuntimeDyLd misses type info data in > the COFF file or doesn't wire it up

I think that even though some Microsoft employees may have good intentions Microsoft as a company can not be trusted. There will be always a danger that they will try to create their own version of R which works only on Windows and that will become increasingly divergent from "other" R. We witnessed such (cursed in my opinion) attempts with their treatment of Java and Internet Explorer.

Thanks for the pointer, it's always helpful to be able to see how another project solved similar problems. > On Mar 8, 2016, at 11:24 AM, Andy Ayers <andya at microsoft.com> wrote: > > FWIW, LLILC (https://github.com/dotnet/llilc) uses MCJIT with a custom memory manager to hold onto the binary bits and discard the rest. > > As far as I know it doesn't leak, though

Hello Tom, Tom Stellard via llvm-dev <llvm-dev <at> lists.llvm.org> writes: > > Hi, > > I'm working on uploading all the packages now. I've downloaded them files several times from different locations (suspected my webgw might muck with the content) using different clients and the result is the same: $ gpg --verify ~/Downloads/cfe-3.8.1.src.tar.xz.sig

We were also able to reproduce the issue on Windows Server 2012. If there's anything we can do to help please let me know; Elliot Waingold (CC'd here) can provide access to the VM we used for testing if that's of any help. # David Smith -- David M Smith <davidsmi at microsoft.com> R Community Lead, Revolution Analytics (a Microsoft company)? Tel: +1 (312) 9205766 (Chicago IL,

YES. My use of LLVM involves an app that JITs program after program and will quickly swamp memory if everything is retained. It is crucial to aggressively throw everything away but the functions we still need to execute. I've been faking it with old JIT (llvm 3.4/3.5) by using a custom subclass of JITMemoryManager that squirrels away the jitted binary code so that when I free the Modules,