Unlimited Polymorphic and Select Type -- Incorrect Output

[fortrandave]

Greetings!

I recently switched from "Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 12.0.4.196 Build 20110427" to "Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 14.0.2.176 Build 20140130" and started getting incorrect application output from code that uses unlimited polymorphic variables and select type.  Here's some sample code:

    module write_table_m
    implicit none
    contains
    subroutine write_table(out, array)
    integer, intent(in) :: out
    class(*), intent(in) :: array(:,:)
    integer :: k, isize = 2

    select type(array)
    type is(real)
        do k = 1, isize
            write(out,*)array(k, :)
        enddo
    class default
        stop 'UNHANDLED DATA TYPE'
    endselect
    
    end subroutine write_table
    end module write_table_m
!*******************************************************************************
    program main
    use write_table_m
    implicit none
    real :: table(2,3) = 10
    call write_table(6, table)
    end program main

And here's the output using the two compilers:

$ fort-2008 select_type_bug.f90
Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 12.0.4.196 Build 20110427
Copyright (C) 1985-2011 Intel Corporation.  All rights reserved.

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

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


$ select_type_bug.exe
   10.00000       10.00000       10.00000
   10.00000       10.00000       10.00000


$ fort select_type_bug.f90
Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 14.0.2.176 Build 20140130
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

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

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

$ select_type_bug.exe
  1.3563156E-19  1.3563156E-19  1.3563156E-19
  1.3563156E-19  1.3563156E-19  1.3563156E-19

I expect to see 10.00000, not 1.3563156E-19.  Is this a known bug?  Is there a workaround?

Thanks,
Dave

[IanH]

I see the expected output with the current version.

>ifort /check:all /check:noarg_temp_created /warn:all /standard-semantics "2015-10-08 unlimited-polymorphic.f90" && "2015-10-08 unlimited-polymorphic.exe"
Intel(R) Visual Fortran Compiler for applications running on IA-32, Version 16.0.0.110 Build 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

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

"-out:2015-10-08 unlimited-polymorphic.exe"
-subsystem:console
"2015-10-08 unlimited-polymorphic.obj"
 10.00000 10.00000 10.00000
 10.00000 10.00000 10.00000

[Simon_Geard]

Ditto. I also get the same (incorrect) result with 14.0.1.139

Probably not much use but I've found that the following variation of your code works:

    subroutine write_table(out, array)
    integer, intent(in) :: out
    class(*), intent(in), target :: array(:,:)
	real, pointer :: a_ptr(:,:)
    integer :: k, isize = 2

    select type(array)
    type is(real)
		a_ptr => array
    class default
        stop 'UNHANDLED DATA TYPE'
    endselect
    do k = 1, isize
        write(out,*)a_ptr(k, :)
    enddo
    
    end subroutine write_table

[Kevin_D_Intel]

I have not yet put my finger on a related internal defect id, but it appears from testing a number of compilers this was first fixed in our initial Intel Fortran Composer XE 2015 (15.0 compiler) release.

$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.090 Build 20140723
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

$ ifort u595206.f90 ; ./a.out
   10.00000       10.00000       10.00000
   10.00000       10.00000       10.00000

[fortrandave]

Kevin,

Thanks for the feedback.  I'll see what my customer has access to.  Also, I feel better that I couldn't find the defect ID myself -- I looked and didn't see anything relevant in the list.

Thanks,
Dave