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
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
