SUMMARY
Tried to profile some (proprietary) code  with   valgrind --tool=callgrind
FWIW this code (and valgrind for that matter) was compiled with gcc 13.2.0  with march=native on a very new x86-64 machine.


Valgrind/callgrind almost immediately aborts with

==3382909== Callgrind, a call-graph generating cache profiler
==3382909== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al.
==3382909== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==3382909== Command:  ./MYPROGRAM etc etc etc
==3382909== 
==3382909== For interactive control, run 'callgrind_control -h'.
vex amd64->IR: unhandled instruction bytes: 0x62 0xF3 0xFD 0x48 0x3A 0xC2 0x1 0x62 0xF1 0xFD
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
==3382909== valgrind: Unrecognised instruction at address 0x40242b.
==3382909==    at 0x40242B: main (main.c:32)
==3382909== Your program just tried to execute an instruction that Valgrind
==3382909== did not recognise.  There are two possible reasons for this.
==3382909== 1. Your program has a bug and erroneously jumped to a non-code
==3382909==    location.  If you are running Memcheck and you just saw a
==3382909==    warning about a bad jump, it's probably your program's fault.
==3382909== 2. The instruction is legitimate but Valgrind doesn't handle it,
==3382909==    i.e. it's Valgrind's fault.  If you think this is the case or
==3382909==    you are not sure, please let us know and we'll try to fix it.
==3382909== Either way, Valgrind will now raise a SIGILL signal which will
==3382909== probably kill your program.
==3382909== 
==3382909== Process terminating with default action of signal 4 (SIGILL)
==3382909==  Illegal opcode at address 0x40242B
==3382909==    at 0x40242B: main (main.c:32)
==3382909== 
==3382909== Events    : Ir
==3382909== Collected : 304493
==3382909== 
==3382909== I   refs:      304,493
Illegal instruction (core dumped)

I put the "unhandled instruction bytes:" i.e.  62 F3 FD 48 3A C2 01 62 F1 FD into  an online disassembler ..
   https://disasm.pro/
... and it says it's the avx512 instruction
   vinserti64x4 zmm0, zmm0, ymm2, 1

https://www.felixcloutier.com/x86/vinserti128:vinserti32x4:vinserti64x2:vinserti32x8:vinserti64x4

Am I correct in presuming this is too modern for V 3.23.0?