[OpenMP] Add Fortran support for omp_* functions needing adapters

[ro-i]

Taking omp_get_uid_from_device and omp_get_device_from_uid as examples.

OpenMP 6.0 defines these functions as follows:

const char *omp_get_uid_from_device(int device_num);

character(:) function omp_get_uid_from_device(device_num)
  pointer :: omp_get_uid_from_device
  integer, intent(in) :: device_num

and

int omp_get_device_from_uid(const char *uid);

integer function omp_get_device_from_uid(uid)
  character(len=*), intent(in) :: uid

As a result, we cannot directly map the Fortran API declarations to the C API declarations. We need some adapter code to do the conversion.

However, this means that we cannot just define the two functions as omp_* in kmp_ftn_entry.h without clashing with the adapter code.

The current situation is less than ideal, as demonstrated by this draft PR, which shall serve as a base for discussing different solution approaches.

---

@mjklemm as discussed

[Meinersbur]

I would suggest to build on top of #169638 and only support LLVM_ENABLE_RUNTIMES build mode to avoid fixing the many differences between the build modes. For instance, the difference between LIBOMP_FORTRAN_MODULES_COMPILER and CMAKE_Fortran_COMPILER. With only LIBOMP_FORTRAN_MODULES_COMPILER set, like a bootstrapping build currently does, you cannot use target_sources(omp kmp_ftn_support.f90), because CMake does not know a Fortran compiler. Also, with openmp and flang-rt built in the same runtimes-bin, the tight libflang_rt.runtime.a to use is just target_link_libraries(omp flang_rt.runtime)

AFAIK, RTLD_NEXT depend on link order, making this a very fragile solution. Why is it needed anyway, given that the Fortran code already has a wrapper to __kmp_get_uid_from_device_?

[Meinersbur]

IIUC this just takes the first libflang_rt.runtime.a. This will likely if compiling more than one flang_rt for another target, or of building libflang_rt.runtime.so instead.