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

Defined assignment with assumed rank dummy argument refuses to compile

Stijn_Schildermans
850 Views

I am trying to implement a defined assignment for a derived type that is as generic as possible (i.e. the value I assign into is defined as class(*), dimension(..)). However, I can not get IFX to compile my code. Below is a minimal reproducing example:

module tesst
    implicit none

    type:: t
        integer:: val 
    end type

    interface
        module subroutine get_val(val, tt) 
            class(*), dimension(..), intent(out):: val 
            type(t), intent(in):: tt
        end subroutine
    end interface

    interface assignment(=)
        module procedure get_val
    end interface
contains
    module procedure get_val
        print *, 'Test'
    end procedure
end module

program test
    use tesst
    implicit none

    integer:: v
    type(t):: ttt 

    v = ttt 
end program

I am not using any compilation options (ifx -o test test.f90). The compilation error I get is:

'test.f90(36): error #6303: The assignment operation or the binary expression operation is invalid for the data types of the two operands.   [TTT]
   v = ttt

 

I do not understand this, since ttt is of type(t), which I believe it should be. I already found that the problem lies in the assumed rank for the argument val, but I do not understand what is wrong with my code. Any help is appreciated.

 

0 Kudos
4 Replies
Steve_Lionel
Honored Contributor III
808 Views

Interesting. NAG Fortran gets an internal compiler error for this. I don't immediately see that this is invalid, but I will ask.

Steve_Lionel
Honored Contributor III
749 Views

Compiler bug in both compilers. Your example is valid, as far as I can tell. Would one of the Intel TCEs please file a report on this? Thanks.

Stijn_Schildermans
738 Views

Thanks a lot for the confirmation! For now I implemented a workaround in my project using the classic interface with a defined procedure for each possible type of val, which works just fine.

0 Kudos
Devorah_H_Intel
Moderator
608 Views

I have reported this bug to Compiler Engineering. It will be fixed in future releases. 

0 Kudos
Reply