February 2017 - ghc-tickets

[GHC] #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories
by GHC 06 Feb '17

06 Feb '17

#13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not exactly sure yet where this is coming from, but I'd like to report an warning on Windows during preprocessing phase: {{{ [00:03:39] Preprocessing library cardano-sl-0.1.0.0... [00:03:39] Warning: Can't find file "C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib/include\ghcversion.h" in directories [00:03:39] src/Pos [00:03:39] . [00:03:39] .stack-work\dist\b7fec021\build [00:03:39] .stack-work\dist\b7fec021\build [00:03:39] .stack-work\dist\b7fec021\build\autogen [00:03:39] .stack-work\dist\b7fec021\build [00:03:39] C:\OpenSSL-Win64\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include [00:03:39] C:\projects\pos-haskell-prototype\rocksdb\include [00:03:39] C:\OpenSSL-Win64\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include [00:03:39] C:\projects\pos-haskell-prototype\rocksdb\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows-ghc-8.0.1 \vector-algorithms-0.7.0.1-8R8UpWgvBC926XMxBjYPpx\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows- ghc-8.0.1\zlib-0.6.1.2-4CWLN1T27kOJhNvXgy46ZV\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\process-1.4.2.0\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows- ghc-8.0.1\vector-0.11.0.0-BEDZb5o2QOhGbIm6ky7rl6\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows-ghc-8.0.1\old- time-1.1.0.3-IcvdkJUsE9M8t3io8peAEp\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\directory-1.2.6.2\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows- ghc-8.0.1\primitive-0.6.1.0-Ip44DqhfCp21tTUYbecwa\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\time-1.6.0.1\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\Win32-2.3.1.1\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows- ghc-8.0.1\network-2.6.3.1-nK9qnsiJR03CWuPIGMmX\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\bytestring-0.10.8.1\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\base-4.9.0.0\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib \integer-gmp-1.0.0.1\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib/include [00:03:39] Asked for by: src/Pos/CLI.hs at line 2 col 1 }}} It appears to trigger for each module using cpphs. The file is present, so I suspect the problem is in unix path character in `C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib/include\ghcversion.h`. Using verbose mode we can observe that's the case: {{{ "cpphs" "-DWITH_WEB" "-DWITH_WALLET" "-include" ".stack- work\dist\ca59d0ab\build\autogen\cabal_macros.h" "--cpp" "-I" ".stack- work\dist\ca59d0ab\build" "-I" ".stack-work\dist\ca59d0ab\build" "-I" ".stack-work\dist\ca59d0ab\build\autogen" "-I" ".stack- work\dist\ca59d0ab\build" "-I" "C:\OpenSSL-Win64\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include" "-I" "C:\rocksdb\include" "-I" "C:\OpenSSL-Win64\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include" "-I" "C:\rocksdb\includ e" "-I" "C:\sr\snapshots\b3566c00\lib\x86_64-windows-ghc-8.0.2\vector- algorithms-0.7.0.1-C2u1KYklHg84I6SQQVEAin\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\zlib-0.6.1.2-7negTfm2ujt1gW4wr40MUp\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\process-1.4.2.0-KoK49SuYVPk1TQ4YVt6ZK5\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\vector-0.11.0.0-LMwQhhnXj8U3T5Bm1JFxG\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows-ghc-8.0.2\old- time-1.1.0.3-KWRsMSdY26c2L27Y9n9cyq\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\directory-1.2.6.2-qiZgXsB5o98ZsOYUWltfF\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\primitive-0.6.1.0-6AbSTw9JXz141LE5p6LGH\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\time-1.6.0.1\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\Win32-2.3.1.1\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\network-2.6.3.1-AwRxOQvT8JM9e8zDFK7aCI\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\bytestring-0.10.8. 1\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\base-4.9.1.0\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib \integer-gmp-1.0.0.1\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib/include" "-D__GLASGOW_HASKELL__=800" "-include" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib/include\ghcversion.h" "-Dmingw32_BUILD_OS=1" "-Dx86_64_BUILD_ARCH=1" "-Dmingw32_HOST_OS=1" "-Dx86_64_HOST_ARCH=1" "-D__GLASGOW_HASKELL_TH__=1" "-D_ _SSE__=1" "-D__SSE2__=1" "-includeC:\Users\ADMINI~1\AppData\Local\Temp\2\ghc2384_0\ghc_18.h" "-x" "assembler-with-cpp" "src\Pos\Binary\Crypto.hs" "-o" "C:\Users\ADMINI~1\AppData\Local\Temp\2\ghc2384_0\ghc_17.hscpp" }}} I highly suspect https://github.com/ghc/ghc/blob/master/utils/ghc- pkg/Main.hs#L1956 since it does some unclear path mungling, probably leaving undosified suffix. Note that those functions were copied from `compiler/main/SysTools.hs` which changed significantly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13166> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13235: (makeVersion [4, 9, 0, 0] <= makeVersion [4, 9]) == False
by GHC 06 Feb '17

06 Feb '17

#13235: (makeVersion [4, 9, 0, 0] <= makeVersion [4, 9]) == False -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have hit a strange bug in cabal project. Zeroes in Version have meaning, which is not logical (at least mathematically). See this example: {{{ import Data.Version makeVersion [4, 9, 0, 0] <= makeVersion [4, 9] False }}} I propose to add zeroes to the version with less numbers, so they could be equally compared. Related discussion: https://github.com/commercialhaskell/stack/issues/2948 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13235> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 06 Feb '17

06 Feb '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): I've rebased the [https://github.com/takano-akio/ghc/commits/nested-cpr branch] on top of the join points work. In nofib, allocations are generally down but the difference is not very big: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- bspt +0.0% +0.1% 0.007 0.007 0.0% compress2 +1.5% -0.9% 0.158 0.158 -3.7% fluid +1.6% -0.2% 0.007 0.007 0.0% infer +0.0% -1.2% 0.039 0.039 0.0% pic +0.1% -0.6% 0.005 0.005 0.0% solid +0.0% -6.6% 0.159 0.159 0.0% -------------------------------------------------------------------------------- Min -0.0% -6.6% -28.7% -28.8% -3.7% Max +1.6% +0.1% +4.3% +4.3% +6.7% Geometric Mean +0.1% -0.1% -14.7% -14.5% +0.0% }}} I'll look more carefully to see why the improvement is so small. I may have messed up something while rebasing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:58> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7102: Type family instance overlap accepted in ghci
by GHC 05 Feb '17

05 Feb '17

#7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: T7102a, T7102 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2994 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"0abe7361249b0b4dc43dc66547451da8916b30bf/ghc" 0abe7361/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0abe7361249b0b4dc43dc66547451da8916b30bf" Don't replace type family instances with the same LHS in GHCi (#7102) This fixes the easy part of #7102 by removing the logic that lets the user replace a type family instance with a new one with the same LHS. As discussed on that ticket, this is unsound in general. Better to have the user redefine the type family from scratch. The example from comment:7 involving loading modules into ghci is not fixed yet; it actually doesn't rely on the instances having the same LHS. This commit adds an expect_broken test for that example as well. Test Plan: T7102a for the fix; T7102 is the test not fixed yet Reviewers: dfeuer, austin, bgamari, goldfire Reviewed By: dfeuer Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D2994 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7102#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11760: runST with lazy blackholing breaks referential transparency
by GHC 05 Feb '17

05 Feb '17

#11760: runST with lazy blackholing breaks referential transparency -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A thunk created with `runST` can be evaluated twice by different threads producing different results. An example (taken from https://twitter.com/obadzz/status/714081240475951105) {{{#!hs {-# LANGUAGE RecordWildCards #-} import qualified Data.STRef.Lazy as S import Control.Monad import Control.Monad.ST.Lazy import Control.Concurrent data ListRef s a = ListRef { element :: a , readCounter :: Int , rest :: Maybe (S.STRef s (ListRef s a)) } toList :: S.STRef s (ListRef s a) -> ST s [(a, Int)] toList r = do ListRef{..} <- S.readSTRef r S.modifySTRef r $ \e -> e { readCounter = readCounter + 1 } xs <- maybe (return []) toList rest return $ (element, readCounter) : xs circularList :: ST s (S.STRef s (ListRef s Char)) circularList = do x3 <- S.newSTRef (ListRef 'c' 0 Nothing) x2 <- S.newSTRef (ListRef 'b' 0 (Just x3)) x1 <- S.newSTRef (ListRef 'b' 0 (Just x2)) S.modifySTRef x3 $ \e -> e { rest = Just x1 } return x1 l :: [(Char, Int)] l = take 15 $ runST $ circularList >>= toList main :: IO () main = do void $ forkIO $ print l void $ forkIO $ print l void getLine print l }}} The output (run multiple times to reproduce): {{{ $ ghc --make -O -threaded -outputdir=.build test.hs [1 of 1] Compiling Main ( test.hs, .build/Main.o ) Linking test ... $ ./test +RTS -N2 [('b',0),('b',0),('c',0),('b',1),('b',1),('c',1),('b',2),('b',2),('c',2),('b',3),('b',3),('c',3),('b',5),('b',4),('c',4)] [('b',0),('b',0),('c',0),('b',1),('b',1),('c',1),('b',2),('b',2),('c',2),('b',3),('b',3),('c',3),('b',4),('b',4),('c',4)] [('b',0),('b',0),('c',0),('b',1),('b',1),('c',1),('b',2),('b',2),('c',2),('b',3),('b',3),('c',3),('b',4),('b',4),('c',4)] $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1 $ }}} Note that the last 3 elements are `('b',5),('b',4),('c',4)` or `('b',4),('b',4),('c',4)`. I was able to reproduce it with few weeks old HEAD. With `-feager- blackholing` it works as expected. `unsafePerformIO` uses `noDuplicate` to prevent such kind of issue. Should `runST` do something similar? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11760> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #13234: Yesod and Persistent cause compiler panic
by GHC 05 Feb '17

05 Feb '17

#13234: Yesod and Persistent cause compiler panic ----------------------------------------+--------------------------------- Reporter: cheshircat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Hello, This is my first bug report for GHC, so excuse me if I don't have all the formatting correct, and please tell me how to correct it! I am working on a yesod app, and upon running cabal run, I got this message: {{{#!hs Preprocessing executable 'creative-index-org' for creative-index- org-0.0.0... [1 of 1] Compiling Main ( Main.hs, dist/build/creative-index- org/creative-index-org-tmp/Main.o ) <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] person_aodw :: t_aodv[tau:1] (CHoleCan: person)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I have attached Main.hs, the cabal file, and a nix-shell file (in case you use nix) that contains the environment I was running this in. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13234> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13232: Undeflow/overflow for floating-point values
by GHC 04 Feb '17

04 Feb '17

#13232: Undeflow/overflow for floating-point values -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC nicely prints overflow for bounded types: {{{#!hs Prelude Data.Word> 232312::Word8 <interactive>:2:1: warning: [-Woverflowed-literals] Literal 232312 is out of the Word8 range 0..255 120 }}} But the same courtesy isn't currently extended to floats: {{{ Prelude Data.Word> 1e5000 :: Float Infinity Prelude Data.Word> 1e-5000 :: Double 0.0 }}} It would be nice if overflow/underflow warnings were issued for floats as well. Note that with the hexadecimal floats proposal (https://github.com/LeventErkok/ghc- proposals/blob/hexFloats/proposals/0000-hexFloats.rst) this would be especially nice, making GHC a very fine platform for numeric computations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13232> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13231: ghc: panic! (the 'impossible' happened)
by GHC 04 Feb '17

04 Feb '17

#13231: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: aufheben | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- '''The crash happens during "stack build" after I updated the resolver to lts-6.30 ''' {{{ -- While building package yesod-auth-1.4.13.5 using: /Users/aufheben/.stack/setup-exe-cache/x86_64-osx/setup-Simple- Cabal-1.22.5.0-ghc-7.10.3 --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.5.0 build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /Users/aufheben/stack/iped/.stack-work/logs /yesod-auth-1.4.13.5.log Configuring yesod-auth-1.4.13.5... Building yesod-auth-1.4.13.5... Preprocessing library yesod-auth-1.4.13.5... [ 1 of 12] Compiling Yesod.PasswordStore ( Yesod/PasswordStore.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/PasswordStore.o ) /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/PasswordStore.hs:166:31: Warning: Defaulting the following constraint(s) to type ‘Integer’ (Integral b0) arising from a use of ‘^’ at Yesod/PasswordStore.hs:166:31 (Num b0) arising from the literal ‘32’ at Yesod/PasswordStore.hs:166:32-33 In the first argument of ‘(-)’, namely ‘2 ^ 32’ In the first argument of ‘(*)’, namely ‘(2 ^ 32 - 1)’ In the second argument of ‘(>)’, namely ‘(2 ^ 32 - 1) * hLen’ /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/PasswordStore.hs:419:1: Warning: Defined but not used: ‘toStrict’ /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/PasswordStore.hs:422:1: Warning: Defined but not used: ‘fromStrict’ [ 2 of 12] Compiling Yesod.Auth.Message ( Yesod/Auth/Message.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth/Message.o ) /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/Auth/Message.hs:23:1: Warning: The import of ‘mappend’ from module ‘Data.Monoid’ is redundant /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/Auth/Message.hs:698:1: Warning: Defined but not used: ‘croatianMessage’ /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/Auth/Message.hs:459:1: Warning: Pattern match(es) are overlapped In an equation for ‘finnishMessage’: finnishMessage Password = ... /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/Auth/Message.hs:459:1: Warning: Pattern match(es) are non-exhaustive In an equation for ‘finnishMessage’: Patterns not matched: CurrentPassword [ 3 of 12] Compiling Yesod.Auth.Routes ( Yesod/Auth/Routes.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth/Routes.o ) [ 4 of 12] Compiling Yesod.Auth ( Yesod/Auth.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/ghc62638_0/libghc_21.dylib, 5): no suitable image found. Did find: /var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/ghc62638_0/libghc_21.dylib: malformed mach-o: load commands size (36088) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13231> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13230: Something strange with "Don't use the splitter on Darwin"
by GHC 04 Feb '17

04 Feb '17

#13230: Something strange with "Don't use the splitter on Darwin" -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Commit 266a9dc4cd34008f1162eb276032c85ef8371842 "Don't use the splitter on Darwin" sounds like it should only affect Darwin, but the perf results indicate otherwise, even though perf.haskell.org builds are done on a linux machine: https://perf.haskell.org/ghc/#revision/266a9dc4cd34008f1162eb276032c85ef837… Total build time went up 13.7% and all nofib object sizes became much larger. I suspect the splitter was disabled completely. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13230> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13225: Fannkuch-redux time regression from join point patch
by GHC 04 Feb '17

04 Feb '17

#13225: Fannkuch-redux time regression from join point patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- According to [https://perf.haskell.org/ghc/#revision/8d5cf8bf584fd4849917c29d82dcf46ee75d… Gipeda], the join point rework caused an impressive 99.9% drop in allocations in fannkuch-redux, but an 8.57% increase in its run-time. Looking at the graph, it appears that this is not just noise. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13225> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5