X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=compiler%2Futils%2FUniqFM.lhs;h=cc2d066ab761896f15e54e176b4b2259fdb46cd8;hb=d436c70d43fb905c63220040168295e473f4b90a;hp=642522d3e749b0ff48994ce9f1d3beaa924156cd;hpb=e7033cf34a8a478758c932d4b8cac04198531299;p=ghc-hetmet.git diff --git a/compiler/utils/UniqFM.lhs b/compiler/utils/UniqFM.lhs index 642522d..cc2d066 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. @@ -801,8 +803,8 @@ getCommonNodeUFMData (NodeUFMData i p) (NodeUFMData i2 p2) | p <# p2 = getCommonNodeUFMData_ p2 (j `quotFastInt` (p2 `quotFastInt` p)) j2 | otherwise = getCommonNodeUFMData_ p j (j2 `quotFastInt` (p `quotFastInt` p2)) where - j = i `quotFastInt` (shiftL1 p) - j2 = i2 `quotFastInt` (shiftL1 p2) + !j = i `quotFastInt` (shiftL1 p) + !j2 = i2 `quotFastInt` (shiftL1 p2) getCommonNodeUFMData_ :: FastInt -> FastInt -> FastInt -> NodeUFMData @@ -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. +-}