Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

merge statement for scalars

Diehl__Martin
Novice
733 Views

Hi,

I found the merge statement as a ternary operator quite useful even when using it outside of its original scope of array assignments. One pitfall I've realized is the fact that even the code that is in the "false-branch" might be evaluated (similar to the Boolean operations in Fortran which are not short circuited). I'm however not sure about the following code, which I find quite useful for setting default arguments

program test
  implicit none
  real, parameter :: a = 5.0
  real            :: x
  real, dimension(:), allocatable :: y

  ! this is invalid, even if I ensure that y(1) exists in case that y is allocated
  ! because y(1) might be evaluated in the case that y is not allocated
  x = merge(y(1),a,allocated(y))

  call hello(a)
  call hello()

contains

subroutine hello(b)
 implicit none
 real, intent(in), optional :: b
 real                       :: c
 
 ! what about this?
 c = merge(b,4.0,present(b))
 write(6,*) c

end subroutine hello


end program

 

0 Kudos
1 Solution
Steve_Lionel
Honored Contributor III
733 Views

There has been some discussion as to whether the standard should say that MERGE doesn't evaluate the false expression, but it currently doesn't say that, and the general language words about "any degree of completeness" apply. There is no short-circuiting in Fortran, though there are proposals for the next revision.

View solution in original post

0 Kudos
3 Replies
Diehl__Martin
Novice
733 Views

I figured out that the PGI compiler will fail with a segmentation fault in this case, so I need not use

if (present(b)) then
  c =  b
else
  c = 4.0
endif

 

0 Kudos
Steve_Lionel
Honored Contributor III
734 Views

There has been some discussion as to whether the standard should say that MERGE doesn't evaluate the false expression, but it currently doesn't say that, and the general language words about "any degree of completeness" apply. There is no short-circuiting in Fortran, though there are proposals for the next revision.

0 Kudos
TimP
Honored Contributor III
733 Views

ifort with normal options will evaluate IF body speculatively when this will facilitate optimization. So it may not make a difference to ifort whether you choose MERGE; the choice could be made according to readability. Documented/supported ifort options to control speculative evaluation presumably apply equally to IF and MERGE. gfortran depends more on MERGE for such optimization. This is a tradition going back to early Cray platforms. Speculative evaluation of a scalar expression may well be required for vectorization of a loop. Under MERGE it looks more evident that the programmer may be intending to facilitate such optimization. Customers using PGI in my experience have been leary of any Fortran syntax of the last 2 decades. A small vendor may have to set priorities about which syntax is optimized and gets severe testing. Priorities of specific customers may have visible influence. I hope I can avoid appearing derogatory; it's actually a strength of Fortran that multiple vendors support it with compilers having various strengths. I spent a lot of time comparing ifort and pgf90 optimization of customer applications and even discussing with customers how reliable the optimizations were with various compilers.

0 Kudos
Reply