Propagate acc link flags

[awnawab]

ecWAM did not propagate OpenACC flags to the executable. This was previously masked by the fact that ifs-source would always compile with OpenACC for nvhpc builds. Once I fixed that bug, it exposed the ecWAM bug that this PR fixes.

[reuterbal]

I can confirm that this works correctly in an IFS build now

[wdeconinck]

This is only required for NVHPC compiler I believe.
Also this would not work in all situations, when e.g. a C++ executable (OOPS) gets linked with ecwam by CrayClang compilers where the Cray C++ compiler is not supporting this flags. A non-issue when we only add this flag for NVHPC.

I propose following:

if( HAVE_ACC AND CMAKE_Fortran_COMPILER_ID MATCHES NVHPC )
  set( ACC_LINK_OPTIONS ${OpenACC_Fortran_FLAGS} ) # for marking intent
  target_link_options(${ecwam} INTERFACE
      $<$<LINK_LANG_AND_ID:C,NVHPC>:SHELL:${ACC_LINK_OPTIONS}>
      $<$<LINK_LANG_AND_ID:CXX,NVHPC>:SHELL:${ACC_LINK_OPTIONS}>
      $<$<LINK_LANG_AND_ID:Fortran,NVHPC>:SHELL:${ACC_LINK_OPTIONS}>
      $<$<LINK_LANG_AND_ID:CUDA,NVIDIA>:SHELL:${ACC_LINK_OPTIONS}> )
endif()

Possibly we could make this proposed ACC_LINK_OPTIONS a cache variable to allow adaptation via toolchain file, but that can be done at later time if that seems necessary.

[awnawab]

This is only required for NVHPC compiler I believe. Also this would not work in all situations, when e.g. a C++ executable (OOPS) gets linked with ecwam by CrayClang compilers where the Cray C++ compiler is not supporting this flags. A non-issue when we only add this flag for NVHPC.

I propose following:

if( HAVE_ACC AND CMAKE_Fortran_COMPILER_ID MATCHES NVHPC )
  set( ACC_LINK_OPTIONS ${OpenACC_Fortran_FLAGS} ) # for marking intent
  target_link_options(${ecwam} INTERFACE
      $<$<LINK_LANG_AND_ID:C,NVHPC>:SHELL:${ACC_LINK_OPTIONS}>
      $<$<LINK_LANG_AND_ID:CXX,NVHPC>:SHELL:${ACC_LINK_OPTIONS}>
      $<$<LINK_LANG_AND_ID:Fortran,NVHPC>:SHELL:${ACC_LINK_OPTIONS}>
      $<$<LINK_LANG_AND_ID:CUDA,NVIDIA>:SHELL:${ACC_LINK_OPTIONS}> )
endif()

Possibly we could make this proposed ACC_LINK_OPTIONS a cache variable to allow adaptation via toolchain file, but that can be done at later time if that seems necessary.

It is very likely I am missing something, but if we are always setting the same link flags for all the language and compiler ID combinations, do we gain something over simply setting target_link_options(${ecwam} INTERFACE SHELL:${ACC_LINK_OPTIONS})?

[wdeconinck]

Right, if we guard with if( HAVE_ACC AND CMAKE_Fortran_COMPILER_ID MATCHES NVHPC ) and the C/C++ compiler are also NVHPC or NVIDIA then there's no reason for the generator expressions.

[wdeconinck]

Does this following line work for CrayFortran or GNU or ... ?

target_compile_options( ${ecwam} PRIVATE "-gpu=maxregcount:128" )

[awnawab]

Does this following line work for CrayFortran or GNU or ... ?

target_compile_options( ${ecwam} PRIVATE "-gpu=maxregcount:128" )

Great spot! This should also be guarded with compiler ID checks. As we test it on more compilers we can relax the compiler ID checks.

[wdeconinck]

As we test it on more compilers we can relax the compiler ID checks.

It probably would not work out of the box on any other compiler anyway, though one could be pleasantly surprised 🤗

[awnawab]

Thanks again for the feedback @reuterbal and @wdeconinck. Unless there are any additional outstanding corrections, could this please be merged?