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

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

Harald1
New Contributor II
1,312 Views

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

 

0 Kudos
3 Replies
FortranFan
Honored Contributor III
1,273 Views

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?

 

0 Kudos
Harald1
New Contributor II
1,266 Views

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.

 

0 Kudos
Devorah_H_Intel
Moderator
1,195 Views

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

0 Kudos
Reply