|
|
 |
 |
 |
 |
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
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.
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
Googleer wrote: > 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?
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.
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:
> 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.
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.
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
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
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
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:
> 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.
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.
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