July 2015 - ghc-tickets

Re: [GHC] #7367: float-out causes extra allocation
by GHC 31 Jul '15

31 Jul '15

#7367: float-out causes extra allocation -------------------------------------+------------------------------------- Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > The Haskell fannkuchredux contribution of Louis Wasserman to "The > Computer Language Benchmarks Game" at shootout.alioth.debian.org times > out on the amd64 machines, but not on the i386. I can reproduce it on my > Debian amd64 machine. > > It turns out that compiling without optimisation or with a simple -O > produces a fast program, but with enourmously large heap space allocated > (10G compared with 67k on a virtual i386 machine) and also more garbage > collector activity. > > The source is below (because I don't find a way to attach the file). At > the end of the source I copied my make command line, run command line > and output produced with option -sstderr. > > --------------------- > > {{{ > {- The Computer Language Benchmarks Game > http://shootout.alioth.debian.org/ > contributed by Louis Wasserman > > This should be compiled with: > -threaded -O2 -fexcess-precision -fasm > and run with: > +RTS -N<number of cores> -RTS <input> > -} > > import Control.Concurrent > import Control.Monad > import System.Environment > import Foreign hiding (rotate) > import Data.Monoid > > type Perm = Ptr Word8 > > data F = F {-# UNPACK #-} !Int {-# UNPACK #-} !Int > > instance Monoid F where > mempty = F 0 0 > F s1 m1 `mappend` F s2 m2 = F (s1 + s2) (max m1 m2) > > incPtr = (`advancePtr` 1) > decPtr = (`advancePtr` (-1)) > > flop :: Int -> Perm -> IO () > flop k xs = flopp xs (xs `advancePtr` k) > where flopp i j = when (i < j) $ swap i j >> flopp (incPtr i) (decPtr j) > swap i j = do > a <- peek i > b <- peek j > poke j a > poke i b > > flopS :: Perm -> (Int -> IO a) -> IO a > flopS !xs f = do > let go !acc = do > k <- peekElemOff xs 0 > if k == 0 then f acc else flop (fromIntegral k) xs >> go > (acc+1) > go 0 > > increment :: Ptr Word8 -> Ptr Word8 -> IO () > increment !p !ct = do > first <- peekElemOff p 1 > pokeElemOff p 1 =<< peekElemOff p 0 > pokeElemOff p 0 first > > let go !i !first = do > ci <- peekElemOff ct i > if fromIntegral ci < i then pokeElemOff ct i (ci+1) else > do > pokeElemOff ct i 0 > let !i' = i + 1 > moveArray p (incPtr p) i' > pokeElemOff p i' first > go i' =<< peekElemOff p 0 > go 1 first > > genPermutations :: Int -> Int -> Int -> Ptr Word8 -> Ptr Word8 -> IO F > genPermutations !n !l !r !perm !count = allocaArray n $ \ destF -> do > let upd j !f run = do > p0 <- peekElemOff perm 0 > if p0 == 0 then increment perm count >> run f else do > copyArray destF perm n > increment perm count > flopS destF $ \ flops -> > run (f `mappend` F (checksum j flops) > flops) > let go j !f = if j >= r then return f else upd j f (go (j+1)) > go l mempty > where checksum i f = if i .&. 1 == 0 then f else -f > > facts :: [Int] > facts = scanl (*) 1 [1..12] > > unrank :: Int -> Int -> (Ptr Word8 -> Ptr Word8 -> IO a) -> IO a > unrank !idx !n f = allocaArray n $ \ p -> allocaArray n $ \ count -> > allocaArray n $ \ pp -> do > mapM_ (\ i -> pokeElemOff p i (fromIntegral i)) [0..n-1] > let go i !idx = when (i >= 0) $ do > let fi = facts !! i > let (q, r) = idx `quotRem` fi > pokeElemOff count i (fromIntegral q) > copyArray pp p (i+1) > let go' j = when (j <= i) $ do > let jq = j + q > pokeElemOff p j =<< peekElemOff pp (if jq <= i > then jq else jq - i - 1) > go' (j+1) > go' 0 > go (i-1) r > go (n-1) idx > f p count > > main = do > n <- fmap (read.head) getArgs > let fact = product [1..n] > let bk = fact `quot` 4 > vars <- forM [0,bk..fact-1] $ \ ix -> do > var <- newEmptyMVar > forkIO (unrank ix n $ \ p -> genPermutations n ix (min fact (ix + > bk)) p >=> putMVar var) > return var > F chksm mflops <- liftM mconcat (mapM takeMVar vars) > putStrLn $ (show chksm) ++ "\nPfannkuchen(" ++ (show n) ++ ") = " ++ > (show $ mflops) > > {- > > wurmli@noah-nofen:~/hpw/haskell/work/fannkuch$ ghc --make > -XBangPatterns -O -threaded -fllvm -rtsopts fannkuchredux.ghc-3.hs > [1 of 1] Compiling Main ( fannkuchredux.ghc-3.hs, > fannkuchredux.ghc-3.o ) > Linking fannkuchredux.ghc-3 ... > wurmli@noah-nofen:~/hpw/haskell/work/fannkuch$ ./fannkuchredux.ghc-3 +RTS > -N4 -sstderr -RTS 12 > 3968050 > Pfannkuchen(12) = 65 > 10,538,122,952 bytes allocated in the heap > 359,512 bytes copied during GC > 47,184 bytes maximum residency (2 sample(s)) > 51,120 bytes maximum slop > 4 MB total memory in use (1 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 6053 colls, 6053 par 0.16s 0.04s 0.0000s > 0.0001s > Gen 1 2 colls, 1 par 0.00s 0.00s 0.0001s > 0.0001s > > Parallel GC work balance: 40.82% (serial 0%, perfect 100%) > > TASKS: 6 (1 bound, 5 peak workers (5 total), using -N4) > > SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) > > INIT time 0.00s ( 0.00s elapsed) > MUT time 44.73s ( 11.51s elapsed) > GC time 0.16s ( 0.04s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 44.89s ( 11.55s elapsed) > > Alloc rate 235,589,887 bytes per MUT second > > Productivity 99.6% of total user, 387.3% of total elapsed > > gc_alloc_block_sync: 31024 > whitehole_spin: 0 > gen[0].sync: 0 > gen[1].sync: 0 > > -} > }}} New description: The Haskell fannkuchredux (included in nofib as fannkuch-redux) contribution of Louis Wasserman to "The Computer Language Benchmarks Game" at shootout.alioth.debian.org times out on the amd64 machines, but not on the i386. I can reproduce it on my Debian amd64 machine. It turns out that compiling without optimisation or with a simple -O produces a fast program, but with enormously large heap space allocated (10G compared with 67k on a virtual i386 machine) and also more garbage collector activity. The source is below (because I don't find a way to attach the file). At the end of the source I copied my make command line, run command line and output produced with option -sstderr. --------------------- {{{ {- The Computer Language Benchmarks Game http://shootout.alioth.debian.org/ contributed by Louis Wasserman This should be compiled with: -threaded -O2 -fexcess-precision -fasm and run with: +RTS -N<number of cores> -RTS <input> -} import Control.Concurrent import Control.Monad import System.Environment import Foreign hiding (rotate) import Data.Monoid type Perm = Ptr Word8 data F = F {-# UNPACK #-} !Int {-# UNPACK #-} !Int instance Monoid F where mempty = F 0 0 F s1 m1 `mappend` F s2 m2 = F (s1 + s2) (max m1 m2) incPtr = (`advancePtr` 1) decPtr = (`advancePtr` (-1)) flop :: Int -> Perm -> IO () flop k xs = flopp xs (xs `advancePtr` k) where flopp i j = when (i < j) $ swap i j >> flopp (incPtr i) (decPtr j) swap i j = do a <- peek i b <- peek j poke j a poke i b flopS :: Perm -> (Int -> IO a) -> IO a flopS !xs f = do let go !acc = do k <- peekElemOff xs 0 if k == 0 then f acc else flop (fromIntegral k) xs >> go (acc+1) go 0 increment :: Ptr Word8 -> Ptr Word8 -> IO () increment !p !ct = do first <- peekElemOff p 1 pokeElemOff p 1 =<< peekElemOff p 0 pokeElemOff p 0 first let go !i !first = do ci <- peekElemOff ct i if fromIntegral ci < i then pokeElemOff ct i (ci+1) else do pokeElemOff ct i 0 let !i' = i + 1 moveArray p (incPtr p) i' pokeElemOff p i' first go i' =<< peekElemOff p 0 go 1 first genPermutations :: Int -> Int -> Int -> Ptr Word8 -> Ptr Word8 -> IO F genPermutations !n !l !r !perm !count = allocaArray n $ \ destF -> do let upd j !f run = do p0 <- peekElemOff perm 0 if p0 == 0 then increment perm count >> run f else do copyArray destF perm n increment perm count flopS destF $ \ flops -> run (f `mappend` F (checksum j flops) flops) let go j !f = if j >= r then return f else upd j f (go (j+1)) go l mempty where checksum i f = if i .&. 1 == 0 then f else -f facts :: [Int] facts = scanl (*) 1 [1..12] unrank :: Int -> Int -> (Ptr Word8 -> Ptr Word8 -> IO a) -> IO a unrank !idx !n f = allocaArray n $ \ p -> allocaArray n $ \ count -> allocaArray n $ \ pp -> do mapM_ (\ i -> pokeElemOff p i (fromIntegral i)) [0..n-1] let go i !idx = when (i >= 0) $ do let fi = facts !! i let (q, r) = idx `quotRem` fi pokeElemOff count i (fromIntegral q) copyArray pp p (i+1) let go' j = when (j <= i) $ do let jq = j + q pokeElemOff p j =<< peekElemOff pp (if jq <= i then jq else jq - i - 1) go' (j+1) go' 0 go (i-1) r go (n-1) idx f p count main = do n <- fmap (read.head) getArgs let fact = product [1..n] let bk = fact `quot` 4 vars <- forM [0,bk..fact-1] $ \ ix -> do var <- newEmptyMVar forkIO (unrank ix n $ \ p -> genPermutations n ix (min fact (ix + bk)) p >=> putMVar var) return var F chksm mflops <- liftM mconcat (mapM takeMVar vars) putStrLn $ (show chksm) ++ "\nPfannkuchen(" ++ (show n) ++ ") = " ++ (show $ mflops) {- wurmli@noah-nofen:~/hpw/haskell/work/fannkuch$ ghc --make -XBangPatterns -O -threaded -fllvm -rtsopts fannkuchredux.ghc-3.hs [1 of 1] Compiling Main ( fannkuchredux.ghc-3.hs, fannkuchredux.ghc-3.o ) Linking fannkuchredux.ghc-3 ... wurmli@noah-nofen:~/hpw/haskell/work/fannkuch$ ./fannkuchredux.ghc-3 +RTS -N4 -sstderr -RTS 12 3968050 Pfannkuchen(12) = 65 10,538,122,952 bytes allocated in the heap 359,512 bytes copied during GC 47,184 bytes maximum residency (2 sample(s)) 51,120 bytes maximum slop 4 MB total memory in use (1 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 6053 colls, 6053 par 0.16s 0.04s 0.0000s 0.0001s Gen 1 2 colls, 1 par 0.00s 0.00s 0.0001s 0.0001s Parallel GC work balance: 40.82% (serial 0%, perfect 100%) TASKS: 6 (1 bound, 5 peak workers (5 total), using -N4) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.00s ( 0.00s elapsed) MUT time 44.73s ( 11.51s elapsed) GC time 0.16s ( 0.04s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 44.89s ( 11.55s elapsed) Alloc rate 235,589,887 bytes per MUT second Productivity 99.6% of total user, 387.3% of total elapsed gc_alloc_block_sync: 31024 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 -} }}} -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7367#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10717: fannkuch-redux allocations increase 10000% between 7.4.2 and 7.6.3
by GHC 31 Jul '15

31 Jul '15

#10717: fannkuch-redux allocations increase 10000% between 7.4.2 and 7.6.3 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- In a recent look at [http://home.smart-cactus.org/~ben/nofib.html historical] nofib trends I noticed that fannkuck-redux appears to regress an almost unbelievable amount in its allocations, == 7.6.3 == {{{ <<ghc: 870987952 bytes, 1668 GCs (1666 + 2), 0/0 avg/max bytes residency (0 samples), 84640 bytes GC work, 1M in use, 0.00 INIT (0.00 elapsed), 2.43 MUT (2.43 elapsed), 0.00 GC (0.00 elapsed), 0.00 GC(0) (0.00 elapsed), 0.00 GC(1) (0.00 elapsed), 1 balance :ghc>> }}} == 7.4.2 {{{ <<ghc: 74944 bytes, 1 GCs (0 + 1), 0/0 avg/max bytes residency (0 samples), 3512 bytes GC work, 1M in use, 0.00 INIT (0.00 elapsed), 2.25 MUT (2.25 elapsed), 0.00 GC (0.00 elapsed), 0.00 GC(0) (0.00 elapsed), 0.00 GC(1) (0.00 elapsed), 1 balance :ghc>> }}} Given that [FoldrBuildNotes] suggests that this test is quite sensitive to fusion, I suspect something broke here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10717> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9070: "Simplifier ticks exhausted"
by GHC 31 Jul '15

31 Jul '15

#9070: "Simplifier ticks exhausted" ----------------------------------+------------------------------------- Reporter: dermesser | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- I know nothing more than what GHC said (I'm on debian, installed from the repositories). {{{ (GHC version 7.6.3 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone base:GHC.Base.$fMonadIO_$c>>={v rJ2} [gid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 31764 }}} The code triggering the error is the code commented out in lines 52-54: {{{ 42 redis_family_raw <- getEnv redisFamilyVar 43 redis_addr <- getEnv redisAddressVar 44 redis_port <- getEnv redisPortVar 45 46 (family,redis_family) <- case (parseFamily family_raw,parseFamily redis_family_raw) of 47 (Just fam, Just rfam) -> return (fam,rfam) 48 x -> fail $ "Unknown address family: " ++ show x 49 50 sockaddr <- getSockAddr family broker_address broker_port_raw 51 52 --redis_conn <- case redis_family of 53 -- WAFamilyInet -> R.connect $ defaultConnectInfo { connectHost = redis_addr, connectPort = Service redis_port } 54 -- WAFamilyUnix -> R.connect $ defaultConnectInfo { connectPort = UnixSocket redis_addr } }}} However, this bug occurs only when compiling with cabal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9070> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9227: Coverage Condition cannot be turned off
by GHC 31 Jul '15

31 Jul '15

#9227: Coverage Condition cannot be turned off ------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Compile this program {{{ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} module Bug1 where class C a b | a -> b data A a = A data B a = B instance C (A a) (B b) }}} and observe the error message {{{ Bug1.hs:9:10: Illegal instance declaration for `C (A a) (B b)' The coverage condition fails in class `C' for functional dependency: `a -> b' Reason: lhs type `A a' does not determine rhs type `B b' In the instance declaration for `C (A a) (B b)' }}} Then read manual, sec 7.6.3.3: {{{ Both the Paterson Conditions and the Coverage Condition are lifted if you give the -XUndecidableInstances flag }}} Compile again with -XUndecidableInstances. Observe the exact same error message. Either the compiler or the documentation is wrong. I certainly hope it is the compiler, because it worked in 7.6 and was quite useful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9227> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8253: example "Core syntax" is ancient
by GHC 31 Jul '15

31 Jul '15

#8253: example "Core syntax" is ancient -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- [http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/options- debugging.html#idp39365504 User's guide section 4.19.5] has some funky "Core syntax" that (according to git blame) dates back to at least 2000, and probably longer ago than that. It could use an update. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8253> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8151: ghc-7.4.2 on OpenIndiana (Solaris) createSubprocess fails
by GHC 31 Jul '15

31 Jul '15

#8151: ghc-7.4.2 on OpenIndiana (Solaris) createSubprocess fails ----------------------------+-------------------------------------------- Reporter: troydm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Keywords: | Operating System: Solaris Architecture: x86 | Type of failure: Runtime performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+-------------------------------------------- when i'm compiling this test.hs with ghc -thread ./test.hs and then execute it i get Starting Subprocess Exit code: ExitFailure 127 This error code indicates that command isn't found (i have ghc in /usr/local/bin) and it's specified in PATH variable, however it acts as if it's not even there however if i remove -threaded flag and recompile code again, it works Starting Subprocess ghc: no input files Usage: For basic information, try the `--help' option. Exit code: ExitFailure 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8151> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #7679: Regression in -fregs-graph performance
by GHC 31 Jul '15

31 Jul '15

#7679: Regression in -fregs-graph performance -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler (NCG) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7192, #8657 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7679#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10467: user's guide description of "foreign export" is out of date
by GHC 31 Jul '15

31 Jul '15

#10467: user's guide description of "foreign export" is out of date -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The first sentence of section 8.2.1 is > When GHC compiles a module (say M.hs) which uses foreign export or foreign import "wrapper", it generates two additional files, M_stub.c and M_stub.h. GHC will automatically compile M_stub.c to generate M_stub.o at the same time. This is false at least for registerised builds, GHC produces an object file directly and its filename is `M.o` not `M_stub.o`. (I don't know what happens in the unregisterised case, but if the final object file name is actually different, that seems inconsistent.) The rest of the section makes similar references to the nonexistent `M_stub.c` and `M_stub.o`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10467> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10523: Add Monoid instance for IO
by GHC 31 Jul '15

31 Jul '15

#10523: Add Monoid instance for IO -------------------------------------+------------------------------------- Reporter: Gabriel439 | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is to add the following `Monoid` instance for `IO`: {{{#!hs instance Monoid a => Monoid (IO a) where mempty = pure mempty mappend = liftA2 mappend }}} I originally proposed this instance on the libraries mailing list a while ago: https://mail.haskell.org/pipermail/libraries/2014-November/024310.html ... and the proposal was well-received so I would like to contribute the instance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10523> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9114: Invalid UTF8 not round-tripped correctly
by GHC 31 Jul '15

31 Jul '15

#9114: Invalid UTF8 not round-tripped correctly ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As reported by Robert Bihlmeyer at http://bugs.debian.org/748125, the promised round-tripping of invalid UTF8 sequences in filenames through String does not work: ``` $ mkdir foo $ touch foo/$(echo -e '\xC0\xB7.txt') $ ghc -e 'System.Directory.getDirectoryContents "foo" >>= print . last' "7.txt" ``` The sequence 0xC8B7 is an (invalid) encoding of 37, i.e. `'7'`, so if it is mapped to `'7'`, no round-tripping is possible. (Other invalid byte sequences are round-tripped.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5