similar to: [LLVMdev] llvm-gcc-4.2 and gfortran

Hello, Jack. > the libgfortran directory. Thanks in advance for any > information as I am working on test fink packaging for > llvm-gcc42. The gfortran is more or less ok nowadays. There are few patches waiting in my queue, but I'll commit them soon. It seems, that llvm-gfortran can compile almost all SPEC and polyhedron (there are few known issues, though). Unfortunately, I

Anton, Doh! It appears that *-*-darwin* is preset in configure to not build libgfortran... # APPLE LOCAL end ARM darwin target powerpc-*-darwin* | i[3456789]86-*-darwin*) noconfigdirs="$noconfigdirs bfd binutils ld gas opcodes gdb gprof" noconfigdirs="$noconfigdirs sim target-rda" # LLVM LOCAL begin noconfigdirs="$noconfigdirs target-boehm-gc

On Dec 27, 2007, at 9:14 AM, Jack Howarth wrote: > Anton, > Doh! It appears that *-*-darwin* is preset in configure to > not build libgfortran... Ah, that should certainly be fixed. Please send in the obvious patch to the llvm-commits list (after verifying that it doesn't break the c/c ++/objc build), thanks Jack! > I'll try removing libgfortran from noconfigdirs.

Anton, I didn't know that EQUIVALENCE is the only unsupported major Fortran feature, as this bug says. Can you give me an update on the status of the Fortran front-end and what the near-term goals are? I am getting more requests from academics doing HPC compilers and it would be useful to know where Fortran support stands. Other llvmdev'ers may be interested too. Thanks,

Vikram, > I didn't know that EQUIVALENCE is the only unsupported major Fortran > feature, as this bug says. Can you give me an update on the status of > the Fortran front-end and what the near-term goals are? Ok. I was going to post something soon after 2.2 release, but let's do it now. LLVM 2.2 will contain (as a part of llvm-gcc 4.2) a port of gfortran compiler to the LLVM

The previously posted benchnarks for gcc vs llvm-gfortran had one mistake. I was actually had the gfortran for 4.3.1 installed instead of that from gcc 4.2.4. Below are the polyhedron benchmark results for all three compilers... gfortran 4.2.4 Benchmark Compile Executable Ave Run Number Estim Name (secs) (bytes) (secs) Repeats Err % --------- -------

Hi, I have installed llvm and llvm-gfortran on Pentium4 machine using 32-bit Ubuntu, it works fine. I recently installed them on AMD64-Ubuntu 8.04, llvm-gfortran gave me following errors $ llvm-gfortran -Wall hello.f95 -o hellof /home/jli127/LLVM/llvm-gcc/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.1/../../../../lib64/libgfortran.a(error.o): In function `_gfortrani_gfc_itoa':

Hi, > I have installed llvm and llvm-gfortran on Pentium4 machine using 32-bit > Ubuntu, it works fine. I recently installed them on AMD64-Ubuntu 8.04, > llvm-gfortran gave me following errors > > $ llvm-gfortran -Wall hello.f95 -o hellof this works here on x86-64 ubuntu 8.10. I took a look in my libgfortran.a and it doesn't reference any of the symbols you mention. >

Anton, With regard to the gfortran test cases which don't fail on x86_64 Linux, these are the exact gfortran.log entries for them under i686 Darwin9... > FAIL: gfortran.dg/array_constructor_12.f90 -O0 (internal compiler error) > FAIL: gfortran.dg/array_constructor_12.f90 -O0 (test for excess errors) Executing on host:

Hello, Eduardo I think these questions were answered yesterday, but: > 1) I know there is a MSIL backend which is still at an experimental > phase. When will it be ready? When there will be someone, which will finish it. Without such brave soul I'd say "never". Currently it's definitely bitrotten and I personally don't see the future for it expect

Hello, Everyone. As of r41125 gfortran builds fine within llvm-gcc 4.2. So, volunteers who know fortran well are needed to check it. Bugfixes and bugreports are welcome. PS: I expect stuff to be horrible broken, but who knows PPS: long doubles (80 bit) are known not to be working. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State

Hi Jack, thanks for the numbers. Any chance of analysing why gcc does better on those where it does much better than dragonegg? Ciao, Duncan. > With the case-insensitive file system patch from http://llvm.org/bugs/show_bug.cgi?id=9656#c15 > applied to dragonegg 2.9, the following Polyhedron 2005 benchmarks are seen on x86_64-apple-darwin10 > under gcc 4.5.3svn using the dragonegg

On Apr 7, 2010, at 8:41 PM, Jack Howarth wrote: > Building the current release 2.7 branch on x86_64-apple-darwin10 > with r81455 reverted, I get the following Polyhedron 2005 benchmark > results (with no test failures)... Very nice! A 14% speedup on a benchmark we don't tune for isn't bad. I imagine that there are several easy wins you could get on it if you were interested

Since the fact that gfortran performance has improved over the major releases, I decided to benchmark the current releases on a MacPro with the Polyhedron 2005 benchmarks using -ffast-math -funroll-loops -msse3 -O3. The results are... gcc release gcc 4.2.4 gcc 4.3.3 gcc 4.4-pre gcc 4.3.3/ gcc 4.4-pre/

With the case-insensitive file system patch from http://llvm.org/bugs/show_bug.cgi?id=9656#c15 applied to dragonegg 2.9, the following Polyhedron 2005 benchmarks are seen on x86_64-apple-darwin10 under gcc 4.5.3svn using the dragonegg plugin... ================================================================================ Date & Time : 8 Apr 2011 19:52:56 Test Name :

On Thu, Apr 08, 2010 at 08:45:48AM -0700, Bob Wilson wrote: > [CCing Dale since this was his change, not mine] > > The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt

On Apr 8, 2010, at 8:45 AMPDT, Bob Wilson wrote: > [CCing Dale since this was his change, not mine] > > The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt for GC.

I've benchmarked the llvm 2.3/llvm-gcc-4.2 release against the stock gfortran compiler from gcc 4.2.4 on a 2.33GHz MacBook Pro using the '-ffast-math -funroll-loops -msse3 -O3' optimization flags. llvm-gfortran Benchmark Compile Executable Ave Run Number Estim Name (secs) (bytes) (secs) Repeats Err % --------- ------- ---------- ------- -------

Building the current release 2.7 branch on x86_64-apple-darwin10 with r81455 reverted, I get the following Polyhedron 2005 benchmark results (with no test failures)... ================================================================================ Date & Time : 7 Apr 2010 22:24:16 Test Name : llvm_gfortran_lin_p4 Compile Command : llvm-gfortran -ffast-math -funroll-loops -msse3

[CCing Dale since this was his change, not mine] The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt for GC. When you build for Fortran, darwin-c.o is not linked so the GC gets