- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
mecej4 wrote: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.
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.
mecej4 wrote: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...
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve Lionel (Intel) wrote: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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve Lionel (Intel) wrote: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.
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.
Steve Lionel (Intel) wrote:Ok thank you.
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.
![](/skins/images/8B6E2C8F64F54CBD7F7262AA46F575DA/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page