icx optimization error on simple C file

[psw]

Hello,

there is a simple C example of latest icx 2022 optimization error. It appears on level -O2 and up, on -O1 works ok.

After starting, you should input any string. The result should be string XORed with 0x36. If you see all 0x36363636, it's a bug.

[MadhuK_Intel]

Hi,

Thanks for reaching out to us.

We are working on your issue, we will get back to you soon.

Meanwhile could you please let us know the OS details on which you are working?

Thanks and Regards,

Madhu.

[psw]

Thanks.

I'm using Windows 10:

Intel(R) oneAPI DPC++/C++ Compiler 2022.0.0 (2022.0.0.20211123)
Target: x86_64-pc-windows-msvc
Thread model: posix

[Viet_H_Intel]

This looks like a compiler bug. I'll report it to our Compiler Developer.

Thanks,

[Viet_H_Intel]

Hi,

Here is our Developer's comments on this issue:

The Intel clang compiler is more strict on pointer types than other compilers, it's a combination of the clang type implementation, plus the aggressive optimizations that the compiler backend tries to do.

In particular, this reinterpretation of the char array pad[] to integer type, doesn't meet the "strict aliasing" requirement for pointers:

bswap_buf((unsigned int *)pad, pwarray, 64);

In general, an object of type "x" needs to be accessed using pointers of type "x".

The exception is that "char *" pointers can safely access any type. The reverse is not true however; integer pointers cannot safely access char-type data.

This article discusses the issue in some detail:

https://stackoverflow.com/questions/52492229/c-byte-array-to-int

Some suggestions:

1) Use the -fno-strict-aliasing flag. This prevents the compiler from making aliasing analysis based on pointer types.

2) Use memcpy as the article suggests:

void bswap_buf (unsigned int *in, unsigned int *out, int len)

{

 int i;

 for (i=0; i < len /4; i++) {

   int val;

   memcpy(&val, (void *)&in[i], 4);

   out[i] = _byteswap_ulong(val);

 }

}

The compiler will not try to use types to analyze memcpy (which is "typeless" with void*). 

Please use one of the suggestions and let us know so that we can close this thread.

Thanks,

[psw]

Thanks for explanation. Formally, you're right.

On the other hand, any other compiler, including clang itself, generates different result, no matter used with -fno-strict-aliasing or not.

Thanks anyway for clarifying.

[Viet_H_Intel]

If it's not related to Intel compilers, can we close this thread?

Thanks,

[psw]

Yes, please

[Viet_H_Intel]

We are going to close this thread. If you need further assistance, please create a new one.

Thanks,