Dummy arguments with VALUE+OPTIONAL and non-present actual arguments

[Harald1]

The following snippet shows that an unallocated actual argument to an optional dummy with the

VALUE attribute is not handled properly as not-present:

program p
  implicit none
  integer, allocatable :: aa
  call sub ()   ! This is OK
  call sub (aa) ! This isn't
contains
  subroutine sub (x)
    integer, value, optional :: x
    if (present(x)) stop 1
  end
end

The code crashes at runtime in line 5.

F2018, 15.5.2.12 (and F2023, 15.5.2.13) explains that in such a situation the actual argument is to be considered as not present.  There is similar text for disassociated POINTER.

Thanks,

Harald

[FortranFan]

For whatever it's worth, Intel Fortran does not conform, the standard for Fortran looks clear enough in its stated semantics with this case.

But now, I don't understand what OP means by, "The code crashes at runtime in line 5."  On Windows, the program completes but leads to unexpected result:

C:\temp>ifort /free /standard-semantics p.f
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.9.0 Build 20230302_000000
Copyright (C) 1985-2023 Intel Corporation.  All rights reserved.

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

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

C:\temp>p.exe
1

The program using gfortran on the other hand can indeed be said to "crash" i.e., encounter a "signal SIGSEGV: Segmentation fault - invalid memory reference":

C:\temp>gfortran -ffree-form p.f -o p.exe

C:\temp>p.exe

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x1110050a
#1  0x110f6323
#2  0x110dd211
#3  0xc6f27ff7
#4  0xc805247e
#5  0xc80014f3
#6  0xc8050f8d
#7  0x110d1594
#8  0x110d15eb
#9  0x110d13ad
#10  0x110d14e5
#11  0xc6447613
#12  0xc80026f0
#13  0xffffffff

This, to me, suggests gfortran does not have an accurate implementation of the standard semantics in this case either.

Perhaps someone will try NAG Fortran and see if it agrees with the standard?

[Harald1]

The code works with NAG 7.1.

On Linux, I get with ifort:

% ifort -V ifort-value-optional.f90 -g -traceback
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.9.0 Build 20230302_000000
Copyright (C) 1985-2023 Intel Corporation.  All rights reserved.

 Intel(R) Fortran 2021.9.0-1497
GNU ld (GNU Binutils; SUSE Linux Enterprise 15) 2.39.0.20220810-150100.7.40
% ./a.out 
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
libpthread-2.31.s  00001481C675C8C0  Unknown               Unknown  Unknown
a.out              00000000004036E1  MAIN__                      5  ifort-value-optional.f90
a.out              00000000004036AD  Unknown               Unknown  Unknown
libc-2.31.so       00001481C657F24D  __libc_start_main     Unknown  Unknown
a.out              00000000004035DA  Unknown               Unknown  Unknown

With gfortran there are several related open PRs.

[Devorah_H_Intel]

Thank you for your report. The issue is now escalated and the fix will be available in future releases. 

[Devorah_H_Intel]

This issue has been fixed in the recently released Intel Fortran Compiler, available for download as part of Intel HPC Toolkit 2024.2.1

[Harald1]

Devorah,

I just updated the compiler, and still get the crash at runtime:

% ifx ifort-value-optional.f90 -O0 -g -traceback -V && ./a.out 
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.2.1 Build 20240711
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

 Intel(R) Fortran 24.0-1693.3
GNU ld (GNU Binutils; SUSE Linux Enterprise 15) 2.41.0.20230908-150100.7.46
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
libpthread-2.31.s  00007F2F8C221910  Unknown               Unknown  Unknown
a.out              0000000000404298  p                           5  ifort-value-optional.f90
a.out              000000000040425D  Unknown               Unknown  Unknown
libc-2.31.so       00007F2F8C04224D  __libc_start_main     Unknown  Unknown
a.out              000000000040418A  Unknown               Unknown  Unknown

 Can you please check?

The code works fine with NAG.

Thanks,

Harald

[Devorah_H_Intel]

I tested the wrong test case. My apologies. I checked this particular bug report again; it is not fixed yet, and it is unknown when it will be fixed. 

[Devorah_H_Intel]

---

@Harald1 wrote:

The following snippet shows that an unallocated actual argument to an optional dummy with the

VALUE attribute is not handled properly as not-present:

program p
  implicit none
  integer, allocatable :: aa
  call sub ()   ! This is OK
  call sub (aa) ! This isn't
contains
  subroutine sub (x)
    integer, value, optional :: x
    if (present(x)) stop 1
  end
end

The code crashes at runtime in line 5.

F2018, 15.5.2.12 (and F2023, 15.5.2.13) explains that in such a situation the actual argument is to be considered as not present.  There is similar text for disassociated POINTER.

Thanks,

Harald

=====================

Interestingly enough, the original test case has no crash with O2.

$ ifx -v 826.f90 -o test1
ifx version 2024.2.0
$ ./test1
1
$ cat 826.f90
program p
  implicit none
  integer, allocatable :: aa
  call sub ()   ! This is OK
  call sub (aa) ! This isn't
contains
  subroutine sub (x)
    integer, value, optional :: x
    if (present(x)) stop 1
  end
end

---

So using the original test case it passes in 2024.2 ifx. Our compiler engineering are working the new issue with O0. The cause has been identified. 

[Harald1]

Devorah,

while it also does not crash for me with -O2, I get a wrong result: the code hits the "stop 1" and prints the stop code.  This should not happen.

I hope this is also known to the engineers.

Thanks,

Harald

[Devorah_H_Intel]

The fix will be included in the 2025.1 IFX release.