- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was trying to mimic the example in the F08 standard . . .
Is this bad Fortran code?
module dollar_mod
implicit none
private
type, public :: dollar_type
real :: amount
contains
procedure :: Write_dollar
generic :: write(formatted) => Write_dollar
end type dollar_type
! This works OK instead of "generic"
! interface write (formatted)
! procedure :: Write_dollar
! end interface
public :: write (formatted)
contains
subroutine Write_dollar &
(dollar_value, unit, b_edit_descriptor, v_list, iostat, iomsg)
class (dollar_type), intent(in) :: dollar_value
integer, intent(in) :: unit
character (len=*), intent(in) :: b_edit_descriptor
integer, dimension(:), intent(in) :: v_list
integer, intent(out) :: iostat
character (len=*), intent(inout) :: iomsg
write (unit=unit, fmt="(f9.2)", iostat=iostat) dollar_value%amount
end subroutine Write_dollar
end module dollar_mod
program test_dollar
! use :: dollar_mod ! Same error message
use, non_intrinsic :: dollar_mod, only: dollar_type, write (formatted)
implicit none
type (dollar_type), parameter :: wage = dollar_type(15.10)
write (unit=*, fmt="(DT)") wage
end program test_dollar
===================================================
$ ifort i_bug.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.143 Build 20161005
Copyright (C) 1985-2016 Intel Corporation. All rights reserved.
i_bug.f90(33): error #6714: There is no visible interface-stmt that defines this generic-spec.
end subroutine Write_dollar
^
compilation aborted for i_bug.f90 (code 1)
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The issue is the "public :: write (formatted)". If you remove this, the module compiles ok but the main program does not. As a type-bound generic, the separate PUBLIC is declaring something else entirely, leading to the error.
Remove the PUBLIC and the mention of write(formatted) in the ONLY.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For the code in #1, I think the only issue I can see is that the error message for that public statement (the interface block is commented out, so there is no stand-alone "write (formatted)" interface to make public) is being reported against the wrong line.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, that's fine. There are two ways to declare a DTIO procedure, and doing it as a TBP is standard F2008 (not F2003, I think). But the scoping rules are different for the TBP.
The standard's example uses the generic TBP but doesn't use PUBLIC as Walt did.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve Lionel (Ret.) wrote:
.. There are two ways to declare a DTIO procedure, and doing it as a TBP is standard F2008 (not F2003, I think). But the scoping rules are different for the TBP. ..
Steve,
Welcome back.
Re: "There are two ways to declare a DTIO procedure, and doing it as a TBP is .. not F2003", please note Fortran 2003 does allow the TBP form of DTIO (emphasis below is mine):
11 9.5.3.7.2 User-defined derived-type input/output procedures 12 For a particular derived type and a particular set of kind type parameter values, there are four possible 13 sets of characteristics for user-defined derived-type input/output procedures; one each for formatted 14 input, formatted output, unformatted input, and unformatted output. The user need not supply all four 15 procedures. The procedures are specified to be used for derived-type input/output by interface blocks 16 (12.3.2.1) or by generic bindings (4.5.4), with a dtio-generic-spec (R1208).
Re: your comment, "But the scoping rules are different for the TBP", yes indeed and that's why I was most disappointed to see a bug like this in Intel Fortran: https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/698148.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I did not have the F2003 standard handy when I wrote earlier. But the thread you linked to relates to a parsing error, not what Walt is seeing. I am not convinced there is a bug here. If you think there is, please cite references to the standard. It wouldn't be the first time I was wrong about something like this!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve Lionel (Ret.) wrote:
I did not have the F2003 standard handy when I wrote earlier. But the thread you linked to relates to a parsing error, not what Walt is seeing. I am not convinced there is a bug here. If you think there is, please cite references to the standard. It wouldn't be the first time I was wrong about something like this!
Steve,
No, I agree - there is no Intel Fortran bug with respect to code in the original post; the issue is indeed as you and IanH described with the superfluous "public :: write(formatted)" statement.
I was only trying to clarify UDDTIO with the TBP form has been part of the standard since Fortran 2003 and also your comment that "the scoping rules are different for the TBP", something that is perhaps not as explicit as it can be made in the standard but which I think would be "intuitively obvious" during compiler implementation. Hence I would have expected Intel Fortran to have supported a statement such as "generic, public :: write(formatted)" from the get-go, for it's part of the "scoping rules" for TBPs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The thing about the Fortran standard is that there are so many "side-effects" that aren't always obvious when reading a single part of it - you have to keep the whole thing in your head, and few of us can manage that. (Maybe Malcolm Cohen can...) Every implementation I know of (even Malcolm's) misses things from time to time. Everyone does the best they can, and fix issues as they become evident. It's most problematic when an existing syntax gets extended. The reason F2008 and F2015 has that introduction section that lists all the differences is explicitly to help implementors find all the things they have to change. The committee is hard-nosed about making sure this is kept complete for exactly this reason.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page