ICC generates incorrect code

[nemequ]

I'm getting incorrect results from ICC when attempting to add implementations of the NEON `vabd_s32`, `vabd_u32`, `vabdq_s32`, and `vabdq_u32` functions to SIMDe.  Here is a reduced version which shows the problem:

#include <stdlib.h>
#include <stdint.h>
#include <assert.h>
#include <stdio.h>
#include <inttypes.h>

/* It's not necessary to put this in a struct; it just makes it easy
 * to switch between a vector and an array for testing.
 *
 * When it is an array -O0 and -O1 work, though -O2 fails.  As a
 * vector it fails even at -O0. */
typedef struct {
  #if defined(USE_VECTOR)
    int32_t values __attribute__((__vector_size__(16)));
  #else
    int32_t values[4];
  #endif
} vec32x4;

vec32x4 abd(vec32x4 a, vec32x4 b) {
  vec32x4 r;

  // #pragma omp simd
  for(size_t i = 0 ; i < (sizeof(r.values) / sizeof(r.values[0])) ; i++) {
    int64_t tmp = ((int64_t) a.values[i]) - ((int64_t) b.values[i]);
    r.values[i] = (int32_t) (tmp < INT64_C(0) ? -tmp : tmp);
  }

  return r;
}

int main(void) {
  int res = EXIT_SUCCESS;
  vec32x4
    a = (vec32x4) { { INT32_C(   463415955), -INT32_C(  1803897040), -INT32_C(  1513176249), -INT32_C(  1092402174) } },
    b = (vec32x4) { { INT32_C(  2138828797),  INT32_C(  1510457891),  INT32_C(  1276585996),  INT32_C(  1160694450) } },
    e = (vec32x4) { { INT32_C(  1675412842), -INT32_C(   980612365), -INT32_C(  1505205051), -INT32_C(  2041870672) } };

  vec32x4 r = abd(a, b);

  for (size_t i = 0 ; i < (sizeof(r.values) / sizeof(r.values[0])) ; i++) {
    if (r.values[i] != e.values[i]) {
      fprintf(stderr, "%" PRId32 " != %" PRId32 "\n", r.values[i], e.values[i]);
      res = EXIT_FAILURE;
    }
  }

  return res;
}

This is with ICC 2021.1 Beta 20200602 on Linux, x86_64.

Similar code works for other types (i.e., a vector of `int16_t` instead of `int32_t`, with the operations happening on `int32_t` instead of `int64_t`).  This happens with both 64 (vabd_{s,u}32) and 128-bit (vabdq_{s,u}32) vectors, with both signed (vabd{,q}_s32) and unsigned (vabd{,q}_u32) integers.

As you can see from the comment in the code, at -O2 and higher it fails if an array is used.  If a vector is used, it fails even at -O0.  GCC and clang both provide correct results.

[Viet_H_Intel]

I've reported this issue to our compiler Developer.

Thanks,

Viet

[Viet_H_Intel]

This problem doesn't show up with icx. Can you compile with icx instead of icc?

Thanks,

[nemequ]

Personally I could, though it's not necessary; I've had a work-around in place since before I posted this.  Actually, I just took a look and we use a completely different implementation now.

I'm more concerned about others who might run into this issue with other software.  SIMDe has an extremely extensive test suite, which is the only reason I caught this.  Others may not be so lucky, and this is a rather nasty issue since it just silently corrupts data… I'd much prefer a segfault or ICE.

The only reason I filed this issue is to let Intel know so you can fix it, hopefully before others run into it without realizing.  I know Intel is moving over to icx, but does that mean icc is no longer supported? If that's the case I can drop support for it in my code (and stop reporting bugs), which would definitely make my life a little easier.

[Viet_H_Intel]

We still support icc. It is just that icx has higher priority. So icc issues may take longer time to address.

Thanks,

[PrasanthD_intel]

Hi Evan,

Thanks for reporting the issue. We are closing this thread as icx is working fine. The issue in icc/icpc will be fixed in future releases. Please look out for future releases. We will no longer respond to this thread. If you require additional assistance from Intel, please start a new thread. Any further interaction in this thread will be considered community only.

Regards

Prasanth