**File:** modules/core/src/ocl.cpp
**Change Type:** modified
**Context:** PR #16608: fixed several problems when running tests on Mac - * failures in ocl_pyrUp * failures in ocl_flip when processing CV_16UC3 or CV_16SC3 data...

**Code Changes:**
```diff
@@ -4705,6 +4705,8 @@ class OpenCLAllocator CV_FINAL : public MatAllocator
             int createFlags = 0, flags0 = 0;
             getBestFlags(ctx, accessFlags, usageFlags, createFlags, flags0);
 
+            bool copyOnMap = (flags0 & UMatData::COPY_ON_MAP) != 0;
+
             cl_context ctx_handle = (cl_context)ctx.ptr();
             int allocatorFlags = 0;
             int tempUMatFlags = 0;
@@ -4764,8 +4766,15 @@ class OpenCLAllocator CV_FINAL : public MatAllocator
```

Review comment:
With the tracing turned on sometimes it hangs on unmap: ``` OpenCV(OpenCL:0): clCreateBuffer(CL_MEM_USE_HOST_PTR|createFlags, sz=100, origdata=0x7fa0d5278680) => 0x7fa0d5277ea0 OpenCV(OpenCL:0): clCreateBuffer() => 0x7fa0d5277ea0 OpenCV(OpenCL:0): handle = clCreateCommandQueue_pfn(ch, dh, props, &retval) OpenCV(OpenCL:0): clEnqueueReadBuffer(q, handle=0x7fa0d5277ea0, CL_TRUE, 0, sz=100, data=0x7fa0d5278680, 0, 0, 0) OpenCV(OpenCL:0): clEnqueueWriteBuffer(q, handle=0x7fa0d5277ea0, CL_TRUE, 0, sz=100, data=0x7fa0d5278680, 0, 0, 0) [ INFO:0] Successfully initialized OpenCL cache directory: /var/folders/ll/ddsp7fq10lvb2lf9v91x6ks40000gn/T/opencv/3.4.x-dev/opencl_cache/ [ INFO:0] Preparing OpenCL cache configuration for context: 32-bit--AMD--AMD_Radeon_HD_-_FirePro_D700_Compute_Engine--1_2__Jan_13_2020_20_12_40_ OpenCV(OpenCL:0): clBuildProgram(binary: core/copyset) OpenCV(OpenCL:0): result = clGetProgramBuildInfo_pfn(handle, devices[0], 0x1181, sizeof(build_status), &build_status, &retsz) OpenCV(OpenCL:0): clCreateKernel('set') OpenCV(OpenCL:0): clSetKernelArg('set', arg_index=0, cl_mem=0x7fa0d5277ea0) OpenCV(OpenCL:0): clSetKernelArg('set', arg_index=1, step_value=10) OpenCV(OpenCL:0): clSetKernelArg('set', arg_index=2, offset_value=0) OpenCV(OpenCL:0): clSetKernelArg('set', arg_index=3, rows_value=10) OpenCV(OpenCL:0): clSetKernelArg('set', arg_index=4, cols_value=5) OpenCV(OpenCL:0): clSetKernelArg('set', arg_index=5, size=2, obj=0x7ffeea546ea0) OpenCV(OpenCL:0): clFinish_pfn(qq) OpenCV(OpenCL:0): clReleaseKernel_pfn(handle) OpenCV(OpenCL:0): clEnqueueReadBuffer(q, handle=0x7fa0d5277ea0, CL_TRUE, 0, sz=100, data=0x7fa0d5278680, 0, 0, 0) OpenCV(OpenCL:0): clEnqueueWriteBuffer(q, handle=0x7fa0d5277ea0, CL_TRUE, 0, sz=100, data=0x7fa0d5278680, 0, 0, 0) OpenCV(OpenCL:0): clEnqueueMapBuffer(handle=0x7fa0d5277ea0, sz=100) => 0x7fa0d5278680 OpenCV(OpenCL:0): clEnqueueUnmapMemObject(handle=0x7fa0d5277ea0, data=0x7fa0d5278680, [sz=100]) ``` sometimes it crashes at the OpenCL kernel (setTo) release, sometimes it crashes at some other random places. if the code that removes ACCESS_FAST flag is commented off, no any error/exception happens. The code returns UMat with OpenCL handle=NULL. Then, obviously, OpenCL kernel refuses to run and then it automatically falls back to CPU implementation. But I'm almost sure that this is much worse and error-prone behaviour than the real data copy. I moved ACCESS_FAST remove code into non-SVM branch, because ACCESS_FAST is really for SVM.