Community
cancel
Showing results for 
Search instead for 
Did you mean: 
OP1
Novice
113 Views

Potential CLASS/TYPE bug

Jump to solution

In the following code, using TYPE on line 42 instead of CLASS (as on line 38) is accepted by the compiler and yields a different (incorrect) output.

I am not sure if:

  • Should using TYPE instead of CLASS be accepted by the compiler? Isn't there an interface violation here?
  • Is the garbage output to be expected when using TYPE?

Thanks for taking a look!

MODULE MY_MODULE
IMPLICIT NONE
TYPE MY_TYPE
    PROCEDURE(USER_PROCEDURE_INTERFACE),POINTER :: USER_PROCEDURE
    INTEGER,ALLOCATABLE :: SOME_ARRAY(:)
    CONTAINS
        PROCEDURE :: INITIALIZE => MY_TYPE_INITIALIZE
END TYPE MY_TYPE
ABSTRACT INTERFACE
    SUBROUTINE USER_PROCEDURE_INTERFACE(SELF)
    IMPORT :: MY_TYPE
    IMPLICIT NONE
    CLASS(MY_TYPE),INTENT(INOUT) :: SELF
    END SUBROUTINE USER_PROCEDURE_INTERFACE
END INTERFACE
CONTAINS
    SUBROUTINE MY_TYPE_INITIALIZE(SELF,USER_PROCEDURE)
    IMPLICIT NONE
    CLASS(MY_TYPE),INTENT(INOUT) :: SELF
    PROCEDURE(USER_PROCEDURE_INTERFACE) :: USER_PROCEDURE
    SELF%USER_PROCEDURE => USER_PROCEDURE
    IF (ALLOCATED(SELF%SOME_ARRAY)) DEALLOCATE(SELF%SOME_ARRAY)
    ALLOCATE(SELF%SOME_ARRAY(5))
    END SUBROUTINE MY_TYPE_INITIALIZE
END MODULE MY_MODULE


PROGRAM MY_PROGRAM
USE MY_MODULE
IMPLICIT NONE
TYPE(MY_TYPE) :: MY_OBJECT
CALL MY_OBJECT%INITIALIZE(PROCEDURE_1)
CALL MY_OBJECT%USER_PROCEDURE ! This will produce the correct output
CALL MY_OBJECT%INITIALIZE(PROCEDURE_2)
CALL MY_OBJECT%USER_PROCEDURE ! This will produce a random number
CONTAINS
    SUBROUTINE PROCEDURE_1(SELF)
        CLASS(MY_TYPE),INTENT(INOUT) :: SELF
        WRITE(*,*) SIZE(SELF%SOME_ARRAY)
    END SUBROUTINE PROCEDURE_1
    SUBROUTINE PROCEDURE_2(SELF)
        TYPE(MY_TYPE),INTENT(INOUT) :: SELF ! Is the use of TYPE acceptable?
        WRITE(*,*) SIZE(SELF%SOME_ARRAY)
    END SUBROUTINE PROCEDURE_2
END PROGRAM MY_PROGRAM

 

0 Kudos

Accepted Solutions
Steve_Lionel
Black Belt Retired Employee
95 Views

This is a compiler bug. The error is that the line:

 

CALL MY_OBJECT%INITIALIZE(PROCEDURE_2)

 

should be rejected.

15.5.2.9 Actual arguments associated with dummy procedure entities
 1 If the interface of a dummy procedure is explicit, its characteristics as a procedure (15.3.1) shall be the same as those of its effective argument, except that a pure effective argument may be associated with a dummy argument that is not pure and an elemental intrinsic actual procedure may be associated with a dummy procedure (which cannot be elemental).

15.3.1 Characteristics of procedures
1 The characteristics of a procedure are the classification of the procedure as a function or subroutine, whether it is pure, whether it is elemental, whether it has the BIND attribute, the characteristics of its dummy arguments,  and the characteristics of its function result if it is a function.

15.3.2.2 Characteristics of dummy data objects
1 The characteristics of a dummy data object are its declared type, its type parameters, its shape (unless it is assumed-rank), its corank, its codimensions, its intent (8.5.10, 8.6.9), whether it is optional (8.5.12, 8.6.10), whether it is allocatable (8.5.3), whether it has the ASYNCHRONOUS (8.5.4), CONTIGUOUS (8.5.7), VALUE (8.5.18), or VOLATILE (8.5.19) attributes, whether it is polymorphic, and whether it is a pointer (8.5.14, 8.6.12) or a target (8.5.17, 8.6.15). If a type parameter of an object or a bound of an array is not a constant expression, the exact dependence on the entities in the expression is a characteristic. If a rank, shape, size, type, or type parameter is assumed or deferred, it is a characteristic.

So... The characteristics of PROCEDURE_2 are NOT the same as that of the explicit interface of the procedure dummy, because one has a polymorphic dummy and one does not.

The NAG compiler complains:

 

Error: Console4.f90(34): Dummy proc USER_PROCEDURE arg 1 is polymorphic, actual proc PROCEDURE_2 arg is not
Error: Console4.f90(34): Incompatible procedure argument for USER_PROCEDURE (no. 2) of MY_OBJECT%INITIALIZE

 

Please report this bug to Intel using the Online Service Center if you can.

View solution in original post

4 Replies
OP1
Novice
107 Views

For some reason I can't edit my post... this reproducer was compiled with Intel compiler 19.1 Update 3 on Windows 10.

Tags (1)
Steve_Lionel
Black Belt Retired Employee
96 Views

This is a compiler bug. The error is that the line:

 

CALL MY_OBJECT%INITIALIZE(PROCEDURE_2)

 

should be rejected.

15.5.2.9 Actual arguments associated with dummy procedure entities
 1 If the interface of a dummy procedure is explicit, its characteristics as a procedure (15.3.1) shall be the same as those of its effective argument, except that a pure effective argument may be associated with a dummy argument that is not pure and an elemental intrinsic actual procedure may be associated with a dummy procedure (which cannot be elemental).

15.3.1 Characteristics of procedures
1 The characteristics of a procedure are the classification of the procedure as a function or subroutine, whether it is pure, whether it is elemental, whether it has the BIND attribute, the characteristics of its dummy arguments,  and the characteristics of its function result if it is a function.

15.3.2.2 Characteristics of dummy data objects
1 The characteristics of a dummy data object are its declared type, its type parameters, its shape (unless it is assumed-rank), its corank, its codimensions, its intent (8.5.10, 8.6.9), whether it is optional (8.5.12, 8.6.10), whether it is allocatable (8.5.3), whether it has the ASYNCHRONOUS (8.5.4), CONTIGUOUS (8.5.7), VALUE (8.5.18), or VOLATILE (8.5.19) attributes, whether it is polymorphic, and whether it is a pointer (8.5.14, 8.6.12) or a target (8.5.17, 8.6.15). If a type parameter of an object or a bound of an array is not a constant expression, the exact dependence on the entities in the expression is a characteristic. If a rank, shape, size, type, or type parameter is assumed or deferred, it is a characteristic.

So... The characteristics of PROCEDURE_2 are NOT the same as that of the explicit interface of the procedure dummy, because one has a polymorphic dummy and one does not.

The NAG compiler complains:

 

Error: Console4.f90(34): Dummy proc USER_PROCEDURE arg 1 is polymorphic, actual proc PROCEDURE_2 arg is not
Error: Console4.f90(34): Incompatible procedure argument for USER_PROCEDURE (no. 2) of MY_OBJECT%INITIALIZE

 

Please report this bug to Intel using the Online Service Center if you can.

View solution in original post

OP1
Novice
68 Views

Thanks Steve - I also suspected it was a bug, but since polymorphism can sometimes get tricky I was not 100% sure. I just reported this to the Intel support team.

Tags (1)
Alina_S_Intel
Employee
51 Views

@OP1 , thank you for reporting this issue! I have escalated it to the development team (CMPLRLLVM-25742).  Please, track the progress in Online Service Center. I'll let you know as soon as the fix is available.

@Steve_Lionel , thank you for the detailed analysis.