Difference between "type" and "data type"?

[Sebastien_B_]

Dear Intel support, the following program raises an error, as I expect: $ cat test.f90 program test real(kind=8) :: i i = 1.0 call mysub(i) contains subroutine mysub(j) real(kind=4), intent(in) :: j print *,j end subroutine mysub end program test $ ifort test.f90 -o test && echo "Success" || echo "Failure" test.f90(4): error #6633: The type of the actual argument differs from the type of the dummy argument. call mysub(i) -------------^ compilation aborted for test.f90 (code 1) Failure On the other hand, this next one is successful, and the program actually works, but I do not understand why. To me the program is as "non-conformant" as the previous one, and I expect the compiler to raise an error (and my Makefile to stop), but it does not... Do you have any clue? I use ifort 11.1. $ cat test.f90 program test integer(kind=4) :: i i = 1 call mysub(i) contains subroutine mysub(j) integer(kind=8), intent(in) :: j print *,j end subroutine mysub end program test $ ifort test.f90 -o test && echo "Success" || echo "Failure" test.f90(4): warning #6075: The data type of the actual argument does not match the definition. call mysub(i) -------------^ Success $ ./test 1 Thank you, Sebastien

[mecej4]

It is a matter of whether an implicit interface is used, as in your first example,  or an explicit interface is available, as in your second example.

When the compiler sees a subroutine call that is not consistent with a known interface, it can issue a warning or an error message, as is appropriate. When a subroutine declaration and invocation are in separate files that are compiled separately, you run into bigger problems that are more difficult to track and solve.

[Sebastien_B_]

mecej4 wrote:
It is a matter of whether an implicit interface is used, as in your first example,  or an explicit interface is available, as in your second example.

Well, in both cases the explicit interface is available because "mysub" is an internal procedure. The only difference is that I pass REAL(8) to REAL(4) in one case, and INTEGER(8) to INTEGER(4) in the other.

mecej4 wrote:
When the compiler sees a subroutine call that is not consistent with a known interface, it can issue a warning or an error message, as is appropriate.

What do you mean by "as is appropriate"? The Fortran standard makes it clear when a call conforms or not to an explicit interface, I see no "intermediate-warnable" cases...

[Steven_L_Intel1]

The second case takes advantage of an extension we offer for integer arguments that are INTENT(IN) - when the kinds don't match we'll convert the argument to the kind of the dummy but give you a warning. We don't do this for real arguments. The standard's rules are for the programmer. The compiler is required to have the ability to diagnose violations of constraints and numbered syntax rules, but the rules of argument matching are not part of this. Compilers are free to provide interpretations of non-conforming code as extensions to the standard.

[Sebastien_B_]

Steve Lionel (Intel) wrote:
The second case takes advantage of an extension we offer for integer arguments that are INTENT(IN) - when the kinds don't match we'll convert the argument to the kind of the dummy but give you a warning. We don't do this for real arguments. The standard's rules are for the programmer. The compiler is required to have the ability to diagnose violations of constraints and numbered syntax rules, but the rules of argument matching are not part of this. Compilers are free to provide interpretations of non-conforming code as extensions to the standard.

Thank you Steve for your answer. I can understand the benefit and i would probably use it if it was part of the standard. However, we (me and others) are developing code aimed to be compiled by other Fortran compilers, i.e. as nearest as possible to the standard. Is there a way to disable all or part of the extensions to the standard provided by default by ifort? I tried "-stand f03" without success.

[Steven_L_Intel1]

What you want is to specify both -stand and -warn stderrors . This will cause detected standard violations to be errors instead of warnings. I will caution you that the compiler can't detect all possible violations.

Curiously, I see that this particular violation is not classified as a standards issue so -warn stderrors doesn't catch this - I will ask that this be changed.

[Sebastien_B_]

Steve Lionel (Intel) wrote:
What you want is to specify both -stand and -warn stderrors . This will cause detected standard violations to be errors instead of warnings. I will caution you that the compiler can't detect all possible violations.

Ok, this is good know. However, it also detects obsolescent-but-not-deleted (so still part of the standard) features, so I can not use it in my context. Nevertheless thank you again for your help.

Steve Lionel (Intel) wrote:
Curiously, I see that this particular violation is not classified as a standards issue so -warn stderrors doesn't catch this - I will ask that this be changed.

Ok thank you.