similar to: [LLVMdev] FORTRAN compiler status?

Hi Duraid, > Does anyone know what the latest is w.r.t a FORTRAN front-end for > LLVM? Is anyone expecting to have typical f90/f95 programs compiling to > LLVM this year, or next? (I'm aware of the "NAG hack" and various other > f2c-type approaches, but they give me a strange feeling in my tummy.) support for Fortran will be much easier once LLVM rebases itself

I just noticed this - I can't promise any particular amount of TLC, but I'll certainly be giving the Fortran front-end some attention as soon as LLVM moves to gcc 4.2. For future reference, does anyone know of a good free Fortran compiler test suite? Cheers, -mike On 5/14/07, Duncan Sands <baldrick at free.fr> wrote: > Hi Duraid, > > > Does anyone know what the

Hi all, I'm looking into using LLVM to do some optimisations of Fortran code. As part of this, I've been trying to build the frontend with f95 support. At the moment, I'm trying to resolve undefined symbol problems for code defined in c-common.c + elsewhere - I'm taking the temporary approach of copy-pasting it into a new file, and linking that in. I have no idea if it will

On 11/8/06, Warren Armstrong <warren.armstrong at anu.edu.au> wrote: > Hi all, > > I'm looking into using LLVM to do some optimisations of > Fortran code. As part of this, I've been trying to build > the frontend with f95 support. At the moment, I'm trying > to resolve undefined symbol problems for code defined in > c-common.c + elsewhere - I'm taking

Hi, I have a first quick patch and a question. The patch links f951 with g++ when LLVM is enabled. It's at the end of this email. I wanted to know if I should submit patches with comments around them like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to the tree. I'd like to make it as easy as possible to apply these, so let me know any rules I should be following.

Hello LLVM-people, I've been trying (on and off) to compile the _full_ SPEC CPU2000 benchmark suite to LLVM bytecode. The biggest problem I'm facing is the Fortran benchmarks, for which some partial support is already available it seems (using f2c). Unfortunately the f2c compiler only allows the translation of Fortran-77 programs to C code (which is then compiled using llvm-gcc).

Hi Chris, > > I use NAG with llvm-gcc4. What sort of errors do you get? Did you > configure llvm-test with the appropriate flags to find it? > Yes, I did. llvm-test is configured as follows: (in /work/LLVM/1.8/ llvm/project/llvm-test): ./configure --with-spec2000=/work/SPEC_CPU2000_1.3_src/benchspec -- without-f2c --with-f95-bin=/work/NAG_f95/bin --with-f95-lib=/work/

On Wed, 30 Aug 2006, Kenneth Hoste wrote: > I've been trying (on and off) to compile the _full_ SPEC CPU2000 benchmark > suite to LLVM bytecode. The biggest problem > I'm facing is the Fortran benchmarks, for which some partial support is > already available it seems (using f2c). ok. > Unfortunately the f2c compiler only allows the translation of Fortran-77 >

On 9/1/06, Chris Lattner <sabre at nondot.org> wrote: > On Fri, 1 Sep 2006, Michael McCracken wrote: > > I wanted to know if I should submit patches with comments around them > > like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to > > the tree. I'd like to make it as easy as possible to apply these, so > > let me know any rules I

Hi, in a thread this afternoon about compiling the Fortran SPEC2000 to LLVM bytecode, Chris mentioned that it should be possible to compile to LLVM with the gfortran front end, although no one has necessarily tried it. I was surprised (and happy) to hear this, as under the impression that it would require a "complete rewrite of the gfortran backend" [1]. Now, I probably misinterpreted

On Wed, 30 Aug 2006, Kenneth Hoste wrote: >> I use NAG with llvm-gcc4. What sort of errors do you get? Did you >> configure llvm-test with the appropriate flags to find it? > Yes, I did. llvm-test is configured as follows: (in /work/LLVM/1.8/ > llvm/project/llvm-test): > ./configure --with-spec2000=/work/SPEC_CPU2000_1.3_src/benchspec -- > without-f2c

Hi, All, I have come across a problem building a DLL from .f90 source (R 2.3.1, Windows XP). When using the R CMD SHLIB procedure, the DLL itself was being built, but its export table was empty. Among the output from R CMD SHLIB the following message appeared: c:\mingw\bin\nm.exe: 'a.out': No such file The reason is the empty list of dependencies in the pattern rule for DLLs

On Fri, 1 Sep 2006, Michael McCracken wrote: > Hi, I have a first quick patch and a question. The patch links f951 > with g++ when LLVM is enabled. It's at the end of this email. Thanks, applied! > I wanted to know if I should submit patches with comments around them > like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to > the tree. I'd like to

We have a user here who is attempting to compile a package which requires f90 (gfortran will do). Our version of R was built with f77 (g77). When the user attempts to build the package, f77 is always invoked and fails due to the presence of f90 features. Is there a simple method or some documentation on how to force a package build to use a different compiler than the one used in

I am reading the manual sections illustrating how to call a Fortran subroutine from R. I feel uneasy at the explicit statement about ".Fortran" interface working with Fortran 77. I would like to call a Fortran-90 subroutine from my R script. Is that supported at all ? Thank you, Maura tutti i telefonini TIM! [[alternative HTML version deleted]]

On 30 Aug 2006, at 23:04, Chris Lattner wrote: > On Wed, 30 Aug 2006, Kenneth Hoste wrote: >>> I use NAG with llvm-gcc4. What sort of errors do you get? Did >>> you configure llvm-test with the appropriate flags to find it? >> Yes, I did. llvm-test is configured as follows: (in /work/LLVM/ >> 1.8/ llvm/project/llvm-test): >> ./configure

Hi, I found some bottlenecks in my R code with Rprof. First I wanted to rewrite them in C, but a colleague keeps suggesting that I learn Fortran, so maybe this is the time to do it... I like to learn new languages and do it fairly quickly. I would appreciate the advice of others about these questions: 1) I hear bad things about Fortran. Sure, F77 looks archaic, but F90/95 seems nicer. Is it

Hi, I'm having some problems cross-compiling from ppc (OS X) to x86 object files and to ia64, at all. I'd appreciate some advice as to whether or not I'm actually supposed to be able to do this, and what's wrong if so. Here's how I configured it: ../llvm-darcslocal/llvm/configure --with-llvmgccdir=$LLVMGCCDIR --prefix=$HOME/Documents/hpcl/LLVM/install The results work fine

I am trying to load a .so file and get the following error message: > dyn.load("taper.so",local=F) Error in dyn.load(x, as.logical(local), as.logical(now)) : unable to load shared library "/home/hpc1367/runs/taper/taper.so": ld.so.1: /usr/local/lib/R/bin/R.bin: fatal: relocation error: file /home/hpc1367/runs/taper/taper.so: symbol f90_init: referenced symbol not

OK, I noticed a few problems with my previous email, so I will boil the question down: What I want to do is compile for x86 and ia64 from darwin. I also want to load my own passes into opt and llc. Should I be using llvmc at all here, or should I be doing something like llvmgcc -> gccas -> opt -> llc ? I've given up on the filetype=obj argument, so now the problem is that llc is