Re: Not! Praise for Gfortran
  Home FAQ Contact Sign in
comp.lang.fortran only
 
Advanced search
POPULAR GROUPS

more...

 Up
Re: Not! Praise for Gfortran         

Group: comp.lang.fortran · Group Profile
Author: Carlie J. Coats
Date: Sep 19, 2008 06:27

Arjen Markus wrote:
> On 19 sep, 14:15, "Carlie J. Coats" jyarborough.com> wrote:
>> Al Greynolds wrote:
>>> Over the last few years I have developed a 30,000 line Fortran-95
>>> engineering application using simultaneously several compilers (XLF,
>>> LF95, G95, and IVF). During that time I toyed with Gfortran and put
>>> up with the 2 steps forward, 1 step back of each binary build.
>>> However, I'm now happy to report my "last" issue with it has been
>>> resolved and more importantly performance is almost identical to XLF
>>> and IVF in most cases. Congratulations to all involved with this
>>> project!
>>> Al Greynolds
>>> www.ruda.com
>> Over the last decade and a half I have developed an 80,000 line
>> environmental modeling utility library. All of it, including the
>> Makefile system, work cleanly on AIX/XLF (with choice of underscoring
>> convention), IRIX (5 and 6, "f77" or "f90"), Linux Alpha/DEC "fort",
>> Linux IA64 (Intel, gcc/g77, gcc/g95), Linux x86 (gcc/g77, gcc/g95,
>> Intel, PathScale, PGI (choice of underscoring), Sun StudioExpress,
>> Absoft (choice of underscoring), OSF1/fort, SunOS (4 or 5, f77 or f90),
>> Cray UNICOS f77 and f90, HP-UX (f77 and F90).
>>
>> The Makefile system does *NOT* work with "gfortran" -- I've tried
>> several versions, the most recent being from the Mandriva RPM
>> gcc-gfortran-4.2.3-6mnb1. For a seemingly random set of the source
>> files, the make-log seems to indicate success, but the object file
>> is nowhere to be found, e.g.
>>
>> ...
>> cd /home/coats/Work/Linux2_x86_64gfort; gfortran -c -DIOAPICPL=1
>> -DAUTO_ARRAYS=1 -DF90=1 -DFLDMN=1 -DFSTR_L=int -DIOAPI_NO_STDOUT=1
>> -DAVOID_FLUSH=1 -O3 -ffast-math -funroll-loops -m64 -Wall -Wsurprising
>> -openmp -I/home/coats/Work/ioapi /home/coats/Work/ioapi/bilin.f
>> Warning: Nonconforming tab character in column 1 of line 22
>> ...
>> ar: bilin.o: No such file or directory
>> ...
>>
>> AND:
>>
>> ls /home/coats/Work/Linux2_x86_64gfort/bilin*
>> /bin/ls: No match.
>>
>> Claiming success when the actual result is failure is *CRAP*. IBM had
>> a similar issue with "xlf77" fifteen years ago, and they *fixed*it*.
>>
>> FWIW -- Carlie Coats
>
> I tried to reproduce the message "Warning: nonconforming tab ..."
> but even though the small test program contains one or two tabs
> per line, and I specify all manner of options, I do not get that.
>
> Could you post that particular file? I am sure the Gfortran people
> are interested in that.
>
> Regards,
>
> Arjen

It's not the "nonconforming tab" issue that has me really griped -- it's
the *claim* of success in the middle of a "make" when in fact there was
a *silent* failure -- for a seemingly random subset of the source codes.

Note that it seems to work to compile codes directly from the source
directory rather than to compile codes from the object-directory by
using absolute paths to the source; the latter *fails*silently* for
about half the codes. This kind of error tells me the authors are
not serious about active work in a multi-compiler-configuration
environment (e.g., I want to keep profile- or debug-enabled executables
separate from optimized/production ones without having to do a complete
rebuild from scratch every time I turn around).

(And for that matter, "khexedit" says the "nonconforming tab" claim is
bogus! The relevant context is line-feed capital-C horizontal-tab in
fixed-form source, so that line 22 is a comment-line and "gfortran"
should not even be looking at its contents.)

If you want the whole thing:

http://www.baronams.com/products/ioapi/AVAIL.html#v30

-- Carlie
no comments
diggit! del.icio.us! reddit!