Default structure constructor vs. type-bound overloaded assignment

Default structure constructor vs. type-bound overloaded assignment

Portrait de _helvio_


I am experiencing compilation errors in my code due to a conflict between overloaded assignments and structure constructors. I can easily solve the problem, but I'd still like to know if I'm abusing the Fortran 2003 language or not in the following toy code:

MODULE matrices IMPLICIT NONE PRIVATE PUBLIC :: oldmatrix TYPE :: oldmatrix COMPLEX :: a(2,2) CONTAINS PRIVATE PROCEDURE, PASS :: eq_mat GENERIC, PUBLIC :: ASSIGNMENT(=) => eq_mat END TYPE oldmatrix INTERFACE oldmatrix MODULE PROCEDURE ctor_mat END INTERFACE oldmatrix CONTAINS PURE ELEMENTAL FUNCTION ctor_mat RESULT(u) REAL, INTENT(in) :: r TYPE(oldmatrix) :: u INTEGER :: i u%a = CMPLX(0.,0.) DO i=1,2 u%a(i,i) = r END DO END FUNCTION ctor_mat PURE ELEMENTAL SUBROUTINE eq_mat(v, u) CLASS(oldmatrix), INTENT(out) :: v TYPE(oldmatrix), INTENT(in) :: u v%a = u%a END SUBROUTINE eq_mat END MODULE matrices PROGRAM test USE matrices IMPLICIT NONE TYPE, EXTENDS(oldmatrix) :: newmatrix END TYPE newmatrix TYPE(oldmatrix) :: x TYPE(newmatrix) :: y COMPLEX, PARAMETER :: unit(2,2) =  #if _OPTION == 1 y = oldmatrix(unit) #elif _OPTION == 2 x = oldmatrix(unit) y = x #elif _OPTION == 3 y = oldmatrix(1.) #endif PRINT *, y END PROGRAM test 

The module provides the derived type "oldmatrix", a type-bound assignment (that allows me to assign objects of parent type "oldmatrix" to an object of an extended/child type), and an user-defined structure constructor. In the program I extend the parent type "oldmatrix" trivially to the child type "newmatrix". Then, I try to assign an "oldmatrix" object to the "newmatrix" object "y": In _OPTION=1, I use the default structure constructor of "oldmatrix" for this purpose; in _OPTION=2, I use an auxiliary "oldmatrix" object "x" before assigning it to "y"; in _OPTION=3, I use the user-defined structure constructor.

I am using the latest ifort to compile the code. If I compile it with

ifort test.f90 -c -fpp -D_OPTION=1

then I get a catastrophic error:

0_1670test.f90(56): catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.compilation aborted for test.f90 (code 1)

If I compile it with -D_OPTION=2 or -D_OPTION=3, then it compiles, builds, and runs successfully.
It looks to me as if the default constructor for "oldmatrix" and the type-bound overloaded assignment are not working in harmony with each other, because there are no problems with the user-defined structure contructor, nor if I use an auxiliary "oldmatrix" object to do the assignment step-by-step.
It compiles and builds successfully with both PGI and GNU compilers. Is this an issue of the Intel compiler, or am I abusing the Fortran 2003 language by trying to use the default structure constructor and an overloaded assignment in the same statement?

5 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

This is a bug in Intel Fortran Composer XE. I have escalated it to the developers as issue # DPD200235283. I will post any updates on this issue to this thread.

Interestingly, the Internal Compiler Error goes away if r in line 23 is changed to a complex variable.

Portrait de _helvio_

Quoting Annalee (Intel)

Interestingly, the Internal Compiler Error goes away if r in line 23 is changed to a complex variable.

Thank you Annalee,I decided to give an example of a structure constructor with a REAL dummy argument because I thought that if it was COMPLEX, the default structure constructor could override the user-defined one. But if the error goes away in this case, that's indeed interesting.

A fix has been found for this issue. We are planning to include it in an update which is currently scheduled for Late January 2013.

Hello Helvio,

This is issue has been fixed in Intel® Fortran Composer XE for Linux* 2013 Update 3 which is now available at the Intel® Registration Center.


Connectez-vous pour laisser un commentaire.