similar to: memory limitation with Fortran interface

I would like to call C routines from Fortran under linux as suggested in section 5.6 of the "Writing R extensions" documentation. I'm familiar with Fortran but not with C. I understand the example provided in Fortran: subroutine testit() double precision normrnd, x call rndstart() x = normrnd() call dblepr("X was", 5, x, 1) call rndend() end but I don't understand

I would like to call C routines from Fortran as suggested in section 5.6 of the "Writing R extensions" documentation. I'm familiar with Fortran but not with C. I understand the example provided in Fortran: subroutine testit() double precision normrnd, x call rndstart() x = normrnd() call dblepr("X was", 5, x, 1) call rndend() end but I don't understand the purpose

Hi, I have a package of my own which seems to work fine under linux. I want to make a compiled version for windows. (I work with windows 2000 and R 2.0) I have followed the steps described in the file readme.packages (in the top-level directory of the binary installation) and I had a trouble at this step (which aim is not documented): C:\Program Files\R\rw2000\src\gnuwin32>make libR.a

Hello! I have a program in Fortran and would like to build a matrix with random numbers, I have a function in C. However, I have problems with the use of function in R. Code to compile: R CMD SHLIB mat.f myrbeta.c -o func.so Code in C. #include <R.h> #include <Rmath.h> void F77_SUB(fseedi)(void){   GetRNGstate(); } void F77_SUB(fseedo)(void){   PutRNGstate(); } void

Hi, here are a couple of strange things happening with R.2.2.0 compiled under Mandrake-10.1 At the begining of the story I have segmentation fault using package RandomFields in conjuction with some Fortran code of mine loaded with dyn.load. One of my fortran programs contains a subroutine named fstat Trying to trace , I simplified the sequence as much as possible and I end up with the the

Hi all, I'm working out some Fortran code for which I want to compute the Choleski decomposition of a covariance matrix in Fortran. I tried to do it by two methods : 1) Calling the lapack function DPOTRF. I can see the source code and check that my call is correct, but it does not compile with: system("R CMD SHLIB ~/main.f") dyn.load("~/main.so") I get: Error in

Hi , I'm currently trying to make available a few fortran subroutines and R functions (which make interface to these subroutines), as an R package. I'm doing it under linux with R 1.9.0 (but hope to do it for windows too). I have trouble for loading my fortran code. Here are the steps involved : 1) In R: # Create tree for package

Hi, I have some trouble with the result of a fortran function calling the R binomial RNG: The C function rbinom is wrapped as in the file attached. My main fortran program starts as call rndstart() and ends as call rndend() I happen to call the binomial RNG within a loop as b = ggrbinom(1.d0,0.5d0) write(*,*) 'b=',b In certain cases, after a few iterations in the loop, b get

Hi Duncan, A DragonEgg/GCC-related question: do you know where these strange FRAME tokens originate from (e.g. %struct.FRAME.matmul)? Compiling simple Fortran code with DragonEgg: > cat matmul.f90 subroutine matmul(nx, ny, nz) implicit none integer :: nx, ny, nz real, dimension(nx, ny) :: A real, dimension(ny, nz) :: B real, dimension(nx, nz) :: C integer :: i, j, k real,

Hello, I'm finding problems with BackEdgeTaken count calculation in even simple fortran loops with gfortran-4.6 + DragonEgg 3.0. Even for simple double loops like this one: program test2 integer i,j,k dimension k(100,100) do j=1,100 do i=1,100 k(i,j) = i enddo enddo write(*,*) k(1,30) end make the ScalarEvolution

Mmm, sorry, the patch I posted crashes if ExitBr is null (which it may be ...) , this one should be ok (and passess all the ScalarEvolution tests in LLVM): diff --git a/lib/Analysis/ScalarEvolution.cpp b/lib/Analysis/ScalarEvolution.cpp index daf7742..b10fab2 100644 --- a/lib/Analysis/ScalarEvolution.cpp +++ b/lib/Analysis/ScalarEvolution.cpp @@ -4293,9 +4293,15 @@

Attached 2012/2/8 Marcello Maggioni <hayarms at gmail.com>: > Mmm, sorry, the patch I posted crashes if ExitBr is null (which it may > be ...) , this one should be ok (and passess all the ScalarEvolution > tests in LLVM): > > diff --git a/lib/Analysis/ScalarEvolution.cpp b/lib/Analysis/ScalarEvolution.cpp > index daf7742..b10fab2 100644 > ---

Your patch should include a testcase, see test/Analysis/ScalarEvolution for examples. "BranchInst* " should be "BranchInst *". You should have spaces after the // in your comments. One of the comment lines isn't indented properly. Nick On 8 February 2012 12:05, Marcello Maggioni <hayarms at gmail.com> wrote: > Attached > > 2012/2/8 Marcello Maggioni

Dear all, Yesterday, from the customer's code I observed relatively simple case, where Polly is unable to detect parallelizable outer loop. Consider two versions of Fortran routine: 1) subroutine filter(H, szh, X, szx, Y, szy) implicit none integer(kind=IKIND), intent(in) :: szh, szx, szy real(kind=RKIND), intent(in) :: H(szh), X(szx) real(kind=RKIND), intent(out) :: Y(szy)

Well, it wasn't intended as a "real" patch to be included , but more as a "proof of concept" for a solution. Do you think it is a valid solution and I'm correct in my assumption? If so then I'll clean up the patch and attach a testcase for inclusion. Thanks! Marcello 2012/2/9 Nick Lewycky <nlewycky at google.com>: > Your patch should include a testcase,

On 8 February 2012 15:50, Marcello Maggioni <hayarms at gmail.com> wrote: > Well, it wasn't intended as a "real" patch to be included , but more > as a "proof of concept" for a solution. Do you think it is a valid > solution and I'm correct in my assumption? If so then I'll clean up > the patch and attach a testcase for inclusion. > I'm

This is the .ll for that graph (attached). I think I understand what you are saying. This particular testcase returns CNC not because the exit block doesn't have a unique predecessor, but because the unique predecessor (the inner loop block) has a successor that is inside the loop (in this case itself, because it's the inner loop block). That doesn't change, anyway, the assuption that

This is instead a very simple (handmade) test case that triggers the problem (attached) Also a more conforming patch has been attached 2012/2/9 Marcello Maggioni <hayarms at gmail.com>: > This is the .ll for that graph (attached). I think I understand what > you are saying. > This particular testcase returns CNC not because the exit block > doesn't have a unique predecessor,

FInally I had the time to complete everything up. Now I included the test case in the patch and the testcase runs with the LLVM tests system. 2012/2/9 Marcello Maggioni <hayarms at gmail.com>: > This is instead a very simple (handmade) test case that triggers the > problem (attached) > Also a more conforming patch has been attached > > 2012/2/9 Marcello Maggioni <hayarms

Oops, sorry for the message title, making it more descriptive now... 2013/2/3 Dmitry Mikushin <dmitry at kernelgen.org> > Dear all, > > Yesterday, from the customer's code I observed relatively simple case, > where Polly is unable to detect parallelizable outer loop. Consider two > versions of Fortran routine: > > 1) > > subroutine filter(H, szh, X, szx, Y,