Bug in ippiCopy_32f_C1R ROI handling

Hi,

I found a bug in ROI handling in ippiCopy_32f_C1R() function. In some cases it writes outside of specified ROI.

IPP library version 2016 Update 2. CPU is Intel Core i5 4460. OS is Windows 8.1 x64.

Here is the code that reproduces the bug:

#include <ippcore.h>
#include <ippi.h>
#include <stdio.h>

int main()
{
    ippInit();
    const IppLibraryVersion* lib = ippiGetLibVersion();
    printf("%s %s %d.%d.%d.%d\n",
        lib->Name,
        lib->Version,
        lib->major, lib->minor, lib->majorBuild, lib->build);

    const int width = 1024;
    const int height = 1024;

    // Initialize 2 images
    static float img1[width * height];
    static float img2[width * height];
    for (int i = 0; i < width * height; i++)
    {
        img1[i] = 1.0;
        img2[i] = 2.0;
    }

    const int bytesPerLine = width * sizeof(float);
    IppiSize roi = { width - 2, height - 2 };
    // Copy (width-2)x(height-2) pixels area from img1 top left corner to img2 at (1, 1)
    // (leaving 1-pixel border near img2 edges untouched)
    ippiCopy_32f_C1R(img1, bytesPerLine, img2 + width + 1, bytesPerLine, roi);

    // Print values of 3x3 pixels area in the top left corner
    printf("%.1f %.1f %.1f\n", img2[0], img2[1], img2[2]);
    printf("%.1f %.1f %.1f\n",
        img2[0 + width * 1],
        img2[1 + width * 1],
        img2[2 + width * 1]);
    printf("%.1f %.1f %.1f\n",
        img2[0 + width * 2],
        img2[1 + width * 2],
        img2[2 + width * 2]);
}

Expected result is that img2 contains 1-pixel border with value 2.0 and inner rectangle filled by 1.0.

Here is the output of the program:

ippIP AVX2 (l9) 9.0.2 (r49912) 9.0.2.49912
2.0 2.0 2.0
2.0 1.0 1.0
1.0 1.0 1.0

Note value at column 1 of line 3 of the dumped matrix. It is expected to be 2.0. Actually other pixels in first and last columns are overwritten too, while they are expected to be left intact.

The same application works correctly on Intel Xeon W5580 CPU, probably it depends on AVX2 presence:

ippIP SSE4.2 (y8) 9.0.2 (r49912) 9.0.2.49912
2.0 2.0 2.0
2.0 1.0 1.0
2.0 1.0 1.0

The bug appears only on large enough images. According to my tests, the bug is not reproduced if image size is less than about 790000 pixels.