Created attachment 81678 [details] crash output I'm running into un-handled instructions, due to -O2 flag (program runs when flag is omitted). This happens on both a pgi c compiler and gnu c compiler. $uname -a: Linux nid02382 2.6.32.59-0.7.1_1.0401.6845-cray_gem_c #1 SMP Thu Feb 21 21:03:43 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $proc/cpuinfo | grep flags flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_goo| 19 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow cons model name : AMD Opteron(TM) Processor 6274
Almost certainly an amd-specific instruction.
It is vpcmov part of the AMD XOP and FMA4 Instructions. https://en.wikipedia.org/wiki/XOP_instruction_set http://support.amd.com/us/Embedded_TechDocs/43479.pdf
Not sure if you guys need more info or potential patch tests from me, if so, let me know. I posted a similar crash output here: http://old.nabble.com/question-on-valgrind's-configure-and-build-process-tc35866077.html
*** Bug 327285 has been marked as a duplicate of this bug. ***
I am affected by the same here: > uname -a Linux lisa 4.3.3-gentoo #1 SMP PREEMPT Fri Jan 8 07:01:39 CET 2016 x86_64 AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G AuthenticAMD GNU/Linux > cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 56 model name : AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G stepping : 1 cpu MHz : 1700.000 cache size : 2048 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 16 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb bpext arat cpb hw_pstate proc_feedback npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall fsgsbase bmi1 xsaveopt bugs : fxsave_leak sysret_ss_attrs Any news about this bug?
using valgrind-3.11.0
This is a AMD specific XOP instruction VPCMOV described in http://support.amd.com/TechDocs/43479.pdf
Created attachment 121654 [details] support vpcmov Hi, I've been hitting this one recently and it's in a lot of my system libraries, so I added vpcmov support. After I wrote this patch I poked around the bug tracker and realized I wrote a broken XOP decoding patch for TBM bextr under a different account nearly six years ago. It was ignored for a while and by the time it got any attention from maintainers I had stopped relying on libvex internals for work. The bug was later consolidated to another issue (https://bugs.kde.org/show_bug.cgi?id=381819); there was modest traffic about 2 years ago, but I wasn't copied on it. Since there wasn't any progress at the time, I changed my compiler settings to use bdver1 to avoid XOP TBM instructions so it never came up again for me. My understanding is there's now a VEX encoding for bextr. The new attached patch piggybacks on PFX_VEX, introducing ESC_M8 instead of incorrectly reusing the VEX ESC constants and adding PFX_XOP; it correctly handles the pop case where XOP decoding should be abandoned. Adding the alternative XOP bextr encoding from the other issue should be simple once there's an XOP decode path. Thanks.
Note there is a more generic XOP bug, also with patch at https://bugs.kde.org/show_bug.cgi?id=339596
I'll give the patch a go.
(In reply to Paul Floyd from comment #10) > I'll give the patch a go. After reworking it to resolve merge conflicts.
The merge conflict is minor. The resteer params need to be removed. There's still a small issue with CPU detection. The testcase builds and runs on an Intel CPU under Valgrind but the xop test exe generates sigill when running standalone.
I also need to look more at #339596 (which has XOP and FMA4 but FMA4 already got added in #369000). As Mark has commented, finding suitable hardware is difficult. I just looked at a AMD EPYC 7773X box ant it no longer has xop. Here is a patch for the feature test for any eventual regression test diff --git a/tests/x86_amd64_features.c b/tests/x86_amd64_features.c index 488f155b6..33fd55d2d 100644 --- a/tests/x86_amd64_features.c +++ b/tests/x86_amd64_features.c @@ -127,6 +127,10 @@ static Bool go(char* cpu) level = 1; cmask = (1 << 27) | (1 << 28); require_xgetbv = True; + } else if (strcmp (cpu, "amd64-xop" ) == 0) { + level = 0x80000001; + cmask = 1 << 11; + require_amd = True; } else if (strcmp (cpu, "amd64-fma4" ) == 0) { level = 0x80000001; cmask = 1 << 16;