Re:Possible bug with assumed-rank array

Matt_Thompson · ‎08-10-2021

All, I have a code that works with GNU but segfaults with Intel. I think it's a bug and tried to file a ticket, but the Support Ticket site sent me here.

I made up a little reproducer:

program main

   implicit none

   real, pointer, dimension(:,:) :: array => null()

   call foo(2)
   call foo(2,array)

   allocate(array(2,2))

   call foo(2,array)

   contains

      subroutine foo(b,x)

         integer, intent(in) :: b
         real, pointer, dimension(:,:), intent(inout), optional :: x

         write (*,*) "present(x): ", present(x)
         write (*,*) "present_and_associated_2d(x): ", present_and_associated_2d(x)
         write (*,*) "present_and_associated(x): ", present_and_associated(x)

      end subroutine foo

      logical function present_and_associated(p) result(a)
         real, pointer, dimension(..), optional, intent(in) :: p
         a = .false.
         if (present(p)) then
            if (associated(p)) then
               a = .true.
            end if
         end if
      end function present_and_associated

      logical function present_and_associated_2d(p) result(a)
         real, pointer, dimension(:,:), optional, intent(in) :: p
         a = .false.
         if (present(p)) then
            if (associated(p)) then
               a = .true.
            end if
         end if
      end function present_and_associated_2d

end program main

With GNU I get:

$ gfortran --version
GNU Fortran (GCC) 11.1.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gfortran -g -fcheck=all tester.F90 && ./a.out
 present(x):  F
 present_and_associated_2d(x):  F
 present_and_associated(x):  F
 present(x):  T
 present_and_associated_2d(x):  F
 present_and_associated(x):  F
 present(x):  T
 present_and_associated_2d(x):  T
 present_and_associated(x):  T

which is what I expect from this.

But with Intel:

$ ifort --version
ifort (IFORT) 2021.3.0 20210609
Copyright (C) 1985-2021 Intel Corporation.  All rights reserved.
$ ifort -g -check all -traceback tester.F90 && ./a.out
 present(x):  F
 present_and_associated_2d(x):  F
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
a.out              0000000000403EFA  Unknown               Unknown  Unknown
libpthread-2.22.s  00002AAAAAFDCC10  Unknown               Unknown  Unknown
a.out              0000000000402E09  main_IP_foo_               23  tester.F90
a.out              0000000000402A54  MAIN__                      7  tester.F90
a.out              00000000004029D2  Unknown               Unknown  Unknown
libc-2.22.so       00002AAAAB40D725  __libc_start_main     Unknown  Unknown
a.out              00000000004028E9  Unknown               Unknown  Unknown

As you can see, GNU is happy with the assumed-rank array version, but Intel is not. This happens on Linux and macOS, so it seems OS independent.

FortranFan · ‎08-10-2021

@Matt_Thompson ,

Nice test case.

There are some serious issues with Intel Fortran compiler IFORT here and you can hope Intel staff will pick it up from here and "run" with it toward proper resolution in the compiler.

There is some doubt as to whether the standard permits an assumed-rank entity as an actual argument corresponding to a dummy argument that is both ASSUMED-RANK and OPTIONAL. Constraint C838 in the standard omits OPTIONAL and says such an entity is disallowed in most other circumstances. Thus one can empathize when a Fortran processor implementation gets this wrong. Nonetheless product stewardship must mean Intel Fortran team seeks clarification on this and either issues a diagnostic on account of there being a named constraint disallowing such an assumed-rank reference; or support it accurately.
Should one strip out the aspect that may be at the root of confusion though, Intel Fortran simply gets it wrong, an even bigger worry for a customer - see below. Hence the attention from Intel staff will be crucial here.

module m
contains
   subroutine sub( a )
      integer, pointer, intent(in) :: a(..)
      print *, "associated(a)? ", associated(a) 
   end subroutine 
end module
   use m
   integer, pointer :: x => null()
   call sub( x )
end

Note the output of "T" using IFORT as part of oneAPI 2021.3 when it should be false.


C:\Temp>ifort /standard-semantics c.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.3.0 Build 20210609_000000
Copyright (C) 1985-2021 Intel Corporation.  All rights reserved.

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

-out:c.exe
-subsystem:console
c.obj

C:\Temp>c.exe
 associated(a)?  T

C:\Temp>

Barbara_P_Intel · ‎08-12-2021

Thanks for the wonderful reproducers. I filed a bug including both of them. The bug id is CMPLRIL0-34113. I'll let you know when a fix is available.

Matt_Thompson · ‎02-08-2022

As an FYI (more to myself, as we had another occasion to use assumed-rank), it looks like this bug is still in Intel Fortran Classic 2021.5.0:

$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.5.0 Build 20211109_000000
Copyright (C) 1985-2021 Intel Corporation.  All rights reserved.

$ ifort tester.F90
$ ./a.out
 present(x):  F
 present_and_associated_2d(x):  F
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
a.out              0000000000403CBA  Unknown               Unknown  Unknown
libpthread-2.22.s  00002AAAAAFDCC10  Unknown               Unknown  Unknown
a.out              0000000000402E19  Unknown               Unknown  Unknown
a.out              0000000000402CE2  Unknown               Unknown  Unknown
libc-2.22.so       00002AAAAB209725  __libc_start_main     Unknown  Unknown
a.out              0000000000402BE9  Unknown               Unknown  Unknown

Dang. And just because I should start getting used to it, New Intel Fortran 2022.0:

$ ifx -V
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2022.0.0 Build 20211123
Copyright (C) 1985-2021 Intel Corporation. All rights reserved.

$ ifx tester.F90
$ ./a.out
 present(x):  F
 present_and_associated_2d(x):  F
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
a.out              0000000000404DEA  Unknown               Unknown  Unknown
libpthread-2.22.s  00002AAAAB66AC10  Unknown               Unknown  Unknown
a.out              0000000000403EDB  Unknown               Unknown  Unknown
a.out              0000000000403D1C  Unknown               Unknown  Unknown
a.out              0000000000403CE2  Unknown               Unknown  Unknown
libc-2.22.so       00002AAAAB897725  __libc_start_main     Unknown  Unknown
a.out              0000000000403BE9  Unknown               Unknown  Unknown

Barbara_P_Intel · ‎02-08-2022

I just checked the bug report. The compiler developer says it's fixed. I ran the two cases against the latest internal version of ifort and ifx. Both compilers print the correct results for both programs!

I expect the fix will be in the next release. It's not too far off!

JohnNichols · ‎02-08-2022

Do you mean the current release from the 25 Jan or the next one? Sorry I only just found out today about the new release.

I really miss the old taskbar thing that used to tell me to update, now you have to use the installer that is hidden away.

Engineers always improve things and make them worse. Apparently Jeep has a new cover for their spare wheel that says "No one under 30 can steal this car it is a stick. "

Barbara_P_Intel · ‎02-09-2022

There have been various releases for Windows during the past couple of weeks to fix an installation problem and a PATH problem. The compilers themselves have not changed.

The next compiler release is targeted for the Spring.

Barbara_P_Intel · ‎05-20-2022

This issue you reported where ASSOCIATED() returns wrong value is fixed. Apparently, the compiler developer found another issue related to this, too. That's also fixed.

The latest release of ifort is 2021.6.0. It's part of oneAPI HPC Toolkit 2022.2 that was recently released.

Please give it a try!