Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

xlf compiler bug?


I'm working on a large application and ran into a strange problem with
the allocate command.  The program had been working fine before I
added a 4th dimension to an allocatable array.  It's allocatable
primarily because the sizes change with the data.  I've found through
trial and error that if one of the intermediate dimensions is 1 the
the allocation fails.  The STAT flag still comes back as 0, but the
array is not allocated.  Previously this dimension had been the last
one, but now it's the 3rd one.  If I hard code that dimension to be 2
then the allocation works fine.  Is this a compiler bug or am I doing
something wrong?

I am using xlf version 7.01 on AIX 5.3

Thanks for any help.

Googleer <stocks@earthlink.net> wrote:
> I'm working on a large application and ran into a strange problem with
> the allocate command.  The program had been working fine before I
> added a 4th dimension to an allocatable array.  It's allocatable
> primarily because the sizes change with the data.  I've found through
> trial and error that if one of the intermediate dimensions is 1 the
> the allocation fails.  The STAT flag still comes back as 0, but the
> array is not allocated.  Previously this dimension had been the last
> one, but now it's the 3rd one.  If I hard code that dimension to be 2
> then the allocation works fine.  Is this a compiler bug or am I doing
> something wrong?

> I am using xlf version 7.01 on AIX 5.3

I would not be willing to make any such speculation without actually
seeing the code, as opposed to your description of the code. The "usual"
advice about asking for debugging help applies here. Even though you
aren't actually asking for debugging help, the same principles apply.
That principle is "show us instead of explaining to us." If you need
help in making the judgement, then that by definition means that you
aren't sure of all the relevant facts. In particular, you might not
realize exactly what the relevant facts are.

It is very common in debug situations for people to have failed to even
mention the factor that actually caused the bug, because they didn't
realize that was important. That makes it hard for people to guess what
the bug might have been.

Likewise, without actually seeing the code, I can't be sure that there
wasn't something else that you forgot to mention which is the actual
source of the problem.  It could be all kinds of things. As one trivial
example, you might have neglected to change an index somewhere,
resulting in out-of-bounds references in one of the versions; that in
turn can cause many symptoms.

If it is a big code, it is worthwhile to try to make a cut-down sample
that illustrates the problem. If the problem can't be duplicated in a
cut down version, then that tends to suggest that the real problem lies
elsewhere in the code, even if the symptoms show up here.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Google groups isn't showing me my posting so I have to respond to my
old post in a new posting.

I wrote a small test program to test the allocate function and found
it worked fine with a dimension of 1.  Evidently I have some other
problem going on.  Sorry for posting in haste.

On May 21, 12:12 pm, Googleer <stocks@earthlink.net> wrote:

> Google groups isn't showing me my posting so I have to respond to my
> old post in a new posting.

> I wrote a small test program to test the allocate function and found
> it worked fine with a dimension of 1.  Evidently I have some other
> problem going on.  Sorry for posting in haste.

I found the problem, and it seems to me to be a bug in either the
compiler or the allocate routine.

The error was that the variable used to declare one of the dimensions
in the call to allocate had a value of zero.

STAT returned as zero.  It seems to me that this should have caused
some kind of error indication,  but it didn't.  A further oddity is
that the allocated function routine returns TRUE saying that the array
is allocated.  However the interactive debugger xldb says it isn't
allocated.  The exact message is "The object is not available".

Is this a bug or a feature?

Googleer wrote:

(snip)

> The error was that the variable used to declare one of the dimensions
> in the call to allocate had a value of zero.
> STAT returned as zero.  It seems to me that this should have caused
> some kind of error indication,  but it didn't.  A further oddity is
> that the allocated function routine returns TRUE saying that the array
> is allocated.  However the interactive debugger xldb says it isn't
> allocated.  The exact message is "The object is not available".

You asked to allocate zero elements, and the system did that.

> Is this a bug or a feature?

I believe a feature.  There are many parts of the newer
versions of the standard to properly treat zero length arrays.
In Fortran 66 they were not allowed, but added somewhat later.

-- glen

It's a feature!  Zero sized arrays have been around since Fortran 90
introduced array processing.  Just like zero-trip DO loops, zero sized
arrays come up naturally, usually as the end case of some sort of
iterative nested process.

It's probably unusual to allocate a zero sized array, but it's
perfectly standard conforming and is specifically allowed.

It's hard to say what the debugger thinks.  It's likely to have
trouble with any zero sized object.

Dick Hendrickson

Googleer <stocks@earthlink.net> wrote:
> I found the problem, and it seems to me to be a bug in either the
> compiler or the allocate routine.

> The error was that the variable used to declare one of the dimensions
> in the call to allocate had a value of zero.

> STAT returned as zero.  It seems to me that this should have caused
> some kind of error indication,  but it didn't.  A further oddity is
> that the allocated function routine returns TRUE saying that the array
> is allocated.

That all sounds perfectly normal. Why do you think that allocating a
zero-sized array should cause an error indication? Zero-sized arrays are
perfectly normal and useful in many contexts. You asked for a zero-sized
array, it allocated one, and it told you that it was allocated. It
doesn't happen to have any elements, but that's valid.

A zero-sized array is useful in much the same way that a zero-trip DO
loop count is useful. If it really always was zero sized (or zero trip
count) in every case, then it would be a bit silly (though still valid).
But typically, one is dealing with something whose size or trip count
can vary from case to case. It might happen to be zero for some cases,
but not in all of them.

Because of that, it is dynamically sized arrays that are most likely to
be validly zero sized. You can have arrays statically zero sized, and
that occasionally is useful (such as when you are using a library
routine that has an array argument and your particular application uses
zero size for that). But dynamically sized arrays are the ones most
commonly zero sized. Allocating one is not unusual at all.

Note that being allocated to zero size is not the same thing as not
being allocated. If it were, then there would have to be a lot of
special-case exceptions in code like

   allocate array to appropriate size
   use it
   deallocate it

The deallocate it part would need an exception if zero size counted as
being unallocated. Deallocating an unallocated array is invalid.
Deallocating an array allocated to zero size is normal and needs no
special-case code.

>  However the interactive debugger xldb says it isn't
> allocated.  The exact message is "The object is not available".

Did it say that it isn't allocated or did it say "The object is not
available?" Those aren't the same statement. I don't know much about
xldb. But note that although the array is allocated, it has no elements.
So if you try to look at the values of the elements, there won't be any
there to look at.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

On May 21, 1:41 pm, nos@see.signature (Richard Maine) wrote:

The exact message was "The object is not available".

It was a multi-dimensioned array and only one of the dimensions was
zero.  I was able to assign values to the array.  It appears that xldb
was confused by the zero.  I would think it should have showed me the
portion of the array that had non-zero dimensions.

Xldb is a really handy tool for debugging, but it isn't perfect.

Googleer <stocks@earthlink.net> wrote:
> It was a multi-dimensioned array and only one of the dimensions was
> zero.  I was able to assign values to the array.  It appears that xldb
> was confused by the zero.  I would think it should have showed me the
> portion of the array that had non-zero dimensions.

There is no portion that has non-zero dimensions. If any of the
dimensions is zero extent, then the whole array is zero sized, the array
size being the product of the extents. You say that you were able to
assign values to it. What are the elements that you think you managed to
assign values to? In particular, what index value did thay have in the
dimension that was zero extent? Whatever index value they had in that
dimension, it was an invalid one, as the zero extent means there are no
valid ones.

Did you have bounds checking turned on? Sounds to me like you set values
that were out of bounds, but didn't get caught.

> Xldb is a really handy tool for debugging, but it isn't perfect.

While I don't know xldb in particular, I suspect that the first part of
that is true, and I'm sure that the second part is. :-)

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

As if by magic, Googleer appeared !

> I am using xlf version 7.01 on AIX 5.3

Richard said more good things than I ever could,
especially about showing us a portion of the code,
but I would just like to point out that that this
a very old version of the compiler which is,
I believe, not supported by IBM any more. The current
version is, I think, 10.1, withh 11.0 on the horizon,

Ian

Googleer wrote:
> I'm working on a large application and ran into a strange problem with
> the allocate command.  The program had been working fine before I
> added a 4th dimension to an allocatable array.  It's allocatable
> primarily because the sizes change with the data.  I've found through
> trial and error that if one of the intermediate dimensions is 1 the
> the allocation fails.  The STAT flag still comes back as 0, but the
> array is not allocated.  Previously this dimension had been the last
> one, but now it's the 3rd one.  If I hard code that dimension to be 2
> then the allocation works fine.  Is this a compiler bug or am I doing
> something wrong?

> I am using xlf version 7.01 on AIX 5.3

A few months ago I posted here about a problem I was having with xlf (a
recent version, possibly the latest).  In my case the runtime error was
created by an allocatable array of user-defined types.  I was able to
reproduce the problem in a few lines of code, and IBM have accepted that
there is a compiler bug, for which a patch will be released soon.

This may not be related to your problem.

On May 21, 11:24 pm, Ian Bush <I.J.B@ku.ca.ld> wrote:

> As if by magic, Googleer appeared !

> > I am using xlf version 7.01 on AIX 5.3

> Richard said more good things than I ever could,
> especially about showing us a portion of the code,
> but I would just like to point out that that this
> a very old version of the compiler which is,
> I believe, not supported by IBM any more. The current
> version is, I think, 10.1, withh 11.0 on the horizon,

> Ian

My employer tends to resist moving to newer versions until there is no
choice.

We were still running EKS until the turn of the century forced a
change.  CDS had long since stopped supporting it and our own  staff
was keeping it going alongside modern systems.

On May 21, 5:21 pm, nos@see.signature (Richard Maine) wrote:

Yes I did have bounds checking turned on.  It appears to allow you to
set a value for the array, but you get a segmentation fault if you try
to refer specifically to an element in the array.  Following is my
little test program.  It blows up if I uncomment either of the lines
in the subroutine.  Otherwise it runs without any error messages and
writes the "x is allocated" message.

__________________________________________________________________________

      module stuff
         double precision, dimension(:,:,:), public,allocatable ::x
      end module stuff

      program memtest
c     Test memory allocation
      use stuff
      integer i,j,k

      i = 10
      j = 10
      k = 0

      allocate (x(i,j,k),stat=ierr)
      if( ierr /= 0 ) then
         write(6,'(" STAT = ",i0)') ierr
         stop
      endif
      if( allocated(x) ) then
         write(6,'("x is allocated")')
      else
         write(6,'("x is NOT allocated")')
      endif

      x = 1.0
      call sub(x,i,j)

      stop
      end

      subroutine sub(y,i,j)
      double precision y(i,j)
      integer i,j
c      y(1,1) = 2.0
c      write(6,'("In sub1 ",f10.3)') y(1,1)
      return
      end

Googleer <stocks@earthlink.net> wrote:
> Yes I did have bounds checking turned on.  It appears to allow you to
> set a value for the array, but you get a segmentation fault if you try
> to refer specifically to an element in the array.  Following is my
> little test program.  It blows up if I uncomment either of the lines
> in the subroutine.  Otherwise it runs without any error messages and
> writes the "x is allocated" message.

[ code elided ]

That all sounds normal and in accordance with the standard. I think you
just don't have the intuition for how zero-sized arrays naturally act.
When you set a value for the array as in your x=1.0, that sets all of
the elements to 1.0 - all of the elements being no elements. This is
*EXACTLY* like doing

  do i = 1 , 10
    do j = 1 , 10
      do k = 1 , 0
        x(i,j,k) = 1.0
      end do
    end do
  end do  

Which is to say that it does nothing. But it is a valid statement, just
like

  if (.false.) something = 1.0

is valid.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc