User defined IO: complex number problem

[Ferdinand_T_]

Hello community,

in the following program, user-defined IO formatted read behaves unusually on complex numbers in ifort 17.0.4.

module m
    implicit none

    type :: t_type
        complex :: x
        integer :: i
        character(len=10) :: s
    contains
        procedure :: t_read
        generic :: read(formatted) => t_read
    end type
contains
    subroutine t_read(t, unit, iotype, vlist, iostat, iomsg)
        implicit none
        class(t_type), intent(inout) :: t
        character(len=*), intent(in) :: iotype
        integer, intent(in), dimension(:) :: vlist
        integer, intent(in) :: unit
        integer, intent(out) :: iostat
        character(len=*), intent(inout) :: iomsg

        ! TEST 1 (OK):
        !read(unit,*,iostat=iostat,iomsg=iomsg) t%x, t%i    ! (1.0,2.0), 3
        !if (iostat /= 0) return

        ! TEST 2 (ERROR):
        !read(unit,*,iostat=iostat,iomsg=iomsg) t%x        ! (1.0,2.0)
        !if (iostat /= 0) return
        !read(unit,*,iostat=iostat,iomsg=iomsg) t%i        ! ERROR
        !if (iostat /= 0) return

        ! TEST 3 (DEBUG):
        read(unit,*,iostat=iostat,iomsg=iomsg) t%x        ! (1.0,2.0)
        if (iostat /= 0) return
        read(unit,*,iostat=iostat,iomsg=iomsg) t%s        ! ')'
        if (iostat /= 0) return
        read(unit,*,iostat=iostat,iomsg=iomsg) t%i        ! 3
        if (iostat /= 0) return
    end subroutine
end module

program p
    use m
    implicit none
    integer :: iostat
    character(len=255) :: str, iomsg
    type(t_type) :: t

    ! Defaults:
    t%x = (0.0,0.0)
    t%i = 0
    t%s = repeat('X',len(t%s))
    
    ! List-directed IO:
    str = '(1.0,2.0) 3'
    read(str,*,iostat=iostat,iomsg=iomsg) t

    ! Output:
    print *, t%x, t%i, "'", trim(t%s), "'"
    if (iostat /= 0) print *, trim(iomsg)

    ! OUTPUT for TEST 1:
    ! (1.000000,2.000000)           3 'XXXXXXXXXX'

    ! OUTPUT for TEST2:
    ! (1.000000,2.000000)           0 'XXXXXXXXXX'
    ! User Defined I/O procedure returned error 59, message: 'list-directed
    ! I/O syntax error, unit -5, file Internal List-Directed Read'

    ! OUTPUT for TEST 3:
    ! (1.000000,2.000000)           3 ')'
end program

The output from ifort 17.0.4 is reported for the three test-cases.

It looks as if the list-directed read does NOT advance beyond the closing parenthesis of the complex number literal in TEST 2, which is verified in TEST 3. Is this a bug or a feature?

Instead, with iifort 16.0.4, TEST 1 and TEST 2 yied similar output as expected.

Any ideas on workarounds that work both in ifort 16.0.4 AND 17.0.4 (and future versions) are appreciated.

Kind regards
Ferdinand

[Steve_Lionel · Accepted solution]

I agree with you that the 17 (and 18) versions get this wrong. Your cases 1 and 2 in the UDIO procedure ought to behave identically. I suggest that you submit a report through the Online Service Portal. 

[Ferdinand_T_]

Thanks Steve,

for the quick confirmation. Maybe one of the service packs for ifort 18 will smooth this out.

Steve Lionel (Ret.) wrote:

I suggest that you submit a report through the Online Service Portal. 

Is it possible to submit such a report with a student license?
Ferdinand

[Steve_Lionel]

I think so - Intel changed things around after I left, but it seems that anyone at least can submit a report. With a student license you don't get "priority". Start here.

[FortranFan]

Ferdinand T. wrote:

.. Any ideas on workarounds that work both in ifort 16.0.4 AND 17.0.4 (and future versions) are appreciated. ..

I have reported issues with defined IO that go back over a year ago and have not seen any positive movement.

So you may want to consider workarounds or stop using defined IO altogether.

Re: workarounds, an option will be to use formatted read using "DT" edit descriptor instead of list-directed.

But if you want to keep it as list-directed, you can try reading in the input into a local CHARACTER variable and perform an internal file read:

[Steve_Lionel]

I saw many UDIO problems fixed in the time since the feature was introduced into ifort. It works a lot better today than it used to. That doesn't mean there aren't still bugs, especially in the more unusual cases such as list-directed and NAMELIST I/O. Indeed, I recall having an extended conversation with an I/O library developer about this, and we agreed that the standard says very little about how that should be handled in UDIO.

[Ferdinand_T_]

FortranFan wrote:

I have reported issues with defined IO that go back over a year ago and have not seen any positive movement.

So you may want to consider workarounds or stop using defined IO altogether.

Thank you for the input, FortranFan. I will stop using UDIO in this case for now. My experience is however that Intel put out a lot of features with the 2003 and 2008 iterations in early stage but keeps updating regularly since then (as witnessed not only by this bug report, there must have been some changes made in the UDIO between the versions 16 and 17 compilers).

FortranFan wrote:

Re: workarounds, an option will be to use formatted read using "DT" edit descriptor instead of list-directed.

But if you want to keep it as list-directed, you can try reading in the input into a local CHARACTER variable and perform an internal file read:

These ideas are much appreciated. However they ultimately seem to amount in writing my own Fortan input parser, hence I will abandon UDIO for now. 

My reason for using list-directed formatted (text-) input is twofold:

1. read (user-)input as fault-tolerantly as possible
2. simplicity of the code

In contrast, I write my objects into text-files with format-directed output to guarantee highest precision (i.e. number of digits) and a nice output formatting.

Kind regards
Ferdinand

[Steve_Lionel]

There were LOTS of UDIO fixes between 16 and 18. Please submit a problem report to Intel for any issues you find.