Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Black Belt
8 Views

interface check mandatory in 16.0.3

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
Highlighted
8 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
Highlighted
8 Views

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

Retired 12/31/2016
0 Kudos
Black Belt
8 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
Highlighted
8 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?

Retired 12/31/2016
0 Kudos