Hi,
I am trying to modernize the CMake logic of ECP AMReX and ECP WarpX away from hipcc to the recommended CMake logic (due to limitations of the hipcc perl script).
Following the guidance in the docs, I link the hip::device target in my projects.
It seems the flags it sets are unfortunately not limited to the C/C++ language but also apply to the Fortran objects in our project (e.g. Fortran bindings). While this worked through hipcc, the hip::device target thus fails to compile.
An alternative approach to use the shipped flang executable for Fortran bindings is not recognized as compiler by the shipped CMake version. Generally, flang is not yet at the quality level (code gen.) of other Fortran compilers and should thus not be enforced (for host-only parts of a CMake project).
I think what probably needs to be done is to limit the compiler & linker flags of the hip::device object to C/C++ objects with generator expressions.
Xref: likely fix in #2190 is approved but unmerged since Nov 2020
Xref: partly related to #2158
Xref: comment #2158 (comment)
Xref: comment #2154 (comment)
Hi,
I am trying to modernize the CMake logic of ECP AMReX and ECP WarpX away from
hipccto the recommended CMake logic (due to limitations of thehipccperl script).Following the guidance in the docs, I link the
hip::devicetarget in my projects.It seems the flags it sets are unfortunately not limited to the C/C++ language but also apply to the
Fortranobjects in our project (e.g. Fortran bindings). While this worked throughhipcc, thehip::devicetarget thus fails to compile.An alternative approach to use the shipped
flangexecutable for Fortran bindings is not recognized as compiler by the shipped CMake version. Generally,flangis not yet at the quality level (code gen.) of other Fortran compilers and should thus not be enforced (for host-only parts of a CMake project).I think what probably needs to be done is to limit the compiler & linker flags of the
hip::deviceobject to C/C++ objects with generator expressions.Xref: likely fix in #2190 is approved but unmerged since Nov 2020
Xref: partly related to #2158
Xref: comment #2158 (comment)
Xref: comment #2154 (comment)