similar to: [LLVMdev] gfortran calling convention

On 9/9/06, Chris Lattner <sabre at nondot.org> wrote: > On Sat, 9 Sep 2006, Steven Bosscher wrote: > > You wrote: > >> The NIST F77 test suite doesn't seem to be compatible with gfortran at > >> all, > > Actually, the entire suite compiles flawlessly with gfortran. > > See http://gcc.gnu.org/wiki/GFortranResults > > Was that true of GCC 4.0.1?

On 9/9/06, Michael McCracken <michael.mccracken at gmail.com> wrote: > On 9/9/06, Steven Bosscher <stevenb.gcc at gmail.com> wrote: > > On 9/9/06, Chris Lattner <sabre at nondot.org> wrote: > > > On Sat, 9 Sep 2006, Steven Bosscher wrote: > > > > You wrote: > > > >> The NIST F77 test suite doesn't seem to be compatible with

On 9/9/06, Steven Bosscher <stevenb.gcc at gmail.com> wrote: > On 9/9/06, Chris Lattner <sabre at nondot.org> wrote: > > On Sat, 9 Sep 2006, Steven Bosscher wrote: > > > You wrote: > > >> The NIST F77 test suite doesn't seem to be compatible with gfortran at > > >> all, > > > Actually, the entire suite compiles flawlessly with

Another option might be g95 instead of gfortran. I haven't used it for a while, but I seem to recall it working fine in gcc 4.0.1. On 9/11/06, Michael McCracken <michael.mccracken at gmail.com> wrote: > On 9/9/06, Michael McCracken <michael.mccracken at gmail.com> wrote: > > On 9/9/06, Steven Bosscher <stevenb.gcc at gmail.com> wrote: > > > On 9/9/06, Chris

On Sat, 9 Sep 2006, Steven Bosscher wrote: > You wrote: >> The NIST F77 test suite doesn't seem to be compatible with gfortran at >> all, > Actually, the entire suite compiles flawlessly with gfortran. > See http://gcc.gnu.org/wiki/GFortranResults Was that true of GCC 4.0.1? -Chris -- http://nondot.org/sabre/ http://llvm.org/

On Sat, 9 Sep 2006, Michael McCracken wrote: >> No, gfortran in gcc 4.0 is, ehm, highly experimental (read: a piece of >> junk). Gfortran in gcc 4.1 was the first one that worked for NIST (and >> for SPEC). > > Hm. I had noticed a bunch of changes in the current sources, but had > hoped 4.0.1 wasn't too far behind. This is discouraging. So, it sounds > like it

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 9/11/06, Chris Lattner <sabre at nondot.org> wrote: > On Sat, 9 Sep 2006, Michael McCracken wrote: > >> No, gfortran in gcc 4.0 is, ehm, highly experimental (read: a piece of > >> junk). Gfortran in gcc 4.1 was the first one that worked for NIST (and > >> for SPEC). > > > > Hm. I had noticed a bunch of changes in the current sources, but had >

On Wed, 30 Aug 2006, Michael McCracken wrote: > 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. Yup. > I was surprised (and happy) to hear this, as under the impression that > it would require a

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

OK: despite Dirk's very kind help, I decided that trying to deal with R configuration and Debian configuration simultaneously was too difficult. I did manage to solve my problem by reconfiguring/making/ installing all of 2.3.1 from source: ./configure F77=/usr/bin/g77 make make install A few questions inspired by this experience: (1) it seems a bit odd that R sets F77=gfortran by

The NIST F77 test suite doesn't seem to be compatible with gfortran at all, so I had to work from my own sample codes, and generate test cases from them. Here's what works now, and I have a separate test case for each of these: statement functions intrinsic functions (print, cos, etc) loops, goto statments scalarized array operations function calls with *no arguments* simple common

Chris and Bill, I have tested the proposed patch from... http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016490.html under i686-apple-darwin9 and it solves the problems building gfortran from llvm svn. The resulting compiler works fine so can we get that patch in before 2.4 is release? Jack ps We do have one oddity left in llvm-gfortran from current llvm svn. I find

On Oct 30, 2008, at 5:23 PM, Jack Howarth wrote: > ps We do have one oddity left in llvm-gfortran from current llvm > svn. I find everytime I compile something with llvm-gfortran that > I get a series of warning messages... > > f951: warning: command line option "-Wformat" is valid for C/C++/ > ObjC/ObjC++ but not for Fortran > f951: warning: command line option

On Oct 30, 2008, at 11:02 PM, Chris Lattner wrote: > On Oct 30, 2008, at 5:23 PM, Jack Howarth wrote: >> ps We do have one oddity left in llvm-gfortran from current llvm >> svn. I find everytime I compile something with llvm-gfortran that >> I get a series of warning messages... >> >> f951: warning: command line option "-Wformat" is valid for C/C++/

Hi all, (Originally posted to r-help) I'm porting a package that I've worked on for OS X to Windows. The package is written in F95 so I need to compile it with gfortran and link it with gcc4. I've been trying to build an R with gcc4 without luck so far. If there is a binary of such a thing info would be appreciated. This package requires a Makefile. My question is, how can I find

From the configure output of the latest devel snapshot: > checking for g77... no > checking for f77... no > checking for xlf... no > checking for frt... no > checking for pgf77... no > checking for fl32... no > checking for af77... no > checking for fort77... no > checking for f90... no > checking for xlf90... no > checking for pgf90... no > checking for

On Sat, May 04, 2019 at 06:42:47PM +0200, Thomas K?nig wrote: > > > - figure out Fortran2003 specification for C/Fortran interoperability > > -- this _sounds_ like the right solution, but I don't think many > > understand how to use it and what is implied (in particular, will > > it require making changes to LAPACK itself?) > > That would actually be fairly

Hi, gfortran trunk and 9-branch now have an option to automatically generate C prototypes for old-style F77 procedures. I just did for a in *.f; do gfortran -fsyntax-only -fc-prototypes-external $a > ${a%.f}.h; done in the src/modules/lapack directory. This generates header files which contain prototypes like int ilaenv_ (int *ispec, char *name, char *opts, int *n1, int *n2, int *n3,

On Mon, 11 Sep 2006, Michael McCracken wrote: >> be though. > > I'm thinking that effort on 4.0.1 gfortran is not worthwhile, since > 4.0.1 fails to compile some pretty basic examples, and there are some > pretty extensive changes between then and 4.2. ok >> comperable) to merge the LLVM changes into 4.1. I'm personally not >> interested in doing the work,