Quantcast
Channel: Intel® Software - Intel® Visual Fortran Compiler for Windows*
Viewing all articles
Browse latest Browse all 5691

Another problem with ASSUMED SHAPE ARRAYS

$
0
0

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
Downloadfillit.f90860 bytes
Downloadstuffit.f90441 bytes

Viewing all articles
Browse latest Browse all 5691

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>