Can the dummy argument of a PURE subroutine with INTENT(OUT) attribute be unlimited polymorphic?

[FortranFan]

The following code compiles with no errors or warnings with the latest Intel Fortran compiler 2015, update 2 even with -stand compiler option:

   pure subroutine foo(val)

      class(*), allocatable, intent(out) :: val

      allocate(val, source=0.0)

   end subroutine foo

but gfortran (GCC 5 development truck) throws an error:

    pure subroutine foo(val)
                          1
Error: INTENT(OUT) argument 'val' of pure procedure 'foo' at (1) may not be polymorphic

I fail to see anything in the standard about INTENT(OUT) and polymorphic dummy arguments and pure procedures.  Is gfortran misinterpreting the standard or is Intel Fortran incorrect to allow this?

Thanks,

[IanH]

This is a consequence of a change made with F2008 corrigendum one^H^H^Htwo.  The issue is that the compiler does not know at compile time whether a polymorphic object has a finalizer or the nature of such a finalizer, there is no requirement that a finalizer be pure, and hence you have the possibility with an INTENT(OUT) polymorphic argument that the pure procedure will have impure thoughts without the compiler being able to detect such thoughts.

[FortranFan]

I overlooked the corrigendum, thanks for pointing it out!  Is there a revised Fortran 2008 standards document that has been reconciled with the 3 corrigenda and contains the replaced (corrected) wordings?

[Steven_L_Intel1]

http://j3-fortran.org/doc/year/14/14-007r2.pdf has been updated through Corrigendum 2. There isn't one with Corrigendum 3. You could also reference http://j3-fortran.org/doc/year/15/15-007.pdf which is the current F2015 draft, but this might mislead you about F2008 changes.

[FortranFan]

Steve,

Thanks for the links.

Is this on the list for Intel compiler updates?  i.e., will a future release give a warning/error in such situations, especially if -stand option is in effect?

[FortranFan]

Steve Lionel (Intel) wrote:

..reference http://j3-fortran.org/doc/year/15/15-007.pdf which is the current F2015 draft, ..

Oh, I was looking for this - thanks for pointing it out.  By the way, it isn't possible to quickly figure out how Fortran 2015 (as of this draft) is different from Fortran 2008, is there?  I wish there were a section in these documents, perhaps as an annex (informative) toward the end, that would summarize what is new and what has changed since the final version of the previous standard. 

[Steven_L_Intel1]

The Introduction has a list of what has changed.

The issue in this thread comes from interpretation F08/0033 which was indeed in Corrigendum 1, not 2. We do implement all the corrigendum changes over time. I will make sure this is on our list.

[Fran-Martinez]

Do you kno if this has already been implemented in version 19.1? It does not seem to be the case but maybe I am using the wrong compiler options (/stand:f18 ?)

[Steve_Lionel]

It is not implemented in the oneAPI compiler, and isn't in 19.1 either. I no longer have access to the bug report database to be able to tell whether the developers have been alerted to this issue. I would hope that all of the F2008 corrigendum issues would have been noted.

[Barbara_P_Intel]

I filed a bug report on this, CMPLRIL0-33535. I'll let you know when it's fixed.

[Barbara_P_Intel]

Sorry for the late notice on this... it's fixed in theh 2021.3.0 compiler.