Another problem with ASSUMED SHAPE ARRAYS

Another problem with ASSUMED SHAPE ARRAYS

I took a previoulsy existing program and converted it using using assumed shape arrays,

ran into this which looks like a BUG anyway. Or maybe something subtle I overlooked ?

I have these two routines STUFFIT and FILLIt, and to keep the coding simple I am using a lower bound of ZERO

on the matrices.

When it calls FILLIT, the called routine crashes, thinking that the lower bound is ONE.

But you can see that the lower bound is ZERO in the calling routine.

This might have to do with the third argument is an OUTPUT as I have specifically

declared. I was under the impression I can pass the lower dimension to an output

array as well. We don't see that problem with the INPUT arrays to FILLIT.

When I check the results of LBOUND it gives me back ONE rather than ZERO as it should.

Of course I could "kluge" this by putting the result in an array with a lower bound of ONE,

but that makes the code a LOT MESSIER cause I then have to copy it elsewhere.

Previously the problem did not appear when I had regular arrays with an explicit lower bound of ZERO.

I was wondering if perhaps the problems appears with just REAL(16) arrays. I was trying to

have a high precision summation, otherwise they would be REAL(8).

See attached routines. I hope they both upload this time.

Maybe I have to give the output array an EXPLICIT lower bound? Its always ZERO anyway.

And * for the upper bound ?

AttachmentSize
Download fillit.f90860 bytes
Download stuffit.f90441 bytes
4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

It shoes both rounties are attached. If you need the main program, I can provide that also.

Well, I changed the dimension of the OUTPUT array to (0:*), but it still crashes, thinking that

the lower bound is ONE. The strange thing is the first DO loop went without crashing.

So c(0) got initialized to ZERO, (line 13) but then it could not do the summation (line 17).

ic = ia + ib = 0 + 0 = 0 right? 

Why is that OK with the input arrays?

I am going to see if it get the same result with REAL(8) arrays.

should they have done that when they tested this ? ?

It would help if you provided a main program, but it has been explained to you in another thread that lower bounds are typically not passed for assumed-shape array dummy arguments because many kinds of actual argument have no obvious lower bound. What does get passed is the extent of the array - how many elements. As you show in stuffit, you can specify your own lower bound - if you don't, it's 1.

If you can provide a complete program, I'll be glad to explain what is going on. 

Steve - Intel Developer Support

Leave a Comment

Please sign in to add a comment. Not a member? Join today