Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

interface check mandatory in 16.0.3

TimP
Honored Contributor III
308 Views

Somehow I missed the announcement of the change.  I can't find a way to turn off interface check, and it's an error, not a warning.  One more reason why customers don't like new compilers.  In this case it's a valid complaint, the code is wrong without -autodouble. 

16.0.3 also requires -fno-inline-functions for this application, which doesn't appear to have been needed in 15.0 or 17.0 compilers.  With default in-lining, this application will stop due to getting wrong array bounds passed in arguments if array bound checking is enabled with this compiler, but it's clean with the 15 and 17 compilers.  Probably too complicated to dig into unless the code owner wants it.

0 Kudos
4 Replies
Lorri_M_Intel
Employee
308 Views

hi Tim -

          We did not turn on interface checking by default.   It's possible we improved detection of an invalid interface if, as you say, it was a legitimate complaint.

          If you would like us to look at the check:bounds + inlining problem, well, you know what to do :-)

                       thanks -

                                      --Lorri

 

 

 

0 Kudos
Steven_L_Intel1
Employee
308 Views

Tim, please also provide an example showing the interface checking issue.

0 Kudos
TimP
Honored Contributor III
308 Views

It seems (not so surprising now that it's simplified) interface checking is mandatory in internal procedures:

        program badinterface
        call sub(0.)
        contains
        subroutine sub(x)
        use iso_fortran_env
        real(real64) :: x   ! or real*8 x
        return
        end subroutine sub
        end


Apparently, people count on setting -autodouble or a synonym to make this valid.

0 Kudos
Steven_L_Intel1
Employee
308 Views

Contained procedures have ALWAYS had interfaces checked, since this is an explicit interface. This is certainly NOT new behavior. Consider:

C:\Projects>ifort t.f90
Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 15.0.4.221 Build 20150407
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

t.f90(2): error #6633: The type of the actual argument differs from the type of
the dummy argument.   [0.]
        call sub(0.)
-----------------^
compilation aborted for t.f90 (code 1)

This is not -warn interface which deals with separately compiled procedures not in modules. If you use -autodouble it does compile.

So what exactly is the new behavior you're seeing?

0 Kudos
Reply