Page MenuHomePhabricator

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

Authored by kkwli0 on Feb 21 2020, 4:23 PM.

Details

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.

Diff Detail

Event Timeline

kkwli0 created this revision.Feb 21 2020, 4:23 PM
jdoerfert accepted this revision.Feb 21 2020, 9:53 PM

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.

This revision is now accepted and ready to land.Feb 21 2020, 9:53 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 25 2020, 6:30 AM

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?

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 added a comment.Feb 25 2020, 9:57 AM

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 added a comment.EditedFeb 25 2020, 11:00 AM
In D75001#1891742, @tra 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 added a comment.Feb 25 2020, 12:05 PM

@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.

In D75001#1891966, @tra 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.

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?

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.

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.