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

Small program segfaults with ifort 15.0.2.179, but not with ifort 13.1.3.198

Øyvind_J_
Beginner
626 Views

In the following code, there is a difference in the qualifiers of the dummy argument:

MODULE mod1
  IMPLICIT NONE
CONTAINS

  SUBROUTINE sub1(arg1)
    REAL(KIND=8), ALLOCATABLE, OPTIONAL :: arg1(:)
    CALL sub2(arg1) ! <--- this is where the segfault happens
  END SUBROUTINE

  SUBROUTINE sub2(arg2)
    REAL(KIND=8), OPTIONAL :: arg2(:)  ! Here arg2 is not declared ALLOCATABLE
    IF(PRESENT(arg2)) THEN
      print *, "arg2 present"
    ELSE
      print *, "arg2 not present"
    END IF
  END SUBROUTINE
END MODULE

PROGRAM segfault1
  USE mod1
  CALL sub1()
END PROGRAM


For me, this program crashes with a segfault when compiled with ifort 15.0.2.179 on Windows, and 15.0.1.133 on Linux. However, when compiled with ifort 13.1.3.198 on Windows or gfortran 4.8.3 on Linux, it runs without error. The segfault can be avoided either by removing the ALLOCATABLE qualifier from arg1, or by adding it to the declaration of arg2.

Am I right that this code is supposed to work?

Øyvind

0 Kudos
5 Replies
mecej4
Honored Contributor III
626 Views

The code is in error, I think, since the Fortran standard says (12.4.1.6):

An optional dummy
31 argument that is not present is subject to the following restrictions:
...

(8) If it is allocatable, it shall not be allocated, deallocated, or supplied as an actual argument
10 corresponding to an optional nonallocatable dummy argument.

The key point is, as you seem to have noticed yourself, that the argument of SUB2 is optional but was not declared allocatable.

The purpose of the rule, I guess, is that one should be able to check that after such an argument has been passed along in a cascade of subroutine/function calls, it should be possible to check that (i) it is/has been present, and (ii) that it is allocated before its contents are referenced or changed.

0 Kudos
Øyvind_J_
Beginner
626 Views

Thanks mecej4!

mecej4 wrote:
The purpose of the rule, I guess, is that one should be able to check that after such an argument has been passed along in a cascade of subroutine/function calls, it should be possible to check that (i) it is/has been present, and (ii) that it is allocated before its contents are referenced or changed.

That makes sense.

Does anybody know if there is a way to make the compiler issue a warning or error message about this?

0 Kudos
Steven_L_Intel1
Employee
626 Views

This is an interesting case. mecej4 is quoting Fortran 2003, and this program is indeed not valid in F2003. But F2008 adds a feature to allow an unallocated allocatable or nullified pointer to be passed to a non-allocatable/non-pointer OPTIONAL argument and be considered omitted. We support this.

However, there's also the issue that the "omittedness" of an OPTIONAL dummy argument is supposed to be passed on when you call another routine with that argument declared as OPTIONAL, and it seems that we broke this in implementing the F2008 feature. I have escalated this as issue DPD200367279.

0 Kudos
Øyvind_J_
Beginner
626 Views

Thanks, Steve!

0 Kudos
Steven_L_Intel1
Employee
626 Views

I expect this to be fixed in the 16.0 release.

0 Kudos
Reply