|
From: Uttam P. <ut...@us...> - 2006-01-10 00:41:10
|
Hi Thanks for the reply. > > You've got the right place, and it's great you're testing, but as J asked in > reply to yr last post (i guess yr not subscribed): Initially my subscribe request/response email bounced back as a spam. That's why I never received an email from Julian, till this message. But now I've completed the subscribe procedure successfully. > > On Friday 06 January 2006 22:42, Julian Seward wrote: > > Thanks. Most of these are harmless - they happen on a PPC970 box > > too. We should improve our regression test mechanism so it only > > reports a failure when there really is one, but that's not as simple > > as it sounds. > > > > > none/tests/ppc32/jm-vmx (stdout) > > > none/tests/ppc32/jm-vmx (stderr) > > > none/tests/ppc32/testVMX (stdout) > > > none/tests/ppc32/testVMX (stderr) > > > > These are VMX (Altivec) tests. I presume they failed because POWER5 > > doesn't support Altivec (right?) You are right. > > > > > none/tests/ppc32/jm-insns (stdout) > > > none/tests/ppc32/jm-insns (stderr) > > > > These should not fail -- tests of the basic integer instruction set. > > Can you send > > > > none/tests/ppc32/jm-insns.stdout.diff and > > none/tests/ppc32/jm-insns.stderr.diff > > > > so we can see why they failed. Strangely, these 2 tests did pass on a PPC970, altivec supported machine but failed on power4 and power5 platform. $ cat none/tests/ppc32/jm-insns.stderr.diff *** jm-insns.stderr.exp 2005-11-25 04:36:08.000000000 -0800 --- jm-insns.stderr.out 2006-01-06 14:07:49.000000000 -0800 *************** *** 1 **** --- 2,18 ---- + disInstr(ppc32): unhandled instruction: 0x........ + primary 31(0x........), secondary 206(0x........) + Your program just tried to execute an instruction that Valgrind + did not recognise. There are two possible reasons for this. + 1. Your program has a bug and erroneously jumped to a non-code + location. If you are running Memcheck and you just saw a + warning about a bad jump, it's probably your program's fault. + 2. The instruction is legitimate but Valgrind doesn't handle it, + i.e. it's Valgrind's fault. If you think this is the case or + you are not sure, please let us know. + Either way, Valgrind will now raise a SIGILL signal which will + probably kill your program. + + Process terminating with default action of signal 4 (SIGILL) + Illegal opcode at address 0x........ + at 0x........: build_viargs_table (in /home/pawar/valgrind-3.1.0/none/tests/ppc32/jm-insns) + by 0x........: main (in /home/pawar/valgrind-3.1.0/none/tests/ppc32/jm-insns) 2) File "none/tests/ppc32/jm-insns.stdout.diff" is quite large, so sending as an attachment with this email. Thanks, Uttam |