[PATCH] D27693: [WinEH] Avoid holding references to BlockColor (DenseMap) entries while inserting new elements

Andy Kaylor via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 12 17:50:22 PST 2016

andrew.w.kaylor created this revision.
andrew.w.kaylor added a reviewer: rnk.
andrew.w.kaylor added a subscriber: llvm-commits.
andrew.w.kaylor set the repository for this revision to rL LLVM.

I ran into a case where the spec2006/483 test was crashing during compilation because the WinEHPrepare pass was inserting a new element into a DenseMap while holding a reference to an existing element and the insertion caused the map to be reallocated.  Near as I can tell, what WinEHPrepare was doing would have been legal with an std::map but isn't guaranteed to work with DenseMap.




Index: lib/CodeGen/WinEHPrepare.cpp
--- lib/CodeGen/WinEHPrepare.cpp
+++ lib/CodeGen/WinEHPrepare.cpp
@@ -1202,8 +1202,12 @@
       Goto->setSuccessor(0, PHIBlock);
       // Update the color mapping for the newly split edge.
+      // Grab a reference to the ColorVector to be inserted before getting the
+      // reference to the vector we are copying because inserting the new
+      // element in BlockColors might cause the map to be reallocated.
+      ColorVector &ColorsForNewBlock = BlockColors[NewBlock];
       ColorVector &ColorsForPHIBlock = BlockColors[PHIBlock];
-      BlockColors[NewBlock] = ColorsForPHIBlock;
+      ColorsForNewBlock = ColorsForPHIBlock;
       for (BasicBlock *FuncletPad : ColorsForPHIBlock)
       // Treat the new block as incoming for load insertion.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D27693.81167.patch
Type: text/x-patch
Size: 958 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161213/5673752c/attachment.bin>

More information about the llvm-commits mailing list