> > 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 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
