[BUG] C/C++ compiler incorrectly sign extending halfword operations

[M_G_1]

Hello, 

The compiler is incorrectly sign-extending halfword operations at all optimization levels above O0. I hit this bug with XE 2013 edition, but I have confirmed the problem exists in the most recent 2016 edition as well. This is affecting a critical project, can you please investigate? A reduced test case is provided below. 

Code:

#include <stdio.h>

typedef short size2s_t;
typedef int size4s_t;
typedef long long int size8s_t;

size8s_t vrmpyhacc(size8s_t Rxx, size8s_t Rss, size8s_t Rtt)
{
Rxx = Rxx + 
  (size2s_t)((Rss>>(0*16))&0xffff) * (size2s_t)((Rtt>>(0*16))&0xffff)
+ (size2s_t)((Rss>>(1*16))&0xffff) * (size2s_t)((Rtt>>(1*16))&0xffff)
+ (size2s_t)((Rss>>(2*16))&0xffff) * (size2s_t)((Rtt>>(2*16))&0xffff)
+ (size2s_t)((Rss>>(3*16))&0xffff) * (size2s_t)((Rtt>>(3*16))&0xffff);

return Rxx;
}

int main()
{
  typedef union {
    signed long long db;
    signed short  hw[4];
  } newvar;
  newvar Rxx, Rss, Rtt;

  Rss.hw[0] = -5;
  Rss.hw[1] = -10;
  Rss.hw[2] = -1;
  Rss.hw[3] = -9;
  Rtt.hw[0] = -3;
  Rtt.hw[1] = -8;
  Rtt.hw[2] = -5;
  Rtt.hw[3] = -1;
  Rxx.db = 0;

  printf("vrmpyhacc: 0x%llx\n", (long long unsigned int) vrmpyhacc(Rxx.db, Rss.db, Rtt.db));

  return 0;
}

Build:

icl vector.c -O1 

Run (observed output):

vrmpyhacc: 0xffffffffffde006d

Expected output:

vrmpyhacc: 0x6d

[Kittur_G_Intel]

Hi,
I tried with the latest 2016 version: Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.0.110 Build 20150815

It worked fine with  with -O2 and -O3 (with VS2013) but yes it does fail with -O1 and is a bug.

Can you let me know the system details including VS version etc? Also, can you attach a pre-processed file generated with (/P) as well? Thanks
_Kittur

[jimdempseyatthecove]

You could remove ambiguities in standards interpretation:

Rxx = Rxx + 
   ((
      (Rss>>(0*16)) * (Rtt>>(0*16))
    + (Rss>>(1*16)) * (Rtt>>(1*16))
    + (Rss>>(2*16)) * (Rtt>>(2*16))
    + (Rss>>(3*16)) * (Rtt>>(3*16))
   ) & 0xFFFF);

Jim Dempsey

[M_G_1]

No, I really can't. This is a simplified case of a much more complicated implementation that is auto-generated from macros. I don't have the option of hand modifying the code. 

[Kittur_G_Intel]

@mariog: I'll filed this issue with the developers on the failure with -O1 since  I am not able to reproduce the issue with -O2 or -O3. but have added that info as well. If you can attach a test reproducer with some system details and vs version that'll be great if possible. Anyways, I'll keep you updated as soon as the release with a fix is out, thx.

_Kittur