application of an elemental function to assumed-rank array

[Aleksey_K_]

Hi folks, I wrote some really beautiful function to compare arrays of arbitrary rank using Intel ifort 19.3. The code below compiles and runs perfectly: it gives right results for whatever integer arrays I throw into the function. However I could not find any reference that it is (current or any future) Fortran standard conforming. PURE LOGICAL FUNCTION array_is_equal(arr1,arr2) RESULT(is_equal) INTEGER, DIMENSION(..), INTENT(in) :: arr1 INTEGER, DIMENSION(..), INTENT(in) :: arr2 is_equal = .FALSE. IF (rank(arr1)==rank(arr2)) THEN IF (all(shape(arr1)==shape(arr2))) THEN is_equal = all(is_equal_val(arr1,arr2)) END IF END IF CONTAINS ELEMENTAL LOGICAL FUNCTION is_equal_val(v1,v2) INTEGER, INTENT(in) :: v1 !< First value. INTEGER, INTENT(in) :: v2 !< Second value. is_equal_val = v1==v2 END FUNCTION is_equal_val END FUNCTION array_is_equal The code uses so-called assumed-rank array so that the function can receive arrays of any rank for comparison. All I could find out is that an intrinsic inquiry function can be used with an assumed-rank array, nothing about a possibility to apply an elemental function element-wise to such an array. Therefore I wonder if it is a bug or a feature in Ifort 19.3. I really enjoy this code working correctly and hope a lot that it is a feature. It would be really sad if this function would stop working with some future release of Intel Fortran due to some fixed incompatibility with the standard. I would like to know if the function above conforms with some Fortran standard so that I can confidently use it in production code. --Aleksey

[jimdempseyatthecove]

Aleksey,

I think your example in #21 would require the REDUCTION clause.

This said, I do not see how this would implicitly abort evaluation by all threads...
... as well as why it would not permit early abort.

The generated code for early abort as well as not would differ slightly. Note, while EXIT may not be permitted, CYCLE is permitted

result = .true.
!$omp parallel do
  if(.not. result) cycle ! quickly reach end of iteration without further reads
  if(a1(i) .ne. a2(i)) result = .false. ! do not use result =((a1(i) .eq. a2(i))
end do 

The parallel workshare construct could be optimized to perform the equivalent code (vectorized). This is not saying that it currently does, but saying that it could. FWIW, I do not see why EXIT is not permitted for a loop like above. Can someone explain this?

Also, "result =((a1(i) .eq. a2(i))" format would produce unnecessary writes.

Jim Dempsey