X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=compiler%2Futils%2FUniqFM.lhs;h=97f8fb45bc2501208c5d8cc12888fcbbb56fb97b;hb=8ffd91b6102f4ad3111cabdf6bdb1998f257887f;hp=642522d3e749b0ff48994ce9f1d3beaa924156cd;hpb=e7033cf34a8a478758c932d4b8cac04198531299;p=ghc-hetmet.git

diff --git a/compiler/utils/UniqFM.lhs b/compiler/utils/UniqFM.lhs
index 642522d..97f8fb4 100644
--- a/compiler/utils/UniqFM.lhs
+++ b/compiler/utils/UniqFM.lhs
@@ -643,7 +643,9 @@ functionality, but may do a few needless evaluations.
 
 \begin{code}
 mkLeafUFM :: FastInt -> a -> UniqFM a
-mkLeafUFM i a	  = LeafUFM i a
+mkLeafUFM i a =
+  ASSERT (iBox i >= 0) -- Note [Uniques must be positive]
+  LeafUFM i a
 
 -- The *ONLY* ways of building a NodeUFM.
 
@@ -848,3 +850,21 @@ use_snd :: a -> b -> b
 use_snd _ b = b
 \end{code}
 
+{- Note [Uniques must be positive]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The getCommonNodeUFMData function assumes that the nodes use
+positive uniques. Specifically, the inner `loop' shifts the
+low bits out of two uniques until the shifted uniques are the same.
+At the same time, it computes a new delta, by shifting
+to the left.
+
+The failure case I (JPD) encountered:
+If one of the uniques is negative, the shifting may continue
+until all 64 bits have been shifted out, resulting in a new delta
+of 0, which is wrong and can trigger later assertion failures.
+
+Where do the negative uniques come from? Both Simom M and
+I have run into this problem when hashing a data structure.
+In both cases, we have avoided the problem by ensuring that
+the hashes remain positive.
+-}