Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Walt_Brainerd
Beginner
74 Views

DTIO error message

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)

0 Kudos
7 Replies
Steve_Lionel
Black Belt Retired Employee
74 Views

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.

IanH
Black Belt
74 Views

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.

Steve_Lionel
Black Belt Retired Employee
74 Views

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.

FortranFan
Honored Contributor I
74 Views

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.  

 

 

Steve_Lionel
Black Belt Retired Employee
74 Views

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!

FortranFan
Honored Contributor I
74 Views

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.

Steve_Lionel
Black Belt Retired Employee
74 Views

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.