- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For some reason I can't edit my post... this reproducer was compiled with Intel compiler 19.1 Update 3 on Windows 10.
- Tags:
- some
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- Thank
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page