I just found a major bug in SelectionDAG. Well, I found it several weeks ago
and finally diagnosed it today.
One possible fix comes down to holding SDUses about to be processed in
a queue. But this would require the SDUse copy constructor to be public.
Why is it private and unimplemented right now? What's the assumption
that's trying to protect?
-Dave
SDUse's Prev and Next members implement a use list. Copying them probably wouldn't immediately break anything, but it wouldn't be meaningful. Dan On Feb 24, 2010, at 3:08 PM, David Greene wrote:> I just found a major bug in SelectionDAG. Well, I found it several weeks ago > and finally diagnosed it today. > > One possible fix comes down to holding SDUses about to be processed in > a queue. But this would require the SDUse copy constructor to be public. > > Why is it private and unimplemented right now? What's the assumption > that's trying to protect? > > -Dave > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Wednesday 24 February 2010 18:47:19 Dan Gohman wrote:> SDUse's Prev and Next members implement a use list. Copying them > probably wouldn't immediately break anything, but it wouldn't be > meaningful.I understand that the copied SDUse wouldn't be represented in the list, so I can understand the general reasons for making the copy constructor private. In this case, however, it _may_ be ok. I need to analyze this a bit more. If I can come up with a solution that doesn't require a copy constructor I will of course use that. I can't get a reduced testcase that breaks on trunk but I do have some debug asserts that I'll try on trunk and see if I can get something to fail. There's an iterator issue with ReplaceAllUsesOf. -Dave