|
From: Gaetano M. <me...@gm...> - 2010-02-22 16:59:10
|
> > The following test case is able
> > to reproduce the error:
> >
> > #include<ipps.h>
> > int main() {
> > const int mySize = 1024;
>> Ipp32f* myRealVector = ippsMalloc_32f(mySize);
> > Ipp32f myResult = 0.0;
> > ippsStdDev_32f(myRealVector, mySize,
> > &myResult, ippAlgHintFast);
> > }
> >
> > the function ippsStdDev_32f is a function in the Intel IPP library.
> > I'm running my test on a RedHat 5.4 64bit
> Thank you for isolating that test case.
> Please post a complete copy of the actual error message from valgrind.
> The message contains several hexadecimal bytes which are
> the actual instruction bytes which are not recognized.
> Knowing those instruction bytes enables diagnosis and fixing
> without requiring access to the Intel IPP library.
> Not all developers have that library.
I didn't see that hexadecimal bytes because I got the screen filled
with ( I had to kill valgrind (3.5.0) with a -9 signal )
==2142== valgrind: Unrecognised instruction at address 0x57c0340.
==2142== Your program just tried to execute an instruction that Valgrind
==2142== did not recognise. There are two possible reasons for this.
==2142== 1. Your program has a bug and erroneously jumped to a non-code
==2142== location. If you are running Memcheck and you just saw a
==2142== warning about a bad jump, it's probably your program's fault.
==2142== 2. The instruction is legitimate but Valgrind doesn't handle it,
==2142== i.e. it's Valgrind's fault. If you think this is the case or
==2142== you are not sure, please let us know and we'll try to fix it.
==2142== Either way, Valgrind will now raise a SIGILL signal which will
==2142== probably kill your program.
and the hexadecimal values were reported only on first two of those blocks,
this is first error block with the values you asked me reported:
vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0x5A 0x6 0x48 0xF
==2142== valgrind: Unrecognised instruction at address 0x57c0340.
==2142== Your program just tried to execute an instruction that Valgrind
==2142== did not recognise. There are two possible reasons for this.
==2142== 1. Your program has a bug and erroneously jumped to a non-code
==2142== location. If you are running Memcheck and you just saw a
==2142== warning about a bad jump, it's probably your program's fault.
==2142== 2. The instruction is legitimate but Valgrind doesn't handle it,
==2142== i.e. it's Valgrind's fault. If you think this is the case or
==2142== you are not sure, please let us know and we'll try to fix it.
==2142== Either way, Valgrind will now raise a SIGILL signal which will
==2142== probably kill your program.
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
|
|
From: John R. <jr...@bi...> - 2010-02-22 18:46:20
|
On 02/22/2010 08:59 AM, Gaetano Mendola wrote: >>> ippsStdDev_32f(myRealVector, mySize, > vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0x5A 0x6 0x48 0xF Disassembling the first 4 bytes gives: rex.W cvtps2pd (%rsi),%xmm0 The problem is: "What is the meaning of the rex.W prefix on cvtps2pd?" The Intel manual http://www.intel.com/Assets/PDF/manual/253666.pdf (Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 2A: Instruction Set Reference, A-M, December 2009) lists the four instructions: 66 0F 5A cvtpd2ps 0F 5A cvtps2pd F2 0F 5A cvtsd2ss F3 0F 5A cvtss2sd but there is no explicit listing for "48 0F 5A". The opcode cvtps2pd (0F 5A) is "convert two packed 32-bit floating point values in %xmm2/mem (source) to two packed 64-bit floating point values in %xmm1 (destination)". It is unclear what applying a rex.W prefix means. Does anybody know? -- |