topic The feature isn't new - it's in Intel® Fortran Compiler

Parameter /check:bounds not applicable for allocated arrays

rase — Tue, 02 Aug 2016 10:57:53 GMT

Is my suspicion correct that the parameter /check:bounds is not applicable for allocated arrays? Is there a possibility to check that the bounds of allocated arrays are not violated, other than an allocation with bounds carefully selected?

Do you have an example?

IanH — Tue, 02 Aug 2016 11:05:07 GMT

Do you have an example?

PROGRAM check_bounds
  IMPLICIT NONE
  INTEGER, ALLOCATABLE :: array(:)
  
  ALLOCATE(array(5))
  array(6) = 2
END PROGRAM check_bounds

>ifort /check:bounds /Od "2016-08-02 check-bounds.f90" && "2016-08-02 check-bounds.exe"
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.3.207 Build 20160415
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

"-out:2016-08-02 check-bounds.exe"
-subsystem:console
"2016-08-02 check-bounds.obj"
forrtl: severe (408): fort: (10): Subscript #1 of the array ARRAY has value 6 which is greater than the upper bound of 5

Image              PC                Routine            Line        Source
2016-08-02 check-  00007FF65C9D49BE  Unknown               Unknown  Unknown
2016-08-02 check-  00007FF65C9D125B  Unknown               Unknown  Unknown
2016-08-02 check-  00007FF65C9FD76E  Unknown               Unknown  Unknown
2016-08-02 check-  00007FF65C9FDFE5  Unknown               Unknown  Unknown
KERNEL32.DLL       00007FF8E2B98102  Unknown               Unknown  Unknown
ntdll.dll          00007FF8E4A8C5B4  Unknown               Unknown  Unknown

Sorry, the frantic search for

rase — Tue, 02 Aug 2016 12:48:00 GMT

Sorry, the frantic search for an error which caused a debug interrupt in a complex project caused a temporary blindness for the obvious. Boundary violations are caught allright, also for allocated arrays, if the parameter /check:boundaries is set. IanH, please take my apologies for the extra work to answer my inconsiderate question.

What you are asking for is

Steven_L_Intel1 — Tue, 09 Aug 2016 17:56:42 GMT

What you are asking for is shape checking, not really bounds checking. At present we don't do shape checking, so in the contexts where the shapes don't match whether or not you get a bounds error is unpredictable.

If you add the option /standard-semantics (Fortran > Language > Enable Fortran 2003 Semantics) then you'll get Fortran standard automatic reallocation on the allocatable array assignment to y. This (the reallocation on different shape) will be the default in version 17.

Some thoughts about shape

Johannes_Rieke — Fri, 12 Aug 2016 12:17:07 GMT

Some thoughts about shape checking. If you modify line 11 in post #4 of Andi to

y(1:6) = z(1:6)

a shape ckeck is done in run time and an error is thrown. This easy case could be covered in compile time, because the allocation is done with a fixed number, isn't it.

forrtl: severe (408): fort: (2): Subscript #1 of the array Y has value 5 which is greater than the up
per bound of 4

Curiously the other way round (lhs index span smaller than rhs) is found at compile time (modified line 10 and 11):

ALLOCATE(y(6))
y(1:4) = z(1:6)

TestCheckBounds.f90(11): error #6366: The shapes of the array expressions do not conform.   
1>compilation aborted for ... TestCheckBounds.f90 (code 1)

In some more complicated cases (index is a part of a user defined type), I've seen that shape checking works not every time. Unfortunately, I have no minimum working example. (PSXE 2016 up3, win32).

@Steve: Will the new default in 17 (including -assume realloc_lhs) have an impact on the performance in cases where the shapes do not changes, because there is a test in run time?

I was able to modify the code

Johannes_Rieke — Fri, 12 Aug 2016 12:32:16 GMT

I was able to modify the code above to a case, where shape checking fails:

PROGRAM TestCheckBounds
     
IMPLICIT NONE
INTEGER(4),DIMENSION(6) :: z
!INTEGER(4),DIMENSION(4) :: y !using this declaration (and commenting out line 10) leads the compiler to indicate an error: "The shapes of the array expressions do not conform."
INTEGER(4),DIMENSION(:),ALLOCATABLE :: y
type foo_t
  integer  ::  bar
  integer  ::  barbar
end type foo_t
type(foo_t) :: foo

foo%bar    = 1
foo%barbar = 4

z = [1,2,3,4,5,6]
WRITE(*,*)," z 1: ", z
ALLOCATE(y(6))
y(foo%bar:foo%barbar) = z(1:6)   !no error indicated during compilation/run time
WRITE(*,*)," y: ", y
z = y   !no error indicated during compilation/run time
WRITE(*,*)," z 2: ", z
READ(*,*)
!y(5) = z(5)  !this line throws an error (as expected)     

END PROGRAM TestCheckBounds

No compile time error is thrown, nor a run time error occurs hitting line 19. Is it a defect or are shapes only checked if the bounds are numbers and not variables?

What I said was that the

Steven_L_Intel1 — Fri, 12 Aug 2016 14:14:20 GMT

What I said was that the compiler does not check shapes in the current version (except in the case for allocatable array assignment). (We're looking at this for development over the next year, but no promises.) You might get lucky with bounds checking enabled, but many times no error is reported.

Yes, there is overhead for checking the shape on allocatable array assignment when the shapes do conform. We try to keep this as low as possible. You can turn off the feature if you want, but we had many, many customers complain that our default didn't match the standard and, nowadays, most if not all other compilers out there do the reallocation by default.

I have a related question

Roman1 — Fri, 12 Aug 2016 18:42:09 GMT

I have a related question about the new array reallocation feature. Will it be possible to check that the reallocation was successful? When I explicitly allocate the array with ALLOCATE, I can check the output STAT variable to make sure that the allocation was successful.

The feature isn't new - it's

Steven_L_Intel1 — Fri, 12 Aug 2016 19:16:34 GMT

The feature isn't new - it's been there for 15 years, but you had to ask for it with /assume:realloc_lhs (or /standard-semantics). The only thing changing is that the default is now realloc_lhs instead of norealloc_lhs.

The language does not provide a means to query the status of an implicit allocation. You're free to do it yourself (as you had to pre-F2003), and then the change in default makes no difference (other than a bit of overhead for the check.)

There actually is one more change, under the hood. Up through version 16, if you had realloc_lhs enabled the code to do the checking and allocation was all inline, which could sometimes inhibit optimization (since it was a lot of intermediate language). As of version 17 it's done in a library call for much less generated code and potentially better optimization. This also allowed us to clean up the compiler quite a bit, improving reliability.

topic The feature isn't new - it's in Intel® Fortran Compiler

Parameter /check:bounds not applicable for allocated arrays

Do you have an example?

Sorry, the frantic search for

Related to this topic: Below

What you are asking for is

Some thoughts about shape

I was able to modify the code

What I said was that the

I have a related question

The feature isn't new - it's