[OpenMP][cmake] ignore warning on unknown CUDA version

[kkwli0]

Summary

With CUDA 10.2 installed on the system, the compiler issues a warning about unknown CUDA version. The warning message makes the LIBOMP_HAVE_VERSION_SCRIPT_FLAG test returns false. As a result, building libomp fails.

/opt/rh/devtoolset-8/root/usr/lib/gcc/ppc64le-redhat-linux/8/../../../../bin/ld: ../../../../lib/libomp.so: version node not found for symbol omp_get_num_places_@@VERSION
/opt/rh/devtoolset-8/root/usr/lib/gcc/ppc64le-redhat-linux/8/../../../../bin/ld: failed to set dynamic section sizes: Bad value

This patch is to make the libomp_check_linker_flag function called in the LIBOMP_HAVE_VERSION_SCRIPT_FLAG test more tolerable with the warning message.

[jdoerfert]

I like this way better. I was hoping we could do it in our cmake only :)

Give others a day or so to comment before your commit but I'm fine with this.

[Hahnfeld]

In D75001#1887876, @jdoerfert wrote:

I like this way better. I was hoping we could do it in our cmake only :)

Give others a day or so to comment before your commit but I'm fine with this.

Well, that doesn't really work if openmp-commits is only subscribed on commit. That said, the solution is a bit ugly but I don't have an alternative right now.

Somewhat related, that means Clang issues a warning for every compilation should there be a "unsupported" CUDA version around, even if it's not used? @tra maybe we can only issue the warning if CUDA is going to be used?

[kkwli0]

Somewhat related, that means Clang issues a warning for every compilation should there be a "unsupported" CUDA version around, even if it's not used? @tra maybe we can only issue the warning if CUDA is going to be used?

Some related issues were discussed in D74571.

Another possible approach is to include C_FLAGS and CXX_FLAGS in the test. Users configure the cmake with -DCMAKE_CXX_FLAGS=-Wno-unknown-cuda-version -DCMAKE_C_FLAGS=-Wno-unknown-cuda-version to get around the issues. So I think this approach can avoid any similar issue blocking the libomp build in the feature.

[tra]

In D75001#1891284, @Hahnfeld wrote:

In D75001#1887876, @jdoerfert wrote:

I like this way better. I was hoping we could do it in our cmake only :)

Give others a day or so to comment before your commit but I'm fine with this.

Well, that doesn't really work if openmp-commits is only subscribed on commit. That said, the solution is a bit ugly but I don't have an alternative right now.

Somewhat related, that means Clang issues a warning for every compilation should there be a "unsupported" CUDA version around, even if it's not used? @tra maybe we can only issue the warning if CUDA is going to be used?

This is a good point. It should only affect compilations done with -x cuda. I'll fix that.
Short-term workaround is to specify invalid path to CUDA installation with --cuda-path=/does/not/exist

[kkwli0]

In D75001#1891742, @tra wrote:

In D75001#1891284, @Hahnfeld wrote:

In D75001#1887876, @jdoerfert wrote:

I like this way better. I was hoping we could do it in our cmake only :)

Give others a day or so to comment before your commit but I'm fine with this.

Well, that doesn't really work if openmp-commits is only subscribed on commit. That said, the solution is a bit ugly but I don't have an alternative right now.

Somewhat related, that means Clang issues a warning for every compilation should there be a "unsupported" CUDA version around, even if it's not used? @tra maybe we can only issue the warning if CUDA is going to be used?

This is a good point. It should only affect compilations done with -x cuda. I'll fix that.
Short-term workaround is to specify invalid path to CUDA installation with --cuda-path=/does/not/exist

@tra Will it also include -fopenmp-targets=nvptx64-nvidia-cuda?

[tra]

In D75001#1891861, @kkwli0 wrote:

@tra Will it also include -fopenmp-targets=nvptx64-nvidia-cuda?

If you're asking whether the warning will be disabled for OpenMP, then no. This OpenMP target appears to rely on CUDA, and I think all the reasons for the warning existence do still apply.
If you're asking about the workaround, it would only work for non-CUDA compilations that don't really need CUDA SDK, so the answer is probably 'no' as well as you will need a valid CUDA path.

[kkwli0]

In D75001#1891966, @tra wrote:

In D75001#1891861, @kkwli0 wrote:

@tra Will it also include -fopenmp-targets=nvptx64-nvidia-cuda?

If you're asking whether the warning will be disabled for OpenMP, then no. This OpenMP target appears to rely on CUDA, and I think all the reasons for the warning existence do still apply.
If you're asking about the workaround, it would only work for non-CUDA compilations that don't really need CUDA SDK, so the answer is probably 'no' as well as you will need a valid CUDA path.

Thanks. I meant the former. This can also solve the other issue mentioned in D74571.

[jdoerfert]

In D75001#1891284, @Hahnfeld wrote:

In D75001#1887876, @jdoerfert wrote:

I like this way better. I was hoping we could do it in our cmake only :)

Give others a day or so to comment before your commit but I'm fine with this.

Well, that doesn't really work if openmp-commits is only subscribed on commit. That said, the solution is a bit ugly but I don't have an alternative right now.

What is the problem with openmp-commits here? I got the emails, didn't you?

@kkwli0 Where are we with this?

[Hahnfeld]

In D75001#1922789, @jdoerfert wrote:

In D75001#1891284, @Hahnfeld wrote:

In D75001#1887876, @jdoerfert wrote:

I like this way better. I was hoping we could do it in our cmake only :)

Give others a day or so to comment before your commit but I'm fine with this.

Well, that doesn't really work if openmp-commits is only subscribed on commit. That said, the solution is a bit ugly but I don't have an alternative right now.

What is the problem with openmp-commits here? I got the emails, didn't you?

There's nothing wrong with openmp-commits. I wanted to say that you have to subscribe the ML before committing. Otherwise only the reviewers are notified and there cannot be "others" chiming in.

[kkwli0]

In D75001#1922789, @jdoerfert wrote:

In D75001#1891284, @Hahnfeld wrote:

In D75001#1887876, @jdoerfert wrote:

I like this way better. I was hoping we could do it in our cmake only :)

Give others a day or so to comment before your commit but I'm fine with this.

Well, that doesn't really work if openmp-commits is only subscribed on commit. That said, the solution is a bit ugly but I don't have an alternative right now.

What is the problem with openmp-commits here? I got the emails, didn't you?

@kkwli0 Where are we with this?

@jdoerfert In terms of the scope of this issue, it is done. It is to ignore the warning in order to avoid build blockage in the future when newer CUDA toolkit is available and installed on the build system. Another related issue that blocked the other part of the tests (related to python binding) was resolved in https://reviews.llvm.org/D76030. As far as I know, the remaining one (not quite an issue, it is by design) is warning issued when -fopenm-targets=nvptx* is specified, users can suppress it.

openmp/runtime/cmake/LibompCheckLinkerFlag.cmake

try_compile(
     try_compile_result
     ${base_dir}/build
     ${base_dir}
     foo
     OUTPUT_VARIABLE OUTPUT)
 
   if(try_compile_result)
     foreach(regex IN LISTS failed_regexes)
-      if("${OUTPUT}" MATCHES ${regex})
+      # Ignore the warning about the newer or unknown CUDA version.
+      if(("${OUTPUT}" MATCHES ${regex}) AND NOT ("${OUTPUT}" MATCHES "Unknown CUDA version"))
         set(retval FALSE)
       endif()
     endforeach()
   else()
     set(retval FALSE)
   endif()
 
   if(${retval})