Suggestion for improvement in error message

[jimdempseyatthecove]

I have an old IVF VS Solution that uses the F90 GLUT library. This solution compiled correctly (without errors) using an older version of IVF.

IVF V17 u 5 performs stronger interface checking.

One of the function calls to the GLUT library specifies a callback function to handle keyboard input. The official interface in the GLUT library has the interface for the callback function declared with its 3 arguments attributed with INTENT(INOUT). The interface, and keyboard function I wrote mistakenly used INTENT(IN), as the function does not "cook" the arguments (and the C function library passes these by value and cannot be changed). The older version of IVF did not complain about the mismatch between INTENT(IN) and INTENT(INOUT).

I am not complaining about the compiler complaining about about the mismatch between INTENT(IN) and INTENT(INOUT)...
I am complaining that the error message simply states the arguments (interface) are (is) incorrect with no additional information as to why it is complaining (in this case, correct argument types with differing INTENT). It would have saved me considerable amount of time in diagnosing and correcting the problem. (The first argument in the C interface is unsigned char, but the Fortran uses GLcint)

Jim Dempsey

[Steve_Lionel]

Jim, this is a good suggestion. Over the years I encouraged the team to provide more detail in the error messages. One of the successes was a message about generic interfaces that now has a lot more info. I would recommend that you file a feature request to the Online Service Center. This way it will get officially recorded in the developers' report database. 

[FortranFan]

jimdempseyatthecove wrote:

.. IVF V17 u 5 performs stronger interface checking. .. I am not complaining about the compiler complaining about about the mismatch between INTENT(IN) and INTENT(INOUT).....

Jim,

I'm surprised you find Intel compiler raises an error message with "stronger interface checking" because one of the issues I've run into with the Intel compiler is with its failure to diagnose a mismatch in INTENT attribute of dummy arguments.  I believe there have been threads on the forum on this topic plus I've reported trouble incidents in the past to Intel Support.  Yet I find the problem persists.  So it'll be useful if you can put together a small reproducer of your situation.  Here's one of the cases I'd noticed a while ago in connection with a team I was working with who had some older code:

subroutine sub( a )
   integer, intent(inout) :: a     !<-- INOUT
   print *, a
end subroutine

program p
   interface
      subroutine sub( a )
         integer, intent(in) :: a  !<-- IN
      end subroutine
   end interface
   integer :: a
   call sub( a )
end program p

C:\Temp>type p.f90
subroutine sub( a )
   integer, intent(inout) :: a     !<-- INOUT
   print *, a
end subroutine

program p
   interface
      subroutine sub( a )
         integer, intent(in) :: a  !<-- IN
      end subroutine
   end interface
   integer :: a
   call sub( a )
end program p

C:\Temp>ifort /gen-interfaces p.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R
) 64, Version 17.0.5.267 Build 20170817
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.13.26129.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:p.exe
-subsystem:console
p.obj

C:\Temp>

Note Intel Fortran compiler 18.0 Update 2 also fails to diagnose the above mismatch whereas gfortran raises the following clear message:

C:temp\p.f90:7:20:
       subroutine sub( a )
                    1
Error: Interface mismatch in global procedure 'sub' at (1): INTENT mismatch in argument 'a'

[FortranFan]

And here's a variant of the same failure to diagnose a mismatch that persists in Intel Fortran 18.0 compiler Update 2:

module m
contains
   subroutine sub( a )
      integer, intent(inout) :: a     !<-- INOUT
      print *, a
   end subroutine
end module

program p
   use m, only : sub
   interface
      subroutine Isub( a )
         integer, intent(in) :: a  !<-- IN
      end subroutine
   end interface
   procedure(Isub), pointer :: psub
   psub => sub
end program p

gfortran catches this with the same clear message:

C:\temp\p.f90:9:11:
    psub => sub
           1
Error: Interface mismatch in procedure pointer assignment at (1): INTENT mismatch in argument 'a'

[IanH]

FortranFan wrote:

C:\Temp>ifort /gen-interfaces p.f90
...

Note Intel Fortran compiler 18.0 Update 2 also fails to diagnose the above mismatch...

Try with /warn:interfaces, not /gen-interfaces.

[jimdempseyatthecove]

FF>>I'm surprised you find Intel compiler raises an error message

You missed the point of my post. I appreciate that the compiler issued an error message...
... I am upset that the error message wasn't more informative.

In my case, I got something like (not sure of exact text):

Error: Interface in mismatch in procedure argument (1)
Error: Interface in mismatch in procedure argument (2)
Error: Interface in mismatch in procedure argument (3)

The function argument was a function call with 3 arguments.

Your gfortran error message is what I would have preferred to receive, stating that the intent was wrong, and not stating a type mismatch.

Not knowing error was in INTENT and .NOT. type, lead me on a goose chase trying to figure out a type mismatch.

Jim Dempsey