Error related to absent optional argument

[mecej4]

The following code is a simplified version of another example posted by "Simon" on the Silverfrost Fortran Forum, see http://forums.silverfrost.com/viewtopic.php?p=18780 . My reading of the Fortran 2008 standard, section 12.5.2.12.3(1) indicates that the code is not conforming since the two elements of array j, which is not present, are referenced in Line-10. Gfortran 4.7 and 5.2 stop with a seg-fault on line-21. Sun Fortran 12.4 on Linux says " Attempting to use a missing optional dummy 'J' Location:  line 10 column 14 of 'pres0.f90'". With Intel Fortran 2015.2.164 and 16.0.0.109 on Linux the program completes execution, and the output was actually what "Simon" expected.

PROGRAM absent
! 
 CALL s1 () 
! 
CONTAINS 
! 
 SUBROUTINE s1 (j) 
  INTEGER, INTENT(IN), OPTIONAL :: j(2)
!
 CALL s2 (j1=j(1),j2=j(2)) 
 END SUBROUTINE s1 
! 
 SUBROUTINE s2 (j1,j2) 
  INTEGER, INTENT(IN), OPTIONAL :: j1, j2
  IF (PRESENT(j1)) THEN 
     PRINT *, 'j1 = ',j1 
  ELSE 
     PRINT *, 'j1 N/A' 
  END IF 
  IF (PRESENT(j2)) THEN 
     PRINT *, 'j2 = ',j2 
  ELSE 
     PRINT *, 'j2 N/A' 
  END IF 
 END SUBROUTINE s2 
END PROGRAM absent 

The program output with Intel Fortran, compiled with -C:

 j1 N/A
 j2 N/A

[Kevin_D_Intel]

I submitted mecej4’s case in post #10 to Development as noted below.

@IanH - It seemed like there was another possible feature request coming from the discussions starting with your post #11 but I’m a little confused. For the test case in post #11, the run-time check leading to the fault is -check bounds. That seems unrelated to the check Lorri mentioned in post #14, which I thought you might be suggesting in post #21 was related to the run-time check triggering the error for that case, and thus leading to your suggestion the run-time checking should be reviewed. Could help clarify this?

(Internal tracking id: DPD200376810 - Incorrect status for optional argument)

[IanH]

Perhaps I am getting my compilers confused - I thought I had seen specific runtime errors from ifort about operations on not present optional arguments.  That's the most appropriate outcome for a debugging build with the code examples in this thread.

But I was also commenting on the inconsistency... if the compiler is going to go to the trouble of fixing up what it passes for the array elements when the base object is not present (my view is that this is an unnecessary fix-up, because the code is non-conforming), then why does it try and do the bounds checks on the array element non-reference?  If the code is non-conforming then there's no need for the "base object not present" test prior to getting the address of a subobject (whether array or component), if the code is conforming, then the bounds check shouldn't crash.

[mecej4]

Perhaps it would help if we separated diverse issues that have become commingled in this thread. Permit me to state some assumptions that I think all of us agree with.

• Given conforming source code, the compiler should produce an EXE that gives expected results, and not to do so constitutes a compiler bug. (Leave aside situations where the program behavior is "implementation-dependent"). This also extends to the few cases of non-conforming code for which the standard imposes constraints on what the compiler should do.
• Given non-conforming code, users expect the EXE to detect violations as early as possible and, if possible, give some diagnostic information such as a traceback if requested by the user.
• Given non-conforming code, with user request to do runtime checks, the compiler should provide as much help as possible to enable the user to catch, diagnose and errors in the code. In these situations, although we often say "the compiler can do whatever it wants", the quality of the helpful information that the compiler can produce is a measure of the quality of the compiler. Quality is demanded by the customers, so no commercial compiler is going to do "whatever it wants". Another indication of quality is consistency in how the compiler responds to similar codes.

I left out "fast code" because that is not an issue here, although that is what most users expect and like regarding IFort.

We seem to have two camps regarding whether the code in #1 is conforming or non-conforming. This question will be resolved in a few weeks, I hope. I am inclined to agree with IanH, although I see the arguments from the other camp as quite reasonable. I just ran the NAG compiler (6.0, Release 1057) on the code in #1. Without checks, the program crashes and asks for permission to send Microsoft a report. With checks, it said:

Runtime Error: pres1.f90, line 10: Reference to OPTIONAL argument J which is not PRESENT
Program terminated by fatal error

For the code in #10, NAG produced the same output as IFort (see #10) when no check options were used ("j2 seems to be present"). With -C, it detected a reference to an argument that is not present.