[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Rebuilding ghc changes interface hashes?



On 09/04/11 06:16, Joachim Breitner wrote:
Hi,

Am Freitag, den 08.04.2011, 22:00 +0200 schrieb Matthias Kilian:
On Wed, Apr 06, 2011 at 08:44:33PM +0200, Matthias Kilian wrote:
I still have to find my noticeses about wether cBooterVersion affects
more than only the ghc lib.

Did a quick test the other day; bootstrapping ghc-7.0.3 from
ghc-6.12.3 with two different VERSION_DATE files. The only visible
change was in the ghc library, so this part indeed isn't worth any
work.

This is one of the changes causing a break in the base library. "-" is
bootstrapped with 7.0.2, "+" was bootstrapped with 6.12.

# diff -u<(ghc --show-iface /usr/lib/ghc-7.0.2/base-4.3.1.0/GHC/List.hi)<(ghc --show-iface /other/usr/lib/ghc-7.0.2/base-4.3.1.0/GHC/List.hi)
--- /dev/fd/63	2011-04-09 05:14:12.454269915 +0000
+++ /dev/fd/62	2011-04-09 05:14:12.454269915 +0000
@@ -5,8 +5,8 @@
  Way: Wanted [],
       got    []
  interface base:GHC.List 7002
-  interface hash: 87193984226122c2dd5964fd86876196
-  ABI hash: 8d7faf049b24c406583f0286cc44d7db
+  interface hash: d8ee4b841dafe12780c3b173e214b5c7
+  ABI hash: 180a90cd1355a939180d28fcca979825
    export-list hash: 0c27906a7932ade6018f397c78520a54
    orphan hash: 693e9af84d3dfcc71e640e005bdc5e2e
    where
@@ -151,7 +151,7 @@
                         case @ a ds of wild { [] ->  z : x xs ->  lgo (f z x) xs }
                     } in
                     lgo z0 xs0) -}
-4314014978c443774e83654e714a6768
+a018d005d4132f400d13b973d8352563
    foldr1 :: forall a. (a ->  a ->  a) ->  [a] ->  a
      {- Arity: 2, Strictness: LS,
         Unfolding: (\ @ a ds :: a ->  a ->  a ds1 :: [a] ->
@@ -161,9 +161,9 @@
                       ->  case @ a ds2 of wild1 {
                            [] ->  x
                            : ipv ipv1
-                          ->  ds x (GHC.List.foldr1_$sfoldr1 @ a ipv ipv1 ds) } }) -}
-7e3de2c9e0866b189d8f94b9801e6793
-  foldr1_$sfoldr1 :: forall a. a ->  [a] ->  (a ->  a ->  a) ->  a
+                          ->  ds x (GHC.List.foldr1_$sfoldr1 @ a ds ipv ipv1) } }) -}
+68a72d0de3128a684265d8108a56fd7b
+  foldr1_$sfoldr1 :: forall a. (a ->  a ->  a) ->  a ->  [a] ->  a
      {- Arity: 3, HasNoCafRefs, Strictness: LLL -}
  328ef6e4bc937a0ad2498240a9327c37
    foldr2 :: forall a b c. (a ->  b ->  c ->  c) ->  c ->  [a] ->  [b] ->  c
@@ -489,10 +489,10 @@
                       r :: b ->
                     c (f x y) r) -}
  "SC:GHC.List.foldr10" [ALWAYS] forall @ a
-                                      sc :: a
-                                      sc1 :: [a]
-                                      sc2 :: a ->  a ->  a
-  GHC.List.foldr1 @ a sc2 (GHC.Types.: @ a sc sc1)
+                                      sc :: a ->  a ->  a
+                                      sc1 :: a
+                                      sc2 :: [a]
+  GHC.List.foldr1 @ a sc (GHC.Types.: @ a sc1 sc2)
    = GHC.List.foldr1_$sfoldr1 @ a sc sc1 sc2
  "all/build" [ALWAYS] forall @ a
                              p :: a ->  GHC.Bool.Bool


So something about the order of arguments changed. I don’t see how that
should be influenced by the bootstrapping compiler, but I hope it is –
if it were not any rebuild of ghc would risk changing the ABI hashes...

That's right, the ABI hashes are not guaranteed to be stable, and in practice do change unpredictably. While this doesn't affect correctness, I realise it's a problem for you, and it's something we'd like to fix. The case above looks like a new one I didn't know about, so I've added it to the wiki.

In fact, I'm pretty impressed that we manage to get the same hashes even sometimes. Do you have any idea how many bits have to be in the right order for that to happen :-)

Cheers,
	Simon


Reply to: