Problem with -recursive -assume realloc_lhs -standard-semantics

[MR]

I see different results for the attached code depending on the used compiler flags. Notice that the code uses a recursive elemental subroutine, which I understand is allowed in f2015, but not allowed by the previous standards, hence the compiler flag -recursive .

Apart from -recursive, I think the code should work without depending on other compiler flags.

The expected result is printing -2 10.

$ ifort -recursive ifb.f90 -o ifb
$ ./ifb
[nothing is printed]
$ ifort -recursive -assume realloc_lhs  ifb.f90 -o ifb
$ ./ifb
          -2          10  [the correct result]
$ ifort -recursive -assume realloc_lhs -standard-semantics ifb.f90 -o ifb
$ ./ifb
 1986356271 1937010735  [arbitrary values]

I am using ifort Version 15.0 Build 20150407.

module m1

! Define an abstract type, a container and the corresponding assignment 

 implicit none
 
 type, abstract :: a_abs
 end type a_abs

 type, extends(a_abs) :: t_cnt
  class(a_abs), allocatable :: f
 end type t_cnt

 interface assignment(=)
   module procedure to_cnt
 end interface

contains

 elemental subroutine to_cnt(y,x)
  class(a_abs), intent(in)  :: x
  type(t_cnt), intent(out) :: y

   select type(x)
    type is(t_cnt)
     y = x%f ! equivalent to "call to_cnt( y , x%f )"
    class default
     allocate( y%f , source=x )
   end select

 end subroutine to_cnt

end module m1

!------------------------

module m2

! Define a specific type and an operation
 
 use m1, only: a_abs

 implicit none

 type, extends(a_abs) :: t_a
  integer, allocatable :: i(:)
 end type t_a

contains

 elemental function add(x,y) result(z)
  class(t_a), intent(in) :: x, y
  type(t_a) :: z

   z%i = x%i + y%i

 end function add
 
end module m2

!------------------------

program p
 use m1
 use m2
 implicit none

 type(t_a) :: a, b
 type(t_cnt) :: cnt

 allocate( a%i(2) , b%i(2) )
 a%i = (/  0 , 6 /)
 b%i = (/ -2 , 4 /)

 cnt = add( a , b )

 select type( f => cnt%f )
  type is(t_a)
   write(*,*) f%i
  class default
   write(*,*) "class default"
 end select

end program p

[Steven_L_Intel1]

The first result is understandable. The last is not, but curiously it reproduces for me only on Linux, not Windows. Very interesting. I found that if you add -assume noprotect_parens, you get the correct result. (This is one of the things that -standard-semantics turns on.) Escalated as DPD200374568.

[TimP]

With -stand set, ifort 16.0 rejects "recursive elemental subroutine"

-recursive doesn't appear to make a difference.

-Qprotect-parens doesn't pose a problem, although assume:protect_parens does produce run-time failure.

[MR]

Steve Lionel (Intel) wrote:

The first result is understandable. The last is not [...]

Steve, thank you. Concerning the first result however, I don't see why -assume realloc_lhs should make a difference, since all the allocations should take place in the source allocation.

[MR]

Tim Prince wrote:

With -stand set, ifort 16.0 rejects "recursive elemental subroutine"

-recursive doesn't appear to make a difference.

OK, I assume that whatever choice in terms of extensions is fine; still it would be nice to be able to override some settings of -stand with an additional, more specific option like -recursive ...

[Steven_L_Intel1]

You need -assume realloc_lhs (or -standard-semantics which includes it) because your assignment to z%i depends on it. 

Eventually we will support the F2015 relaxed restriction on RECURSIVE ELEMENTAL.

[MR]

Steve Lionel (Intel) wrote:

You need -assume realloc_lhs (or -standard-semantics which includes it) because your assignment to z%i depends on it. 

Eventually we will support the F2015 relaxed restriction on RECURSIVE ELEMENTAL.

Oh, yes, sorry, I added the two allocations in the main program and forgot this one; adding allocate(z%i(size(x%i))) removes the need for realloc_lhs, so the problem here is completely independent from -assume realloc_lhs .

Marco