Compiler does not flag the type mismatch in FUNCTION statement

[FortranFan]

I apologize if this is a known issue and being worked on, but I failed to locate any relevant thread on this.

module mykinds_m

   use, intrinsic :: iso_fortran_env, only : I2 => int16, I4 => int32

   implicit none

end module mykinds_m

module m

   use mykinds_m, only : I2, I4

   implicit none

   interface

      function f( i ) result(RetVal)

         import :: I4, I2

         !.. Argument list
         integer(I4), intent(in) :: i
         !.. Function result
         integer(I2) :: RetVal

      end function f

   end interface

end module m

module n

   use mykinds_m, only : I2, I4

   use m, only : f

   implicit none

   integer(I2), parameter :: i = 0

contains

   subroutine foo()

      integer(I4) :: j

      j = f( i )  !.. Note the type mismatch in argument as well as result

   end subroutine foo

end module n

Compiling with Intel(R) Visual Fortran Compiler 16.0.1.146 [Intel(R) 64]...
m.f90

m - 0 error(s), 0 warning(s)

[FortranFan]

Forgot to add: the issue seems to be related to the use of named constant as actual argument in the function statement on line 48.  If the argument is not a named constant, the compiler correctly raises warnings (I would prefer these be classified as errors instead):

module mykinds_m

   use, intrinsic :: iso_fortran_env, only : I2 => int16, I4 => int32

   implicit none

end module mykinds_m

module m

   use mykinds_m, only : I2, I4

   implicit none

   interface

      function f( i ) result(RetVal)

         import :: I4, I2

         !.. Argument list
         integer(I4), intent(in) :: i
         !.. Function result
         integer(I2) :: RetVal

      end function f

   end interface

end module m

module n

   use mykinds_m, only : I2, I4

   use m, only : f

   implicit none

contains

   subroutine foo()

      integer(I2) :: x
      integer(I4) :: j

      x = 0
      j = f( x )  !.. Note the type mismatch in argument as well as result

   end subroutine foo

end module n

Compiling with Intel(R) Visual Fortran Compiler 16.0.1.146 [Intel(R) 64]...
m.f90
m.f90(48): warning #6075: The data type of the actual argument does not match the definition.   
m.f90(48): warning #5448: In the call to F, actual argument #1 does not match the type and kind of the corresponding dummy argument.

m - 0 error(s), 2 warning(s)

[Steven_L_Intel1]

It's not a bug, it's a feature!

You've asked about two issues.

1. The type mismatch of the INTEGER(2) actual argument with the INTEGER(4) dummy argument.  This is an extension we support, where if you pass a constant (including named constant) that is a smaller KIND and the interface is known, we convert it to the larger KIND automatically. For integer variables, at least (not sure about REAL), as in the second example, we'll convert the value to a temp, pass the temp and convert it back on return.  If you compile with standards warnings enabled, you get:

t.f90(48): warning #7320: Standard F2008 requires that the type AND type parameters of the actual argument be the same as the type AND type parameters of the dummy argument.   [0]
      j = f( i )  !.. Note the type mismatch in argument as well as result
-------------^

Oddly, I can't reproduce the second warning you show for the second example. What compile options did you use? I wouldn't expect to see both of those as they are redundant.

2. The "type mismatch" of the function result. This is simply the standard rules for intrinsic assignment. The INTEGER(2) result value will be converted to INTEGER(4) for the assignment. Fortran has no concept of "type mismatch" here, as long as assignment is defined, either by the language or a defined assignment declaration.

Regarding the warning - we have seen many old programs that deliberately mismatch types.While your program uses explicit interfaces, you'd get similar warnings if generated interface checking was used. We DID give you a diagnostic here. If you prefer this one to be an error, you can do that with the /Qdiag switch.

[FortranFan]

Steve Lionel (Intel) wrote:

..

Oddly, I can't reproduce the second warning you show for the second example. What compile options did you use? I wouldn't expect to see both of those as they are redundant...

Thanks, Steve, for your feedback.  Here're the details on compiler options with the second example: perhaps it's /warn:all that brings up the second warning?

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

m.f90(48): warning #6075: The data type of the actual argument does not match th
e definition.   
      j = f( x )  !.. Note the type mismatch in argument as well as result
-------------^
m.f90(48): warning #5448: In the call to F, actual argument #1 does not match th
e type and kind of the corresponding dummy argument.
      j = f( x )  !.. Note the type mismatch in argument as well as result
-------------^

[FortranFan]

Steve Lionel (Intel) wrote:

.. Regarding the warning - we have seen many old programs that deliberately mismatch types.While your program uses explicit interfaces, you'd get similar warnings if generated interface checking was used. We DID give you a diagnostic here. If you prefer this one to be an error, you can do that with the /Qdiag switch.

Appreciate your explanation as well as the warnings raised by the compiler, my point is just that when something like /standard-semantics is in effect, then perhaps the compiler can become more strict and not be as concerned about old programs since these old codes are most likely not going to use /standard-semantics anyway.  I know about /Qdiag switch and do use it when necessary in some projects.  It's just that some things feel like true errors like the interface mismatch shown here and directionally, I'd think it will be good progress and helpful for users if Intel compiler starts classifying things like these as errors - just an opinion and a suggestion - no big deal.

[Steven_L_Intel1]

No, that's not what /standard-semantics is for. That option brings the compiler's default behavior into line with Fortran 2003 where the defaults differ. The big example is /assume:realloc_lhs, but there are others as listed in the documentation for /standard-semantics.

It is NOT an error-checking option nor does it make the compiler less forgiving for extensions.

In the cases you mention, we define a behavior as an extension. If you ask for standards checking, we tell you about it but do it anyway.

I figured out the second message. It's an option /warn:argument_checking which is not documented. Curious...