CUB uses non-standard C++ extensions that break strict compilers

[maddyscientist]

Summary

Some Nvidia teams regularly use CUB with NVRTC, a compiler with a very strict interpretation of C++. CUB currently uses some non-standard language extensions, such as anonymous structs, which break NVRTC compilation. We should build our test harness with compiler flags that audit non-standard extension usages, such as -Wpedantic for GCC/Clang and /W4 for MSVC, and remove as many warning suppressions as possible.

NVIDIA/cccl#856 may be related, as it is another NVRTC issue.

Deliverables

• [1.12] Enable -Wpedantic / /W4 in our builds and fix the issues identified by these flags.
• [1.12] Audit the current warning suppressions and remove any that are hiding functional problems. Such issues should be fixed instead.

Original Issue

I've repurposed this existing issue about anonymous structs to a larger purpose of improving C++ standard compliance across Thrust and CUB. The original issue was:

Title: CUB uses anonymous structs which is disallowed in C++

For example see

cub/cub/block/specializations/block_reduce_raking_commutative_only.cuh

Line 98 in ea48955

struct

This is illegal in C++, see for example

https://stackoverflow.com/questions/2253878/why-does-c-disallow-anonymous-structs

This causes issues with nvrtc which is a strict C++ compiler.

[alliepiper]

Thanks for pointing this out.

I don't see any gcc warning flags for this (other than -Wpedantic), but clang can issue warnings on these.

We should enable that and clean these up.

[alliepiper]

I'm going to try fixing this by enabling -Wpedantic//W4 for our Thrust/CUB builds. This should hopefully prevent other non-standard extensions from creeping in and breaking NVRTC.

[alliepiper]

Slipping to 1.12.0, since this won't be done in time for 1.11.0.

[alliepiper]

Looks like using -Wpedantic with nvcc has issues. Thousands of non-suppressible warnings are emitted for the simplest translation units:

$ cat t.cu
int main() {}

$ nvcc -Xcompiler="-Wpedantic -Werror" t.cu
/tmp/tmpxft_0000644c_00000000-6_t.cudafe1.cpp:1:3: error: style of line directive is a GCC extension [-Werror]
 # 1 "t.cu"
   ^
t.cu:2:3: error: style of line directive is a GCC extension [-Werror]
t.cu:2:3: error: style of line directive is a GCC extension [-Werror]
t.cu:2:3: error: style of line directive is a GCC extension [-Werror]
t.cu:2:3: error: style of line directive is a GCC extension [-Werror]
t.cu:2:3: error: style of line directive is a GCC extension [-Werror]
t.cu:2:3: error: style of line directive is a GCC extension [-Werror]
t.cu:3:3: error: style of line directive is a GCC extension [-Werror]
t.cu:6:3: error: style of line directive is a GCC extension [-Werror]
t.cu:1:3: error: style of line directive is a GCC extension [-Werror]
 int main() {}
   ^~
/usr/local/cuda/bin/../targets/x86_64-linux/include/cuda_runtime.h:62:3: error: style of line directive is a GCC extension [-Werror]
 #endif
   ^~
/usr/local/cuda/bin/../targets/x86_64-linux/include/cuda_runtime.h:65:3: error: style of line directive is a GCC extension [-Werror]
 #endif
   ^~
[ 11,332 lines with the same error follow]

Reported NVBug 3199547 to see if the nvcc folks have any workarounds.

[alliepiper]

The good news is that MSVC /W4 works and does catch a lot of the issues -Wpedantic would cover, including the anonymous structs, so I can definitely get those cleaned up either way.

[alliepiper]

Compiler folks say there is no workaround for -Wpedantic with gcc/nvcc and no plans to fix this (NVBug 3199547).

We'll have to rely on MSVC's /W4 to do compliance checks for now.

[alliepiper]

The original bug in this issue has been fixed by 39a2172.