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