> I found that the mxn submatrix was always initialized at all its > entries. I did this several times, until "gdb continue" resulted > in the program completing (because of looping, the breakpoint > re-occurred several times). > > This is why I am puzzled as to why valgrind is reporting uninitialised > value(s).
Thank you for the test case. After installing lapack and blas (Fedora 17), then I see the behavior you describe. I did not get the corresponding debuginfo versions, so I have not seen inside iladr. What I did do is binary search on: ----- tsvd3.cpp // Elliminate spurious valgrind uninitialized errors #if 1 for( int iii=38; iii<lwork; ++iii ) work[iii]=123.456; #endif ----- I see no complaints when starting the loop at iii=1,2,4,8,16,32; then errors at 64,48,40; no complaint at 36; errors at 38; no complaint at 37. Hmmm... At this point it's at least somewhat reasonable to file a bug report and include the test case. The rejoinder will be that memcheck finds a real error, and the code "Eliminate ... uninit errors" is the proof. I'm not so sure. I did notice that all the complaints on x86_64 are after a 'ucomisd' instruction where the low 64 bits of the register have a double floating point value, with the high 64 bits being zero. When the other operand to ucomids also is a register, then that register often has all bits zero (128 zero bits). In most ways the operating width is 64 bits, yet the register has 128 bits. -- ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
