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

Runtime error in UDDTIO depending of order of statements

johnyb_
New Contributor I
740 Views

I am still hoping to be able to use UDDTIO in our Fortran programs before retirement, but time is running short. While the v17 compiler corrects a few of the many bugs I signalled, it manages to introduce new, fascinating ones like this:

module m_test
   type t1
        integer :: a
      contains
        procedure, private :: r_t1
        generic :: read(formatted) => r_t1
    end type
    contains
        subroutine r_t1(dtv, unit, iotype, vlist, iostat, iomsg)
            class(t1),          intent(inout)   :: dtv
            integer,            intent(in)      :: unit
            character(len=*),   intent(in)      :: iotype
            integer,            intent(in)      :: vlist(:)
            integer,            intent(out)     :: iostat
            character(len=*),   intent(inout)   :: iomsg
            read(unit, fmt="(i4)", iostat=iostat, iomsg=iomsg) dtv%a
        end subroutine
end module

program test
    use m_test

    character(len=:), allocatable :: str
    type(t1) :: x,y,z
    str="111122223333444455555"
    read(str, fmt="(DT,DT,DT)") x,y,z
    print *, x%a, y%a, z%a
    read(str, fmt="(3DT)") x,y,z
    print *, x%a, y%a, z%a
end program

when compiled and run gives this.

C:\dev\f95\bugs\intel>ifort test.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.4.210 Build 20170411
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:test.exe
-subsystem:console
test.obj

C:\dev\f95\bugs\intel>test
        1111        2222        3333
forrtl: severe (125): A derived type variable in this statement requires a DT format specifier because it has a component that is ALLOCATABLE, POINTER, or PRIVATE, unit -5, file Internal Formatted Rea
d
Image              PC                Routine            Line        Source
test.exe           00007FF7CDF4E9CD  Unknown               Unknown  Unknown
test.exe           00007FF7CDF39226  Unknown               Unknown  Unknown
test.exe           00007FF7CDF31569  Unknown               Unknown  Unknown
test.exe           00007FF7CDFA024E  Unknown               Unknown  Unknown
test.exe           00007FF7CDFA05E5  Unknown               Unknown  Unknown
KERNEL32.DLL       00007FFA1AA216AD  Unknown               Unknown  Unknown
ntdll.dll          00007FFA1B8154E4  Unknown               Unknown  Unknown

C:\dev\f95\bugs\intel>

If I simply change the order of the two read statements:

...
program test
    use m_test

    character(len=:), allocatable :: str
    type(t1) :: x,y,z
    str="111122223333444455555"
    read(str, fmt="(3DT)") x,y,z
    print *, x%a, y%a, z%a
    read(str, fmt="(DT,DT,DT)") x,y,z
    print *, x%a, y%a, z%a
end program

it seems to run ok:

C:\dev\f95\bugs\intel>ifort test.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.4.210 Build 20170411
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:test.exe
-subsystem:console
test.obj

C:\dev\f95\bugs\intel>test
        1111        2222        3333
        1111        2222        3333

C:\dev\f95\bugs\intel>

the compiler v16 update 4 does not expose this problem.

 

0 Kudos
7 Replies
Xiaoping_D_Intel
Employee
740 Views

Thank you for your report! This issue is better to be reported via our Online Service Center at https://supporttickets.intel.com/ 

Instructions on how to file a ticket are available here:

https://software.intel.com/en-us/articles/how-to-create-a-support-request-at-online-service-center 

 

Thanks,

Xiaoping Duan

Intel Customer Support

0 Kudos
andrew_4619
Honored Contributor II
740 Views

Duan, Xiaoping (Intel) wrote:

Thank you for your report! This issue is better to be reported via our Online Service Center at https://supporttickets.intel.com/ 

Instructions on how to file a ticket are available here:

https://software.intel.com/en-us/articles/how-to-create-a-support-request-at-online-service-center 

 

Thanks,

Xiaoping Duan

Intel Customer Support

Dear Intel. This sucks IMO. I a user has gone to the trouble of reporting a bug and posting a reproducer and now you want them to do it again via a different system despite the fact you have all the information? Also, what about users that do not have current maintenance that can't access the support centre? I bug is a bug and it benefits all users to get it fixed.

I suggest you review the new policy.

Andrew

0 Kudos
Steve_Lionel
Honored Contributor III
740 Views

I was surprised to learn that anyone can submit reports through the Service Center - it doesn't require paid support.

0 Kudos
mecej4
Honored Contributor III
740 Views

Filing a support ticket seems to require going through a lot of red tape -- almost as much as filing an application for a national passport. Faced with that barrier, many users may simply give up.

The support ticket setup seems to exclude public discussion of compiler/programming issues. Another instance of "No good deed shall go unpunished"? Sad!

0 Kudos
andrew_4619
Honored Contributor II
740 Views

I just looked at filling a ticket, by the third page of questions I had lost interest. From a personal view point I don't see an reasons for jumping through these hoops unless I was desperate and could not find a work around.

0 Kudos
Xiaoping_D_Intel
Employee
740 Views

I have reproduced the error and opened a bug report for it. The bug track ID is CMPLRS-43656.

 

Thanks,

Xiaoping Duan

Intel Customer Support

0 Kudos
johnyb_
New Contributor I
740 Views

This is the first time I have been asked to resubmit my bug report elsewhere. It has been some time of course since the last report, as we have suspended work around UDDTIO because of the many problems encountered.

I am always hoping when I encounter a problem like the one reported here, that the error is in my code and not in the compiler. So I report it in the forum as there are several people here who have a far better knowledge of Fortan than I do and can perhaps point out my error. 
We do have current support for the compiler (since many years), but it is our IT admin who manages the support account linked to our serial numbers and that is only used to download new versions or licence files. The IT admin is of course not involved in our Fortran developments.

I agree with mecej4 and andrew_4619 that it is not very customer friendly to require going through a lot of red tape to report a bug and confining bug reports in a "support center" hides them from other users who could perhaps profit from knowing about them. 
I also note that the support site seems to be confused and shows me as signed in and asks me to sign up, but refuses any text entry. If I were an unkind person I would think the same team tests the support site that tests the compiler.

0 Kudos
Reply