merge statement for scalars

[Diehl__Martin]

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

[Diehl__Martin]

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

[Steve_Lionel · Accepted solution]

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.

[TimP]

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.