On Feb 25, 2010, at 2:24 PM, David Greene wrote:> On Thursday 25 February 2010 16:17:10 David Greene wrote: >> On Thursday 25 February 2010 16:07:59 Chris Lattner wrote: >>> On Feb 25, 2010, at 12:01 PM, David Greene wrote: >>>> I am seeing a whole lot of failures in the tests on trunk. From >>>> discussions with Chris and others, I should not be seeing this. >>> >>> Does 'make check-lit' pass for you in llvm/test? >> >> Nope. In fact I am seeing more failures in debug mode now. > > And curiously, none in Release mode. No FAIL messages anyway. I > still see this: > > [x86_64-off-opt]: Expected Passes : 5006 > [x86_64-off-opt]: Expected Failures : 33 > [x86_64-off-opt]: Unsupported Tests : 66 > > [x86_64-off-dbg]: Expected Passes : 5001 > [x86_64-off-dbg]: Expected Failures : 33 > [x86_64-off-dbg]: Unsupported Tests : 66 > [x86_64-off-dbg]: Unexpected Failures: 5 > > Why would changing the test harness change the result of the tests?SDUse::setInitial should initialize List to null in your patch. You're probably seeing random uninitialized data noise without that. (Though valgrind wouldn't notice this because of the aggressive reuse of allocated memory.) Also, the replacement getOperandNo is returning the index in the use list, rather than the index in the operand array. Dan
On Feb 25, 2010, at 6:20 PM, Dan Gohman wrote:> > On Feb 25, 2010, at 2:24 PM, David Greene wrote: > >> On Thursday 25 February 2010 16:17:10 David Greene wrote: >>> On Thursday 25 February 2010 16:07:59 Chris Lattner wrote: >>>> On Feb 25, 2010, at 12:01 PM, David Greene wrote: >>>>> I am seeing a whole lot of failures in the tests on trunk. From >>>>> discussions with Chris and others, I should not be seeing this. >>>> >>>> Does 'make check-lit' pass for you in llvm/test? >>> >>> Nope. In fact I am seeing more failures in debug mode now. >> >> And curiously, none in Release mode. No FAIL messages anyway. I >> still see this: >> >> [x86_64-off-opt]: Expected Passes : 5006 >> [x86_64-off-opt]: Expected Failures : 33 >> [x86_64-off-opt]: Unsupported Tests : 66 >> >> [x86_64-off-dbg]: Expected Passes : 5001 >> [x86_64-off-dbg]: Expected Failures : 33 >> [x86_64-off-dbg]: Unsupported Tests : 66 >> [x86_64-off-dbg]: Unexpected Failures: 5 >> >> Why would changing the test harness change the result of the tests? > > SDUse::setInitial should initialize List to null in your patch. You're > probably seeing random uninitialized data noise without that. > (Though valgrind wouldn't notice this because of the aggressive reuse > of allocated memory.) > > Also, the replacement getOperandNo is returning the index in the > use list, rather than the index in the operand array.Yes. David, to clarify, what do you see with a *clean checkout* with no patches in it? -Chris
On Thursday 25 February 2010 20:40:05 Chris Lattner wrote:> Yes. David, to clarify, what do you see with a *clean checkout* with no > patches in it?This is the clean checkout. That's what the "off" means - official. -Dave
On Thursday 25 February 2010 20:20:56 Dan Gohman wrote: Wrong thread?> SDUse::setInitial should initialize List to null in your patch. You're > probably seeing random uninitialized data noise without that. > (Though valgrind wouldn't notice this because of the aggressive reuse > of allocated memory.)Why isn't the default constructor called? I would have expected that to be invoked for every new SDUse. I will fix this.> Also, the replacement getOperandNo is returning the index in the > use list, rather than the index in the operand array.Thanks. I don't have the source right in front of me. I'll take a look when I can. -Dave
On Thursday 25 February 2010 21:27:21 David A. Greene wrote:> Thanks. I don't have the source right in front of me. I'll take a look > when I can.Here's a fixed patch. It shows the same iterator errors I'm seeing with 2.5. Run make-check with a Debug+Checks compiler. I will file a bug once I have a proper internet connection. :-/ -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: sdxdebug.patch Type: text/x-patch Size: 7858 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100225/6d9e89ad/attachment.bin>