is_valid_utf8 assumes avx2 support implies avx support about bytestring

[Bodigrim]

FWIW Intel says that AVX2 always implies AVX: https://www.intel.com/content/www/us/en/support/articles/000058796/processors.html
Sounds like a misconfigured VM to me.

[AndreasPK]

FWIW Intel says that AVX2 always implies AVX: https://www.intel.com/content/www/us/en/support/articles/000058796/processors.html Sounds like a misconfigured VM to me.

That makes sense and brings some sanity to this.

I'm not so sure that my system really supports avx2. I compiled other code snippets that should prove that avx/avx2 are supported and these examples suggest that avx2 is also not supported:

Based on your comment here jgm/pandoc#8947 (comment) it seems your setup somehow reports avx2 support while crashing if avx instructions are used. At this point this seems most likely to be an qemu issue not a haskell/bytestring one. I will close this ticket.

[clyring]

It's very surprising that avx2 does not imply avx. Would you like to prepare the patch?

[Bodigrim]

According to https://en.wikipedia.org/wiki/CPUID#EAX=1:_Processor_Info_and_Feature_Bits, one has to run __get_cpuid_count(1, 0, &eax, &ebx, &ecx, &edx); and test 28th bit of ecx to determine avx support. @AndreasPK could you check that it solves the issue? It's highly unexpected that avx is unsupported while avx2 is.

[benz0li]

It's highly unexpected that avx is unsupported while avx2 is.

I agree. @freijon runs [a possibly custom-built] QEMU (v6.2.0) on a Windows host (x86_64) with WHPX acceleration (-accel whpx).

Cross reference: When using qemu-system-x86_64 whpx acceleration, cpu information is set strangely. (#1137) · Issues · QEMU / QEMU · GitLab

[freijon]

I upgraded to QEMU 8.1.0-rc2 (on scoop) which doesn't change anything.

I'm not so sure that my system really supports avx2. I compiled other code snippets that should prove that avx/avx2 are supported and these examples suggest that avx2 is also not supported:

Source

AVX

#include <immintrin.h>
#include <stdio.h>

int main() {

  /* Initialize the two argument vectors */
  __m256 evens = _mm256_set_ps(2.0, 4.0, 6.0, 8.0, 10.0, 12.0, 14.0, 16.0);
  __m256 odds = _mm256_set_ps(1.0, 3.0, 5.0, 7.0, 9.0, 11.0, 13.0, 15.0);

  /* Compute the difference between the two vectors */
  __m256 result = _mm256_sub_ps(evens, odds);

  /* Display the elements of the result vector */
  float* f = (float*)&result;
  printf("%f %f %f %f %f %f %f %f\n",
    f[0], f[1], f[2], f[3], f[4], f[5], f[6], f[7]);

  return 0;
}

Compile with:
gcc -mavx -o hello_avx hello_avx.c

./hello_avx
[1] 879 illegal hardware instruction ./hello_avx

AVX2

#include <immintrin.h>
#include <stdio.h>

int main() {

  int i;
  
  int int_array[8] = {100, 200, 300, 400, 500, 600, 700, 800};
  
  /* Initialize the mask vector */
  __m256i mask = _mm256_setr_epi32(-20, -72, -48, -9, -100, 3, 5, 8);

  /* Selectively load data into the vector */
  __m256i result = _mm256_maskload_epi32(int_array, mask);
  
  /* Display the elements of the result vector */
  int* res = (int*)&result;
  printf("%d %d %d %d %d %d %d %d\n", 
    res[0], res[1], res[2], res[3], res[4], res[5], res[6], res[7]);
  
  return 0;
}

Compile with:
gcc -mavx2 -o mask_load mask_load.c

❯ ./mask_load
[1] 798 illegal hardware instruction ./mask_load

Both instructions result in an illegal hardware instruction.

Unless the second snippet also includes AVX code, this suggests that AVX2 is not supported as well. But I'm no expert on this topic.