similar to: Windows gcc toolchain for R 3.2.0

To anyone following the Windows toolchain saga: The gcc 4.9.2 toolchain that is currently in Rtools33 has too many incompatibilities with existing code, so we won't be using it in the R 3.2.0 build. I will soon be uploading to CRAN a new version of Rtools33 that is very similar to Rtools32, containing gcc 4.6.3. We are continuing to work on the new toolchain, and hope to have it ready

Duncan, ----- Original Message ----- > From: "Duncan Murdoch" <murdoch.duncan at gmail.com> > To: "R-devel at r-project.org" <r-devel at r-project.org>, rcpp-devel at r-forge.wu-wien.ac.at > Sent: Wednesday, March 18, 2015 6:27:26 AM > Subject: [Rcpp-devel] Windows gcc toolchain for R 3.2.0 > > To anyone following the Windows toolchain saga: >

On 29/05/2015 4:16 PM, Sue McDonald wrote: > My apologies for cross-posting. I found this site, after I had posted on > stack-overflow. > > I need to compile several static libraries (C & Fortran) which will later > be linked with an R package. Rtools33 directory includes /i686-w64-mingw32 > directory which I understand creates 32 bit binaries. Yet, there are other > 64

On 30/05/2015 13:14, Duncan Murdoch wrote: > On 29/05/2015 4:16 PM, Sue McDonald wrote: >> My apologies for cross-posting. I found this site, after I had posted on >> stack-overflow. >> >> I need to compile several static libraries (C & Fortran) which will later >> be linked with an R package. Rtools33 directory includes /i686-w64-mingw32 >> directory

On Tue, Mar 10, 2015 at 4:07 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 09/03/2015 11:02 PM, Hsiu-Khuern Tang wrote: >> Hi Duncan, >> >> On Mon, Mar 9, 2015 at 10:40 AM, Duncan Murdoch >> <murdoch.duncan at gmail.com> wrote: >>> On 09/03/2015 11:07 AM, Hsiu-Khuern Tang wrote: >>>> >>>> On Mon, Mar 9, 2015 at

My apologies for cross-posting. I found this site, after I had posted on stack-overflow. I need to compile several static libraries (C & Fortran) which will later be linked with an R package. Rtools33 directory includes /i686-w64-mingw32 directory which I understand creates 32 bit binaries. Yet, there are other 64 bit directories as well. I have three related questions: 1. Can

On 09/03/2015 11:02 PM, Hsiu-Khuern Tang wrote: > Hi Duncan, > > On Mon, Mar 9, 2015 at 10:40 AM, Duncan Murdoch > <murdoch.duncan at gmail.com> wrote: >> On 09/03/2015 11:07 AM, Hsiu-Khuern Tang wrote: >>> >>> On Mon, Mar 9, 2015 at 3:50 AM, Duncan Murdoch <murdoch.duncan at gmail.com> >>> wrote: >>>> On 08/03/2015 10:02 PM,

Hi Duncan, On Mon, Mar 9, 2015 at 10:40 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 09/03/2015 11:07 AM, Hsiu-Khuern Tang wrote: >> >> On Mon, Mar 9, 2015 at 3:50 AM, Duncan Murdoch <murdoch.duncan at gmail.com> >> wrote: >> > On 08/03/2015 10:02 PM, Hsiu-Khuern Tang wrote: >> >> Hi, >> >> >> >> [This

On Mon, Mar 9, 2015 at 3:50 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 08/03/2015 10:02 PM, Hsiu-Khuern Tang wrote: >> Hi, >> >> [This is a follow-up to the "New version of Rtools for Windows" thread >> in January, but I just subscribed and don't know how to reply to an >> old thread -- my apologies.] > > I am planning to

On Wed, 2015-03-18 at 07:55 -0700, Dan Tenenbaum wrote: > Is it not considered a "known problem" that C++ libraries linked > against by R packages need to be rebuilt with g++ 4.9.2 in order for > the R packages to install/load? This could well be due to incompatible thread models (win32 vs posix). See the thread "V8 crashes..." on the Rcpp-devel mailing list. We have

I was debugging a problem reported to me regarding PL/R, and found that I can duplicate it using only R sources. It might be characterized as possibly a misuse of the findFun() function, but I leave that for the R devel experts to decide. The below results are all with R-2.5.1 (I can't seem to download r-patched at the moment, but didn't see anything in the 2.5.1-patched release

Thanks to the hard work of Bill Wendling (wendling at isanbard.org), LLVM now translates setjmp/longjmp calls into the LLVM "exception handling" instructions invoke & unwind. This means that all of the LLVM optimizers are now aware of the extra control flow edges made possible by setjmp & longjmp, so data flow analyses won't make incorrect transformations. A variety of

On 11/03/2015 3:09 PM, Dan Tenenbaum wrote: > > ----- Original Message ----- > > From: "Duncan Murdoch" <murdoch.duncan at gmail.com> > > To: "Dan Tenenbaum" <dtenenba at fredhutch.org> > > Cc: r-devel at r-project.org > > Sent: Wednesday, March 11, 2015 12:06:48 PM > > Subject: Re: [Rd] Notes on building a gcc toolchain for

On Mon, 21 Nov 2005 16:53:58 -0600 (CST), Chris wrote: >On Mon, 21 Nov 2005, Kurt Harriman wrote: >> I would like to build an x86 executable consisting of a number of >> subsystems (mostly legacy C code). One subsystem will be compiled >> to native code using llvm. It calls, and is called by, the other >> subsystems, many of which have to be compiled using gcc

Do the LLVM Setjmp/Longjmp intrinsics interact with C++ exception handling and execute C++ cleanup actions? I compiled a small example using setjmp/longjmp using clang and they did not execute C++ cleanup actions and calling longjmp bypassed calling destructors on objects that were allocated between the call to setjmp and longjmp. I’m wondering if the LLVM intrinsics behave differently from

Martin wrote: > Just this morning, > I found (again!, we had something close to this before) > the following related bugous behavior : > After interrupting a plot (which would have taken a few minutes and was > "wrong" anyway), starting another plot, interrupting again [with C-c], > and maybe the same once more, > R started just giving a ">" prompt

On 08/03/2015 10:02 PM, Hsiu-Khuern Tang wrote: > Hi, > > [This is a follow-up to the "New version of Rtools for Windows" thread > in January, but I just subscribed and don't know how to reply to an > old thread -- my apologies.] I am planning to put a new Rtools online today that uses a different build of gcc 4.9.2. I will be concentrating on getting it to work

On Tue, Nov 24, 2015 at 12:10:12AM +0100, Jeroen Ooms wrote: > Currently it is all to easy for package authors to introduce a memory > leak or stack imbalance by calling Rf_error() or > R_CheckUserInterrupt() in a way that skips over the usual cleanup > steps. I have a more modest request: Please improve the documentation of exactly what Rf_error() does and how it should be used!

Hi, [This is a follow-up to the "New version of Rtools for Windows" thread in January, but I just subscribed and don't know how to reply to an old thread -- my apologies.] I was able to use the nuwen distro to build a gcc 4.9.2 toolchain and use it to build the latest R-patched with it. Below are some notes about what I did; I hope they will be useful for keeping Rtools

Nick Johnson wrote: >> probably there should be a switch to choose whether codegen should turn >> unwind/invoke into dwarf or setjmp/longjmp style code. It seems to me that there is an implicit, and undocumented, assumption that unwinding needs to handle stack-allocated objects. In languages without stack-allocated objects (ie. most languages that support exceptions) there is no