@@ -906,30 +906,27 @@ struct _pi_kernel : _pi_object {
906
906
907
907
// Hash function object for the unordered_set below.
908
908
struct Hash {
909
- size_t operator ()(
910
- const std::unordered_map<void *, MemAllocRecord>::iterator &It) const {
911
- return std::hash<void *>()(It->first );
909
+ size_t operator ()(const std::pair<void *const , MemAllocRecord> *P) const {
910
+ return std::hash<void *>()(P->first );
912
911
}
913
912
};
914
913
915
914
// If kernel has indirect access we need to make a snapshot of all existing
916
915
// memory allocations to defer deletion of these memory allocations to the
917
916
// moment when kernel execution has finished.
918
- // We store iterators because iterator is not invalidated by insert/delete for
919
- // std::map.
920
- // Why need to take a snapshot instead of just reference-counting the
921
- // allocations, because picture of active allocations can change during kernel
922
- // execution (new allocations can be added) and we need to know which memory
923
- // allocations were retained by this kernel to release them (and don't touch
924
- // new allocations) at kernel completion.
925
- // Same kernel may be submitted several times and retained allocations may be
926
- // different at each submission. That's why we have a set of memory
927
- // allocations here and increase ref count only once even if kernel is
928
- // submitted many times. We don't want to know how many times and which
929
- // allocations were retained by each submission. We release all allocations
930
- // in the set only when SubmissionsCount == 0.
931
- std::unordered_set<std::unordered_map<void *, MemAllocRecord>::iterator, Hash>
932
- MemAllocs;
917
+ // We store pointers to the elements because pointers are not invalidated by
918
+ // insert/delete for std::unordered_map (iterators are invalidated). We need
919
+ // to take a snapshot instead of just reference-counting the allocations,
920
+ // because picture of active allocations can change during kernel execution
921
+ // (new allocations can be added) and we need to know which memory allocations
922
+ // were retained by this kernel to release them (and don't touch new
923
+ // allocations) at kernel completion. Same kernel may be submitted several
924
+ // times and retained allocations may be different at each submission. That's
925
+ // why we have a set of memory allocations here and increase ref count only
926
+ // once even if kernel is submitted many times. We don't want to know how many
927
+ // times and which allocations were retained by each submission. We release
928
+ // all allocations in the set only when SubmissionsCount == 0.
929
+ std::unordered_set<std::pair<void *const , MemAllocRecord> *, Hash> MemAllocs;
933
930
934
931
// Counter to track the number of submissions of the kernel.
935
932
// When this value is zero, it means that kernel is not submitted for an
0 commit comments