PROTECTED variable type-bound procedure with passed INOUT argument called from outside.

[Daniel_Dopico]

The following code works in Intel One Api but it does not compile in gFortran, due to the PROTECTED attribute which is supposed to prevent the modification of variables from outside the module. Apparently Intel Fortran is not properly considering the case in which this modification is done through a type-bound procedure with PASS and intent (INOUT) argument.

According to me, the right behavior is gFortran's and the code should not compile either in Intel Fortran. 

What do you think?

! Module containing the derived type variable.
MODULE constantes
    IMPLICIT NONE

    
    TYPE tform
        INTEGER::n=0
        CONTAINS
        PROCEDURE,PASS::INCn
    END TYPE tform

    TYPE(tform),PROTECTED::form

    PRIVATE INCn

CONTAINS
    !> Type bound function with attribute INOUT for the passing argument.
    SUBROUTINE INCn(fSW)
        
        CLASS(tform),INTENT(INOUT)::fSW
        INTEGER::nombre
    
        fSW%n=fSW%n+1
    END SUBROUTINE INCn
END MODULE constantes    
    
! Program calling the type bound in form.
PROGRAM use_form
    USE constantes
    IMPLICIT NONE

    PRINT *,'The value of n is initially ',form%n
    !form%n=form%n+1    !This line does not compile, because of the PROTECED attribute of form
    CALL form%INCn()    !This line works in Intel Fortran despite of the PROTECTED attribute but not in gFortran.
    PRINT *,'The value of n is now ',form%n
    
END PROGRAM use_form

[FortranFan]

For whatever it's worth, I agree - Intel Fortran does not conform in this case.

[Ron_Green]

I'm going to ask our Standards people to look at this one.  

My initial reaction is that the modification of %n is within the defining module.  Which to me seems valid.

In OOD this looks like an accessor function for the object.  Maybe I am missing some nuance or restriction due to intent(inout) and/or class(tform) but from my cursory reading of the Standard this seems valid to me.  And it seems like a valid accessor to the object to safely increment n without direct user modification. Am I missing something?

[IanH]

The modification of `form` (i.e. its appearance in a variable definition context) is not within the defining module.  A variable definition context covers the variable being used as an actual argument corresponding to an INTENT(INOUT) dummy.  The compiler should diagnose.

It would be permitted if the referenced procedure did not take the protected object as an argument (e.g. if `INCn` was NOPASS, and within its body just worked directly with `form`, rather than via a dummy argument).

[Ron_Green]

Thanks Ian.  Your explanation makes perfect sense.  I'll ask Barbara to open a bug report on this case.

[Daniel_Dopico]

Thank you @Ron_Green and @IanH for the interesting discussion. I tried to put myself a ticket yesterday (05882979) on this matter but I think I made some mistake because I don't see the attachment. If you open one I can close mine.

Thanks.

[Barbara_P_Intel]

@Daniel_Dopico, I saw your ticket and read that you want to close it. I did.

I lost the virtual coin toss with @Ron_Green (that pirate), bug id CMPLRLLVM-48691.

Is this the output you expect? Just as a sanity check.

+ ifx -what use_form.f90
 Intel(R) Fortran 24.0-1046
+ a.out
 The value of n is initially            0
 The value of n is now            1

[Daniel_Dopico]

Thank you @Barbara_P_Intel . I requested to close it because I think I had not included either the code or the link to this post so the ticket was useless.

The ticketing system changed since my last one and I am not particularly familiar with the new one.

[Devorah_H_Intel]

The fix for this issue will be included in the 2025.1 ifx release.