You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Related to #2075. Possibly related to #1598, if Clang-CUDA requires a recent NVIDIA CUDA Toolkit to be installed.
Test coverage
Currently, we have no test coverage for Clang-CUDA. If this scenario is important to some users (as it appears to be) and is likely to be damaged as we modify preprocessor logic for Clang and CUDA separately, we should have test coverage to prevent major/obvious regressions.
__CUDACC__ preprocessor logic
Also, if this is important, we should audit the codebase for places where we're testing __CUDACC__ but Clang-CUDA could handle the normal codepath instead of needing the workaround codepath. (I suspect that Clang-CUDA can handle the normal codepath when "front-end stuff" is involved, but that we need the workaround codepath when "codegen intrinsic stuff" is involved.)
This front-end __is_assignable_no_precondition_check makes MSVC behave like Clang, thus I believe there's no need to investigate making Clang-CUDA take this path.
Front-end stuff: Clang-CUDA likely supports "conditional explicit" in all Standard modes, so making it use the modern path would be good (as we already do for vanilla Clang).
Related to #2075. Possibly related to #1598, if Clang-CUDA requires a recent NVIDIA CUDA Toolkit to be installed.
Test coverage
Currently, we have no test coverage for Clang-CUDA. If this scenario is important to some users (as it appears to be) and is likely to be damaged as we modify preprocessor logic for Clang and CUDA separately, we should have test coverage to prevent major/obvious regressions.
__CUDACC__preprocessor logicAlso, if this is important, we should audit the codebase for places where we're testing
__CUDACC__but Clang-CUDA could handle the normal codepath instead of needing the workaround codepath. (I suspect that Clang-CUDA can handle the normal codepath when "front-end stuff" is involved, but that we need the workaround codepath when "codegen intrinsic stuff" is involved.)Current examples:
Already patched
STL/stl/inc/yvals_core.h
Lines 428 to 432 in 303df3d
Already patched by Casey Carter (@CaseyCarter) in
<random>: Implement LWG-3519 #2208! 🎉 (This is a good example of "front-end stuff".)STL/stl/inc/yvals_core.h
Lines 586 to 592 in 303df3d
This is what handle Clang-CUDA #2075 is patching.
No action necessary
STL/stl/inc/cmath
Lines 15 to 16 in 303df3d
Codegen intrinsics, excludes both Clang and CUDA, no action necessary.
STL/stl/inc/limits
Lines 19 to 21 in 303df3d
STL/stl/inc/limits
Lines 1054 to 1056 in 303df3d
STL/stl/inc/limits
Lines 1157 to 1159 in 303df3d
These are all codegen intrinsics.
STL/stl/inc/type_traits
Lines 636 to 639 in 303df3d
STL/stl/inc/type_traits
Lines 661 to 664 in 303df3d
This front-end
__is_assignable_no_precondition_checkmakes MSVC behave like Clang, thus I believe there's no need to investigate making Clang-CUDA take this path.STL/stl/inc/yvals_core.h
Lines 438 to 441 in 303df3d
This is for MSVC-specific type trait optimizations. No reason to make Clang-CUDA use this.
STL/stl/inc/yvals_core.h
Lines 556 to 563 in 303df3d
We already test for Clang before CUDA here, no action necessary. (Ditto for the restore macro below.)
Possible enhancements
STL/stl/inc/functional
Lines 858 to 859 in 303df3d
Front-end SFINAE, I suspect that Clang-CUDA doesn't need this workaround. (Also applies to Use
int = 0SFINAE in<memory>to improve compiler throughput #2124.)STL/stl/inc/xutility
Lines 36 to 40 in 303df3d
STL/stl/inc/xutility
Lines 66 to 73 in 303df3d
Clang-CUDA might be capable of using
__builtin_bit_cast.STL/stl/inc/yvals_core.h
Lines 450 to 451 in 303df3d
Front-end stuff: Clang-CUDA likely supports "conditional
explicit" in all Standard modes, so making it use the modern path would be good (as we already do for vanilla Clang).