Problem with pointer to extended type?

[Daniel_Dopico]

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

[Steve_Lionel]

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.

[FortranFan]

---

@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.

[Steve_Lionel]

@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.

[FortranFan]

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.

[Steve_Lionel]

Thanks - you're correct, and I missed an important point.

[Barbara_P_Intel]

Thanks, @FortranFan, for the reproducer. I filed a bug report for your example, CMPLRLLVM-56838.

It does compile and run with NAG.

[Daniel_Dopico]

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?

[Barbara_P_Intel]

@Daniel_Dopico, that is my understanding.

[FortranFan]

---

@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.

[Daniel_Dopico]

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.