Dan Hoeflinger

> > Our documentation only makes mention of the case where we use a `sycl::usm_allocator` with `sycl::usm::alloc::shared`, but should we also provide a specialization for `sycl::usm_allocator` with `sycl::usm::alloc::host` to be...

When run through the input data sweep tests from #1429, it seems that both `shared` and `host` `usm_allocator` iterators encounter issues when used as the source iterator for a `permutation_iterator`....

> When run through the input data sweep tests from #1429, it seems that both `shared` and `host` `usm_allocator` iterators encounter issues when used as the source iterator for a...

@MikeDvorskiy @mmichel11 Actually there is a fundamental problem with this, and it will not work. This breaks host_iterators because `std::vector::iterator` with a default allocator are indistinguishable from `std::vector_iterator` with a...

Update: Actually, for icpx, the `std::vector::iterator` **_does_** distinguish between host_iterator and usm_allocator, except for the case of `std::vector::iterator` (which is always `std::_Bit_iterator`, regardless of the allocator it seems). I've provided...

Following up on this strategy of first checking if `usm allocator` is distinguishable vs the default allocator within the iterator type... It is possible (though I believe improbable) for an...

@MikeDvorskiy After our offline discussion, I've updated the PR in 2 ways. 1) Made it more readable by abstracting out definitions of std::vector::iterator of different types 2) Not only do...

@vossmjp bump (being flagged as a stale branch, and should be a easy merge I think)

out of date

Converted to draft until we can discuss more officially the proposal.