Compiler error when optimising loop

ChristopherBell — Mon, 24 Feb 2025 15:53:44 GMT

I'm using the 2023 OneAPI C++ compiler to rebuild some existing software that we have previously built with the 2019 Intel compiler. I am seeing an error in a loop which "expands" an array of 4 byte integers to become 8 byte integers in the same storage space.

Qualitatively it works like this:

Declare an array long enough to hold N 8 byte (long long) integers
Read N 4 byte (int) integers into the bottom half of this
Working from the end of the array backwards copy each 4 byte integer into the appropriate 8 byte slot by array index.

The coding that matters could be written:

long long *buff_8; // Dynamically allocated space to hold N long longs

int *buff_4 = (int *)buff_8; // Interpret this space as 4 byte integers

... populate buff_4[] with an array of N 4 byte integer values

for(i=N-1; i>=0; i--) buff_8[i] = buff_4[i]; // Copy the numbers to long long format

I have attached two very simple files which show the problem:

main.c sets up, populates and tests the storage
sub.c performs the I4 => I8 copy

To reproduce this just create a console C project of these two files, nothing fancy required, use a Release build to turn on optimisation (I used /O2) and turn off interprocedural optimisation.

Working on Windows (in VS2022) if I perform the copy in a separate function in a separate file and turn interprocedural optimisation to multiifile (/Qipo) this works fine, if I turn it off it fails and I get zeros. Interestingly if I use Intel 2019 compilers the opposite is true: it fails when using /Qipo but works without.

I also tried on Linux where I got different behaviour: the Intel 2019 compiler failed when I wrote this as a single function, but worked if I put a #pragma novector before the copy loop, the OneAPI compiler has - so far - worked OK.

We see this problem in the 2024 compiler as well, haven't tried 2025.

We can solve the problem by isolating that function and using #pragma optimize ("", off) to stop it being optimised, so it is not a show-stopper. But I think it is quite a serious compiler bug.

Re: Compiler error when optimising loop

yzh_intel — Thu, 27 Feb 2025 17:30:35 GMT

Hi, icpx defaults to O2 optimization level, and it assumes code doesn't violate strict aliasing rule. In your code, buff_8 and buff_4 point to the same address, which violates this rule. This issue can be avoided with option "-fno-strict-aliasing".

Re: Compiler error when optimising loop

ChristopherBell — Thu, 27 Feb 2025 18:11:17 GMT

Thanks a bunch for that. I have never heard about strict aliasing before, I just assumed that memory contents were mine to interpret as I pleased.

I have loads of mixed float and int arrays as well, which I see contravene that rule. I'm going to need that compiler flag!

topic Re: Compiler error when optimising loop in Intel® oneAPI DPC++/C++ Compiler

Compiler error when optimising loop

Re: Compiler error when optimising loop

Re: Compiler error when optimising loop