On Tue, 16 Apr 2024 15:40:12 +0200 Timo =?utf-8?Q?R=C3=B6hling?= <roehl...@debian.org> wrote:
* Gianfranco Costamagna <locutusofb...@debian.org> [2024-04-16 09:06]: >I agree with Cory, to me looks also a regression in thrust > >I'm trying some hacky patch, lets see > >Description: Reintroduce fallback lost in https://github.com/ROCm/rocThrust/commit/2b80e29803d60f01701a67bc57ef06dacfe8af8b >Author: Gianfranco Costamagna <locutusofb...@debian.org> >Last-Update: 2024-04-16 > >--- rocthrust-5.7.1.orig/thrust/detail/type_traits.h >+++ rocthrust-5.7.1/thrust/detail/type_traits.h >@@ -731,6 +731,8 @@ using invoke_result_t = > #else // 2017+ > ::cuda::std::invoke_result_t<Invokable, Args...>; > #endif >+#else >+ std::invoke_result_t<Invokable, Args...>; > #endif > > template <class F, class... Us> >Thanks for the patch and upstream PR. If that does not pan out, I could split stdgpu into two separate (source) packages to have the openmp backend built against libthrust-dev. I prefer your solution, though.
I would say, we NMU now to unblock the amdgpu transition to time64_t, and then we can split or do whatever you prefer... There is some rush to finish time64_t without regressing the current set of packages... (whenever possible of course!) G.
OpenPGP_signature.asc
Description: OpenPGP digital signature
