Summary: | Unrecognised instruction __ieee754_pow_sse2 | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Martin Liška <marxin.liska> |
Component: | general | Assignee: | Julian Seward <jseward> |
Status: | REPORTED --- | ||
Severity: | normal | CC: | darkdefende, tom |
Priority: | NOR | ||
Version: | 3.9.0.SVN | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | libm.so |
Description
Martin Liška
2013-06-09 17:17:36 UTC
Hmm, I am not sure what this instruction is. We have pretty comprehensive coverage in the trunk so I am a bit surprised it is not supported. Can you use objdump -d on /lib64/libm-2.15.so to find the instruction (or just email the /lib64/libm-2.15.so to me directly) I'm decoding things right then there is a three byte VEX prefix followed by 0x6B which is an IMUL instruction. After I met the problem, I recompiled my glibc library with enabled FMA4 instead of SSE2. FMA4 works for me. Original libm.so library was taken from gentoo stage3 archive and I will add it as an attachment. Created attachment 80920 [details]
libm.so
I don't think that is the libm.so you were using, as it has no __ieee754_pow_sse2 symbol in it... Unfortunately, I recompiled that library and old one was overwritten. What about googling source code (probably assembler) for __ieee754_pow_sse2? Link: http://sterlingdesktops.com/pub/slack-stuff/glibc-2.15/glibc-2.15/sysdeps/x86_64/fpu/multiarch/e_pow.c That's not going to help because an SSE2 routine can't be explicitly using an instruction with a VEX prefix as VEX is a much newer processor feature than SSE2. I assume that __ieee754_pow_sse2 is a C routine with either SSE2 intrinsics, or fragments of inline assembly, and that your compiler chose to use a VEX instruction for one of the C bits because of the compiler flags you had chosen. OK, so please close the bug as invalid, maybe the libm.so library taken from gentoo distribution was compiled with some strange CFLAGS that mixed SSE2 with newer VEX instructions. Thanks, Martin The bug's not invalid though. As far as we know this was an entirely valid instruction that the compiler was perfectly entitled to generate and that valgrind just happens not to support. This is almost certainly an AMD-specific extension (XOP or some such) since (a) this is an AMD cpu, and (b) we have very comprehensive Intel coverage up to and including AVX2. I have this problem also with Valgrind 3.10.1 on my Gentoo system. I do also believe that this is a AMD-specific extension. Would it help if I posted my "libm-2.20.so" file? If there is any other info/files I can provide to help, I'll be glad to do so. |