Andrey Alekseenko

> The old names will definitely be kept for the macros for some time for backwards compatibility, so there should not be an immediate urgency for you to do this....

> Try catch (sycl::exception&) Not helping: ```console $ acpp -O2 --acpp-targets=generic sg_sizes.cpp && ./a.out [AdaptiveCpp Warning] OpenCL device gfx1034 does not have a valid USM provider. Memory allocations are not...

> So, when the backend starts it notices the problem, and registers with the runtime that there is an issue. Is that so? As long as `get_info` is not called...

> I think the spec does not really apply here. IMO none of these queries should ever fail. If they fail, something is broken and you are operating the implementation...

BTW, same behavior with from "Intel(R) FPGA Emulation Device" (`libintelocl_emu.so`).

Hi! We have the following, all over sub-groups: `sycl::any_of_group`, `sycl::reduce_over_group`, `sycl::select_from_group`, `sycl::shift_group_(left|right)`. Having StdPar support for `std::exclusive_scan` (over a USM device buffer) would also be of interest soon-ish, but not...

> Do you really want stdpar support and std::exclusive_scan, or do you want hipsycl::algorithms::exclusive_scan? The hipsycl::algorithms library is what sits below stdpar and has a more SYCL-like interface with queue...

Yes, looks like that. And BTW, the year in `acpp --acpp-version | grep Copyright` is out-of-date too. Shall this get a "good first issue" label? I don't think there's any...

One reason is that [we overwrite `result[0]` before doing the inclusive scan](https://github.com/AdaptiveCpp/AdaptiveCpp/blob/b61a18683cb66734b3d6a1d02ab3e3cb6f1d7d8d/include/hipSYCL/sycl/libkernel/generic/hiplike/group_functions.hpp#L526-L529), but moving this conditional assignment after the `__hipsycl_joint_inclusive_scan` is not enough to solve the problem. Upd 1: And...

Related: #714