Can't compile in Debug mode with CCCL Thrust in Mac

[correaa]

When configuring with -DCMAKE_BUILD_TYPE=Debug, the macro -DCCCL_ENABLE_ASSERTIONS gets activated. And this line produces an error:

/usr/bin/c++ -DBLAS_DOT_RETURNS_VOID -DCCCL_ENABLE_ASSERTIONS -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_OMP -DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_CPP -I/Users/correatedesco1/boost-multi/include -I/Users/correatedesco1/include -isystem /opt/homebrew/include -isystem /opt/homebrew/opt/libomp/include -fexperimental-library -g -std=c++2b -arch arm64 -Xclang -fopenmp -Werror -MD -MT include/boost/multi/adaptors/thrust/omp/test/CMakeFiles/omp.cpp.x.dir/omp.cpp.o -MF include/boost/multi/adaptors/thrust/omp/test/CMakeFiles/omp.cpp.x.dir/omp.cpp.o.d -o include/boost/multi/adaptors/thrust/omp/test/CMakeFiles/omp.cpp.x.dir/omp.cpp.o -c /Users/correatedesco1/boost-multi/include/boost/multi/adaptors/thrust/omp/test/omp.cpp
In file included from /Users/correatedesco1/boost-multi/include/boost/multi/adaptors/thrust/omp/test/omp.cpp:9:
In file included from /Users/correatedesco1/boost-multi/include/boost/multi/adaptors/thrust/omp.hpp:4:
In file included from /Users/correatedesco1/include/thrust/system/omp/memory.h:33:
In file included from /Users/correatedesco1/include/thrust/memory.h:32:
In file included from /Users/correatedesco1/include/thrust/detail/pointer.h:37:
In file included from /Users/correatedesco1/include/thrust/detail/type_traits/pointer_traits.h:32:
In file included from /Users/correatedesco1/include/thrust/iterator/iterator_traits.h:49:
In file included from /Users/correatedesco1/include/cuda/iterator:28:
In file included from /Users/correatedesco1/include/cuda/__iterator/strided_iterator.h:30:
In file included from /Users/correatedesco1/include/cuda/std/__mdspan/submdspan_helper.h:27:
In file included from /Users/correatedesco1/include/cuda/std/__mdspan/concepts.h:50:
In file included from /Users/correatedesco1/include/cuda/std/span:54:
In file included from /Users/correatedesco1/include/cuda/std/array:42:
/Users/correatedesco1/include/cuda/std/__utility/unreachable.h:29:3: error: use of undeclared identifier '__assert_fail'; did you mean '__assert_rtn'?
   29 |   _CCCL_ASSERT(false, "unreachable");
      |   ^
/Users/correatedesco1/include/cuda/std/__cccl/assert.h:143:45: note: expanded from macro '_CCCL_ASSERT'
  143 | #  define _CCCL_ASSERT(expression, message) _CCCL_ASSERT_HOST(expression, message)

[pauleonix]

Officially, according to Platform Support only Windows and Linux are supported.

In general, CCCL should work everywhere the CUDA Toolkit is supported

[correaa]

That is a very good answer. I must say, this is very close to be usable on Mac.

[pauleonix]

In that case (i.e. only minimal, trivial to maintain changes needed) there might be a chance that a PR in that direction would be accepted. Not that that would change the official support status because it is just not part of our CI and by definition it would only be a fraction of CCCL working (due to the missing CTK).

On the other hand the future of the (parallel) non-CUDA Thrust backends is unclear to me. AFAIK the amount of users and the community support are just not there. Quite a few important algorithms (scans, sort?) fell back to sequential execution the last time I looked. Then again the OMP backend is used by the NVC++ HPC compiler for stdpar with the multicore option so there seems to be at least one important internal user.

@jrhemstad Any pointers if writing code using Thrust w/o CUDA in 2025 is a good idea?

[correaa]

ok, I will see what is the replacement for __assert_fail in Mac (I guess in apple-clang)

Yes, I have the same question, how the future of Thrust looks like, now that it is part of a larger thing.

At the time, Thrust hit a sweet spot of being both lean and, in principle generic.
And, at least looked to me, that it standed by itself.

As part of a larger project CCCL the goal of Thrust became a murkier. At least when looking from outside.

For example, I benefited by AMD adopting the Thrust framework (HIPThrust), and porting a Thrust based application in a few hours. but I can see that since Thrust is now part of CCCL, HIPThrust developers would have to extract Thrust manually from a larger project and I don't know how sustainable is that. Ideally, they could have contributed to Thrust the HIP backend but with CCCL it looks more complicated.

For context, I am writing both a high level C++ library and a C++ code and Thrust provided me with an easy off-ramp to make the code parallel, on GPUs. and where I don't have nvidia GPU, it in principle offered me a way to provide OMP, and TBB. So it was very convenient.