[Bug target/95144] New: Many AVX-512 functions take an int instead of unsigned int

evan@coeus-group.com gcc-bugzilla@gcc.gnu.org
Thu May 14 23:21:18 GMT 2020


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95144

            Bug ID: 95144
           Summary: Many AVX-512 functions take an int instead of unsigned
                    int
           Product: gcc
           Version: 10.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: evan@coeus-group.com
  Target Milestone: ---

There are a bunch of functions in AVX-512F which, according to Intel's
documentation (https://software.intel.com/sites/landingpage/IntrinsicsGuide/),
take an unsigned integer as an argument but GCC's header has the type as a
signed integer.

This causes problems with -Wsign-conversion.  Here is an example which will
generate a warning with -Wsign-conversion (or https://godbolt.org/z/kTBTAD if
you prefer):

  #include <immintrin.h>

  static __m256i foo (__m256i a, unsigned int imm8) {
    return _mm256_srai_epi64(a, imm8);
  }

  __m256i bar(__m256i a) {
    return foo(a, 7);
  }


AFAICT all the functions which take unsigned imm8 arguments have this problem
in clang.  Here is a quick list:

 * _mm256_mask_slli_epi16
 * _mm256_mask_slli_epi32
 * _mm256_mask_slli_epi64
 * _mm256_mask_srai_epi16
 * _mm256_mask_srai_epi32
 * _mm256_mask_srai_epi64
 * _mm256_mask_srli_epi32
 * _mm256_mask_srli_epi64
 * _mm256_maskz_slli_epi16
 * _mm256_maskz_slli_epi32
 * _mm256_maskz_slli_epi64
 * _mm256_maskz_srai_epi16
 * _mm256_maskz_srai_epi32
 * _mm256_maskz_srai_epi64
 * _mm256_maskz_srli_epi32
 * _mm256_maskz_srli_epi64
 * _mm256_srai_epi64
 * _mm512_mask_slli_epi16
 * _mm512_mask_slli_epi32
 * _mm512_mask_slli_epi64
 * _mm512_mask_srai_epi16
 * _mm512_mask_srai_epi32
 * _mm512_mask_srai_epi64
 * _mm512_mask_srli_epi16
 * _mm512_mask_srli_epi32
 * _mm512_mask_srli_epi64
 * _mm512_maskz_slli_epi16
 * _mm512_maskz_slli_epi32
 * _mm512_maskz_slli_epi64
 * _mm512_maskz_srai_epi16
 * _mm512_maskz_srai_epi32
 * _mm512_maskz_srai_epi64
 * _mm512_maskz_srli_epi32
 * _mm512_maskz_srli_epi64
 * _mm512_slli_epi16
 * _mm512_slli_epi32
 * _mm512_slli_epi64
 * _mm512_srai_epi16
 * _mm512_srai_epi32
 * _mm512_srai_epi64
 * _mm512_srli_epi16
 * _mm512_srli_epi32
 * _mm512_srli_epi64
 * _mm_mask_slli_epi16
 * _mm_mask_slli_epi32
 * _mm_mask_slli_epi64
 * _mm_mask_srai_epi16
 * _mm_mask_srai_epi32
 * _mm_mask_srai_epi64
 * _mm_mask_srli_epi32
 * _mm_mask_srli_epi64
 * _mm_maskz_slli_epi16
 * _mm_maskz_slli_epi32
 * _mm_maskz_slli_epi64
 * _mm_maskz_srai_epi16
 * _mm_maskz_srai_epi32
 * _mm_maskz_srai_epi64
 * _mm_maskz_srli_epi32
 * _mm_maskz_srli_epi64

It looks like clang has the same problem, though ICC and MSVC do not.  Here is
an almost identical bug report I filed against LLVM:
https://bugs.llvm.org/show_bug.cgi?id=45931


More information about the Gcc-bugs mailing list