Re: IBM XL Fortran

Richard Maine wrote:
Gib Bogle <g.bogle@xxxxxxxxxxxxxxxxxxxxxx> wrote:

Since I didn't get a reply to my post about a bug in IBM XL Fortran, I'd
like to ask some more general questions. Is anyone here using XL Fortran? If so, do you have any problems with it? What is the general
opinion about this compiler? Is it well supported?

It has been a long time since I had an oportunity to work with IBM XL
Fortran. There were only a handful of suitable IBM boxes at work. They
weren't boxes that I often worked on, and the group who did use them
moved on to other boxes several years ago (I forget how many years, but
more than a few).

My general impression, from the little work I did, plus a bit of
3rd-hand data, is that it was/is a solid, well-maintained compiler. It
tended to be pickier than some about requiring code to conform to the
standard, but I don't necessarily regard that as a negative.

The NCEP supercomputers are all IBMs with XLF fortran (v10.1) on them and I use them on a day to day basis.

I agree with Richard's summation. Solid is a good word to use and XLF is actively maintained. I have uncovered some bugs in the compiler over the years (in 8.1 and 10.1), reported them and they were fixed or are still in the process of being so. We do, however, have a cadre of IBM folks and contractors (on site and close by) that are involved in that sort of thing.

The only (very slight) difference I have with Richard's comments is that I always found the IBM to be more forgiving that most i.e. questionable (to me) code always compiled and ran as expected on an IBM when it might have crashed and burned (for various reasons) on other platforms. But, I suspect that may have more to do with the way the sysadmins set up the default configuration (i.e. turn on all the "dusty desk" switches) than with the compiler itself.

BTW, your (Gib Bogle's) example code compiled on the IBMs here and I got the same result as you:

/scratch : xlf90 -qversion
IBM XL Fortran Enterprise Edition V10.1 for AIX
Version: 10.01.0000.0002
/scratch : xlf90_r -q64 -qsuffix=f=f90 bug.f90 -o bug
** bug_mod === End of Compilation 1 ===
** bug_main === End of Compilation 2 ===
1501-510 Compilation successful for file bug.f90.
/scratch : bug
loop: 4 0
loop: 3 100
loop: 2 100
loop: 1 100

cheers,

paulv

--
Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx
.

Relevant Pages

  • Re: Letter to US Sen. Byron Dorgan re unpaid overtime
    ... >> both less efficient and less safe than the Fortran and Basic standard. ... >> The C for loop is actually trying to do what a do loop does. ... sloppy thinking that results from confusing a programming language ... > I do not believe that you are capable of writing a conforming C compiler. ...
    (comp.programming)
  • Bug in IBM Fortran compiler?
    ... while trying to compile an application with the IBM Fortran compiler I ... "Add" subroutine, but I just found that the assignment ...
    (comp.lang.fortran)
  • Re: Question on ProDOS SmartPort drive remapping
    ... be used to create the compiler, ... a quick linkage to the "execute routine" of the interpreter, ... ran faster in less memory than the IBM-produced FORTRAN G, ... I do remember that IBM preferred the end test DO loop, ...
    (comp.sys.apple2)
  • Re: COMPILER PERFORMANCE
    ... IBM did produce a statement to inform users how to write efficient code ... That was before the compiler was released. ... Fortran to S/360 PL/I. ...
    (comp.lang.pl1)
  • Re: COMPILER PERFORMANCE
    ... IBM did produce a statement to inform users how to write efficient code ... That was before the compiler was released. ... Fortran to S/360 PL/I. ...
    (comp.lang.pl1)