- ghc-tickets - Haskell.org

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

06 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 06 Feb '17

06 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 05 Feb '17

05 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

[GHC] #10823: Expose keepAlive to Template Haskell
by GHC 04 Feb '17

04 Feb '17

#10823: Expose keepAlive to Template Haskell -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{keepAlive}}} is a [https://github.com/ghc/ghc/blob/efa7b3a474bc373201ab145c129262a73c86f959/co… function in TcRnMonad] that adds a {{{Name}}} to the set of {{{Name}}}s to keep when pruning out dead code. A concrete use case for exposing this to Template Haskell is in LiquidHaskell, which will soon function as a Core plugin. In LiquidHaskell, a subset of Haskell functions can be "lifted" to the logic level and used in types. For example: {{{ module Test (ok) where [lq| inline gt |] gt x y = x > y [lq| ok :: x:Int -> { v:Int | gt x v } |] ok x = x + 1 }}} LiquidHaskell runs a transformation from the {{{CoreBind}}} for {{{gt}}} to its internal representation of decidable logic. Since Core plugins are run after "dead" code is removed at the end of desugaring, and since {{{gt}}} is not exported, the {{{CoreBind}}} for {{{gt}}} would not reach the {{{CoreBinds}}} LH receives as a Core plugin. The solution for this is to be able to mark names with {{{keepAlive}}} from Template Haskell. Proposed specification: {{{ keepAlive :: Name -> Q () }}} where {{{Name}}} is a Template Haskell {{{Name}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10823> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #13229: Add -ddump-inlinings-reasoning
by GHC 04 Feb '17

04 Feb '17

#13229: Add -ddump-inlinings-reasoning -------------------------------------+------------------------------------- Reporter: nomeata | 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: -------------------------------------+------------------------------------- It always takes me a while (usually by reading the source code) that `-ddump-inlinings` is not as useful as I want it to be without `-dverbose- core2core`. This just happened to me yesterday. But the latter is very verbose! In changeset:6128b2ffbe36ed2779583e05ee9d817eaafc1c9c Ben documented this behaviour (thanks!) but it is still annoying. Can we not have a flag `-ddump-inlinings-reasoning` that enables the more verbose variant of `-ddump-inlinings` independent of `-dverbose- core2core`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13229> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13181: Introduce GHC.TypeNats module with natVal
by GHC 03 Feb '17

03 Feb '17

#13181: Introduce GHC.TypeNats module with natVal -------------------------------------+------------------------------------- Reporter: phadej | Owner: phadej Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 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: -------------------------------------+------------------------------------- See [https://mail.haskell.org/pipermail/libraries/2017-January/027615.html libraries thread] Currently we have in the GHC.TypeLits module {{{ natVal :: forall n proxy. KnowNat n => proxy n -> Integer }}} However, the result integer is never negative. Numeric.Natural module is in base since base-4.8.0.0. --- I propose that we introduce new module GHC.TypeNats with natVal and natVal' {{{ natVal :: forall n proxy. KnownNat n => proxy n -> Natural }}} and {{{ natVal' :: forall n. KnownNat n => Proxy# n -> Natural }}} and other KnownNat related terms and type families. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13181> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13186: Change EvNum to EvNum :: Natural -> EvLit
by GHC 03 Feb '17

03 Feb '17

#13186: Change EvNum to EvNum :: Natural -> EvLit -------------------------------------+------------------------------------- Reporter: phadej | 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: #8306 #8412 | #13181 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently we carry `Nat` kind as an Integer internally. Just changing the type of EvNum (and related isomorphic types like `HsTyLit` etc) does pretty far. The core problem is that we should be able to output Natural literals into Core. Also this would need change to parser, to accept only Naturals in types. Currently negative literals are caught in the renamer (due the fact that template-haskell might inject negative integers as well). This will propagate to template-haskell, changing TyLit there as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13186> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3