- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tim, please also provide an example showing the interface checking issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page