Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28746 Discussions

Write Derived Typy via UDTIO, weird behavior

Max_N_
Beginner
442 Views

Hello,

I was trying to understand user-defined derived type I/O, but had some weird issues. I stripped it down to this minimal example:

  1 ! ============== !
  2 ! === MODULE === !
  3 ! ============== !
  4 
  5 module SomeModule
  6 
  7 implicit none
  8 
  9 interface write(formatted)
 10     module procedure WriteSomeType
 11 end interface
 12 
 13 type SomeType
 14     integer :: value
 15 end type
 16 
 17 contains
 18 
 19 subroutine WriteSomeType(var, unit, iotype, v_list, ios, iom)
 20 
 21     class(SomeType), intent(in)    :: var
 22     integer        , intent(in)    :: unit
 23     character(*)   , intent(in)    :: iotype
 24     integer        , intent(in)    :: v_list(:)
 25     integer        , intent(out)   :: ios
 26     character(*)   , intent(inout) :: iom
 27 
 28     write(*,*) "DEBUG: using UDTIO"
 29 
 30     write(unit, *, iostat=ios, iomsg=iom) var % value
 31 
 32 end subroutine WriteSomeType
 33 
 34 end module SomeModule
 35 
 36 ! =============== !
 37 ! === PROGRAM === !
 38 ! =============== !
 39 
 40 program SomeProgram
 41 
 42 use SomeModule
 43 
 44 implicit none
 45 
 46 type(SomeType) :: var
 47 
 48 var % value = 10
 49 
 50 write(*,*) var
 51 
 52 contains
 53 
 54 !subroutine SomeSubroutine(arg)
 55 !
 56 !    type(SomeType) :: arg
 57 !
 58 !    write(*,*) arg
 59 !
 60 !end subroutine SomeSubroutine
 61 
 62 end program SomeProgram

When I compile this with ifort 15.0.1 on CentOS 6 and run it, the output is

DEBUG: using UDTIO          10

indicating, that the the UDTIO subroutine has been used. When I uncomment SomeSubroutine and recompile, the output is

          10

so just the usual output of derived types. I do not understand this - I don't even call SomeSubroutine?

Thanks,

Max

0 Kudos
2 Replies
Steven_L_Intel1
Employee
442 Views

I can reproduce this in 16.0.1 - looks like a compiler bug. Escalated as issue DPD200381583. Thanks.

0 Kudos
Steven_L_Intel1
Employee
442 Views

Fixed for a release later this year.

0 Kudos
Reply