Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
1 View

UDDTIO with Allocatable Component

Hi! In the project attached, derived-types KeyValuePair and Value are introduced. The difference between these are that components of KeyValuePair are ALLOCATABLE while those within Value are not. The NAMELIST read statements behaves differently due to that difference I think. How could I write the UDIO procedures If I still want to employ those ALLOCATABLE components ? Thanks for any help.

0 Kudos
9 Replies
Highlighted
Black Belt
1 View

You don't explain what you

You don't explain what you see that you consider different.

With the current beta I get an access violation with either case, that I suspect is due to an incorrectly set up descriptor for the polymorphic argument for the object being read in the user defined derived type I/O procedure.

0 Kudos
Highlighted
New Contributor I
1 View

Quote:ianh wrote:

ianh wrote:

You don't explain what you see that you consider different.

With the current beta I get an access violation with either case, that I suspect is due to an incorrectly set up descriptor for the polymorphic argument for the object being read in the user defined derived type I/O procedure.

Thanks lanH, the statement marked as error generates a run-time error message:

severe (188): An assignment was made from an object of one size to an object of a different size that cannot be deallocated.

while the other one is just fine. The compilation environment is 2018u2  and VS2015 on x64 platform.

0 Kudos
Highlighted
Valued Contributor III
1 View

Quote:ianh wrote:

ianh wrote:

.. With the current beta I get an access violation with either case, that I suspect is due to an incorrectly set up descriptor for the polymorphic argument for the object being read in the user defined derived type I/O procedure.

".. incorrectly set up descriptor for the polymorphic argument for the object being read in the user defined derived type I/O procedure... " huh, what!?   

0 Kudos
Highlighted
Valued Contributor III
1 View

@Blane J.,

@Blane J.,

It will help if you can provide sufficient details, one way to do is as follows for a compiler problem with Intel Fortran which throws an unexpected access violation error with your use of SELECT TYPE construct in a defined input/output procedure:

The code is:

module m

   type :: t
      character(len=:), allocatable :: s
   contains
      procedure, pass(this), private :: read_t
      generic :: read(formatted) => read_t
   end type t

contains

   subroutine read_t(this, lun, iotype, vlist, istat, imsg)

      ! Argument list
      class(t), intent(inout)        :: this
      integer, intent(in)            :: lun
      character(len=*), intent(in)   :: iotype
      integer, intent(in)            :: vlist(:)
      integer, intent(out)           :: istat
      character(len=*),intent(inout) :: imsg

      ! Local variables
      character(len=10) :: s

      istat = 0
      blk_if: if (iotype == "NAMELIST") then
         read( unit=lun, fmt=*, iostat=istat, iomsg=imsg ) s
         this%s = "iotype identified as NAMELIST" // new_line("") // &
            "LIST-DIRECTED READ was " // trim(s) // new_line("")
         select type ( this )
            type is ( t )
               this%s = this%s // "SELECT TYPE block identified TYPE IS (t)"
               exit blk_if
         end select
         this%s = this%s // "BYPASSED: SELECT TYPE block"
      end if blk_if

      return

   end subroutine read_t

end module

program p

   use m, only : t

   implicit none

   type(t) :: foo
   namelist / nml_t / foo
   character(len=:), allocatable :: snml

   snml = '&nml_t foo="xx", /'
   read( unit=snml, nml=nml_t )

   print *, foo%s

   stop

end program p

Console output with all the details is

C:\Temp>type p.f90
module m

   type :: t
      character(len=:), allocatable :: s
   contains
      procedure, pass(this), private :: read_t
      generic :: read(formatted) => read_t
   end type t

contains

   subroutine read_t(this, lun, iotype, vlist, istat, imsg)

      ! Argument list
      class(t), intent(inout)        :: this
      integer, intent(in)            :: lun
      character(len=*), intent(in)   :: iotype
      integer, intent(in)            :: vlist(:)
      integer, intent(out)           :: istat
      character(len=*),intent(inout) :: imsg

      ! Local variables
      character(len=10) :: s

      istat = 0
      blk_if: if (iotype == "NAMELIST") then
         read( unit=lun, fmt=*, iostat=istat, iomsg=imsg ) s
         this%s = "iotype identified as NAMELIST" // new_line("") // &
            "LIST-DIRECTED READ was " // trim(s) // new_line("")
         select type ( this )
            type is ( t )
               this%s = this%s // "SELECT TYPE block identified TYPE IS (t)"
               exit blk_if
         end select
         this%s = this%s // "BYPASSED: SELECT TYPE block"
      end if blk_if

      return

   end subroutine read_t

end module

program p

   use m, only : t

   implicit none

   type(t) :: foo
   namelist / nml_t / foo
   character(len=:), allocatable :: snml

   snml = '&nml_t foo="xx", /'
   read( unit=snml, nml=nml_t )

   print *, foo%s

   stop

end program p



C:\Temp>ifort /standard-semantics /warn:all /stand /traceback p.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R
) 64, Version 19.0.0.045 Beta Build 20180317
Copyright (C) 1985-2018 Intel Corporation.  All rights reserved.

ifort: NOTE: The Beta evaluation period for this product ends on 11-oct-2018 UTC
.
p.f90(12): remark #7712: This variable has not been used.   [VLIST]
   subroutine read_t(this, lun, iotype, vlist, istat, imsg)
----------------------------------------^
Microsoft (R) Incremental Linker Version 14.13.26131.1
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:p.exe
-subsystem:console
-incremental:no
p.obj

C:\Temp>p.exe
forrtl: severe (157): Program Exception - access violation
Image              PC                Routine            Line        Source

p.exe              000000013FF314C0  M_mp_READ_T                30  p.f90
p.exe              000000013FF6E35E  Unknown               Unknown  Unknown
p.exe              000000013FF6E0F6  Unknown               Unknown  Unknown
p.exe              000000013FF43478  Unknown               Unknown  Unknown
p.exe              000000013FF3A5FC  Unknown               Unknown  Unknown
p.exe              000000013FF363F1  Unknown               Unknown  Unknown
p.exe              000000013FF32A58  Unknown               Unknown  Unknown
p.exe              000000013FF31291  MAIN__                     55  p.f90
p.exe              000000013FFB03E2  Unknown               Unknown  Unknown
p.exe              000000013FFB07DC  Unknown               Unknown  Unknown
kernel32.dll       0000000076D559CD  Unknown               Unknown  Unknown
ntdll.dll          0000000076FB383D  Unknown               Unknown  Unknown

C:\Temp>gfortran -std=f2008ts p.f90 -o p_gfortran.exe

C:\Temp>p_gfortran.exe
 iotype identified as NAMELIST
LIST-DIRECTED READ was xx
SELECT TYPE block identified TYPE IS (t)

C:\Temp>

Note gfortran compiler handles the same code ok but it's Intel Fortran that has the issue at line 30 in the file that has the SELECT TYPE instruction..

0 Kudos
Highlighted
Black Belt
1 View

Quote:FortranFan wrote:

FortranFan wrote:

Quote:

ianh wrote:

 

.. With the current beta I get an access violation with either case, that I suspect is due to an incorrectly set up descriptor for the polymorphic argument for the object being read in the user defined derived type I/O procedure.

 

 

".. incorrectly set up descriptor for the polymorphic argument for the object being read in the user defined derived type I/O procedure... " huh, what!?   

The compiler has to construct a descriptor for the dummy argument that corresponds to the thing that the user defined derived type I/O procedure is trying to read in (`this` in your later example).  This descriptor is where the compiler stores information about the dynamic type of the object being defined.  It appears that the compiler isn't doing that correctly - consequently you observe an access violation when the select type statement is executed.

0 Kudos
Highlighted
New Contributor I
1 View

@FortranFan,

@FortranFan,

Thanks for your suggestion. For my project contains a DLL and the main program depend on that, I'am not sure how to compile that from the command line. The error I encontered is quite similar to an access and reference issue (memory access issue). For now I don't have the beta version and since both you and lanH produced access violation by the beta, and you suggested a success execution with gfortran, I thought that is probably a compiler failure somehow.

 

0 Kudos
Highlighted
Valued Contributor III
1 View

Quote:Blane J. wrote:

Blane J. wrote:

.. I'am not sure how to compile that from the command line. .. I thought that is probably a compiler failure somehow.

@Blane J.,

Yes, my impression too is Intel Fortran compiler has bug(s) with SELECT TYPE instructions in defined input/output procedures, 19.0 beta acts one way, 18.0 Update 2 somewhat differently, same with internal read versus external files.  You may consider submitting this at the Intel Online Service Center.

But note I don't think this has to do with compiling in a DLL or a command line.  What I was trying to do is offer you an example of how to share all the details including code, compiler version, compilation and linking options, run commands, and the error(s).  This is so you can do the same here or in the future; you posted an attachment initially and a text snippet of the error later, but that didn't quite provide the complete picture for the case at hand.

 

0 Kudos
Highlighted
Valued Contributor III
1 View

Quote:ianh wrote:

ianh wrote:

The compiler has to construct a descriptor for the dummy argument that corresponds to the thing that the user defined derived type I/O procedure is trying to read in (`this` in your later example).  This descriptor is where the compiler stores information about the dynamic type of the object being defined.  It appears that the compiler isn't doing that correctly - consequently you observe an access violation when the select type statement is executed.

Ok, that's better.  In Quote #2, with "incorrectly set up descriptor", it wasn't quite clear, at least to me, if you were implying a coding error by OP or an issue with Intel Fortran compiler. 

0 Kudos
Highlighted
New Contributor I
1 View

@FortranFan,

@FortranFan,

OK, that's indeed a clear way, I'll try it out when asking for help next time. I also reported the problem to the OSC and waiting for reply.

0 Kudos