Bug 481729 - valgrind doesn't support AVX512
Summary: valgrind doesn't support AVX512
Status: RESOLVED DUPLICATE of bug 383010
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: 3.22.0
Platform: Other Other
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-02-23 16:49 UTC by H.J. Lu
Modified: 2024-02-25 02:09 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2024-02-23 16:49:05 UTC
[hjl@gnu-skx-1 valgrind-1]$ cat m.c 
#include <x86intrin.h>

extern void foo (__m512 *);

__m512 x;

int
main ()
{
  foo (&x);
  return 0;
}
[hjl@gnu-skx-1 valgrind-1]$ cat x.S
	.text
	.globl foo
foo:
	vmovdqu8 (%rdi), %zmm0
	nop
1:
	ret
	.section .note.GNU-stack,"",@progbits
[hjl@gnu-skx-1 valgrind-1]$ gcc -mavx512f m.c x.S -g
[hjl@gnu-skx-1 valgrind-1]$ valgrind ./a.out
==2885282== Memcheck, a memory error detector
==2885282== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2885282== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==2885282== Command: ./a.out
==2885282== 
vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7F 0x48 0x6F 0x7 0x90 0xC3 0x0 0xF3
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==2885282== valgrind: Unrecognised instruction at address 0x40111b.
==2885282==    at 0x40111B: ??? (x.S:4)
==2885282==    by 0x489C109: (below main) (in /usr/lib64/libc.so.6)
==2885282== Your program just tried to execute an instruction that Valgrind
==2885282== did not recognise.  There are two possible reasons for this.
==2885282== 1. Your program has a bug and erroneously jumped to a non-code
==2885282==    location.  If you are running Memcheck and you just saw a
==2885282==    warning about a bad jump, it's probably your program's fault.
==2885282== 2. The instruction is legitimate but Valgrind doesn't handle it,
==2885282==    i.e. it's Valgrind's fault.  If you think this is the case or
==2885282==    you are not sure, please let us know and we'll try to fix it.
==2885282== Either way, Valgrind will now raise a SIGILL signal which will
==2885282== probably kill your program.
==2885282== 
==2885282== Process terminating with default action of signal 4 (SIGILL)
==2885282==  Illegal opcode at address 0x40111B
==2885282==    at 0x40111B: ??? (x.S:4)
==2885282==    by 0x489C109: (below main) (in /usr/lib64/libc.so.6)
==2885282== 
==2885282== HEAP SUMMARY:
==2885282==     in use at exit: 0 bytes in 0 blocks
==2885282==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2885282== 
==2885282== All heap blocks were freed -- no leaks are possible
==2885282== 
==2885282== For lists of detected and suppressed errors, rerun with: -s
==2885282== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction (core dumped)
[hjl@gnu-skx-1 valgrind-1]$
Comment 1 Paul Floyd 2024-02-23 17:52:22 UTC

*** This bug has been marked as a duplicate of bug 383010 ***