- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Should this code work?
Intel One API and Parallel Studio throw an "The type of the actual argument differs from the type of the dummy argument. [T]" error but gFortran compiles the code ONLY if the "intent(IN)" attribute is present (I assume that in order to prevent for reassigning the POINTER to a different type inside the function).
MODULE mod_1
TYPE,ABSTRACT:: abstract_type
INTEGER:: i
CONTAINS
END TYPE abstract_type
TYPE,EXTENDS(abstract_type):: extended_type
INTEGER:: j
CONTAINS
END TYPE extended_type
CONTAINS
SUBROUTINE f2(t)
CLASS(abstract_type),POINTER,intent(in)::t
PRINT*,"f2 executed"
END SUBROUTINE f2
END MODULE mod_1
! Main program
PROGRAM MAIN
USE mod_1
IMPLICIT NONE
class(extended_type),POINTER::t
CALL f2(t)
END PROGRAM MAIN
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nagfor says:
Error: class_bug.f90, line 21: Incorrect data type EXTENDED_TYPE (expected ABSTRACT_TYPE) for argument T (no. 1) of F2
The issue is that dummy argument T is a pointer. The F2018 standard says (emphasis mine):
"The actual argument shall be polymorphic if and only if the associated dummy argument is polymorphic, and either both the actual and dummy arguments shall be unlimited polymorphic, or the declared type of the actual argument shall be the same as the declared type of the dummy argument."
If it weren't a pointer, then the rule is different:
"The dummy argument shall be type compatible with the actual argument."
and this case would be allowed.
As for INTENT(IN), that is required when the actual argument is not a pointer. If gfortran compiles the code as shown here, it has a bug.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Daniel_Dopico wrote:Should this code work?
..
No, it should not. You also have a comment back as to why.
But note, Fortran is "funny that way"!!
You have made the attention to the "intent(in)" attribute go with the pointer . If that is intended and part of a well-thought plan for a "library" API which can be your "f2" subroutine, then you may want to also make a separate note about the "automatic targeting" facility in the Fortran standard that permits you the following. I expect NAG Fortran to support this version and not throw an error.
MODULE mod_1
TYPE,ABSTRACT:: abstract_type
INTEGER:: i = 0
CONTAINS
END TYPE abstract_type
TYPE,EXTENDS(abstract_type):: extended_type
INTEGER:: j = 0
CONTAINS
END TYPE extended_type
CONTAINS
SUBROUTINE f2(t)
CLASS(abstract_type),POINTER,intent(in)::t
PRINT*,"In f2: t%i = ", t%i
END SUBROUTINE f2
END MODULE mod_1
! Main program
PROGRAM MAIN
USE mod_1
IMPLICIT NONE
class(extended_type), allocatable, target :: t
allocate( t ) ; t%i = 42
CALL f2(t)
END PROGRAM MAIN
gfortran does as I expect:
C:\temp>gfortran -ffree-form p.f -o p.exe
C:\temp>p.exe
In f2: t%i = 42
But Intel Fortran raises the same error as in your original post and it's now a compiler issue which Intel Support team can follow up with the Intel Fortran team.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@FortranFan , please read my reply above yours. Your new example is not valid - I quoted the relevant text in the standard. It's gfortran that has the bug, in my opinion.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Try the "new example" I posted as-is with NAG Fortran and post the response, I expect NAG Fortran to not complain of anything and accept it as valid.
The actual argument in this "new example" is not a pointer and "automatic targeting" facility in the standard is brought into effect. The verbiage in the standard then effectively permits the declared type of the actual argument to be an extended type of the declared type of the dummy argument.
This might actually be a use case of interest to OP, in that some (or many) consumers of the equivalent of "f2" in actual code(s) can really do well by not having to employ pointers whilst working with polymorphic objects whose declared type is not abstract.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks - you're correct, and I missed an important point.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, @FortranFan, for the reproducer. I filed a bug report for your example, CMPLRLLVM-56838.
It does compile and run with NAG.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you @Barbara_P_Intel. If I got it right I don't need to put any ticket with my original code, since the behaviour is correct, right?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Barbara_P_Intel wrote:Thanks, @FortranFan, for the reproducer. I filed a bug report for your example, CMPLRLLVM-56838.
It does compile and run with NAG.
Thanks, that will be a good update for the customers of Intel Fortran compiler when implemented, if the Intel Fortran team agrees to the fix in response to your report.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you Steve and FortranFan for the discussion, you guys are great!
Fortran Fan, great that you end up with a real bug from my code with that changes.

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