Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29005 Discussions

Compiler bug: boundary check triggering false positives

Balint_Aradi
New Contributor I
269 Views

The recent ifx compiler reports false positive run-time errors for array boundary violations.

 

Code:

module testmod
  implicit none

contains

  subroutine testsub(x)
    real, intent(inout) :: x(3, *)

    real :: a
    a = sqrt(1.0 / 3.0)
    x(1:3, 1) = [a, a, a]

  end subroutine testsub

end module testmod


program testprog
  use testmod, only : testsub
  implicit none

  real :: x(3, 1)

  x(:,:) = 0.0
  call testsub(x(1, 1))

end program testprog

Compiled and run with

ifx -g -O0 -check bounds test.f90; ./a.out

Results in

forrtl: severe (408): fort: (3): Subscript #1 of the array X has value 0 which is less than the lower bound of 1

Image              PC                Routine            Line        Source             
a.out              000000000040226D  Unknown               Unknown  Unknown
a.out              0000000000402390  Unknown               Unknown  Unknown
a.out              000000000040218D  Unknown               Unknown  Unknown
libc.so.6          00007FEDD7F2A248  Unknown               Unknown  Unknown
libc.so.6          00007FEDD7F2A30B  __libc_start_main     Unknown  Unknown
a.out              00000000004020A5  Unknown               Unknown  Unknown

As far as I can see, the code is absolutely standard conforming and no array boundary violation happens. No other compilers report any violation at this place.

 

 

1 Solution
Igor_V_Intel
Employee
160 Views

Thank you for reporting this problem. I reproduced this behavior with the 2025.0 compiler version. However, I found that it is corrected in the latest compiler builds.

Please expect it to be fixed in the upcoming compiler updates.


View solution in original post

1 Reply
Igor_V_Intel
Employee
161 Views

Thank you for reporting this problem. I reproduced this behavior with the 2025.0 compiler version. However, I found that it is corrected in the latest compiler builds.

Please expect it to be fixed in the upcoming compiler updates.


Reply