runtime array bounds checking on allocated arrays

runtime array bounds checking on allocated arrays

Imagen de Johannes
Johannes
Mié, 14/11/2012 - 02:30

Hi all,

I have simplified a complex code to the following program and got the same unwanted behaviour. With compiler flag set to check bounds I got no runtime error where one should be:

program array_bounds_check
!
  implicit none
!  
! --- locals
  integer,parameter :: column = 10, row = 20
  real(kind(1.d0)), allocatable  :: r1dummy_alloc(:)
  real(kind(1.d0)), allocatable  :: r2dummy_alloc(:,:)  
  real(kind(1.d0))               :: r1dummy_static(column)
  real(kind(1.d0))               :: r2dummy_static(column,row)
! ==============================================================================  
  allocate(r1dummy_alloc(column))
  allocate(r2dummy_alloc(column,row))
  r1dummy_alloc  = 0.d0
  r2dummy_alloc  = 0.d0
  r1dummy_static = 0.d0
  r2dummy_static = 0.d0
  
  call random_number(r2dummy_alloc)
  r2dummy_static = r2dummy_alloc
!
! *** for allocated arrays 
  ! this should produce a runtime array bounds error
  ! but this does show an error in ifort 12.1.6.369 !!  
  r1dummy_alloc = maxval(r2dummy_alloc(1:column,1:row),dim=1) 
  ! this should work -> and it does in ifort 12.1.6.369
  r1dummy_alloc = maxval(r2dummy_alloc(1:column,1:row),dim=2)  
!
! *** for static arrays  
  ! this produces a compile array bounds error
  !r1dummy_static = maxval(r2dummy_static(1:column,1:row),dim=1) 
  ! this should work -> and it does in ifort 12.1.6.369
  r1dummy_static = maxval(r2dummy_static(1:column,1:row),dim=2)
  
  
! ------------------------------------------------------------------------------  
  deallocate(r1dummy_alloc)
  deallocate(r2dummy_alloc)
  
end program array_bounds_check

ifort 12.1.6.369; compiler flags: /nologo /debug:full /Od /warn:declarations /warn:unused /warn:uncalled /warn:interfaces /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /check:uninit /check:format /check:output_conversion /check:arg_temp_created /libs:static /threads /dbglibs /c

For static arrays a compile error occured where it should be. Should array bound checking for allocated arrays work with maxval/ maxloc, ... ? Have I coded the test program correct? Is it the same issue as in DPD200182047 (http://software.intel.com/en-us/forums/topic/278270 array bound checking for pointers) and is it solved in 13.1.119 ?

Kind regards,

Johannes

RSS Superior
publicaciones de 8 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de Johannes
Johannes
Mié, 14/11/2012 - 04:03

UPDATE:

If I use a more strict syntax in line 25/ 27


r1dummy_alloc(1:column) = maxval(r2dummy_alloc(1:column,1:row),dim=1)

I got a compile time compiler error message: "error #6366: The shapes of the array expressions do not conform. [R1DUMMY_ALLOC]"

This is good to know. Nevertheless, an error message for the original syntax with the allocated array like in the static case would be a nice feature.

Kind regards,
Johannes

Superior
Imagen de IanH
IanH
Mié, 14/11/2012 - 12:46

Separate to whether F95 semantics deserve a warning/error, note that your original code is valid Fortran 2003, and will work with the ifort compiler if you supply the right command line (/standard-semantics, which includes /assume:realloc_lhs). The left hand side of an assignment is reallocated to match the size and type parameters of the right hand side, when the size does not match and/or the type parameters are deferred.

Superior
Imagen de Steve Lionel (Intel)
Steve Lionel (Intel)
Mié, 14/11/2012 - 20:37

Intel Fortran does not currently do "shape checking" on assignments. As Ian says, if you enable "standard-semantics" you'll get automatic reallocation of an allocatable array on the left side of an assignment. But if it isn't allocatable, it's unpredictable whether or not you'll get an error if the shapes don't match.

Steve
Superior
Imagen de Johannes
Johannes
Jue, 15/11/2012 - 00:21

Thanks Steve and thanks IanH for your replies.

I have not used the /standard-semantics flag as you can see in my initial post, in VS2010 2003 semantics are set to "no". So, no /standard-semantics flag is means by default no 2003 semantics I assume then. I tested this and indeed the shape of r1dummy still is 10, if no 2003 semantics and the shape of r1dummy is 20, if 2003 semantics are set.

Still one thing I don't understand. If I use 

r1dummy_alloc(1:column) =
in line 25 a compile time error occures. Isn't that a "shape checking". Why is it unpredictable whether I get an error or not? If the compiler knows that it have to reallocate r1dummy from shape 10 to 20, why can't there be an error message if the shapes does not match and no 2003 semantics are set?

However, I know for future that I have to be careful in assigning allocated arrays and that I should define the shape on the lhs.

Best regards,
Johannes

Superior
Imagen de Steve Lionel (Intel)
Steve Lionel (Intel)
Lun, 19/11/2012 - 12:54

In the case you show here, no reallocation is done and it is the programmer's responsibility to ensure that the shapes match. The automatic reallocation happens only when the left side is the name of an allocatable array, without any subscripts.

Steve
Superior
Imagen de Johannes
Johannes
Mié, 21/11/2012 - 02:19

Thanks Steve,

I was yust wondering wheather it is possible for the compiler to do a shape checking for the case if /standard-semantics[-] means no 2003 support. In case the 2003 semantics are true


real(kind(1.d0)), allocatable  :: r1dummy_alloc(:)

real(kind(1.d0))                    :: r1dummy_stat(20)

!

allocate(r1dummy(10))

r1dummy_alloc = r1dummy_stat(1:20)  ! in this line a lhs reallocation is done. shape r1dummy_alloc is now 20

Doing the same thing with no 2003 semantics delivers


real(kind(1.d0)), allocatable  :: r1dummy_alloc(:)

real(kind(1.d0))                    :: r1dummy_stat(20)

!

allocate(r1dummy(10))

r1dummy_alloc = r1dummy_stat(1:20)  ! in this line no reallocation is done on lhs and no runtime error occurs.

                                                         ! Only element 1:10 is transferred to r1dummy_alloc.

In the second case it would be a nice feature for the compiler to give a runtime error if demanded by a flag. If the compiles knows that it have to reallocate r1dummy_alloc with 2003 semantics, it should also know that the shapes does not match?
However, the solution to avoid this I posted some line above. Yust add the range to the assinment of r1dummy_alloc(1:10) and you get a compile time error, which is good.

Kind regards,
Johannes

Superior
Imagen de Steve Lionel (Intel)
Steve Lionel (Intel)
Mié, 21/11/2012 - 07:18

I agree it would be nice to have. A feature request for this was submitted quite a long time ago, and I will add you to the list of customers asking for it. The request ID is DPD200022151.

Steve
Superior

Inicie sesión para dejar un comentario.