Intel Fortran Compiler: a request to check when dummy arguments get defined/referenced in ways contrary to INTENT specifcations.

FortranFan · ‎03-10-2017

This is in conjunction with another ongoing thread on this forum. Fortran 2008 Note 5.17 says

Now consider the following simple code and the runtime exception (as expected) using Intel Fortran compiler.

module m

   use, intrinsic :: iso_c_binding, only : c_loc, c_ptr, c_f_pointer

   implicit none

   private

   public :: s1

contains

   subroutine s1( i )

      integer, intent(in) :: i

      call s2( i )

      return

   end subroutine s1

   subroutine s2( i )

      integer, intent(in), target :: i

      type(c_ptr) :: add_i

      add_i = c_loc(i)

      call s3( add_i )

      return

   end subroutine s2

   subroutine s3( a )

      type(c_ptr), intent(in) :: a

      integer, pointer :: ptr_i

      call c_f_pointer( cptr=a, fptr=ptr_i )

      ptr_i = 42
      
      ptr_i => null()

      return

   end subroutine s3

end module m

program p

   use m, only : s1

   integer, parameter :: i = 0

   call s1( i )

   stop

end program p

C:\..>ifort -c /standard-semantics /traceback /stand /warn:all m.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R
) 64, Version 17.0.1.143 Build 20161005
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.


C:\..>ifort -c /standard-semantics /traceback /stand /warn:all p.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R
) 64, Version 17.0.1.143 Build 20161005
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.


C:\..>link /out:p.exe /subsystem:console p.obj m.obj
Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.


C:\..>p.exe
forrtl: severe (157): Program Exception - access violation
Image              PC                Routine            Line        Source

p.exe              000000013FAA10BD  M_mp_S1                    17  m.f90
p.exe              000000013FAA103D  MAIN__                      7  p.f90
p.exe              000000013FACE61E  Unknown               Unknown  Unknown
p.exe              000000013FACE9B5  Unknown               Unknown  Unknown
kernel32.dll       00000000772659CD  Unknown               Unknown  Unknown
ntdll.dll          000000007739A561  Unknown               Unknown  Unknown

I believe the above source is standard-conforming and the variable definition on line 45 is allowed but I think it is contingent upon the variable (ptr_i in this case) being associated with a definable target which is not the case.

This appears to be an improvement opportunity for Intel Fortran compiler to be "more sophisticated" as alluded to in the standard!

IanH · ‎03-12-2017

The program isn't standard conforming as it violates (at least) F2008 5.3.10p2. But that's totally on the head of the programmer.

I think it impractical to expect the compiler to robustly identify these sorts of things at compile time. Consider the analysis that would be required - you would basically have to model the execution of the entire program, including any input files.

FortranFan · ‎03-12-2017

ianh wrote:

The program isn't standard conforming as it violates (at least) F2008 5.3.10p2. But that's totally on the head of the programmer. ..

Either way Intel Fortran compiler can try to do better, that was the main point in the post.

But I do not see anything in the standard that indicates the code is non-conforming; what is going in the code is essentially as explained in Note 5.16 which says, "the INTENT restrictions on pointer dummy arguments apply only to the association of the dummy argument; they do not restrict the operations allowed on its target."

As to Fortran 2008 Section 5.3.10, paragraph 2, the standard states:

and nothing in the code in the original post is offending in terms of this verbiage. But if the Intel compiler team agrees with ianh's assertion (which I doubt highly because of everything I have read plus the fact this code is actually from another long thread where several keen pairs of eyes were taking a close look with the standard in mind) then take some action items to issue some warnings at compile-time. I think coders can accept a situation of conformant code with no compile-time errors or warnings but failing with undefined behavior or exceptions during execution due to their own programming error or faulty logic. But I think customers can legitimately expect to see improvements over time in compiler implementations of more and better warnings when it comes to non-conforming code,

ianh wrote:

.. I think it impractical to expect the compiler to robustly identify these sorts of things at compile time...

It is the standard that informs coders to expect something more from the processor with statements such as those in Note 5.17.

I think it will be better if the Intel compiler team takes a look at this and investigates if something useful for the coders can be done here. If the code is non-conforming, then try to provide some compile-time warnings when /stand is in effect; but if the code is deemed to be conforming by the processor, then strive to do more to help customers, at least when explicit interfaces with INTENT attributes are available for all the involved procedures.

For example, in this instance it could issue a suggestion about /assume:noprotect_constants or the VALUE attribute on the dummy argument, etc., aspects which can help the code avoid run-time exceptions.

The point is to help customers more with any potential issues with their code.

IanH · ‎03-13-2017

FortranFan wrote:

Quote:

ianh wrote:

The program isn't standard conforming as it violates (at least) F2008 5.3.10p2. But that's totally on the head of the programmer. ..

Either way Intel Fortran compiler can try to do better, that was the main point in the post.

But I do not see anything in the standard that indicates the code is non-conforming; what is going in the code is essentially as explained in Note 5.16 which says, "the INTENT restrictions on pointer dummy arguments apply only to the association of the dummy argument; they do not restrict the operations allowed on its target."

I don't see the relevance. There are no pointer dummy arguments in the example.

As to Fortran 2008 Section 5.3.10, paragraph 2, the standard states:

and nothing in the code in the original post is offending in terms of this verbiage.

The i dummy argument of the s2 procedure is intent(in), but execution of the body of s2 will change that dummy argument. This violates the "shall neither be defined nor become undefined" bit of the first sentence.

Definition of a variable is an execution concept - it is something that happens when the program runs. In the absence of other restrictions, an executable statement that would define a variable that the standard specifies must not be defined is only problematic if that statement is actually executed. In the general case, knowing whether a particular executable statement is going to be executed requires actually executing the program, with its specific input. Consider if line 45 (or the call sequence leading up to that line) were bracketed by an IF construct, that triggered on a logical expression that depended on a random number, or a value read from the keyboard or similar. It is unreasonable, in the general case, to expect compilers to be able to model the execution of entire programs with their input.

(The standard's rules around INTENT(IN) also include restrictions, as constraints, on the variable appearing in a variable definition context. Whether something appears in a variable definition context is a property of the source code, which is something that can be inspected by a compiler at compile time.)

But if the Intel compiler team agrees with ianh's assertion (which I doubt highly because of everything I have read plus the fact this code is actually from another long thread where several keen pairs of eyes were taking a close look with the standard in mind)

Which thread?

...then take some action items to issue some warnings at compile-time. I think coders can accept a situation of conformant code with no compile-time errors or warnings but failing with undefined behavior or exceptions during execution due to their own programming error or faulty logic. But I think customers can legitimately expect to see improvements over time in compiler implementations of more and better warnings when it comes to non-conforming code,

Quote:

ianh wrote:

.. I think it impractical to expect the compiler to robustly identify these sorts of things at compile time...

It is the standard that informs coders to expect something more from the processor with statements such as those in Note 5.17.

I think it will be better if the Intel compiler team takes a look at this and investigates if something useful for the coders can be done here. If the code is non-conforming, then try to provide some compile-time warnings when /stand is in effect; but if the code is deemed to be conforming by the processor, then strive to do more to help customers, at least when explicit interfaces with INTENT attributes are available for all the involved procedures.

For example, in this instance it could issue a suggestion about /assume:noprotect_constants or the VALUE attribute on the dummy argument, etc., aspects which can help the code avoid run-time exceptions.

The point is to help customers more with any potential issues with their code.

This sort of error is the domain of run-time correctness checking, not compile time.