Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26755 Discussions

Operator overloading with parameterized derived types

geard__simon
Beginner
220 Views

I am trying to use this feature but it doesn't seem to work. As far as I can see the attached code should compile but it doesn't. I've been staring at this code for so long I wouldn't spot an error anyway so I'd appreciate a second opinion. This is the comment at the top of the file:

! Created by  on 22/02/2020.
!
! ifort (IFORT) 19.1.0.166 20191121
!
! Build:
!   ifort -debug -check bounds -warn all -traceback AGd.f90 -o AGd
!
! Result:
!
! AGd.f90(109): error #6549: An arithmetic or LOGICAL type is required in this context.
!    v = 3*s + 1
!---------^
!AGd.f90(109): error #6355: This binary operation is invalid for this data type.
!    v = 3*s + 1
!---------^

 

0 Kudos
9 Replies
FortranFan
Honored Contributor II
220 Views

Looks like a compiler bug to me, I suggest submitting a support request for Intel OSC so their support/Fortran team to review the 2 errors raised by the compiler vis-a-vis your code and to give you feedback on them.

geard__simon
Beginner
220 Views

Thank you. Support was the first place I tried but the only reply was that my licence didn't include support and the request was closed. I thought they might be interested anyway but I've not heard anything. So my only hope now is that someone from Intel monitors this forum and is interested in a potential compiler bug or that someone with support picks it up. I'll do my best to side-step the issue for now and hope that it will be fixed sometime in the future.

andrew_4619
Honored Contributor I
220 Views

geard, simon wrote:

Thank you. Support was the first place I tried but the only reply was that my licence didn't include support and the request was closed. I thought they might be interested anyway but I've not heard anything. So my only hope now is that someone from Intel monitors this forum and is interested in a potential compiler bug or that someone with support picks it up. I'll do my best to side-step the issue for now and hope that it will be fixed sometime in the future.

 

Intel is a large company. Large companies move at the same speed as glaciers. You need to find a work around !

geard__simon
Beginner
220 Views

I have found a sort of work round - one that enables me to build. The solution is to add user-defined operators like so:

    interface operator(.mult.)
        module procedure i_times_gav, gav_times_i, r_times_gav, gav_times_r, gav_times_gav
    end interface

    interface operator(.plus.)
        module procedure i_plus_gav, gav_plus_i, r_plus_gav, gav_plus_r, gav_plus_gav
    end interface

    interface operator(.minus.)
        module procedure i_minus_gav, gav_minus_i, r_minus_gav, gav_minus_r, gav_minus_gav
    end interface

Then the usage becomes

r3 = (1 .plus. s3) .mult. (1 .minus. (3.mult.s3)) .mult. (1 .plus. (3.mult.s3))

Of course this is only useful for completing the implementation but that at least is something.

 

FortranFan
Honored Contributor II
220 Views

geard, simon wrote:

I have found a sort of work round - one that enables me to build. The solution is to add user-defined operators like so ..

If you're ok with moving away from generic operators with type-bound procedures but open to using newer features, you can try the Fortran 2018 with generic operators and see if they work for you:

generic :: operator(*) => i_times_gav, gav_times_i, r_times_gav, gav_times_r, gav_times_gav

generic :: operator(+) => i_plus_gav, gav_plus_i, r_plus_gav, gav_plus_r, gav_plus_gav

generic :: operator(-) => i_minus_gav, gav_minus_i, r_minus_gav, gav_minus_r, gav_minus_gav

You can then have your usage closer to black-board abstraction:

Barbara_P_Intel
Moderator
220 Views

I filed a bug report on this. I'll keep you posted on its progress to a fix.

 

JohnNichols
Valued Contributor II
220 Views

Intel is a large company. Large companies move at the same speed as glaciers. You need to find a work around !

Actually I find that Intel watch this forum fairly well.  

They do not always solve the problems but you get good feedback 

I suspect some of these old people never sleep 

JMN

Barbara_P_Intel
Moderator
192 Views

This compiler bug is fixed in version 19.1.2 in PSXE 2020 Update 2 that was just released.



jimdempseyatthecove
Black Belt
179 Views

You have written a pure function named i_times_gav and gav_times_i , but have only have declared an operator(*) procedure for gav_times_i

Jim Dempsey

Reply