xlf Fortran Oddity

From: Jared Ahern (thwomp_at_aol.com)
Date: 03/23/05 

Date: 22 Mar 2005 20:38:24 -0800

Hey,

I've been in the process of creating a support program (startup file
generator, etc) for a large existing code. I use derived types with
allocatable array components, which I know is an F2003 extension, but
is stated to be fully supported by most of the compilers I use. After
getting my support code up and running on a linux machine
(cross-checking with Intel/ifort and PG/pgf compilers), I tried to move
it to a large IBM SP3 with AIX. It compiles successfully, however it
fails at runtime.

After a lot of checking, I found that it fails in the middle of an
implied-do loop in a write statement. Sometimes this error appears as
an out-of-memory (stack) error, and sometimes just writes garbage or
nothing but whitespace. When compiled with array bounds checking, an
array bounds exception invariably occurs, for no reason apparent to me.
 This is code unchanged from the successful compilations and executions
with ifort and pgf90. The grad students in my office (myself included)
have always regarded xlf as usually a very strict compiler; so my first
thought was that I had violated part of the standard (plus the
allocatable component extension). I now think that it might be a
(minor) compiler bug.

Here's a listing of a test program that generally reproduces the same
problem (sometimes with different error messages without -C, due to
small array sizes here):

!!!!!!!!!!!!!!!!!!!!!!!!!!!
PROGRAM tester
   IMPLICIT NONE

   TYPE MyType
      INTEGER :: ni
      REAL, ALLOCATABLE :: x(:)
   END TYPE MyType

   TYPE(MyType), ALLOCATABLE :: var(:)
   INTEGER :: i,j,nj

   !! allocate & initialize derived type
   nj = 3
   ALLOCATE(var(nj))
   DO j=1,nj
      var(j)%ni = 2*j
      ALLOCATE(var(j)%x(var(j)%ni))
      DO i=1,var(j)%ni
         var(j)%x(i) = 10*i
      ENDDO
   ENDDO

   !! check that everything is setup
   WRITE(*,*) "nj = ",nj
   DO j=1,nj
      DO i=1,var(j)%ni
         WRITE(*,*) j,i,var(j)%x(i)
      ENDDO
   ENDDO

   !! TEST#1: checking implied-do index usage
   !! Succeeds on all compilers
   WRITE(*,*) ((10*i+j,i=1,3),j=1,3)

   !! TEST#2: check single array output
   !! Succeeds on all compilers
   WRITE(*,*) (var(nj)%x(i),i=1,var(nj)%ni)

   !! TEST#3: check index output
   !! Succeeds with ifort, pgf90; fails with xlf/AIX
   WRITE(*,*) (var(j)%ni,j=1,nj)

   !! TEST#4: check full output
   !! Succeeds with ifort, pgf90; fails with xlf/AIX
   WRITE(*,*) ((var(j)%x(i),i=1,var(j)%ni),j=1,nj)

   !! End program run
   !! This does not appear on xlf/AIX if -C option given
   WRITE(*,*) "At end!"

END PROGRAM tester
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

On AIX, I'm compiling for now with (on xlf 8.1 I think, at a remote
site):

    xlf95 -g -C -qextchk -qflttrap -qsigtrap -qsuffix=f=f90 tester.f90
-o tester.x

and I get errors such as:

    Signal received: SIGTRAP - Trace trap
         Fortran language trap: subscript out of bounds

One interesting part of this is that (without -C), the presence or
non-presence of test #3 changes the output for test #4. Now, my actual
program does these writes to the unit number of an unformatted file,
and the implied-do loop on the write is required by the legacy code
(for really long single records), which I cannot change at this time.
As a workaround, I was advised that I could change ALLOCATABLE to
POINTER in the type definition (of %x); this works for the tests I've
run.

So in conclusion (sorry about the length here), I'm asking:

1) Should the code above work, or do I have a stupid error? Why does
the change to POINTER fix things? Should I try to have someone update
xlf to a newer version, or is this 'problem' not yet fixed?

2) For future reference, is there a way to write out the single records
to an unformatted file, like I want to use the implied-do for, but
spread across several write statements?

3) After reading though my Metcalf/Reid/Cohen F2003 book, I am left
with one thought about arrays of derived types each containing
allocatable (or pointer?) arrays: Can the len parameters of the type be
different for each element of an array of those types? If so, how? I
suppose that they wouldn't really be allocatable arrays at this point
though, just normal array components with parameterized sizes.
Eventually, a F2003 compiler is bound to exist... (I'll work on the
supply of lemon-soaked napkins ;)

Thanks, all!
Jared

Relevant Pages

  • Re: A Tale of Two Memory Managers (long)
    ... compilers. ... but the JIT also generates atrocious code. ... Multidimensional array access is even worse. ... deep implications for performance as every structure goes through the stack. ...
    (borland.public.delphi.non-technical)
  • Re: [OT] Funny
    ... matter of what is likely to happen in practice than what the standard ... Or more precisely, mixing f77 and f90. ... That's because f77 had no concept of array stride (i.e. noncontiguous ... to do was pass its starting address...and that's all most compilers ...
    (comp.lang.fortran)
  • Re: xlf Fortran Oddity
    ... I do not believe that Allocatable Derived Type is a Fortran 90/95 construct. ... This is supported by some compilers as an F2k extension. ... When compiled with array bounds checking, ... allocate & initialize derived type ...
    (comp.lang.fortran)
  • Re: internal read of character array. F/ifort differences
    ... undefined variables. ... different resultsfr on different compilers or situations. ... the array defined by the subroutine argument Headers, ... doesn't happen until after the end-of-file is detected. ...
    (comp.lang.fortran)
  • Re: xlf Fortran Oddity
    ... END TYPE MyType ... And, FWIW, I've had some minor issues with the xlf compilers so I wouldn't grant it any ... When compiled with array bounds checking, ...
    (comp.lang.fortran)