Intel® C++ Compiler
Support and discussions for creating C++ code that runs on platforms based on Intel® processors.
Announcements
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
7768 Discussions

icx optimization error on simple C file

psw
Beginner
668 Views

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.

0 Kudos
8 Replies
MadhuK_Intel
Moderator
643 Views

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
Beginner
630 Views

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
Moderator
582 Views

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


Thanks,


Viet_H_Intel
Moderator
544 Views

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
Beginner
512 Views

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
Moderator
505 Views

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

Thanks,


psw
Beginner
503 Views

Yes, please

Viet_H_Intel
Moderator
498 Views

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


Thanks,


Reply