search for: addmodifiednodetocsemap

On Monday 01 March 2010 20:32:07 Dan Gohman wrote: > > No, what I mean is the thing under UI at the point of call to > > AddModifiedNodeToCSEMaps gets deleted. So UI is invalid and when > > we loop back around and check it against UE we blow up with a > > singular iterator error. > > UI is incremented before AddModifiedNodeToCSEMaps is called, so > I'm still not seeing what you're describing here. It's not...

...nately, any of the nodes under the iterators may change so I don't > > see an easy way to fix this. > > The thing it's iterating over is a linked list. And the use_end() iterator > is essentially a null pointer. No, what I mean is the thing under UI at the point of call to AddModifiedNodeToCSEMaps gets deleted. So UI is invalid and when we loop back around and check it against UE we blow up with a singular iterator error. I can add code to save a few values of UI, find one that "works" after AddModifiedNodeToCSEMaps and get llc to finish. But that's a horrible hack only mea...

...the iterators may change so I don't >>> see an easy way to fix this. >> >> The thing it's iterating over is a linked list. And the use_end() iterator >> is essentially a null pointer. > > No, what I mean is the thing under UI at the point of call to > AddModifiedNodeToCSEMaps gets deleted. So UI is invalid and when > we loop back around and check it against UE we blow up with a > singular iterator error. UI is incremented before AddModifiedNodeToCSEMaps is called, so I'm still not seeing what you're describing here. Dan

On Mar 2, 2010, at 8:57 AM, David Greene wrote: > On Monday 01 March 2010 20:32:07 Dan Gohman wrote: > >>> No, what I mean is the thing under UI at the point of call to >>> AddModifiedNodeToCSEMaps gets deleted. So UI is invalid and when >>> we loop back around and check it against UE we blow up with a >>> singular iterator error. >> >> UI is incremented before AddModifiedNodeToCSEMaps is called, so >> I'm still not seeing what you're describing...

On Mar 1, 2010, at 7:26 AM, David Greene wrote: > >> Perhaps this can be fixed by making the code skip the ReplaceUses >> call in the case where there are no uses to replace. That's not trivial >> to detect though. > > Why not just check the same thing the added asserts check? You mean ->getOpcode() == ISD::DELETED_NODE? That's not fundamentally any

On Friday 26 February 2010 19:09:01 Dan Gohman wrote: > I've now looked at your latest patch. In summary, it does expose a > subtle problem. I haven't seen anything that here would lead to > observable misbehavior yet though. Well, I'm definitely observing misbehavior. I know it has something to do with local changes here but I haven't isolated it yet. >