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

Issue discovered when overloading "generic::operator(=)"

Alberto_F__M_
Beginner
598 Views

Dear Intel Fortran Compiler for Linux and Mac OS X users and developers,

I have discovered an Intel 16.0.0 compiler error (with 15.0.2 is also there) when compiling my Fortran03 software which I believe to be standard conforming. Although this is a quite complex software with many data types, and a complex relationship among them (aggregation, 3-level inheritance hierarchy, etc.), I could already reproduce the compiler error on a simplified test case. In particular, I developed three test cases which are attached to this post. The following outcome was observed for these three test cases:

- overloaded_assignment_test1.f90: compiles and generates the output that I would expect.

amartin@Aetos:~/pruebas_fortran_03$ ifort overloaded_assignment_test1.f90
amartin@Aetos:~/pruebas_fortran_03$ ./a.out
 A_C1_t
 C_C1_t

- overloaded_assignment_test2.f90: DOES NOT COMPILE. I believe it to be standard confirming. Compiler error is as follows:

overloaded_assignment_test2.f90(104): error #6197: An assignment of different structure types is invalid.   [C1]
  B = C1
------^
compilation aborted for overloaded_assignment_test2.f90 (code 1)

Note that the only difference among *test1 and *test2, is that, in the latter, the (abstract) intermediate-level data type, type(C_t), has a deferred TBP, called output_C, which its children, type(C1_t) and type(C2_t), are forced to implement.

- overloaded_assignment_test3.f90. Compiles and generates the output that I would expect.

amartin@Aetos:~/pruebas_fortran_03$ ifort overloaded_assignment_test3.f90
amartin@Aetos:~/pruebas_fortran_03$ ./a.out
 A_C1_t
 C_C1_t

Note that the only difference among *test2 and *test3 is that the overloaded assignment is called with a rhs being of "class(C_t) :: pointer" type previously set to point to the instance of type(C1_t), instead of with a rhs being of type(C1_t) directly.

Could you please help me and confirm my suspicions? (i.e., a compiler related issue) How can it be more elegantly work-arounded?

Thanks very much in advance for your support.

 

 

 

 

0 Kudos
2 Replies
FortranFan
Honored Contributor III
598 Views

Alberto F. M. wrote:

Dear Intel Fortran Compiler for Linux and Mac OS X users and developers,

I have discovered an Intel 16.0.0 compiler error (with 15.0.2 is also there) when compiling my Fortran03 software which I believe to be standard conforming. .. Could you please help me and confirm my suspicions? (i.e., a compiler related issue) How can it be more elegantly work-arounded? ..

Yes, this one also appears to be an issue in Intel Fortran.

Again, you ask, "How can it be more elegantly work-arounded?"  Simply as a workaround just until the compiler is fixed, the code snippet you show in test2 can be made to function as shown below; not much elegant!

program test

   use AB_class, only : A_t, B_t
   use C1_class, only : C1_t

   implicit none

   type(B_t) :: B
   class(A_t), target, allocatable :: C1

   allocate( C1_t :: C1 )
   B = C1

   call B%output_A()
   select type ( C1 )
      class is ( C1_t ) 
         call C1%output_C()
      class default
   end select

   deallocate( C1 )

   stop

end program test
 A_C1_t
 C_C1_t
Press any key to continue . . .

 

0 Kudos
Kevin_D_Intel
Employee
598 Views

@Alberto, Thank you for the test cases. We'll look at these. As FortranFan wrote, these are likely compiler defects and likely have been reported earlier so we'll update you on any existing internal tracking ids or new ids if needed.

@FortranFan, Thank you for investigating and the work around.

0 Kudos
Reply