April 2015 - ghc-tickets

[GHC] #10160: GHCi :sprint has odd/unhelpful behavior for values defined within the REPL
by GHC 19 Apr '15

19 Apr '15

#10160: GHCi :sprint has odd/unhelpful behavior for values defined within the REPL -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Keywords: :sprint | Operating System: Unknown/Multiple thunk evaluation | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Wanted to use :sprint to help learners visualise thunk evaluation behavior in their data. Ran into some behaviors that a few people I checked with didn't have a good explanation for. I couldn't find anything in the user guide to explain this. I don't think it technically violates Haskell Report requirements, but it makes :sprint considerably less useful if you're teaching somebody non-strictness. Examples with code in the REPL: {{{ Prelude> let x = [1, 2, 3] Prelude> :sprint x x = _ Prelude> :t x x :: Num t => [t] -- this makes sense so far. Prelude> let x = [1, 2, 3 :: Integer] Prelude> :sprint x x = [1,2,3] -- errr, what? Prelude> let x = Just (1 :: Integer) Prelude> :sprint x x = Just 1 Prelude> let just = Just Prelude> let x = just (1 :: Integer) Prelude> :sprint x x = _ Prelude> let x = Just (undefined :: Integer) Prelude> :sprint x x = Just _ Prelude> let x = just (undefined :: Integer) Prelude> :sprint x x = _ Prelude> let x = [1, 2, 3 :: Integer] Prelude> let y = x Prelude> :sprint y y = [1,2,3] Prelude> let x = 1 : 2 : (3 :: Integer) : [] Prelude> :sprint x x = [1,2,3] Prelude> let x = [1] ++ [2] ++ [(3 :: Integer)] Prelude> :sprint x x = _ Prelude> let y = (:) Prelude> let x = 1 `y` (2 `y` ((3 :: Integer) `y` [])) Prelude> :sprint x x = _ Prelude> x [1,2,3] Prelude> :sprint x x = [1,2,3] }}} So the behavior here seems to be: Constructors used directly in the construction of data and are not passed functions (including polymorphic vals awaiting concrete instances)/bottoms are immediately evaluated Example, but with loading data from a file: Contents of the file: {{{ x :: Num a => [a] x = [1, 2, 3] }}} GHCi session: {{{ Prelude> :t x x :: Num a => [a] Prelude> :sprint x x = _ Prelude> x [1,2,3] Prelude> :sprint x x = _ }}} Then when x is loaded from a file, but has a different type: {{{ Prelude> :t x x :: [Integer] Prelude> :sprint x x = _ Prelude> head x 1 Prelude> :sprint x x = [1,2,3] }}} Now, this is a bit confusing. Earlier I was able to get :sprint to return [1, _, _] when I evaluated head x, but a couple hours later when I went to write this ticket, I couldn't reproduce that behavior. Is there documentation that explains: 1. Why data is shown as having been evaluated at time of declaration (seemingly) by :sprint when it's defined in the GHCi 2. Why declaring code in GHCi and loading it from a file behaves differently with :sprint (I considered let expression in the implicit GHCi do-block...couldn't find anything to explain this) 3. Why evaluating 'head x' forces the other values as well Are any of these behaviors a bug? If not, are they documented anywhere? Is the "eager" treatment of constructors in GHCi a performance thing? That seems strange given I didn't have -fobject-code turned on. :sprint not demonstrating semantics that match what I expect from a non- strict language hinders its utility as a teaching tool and means the only robust option for learners that I can find is testing evaluation with bottom values. {{{ -- So that you know i picked "7.8.4" as the version consciously [callen@atlantis ~/Work/fpbook]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.4 [callen@atlantis ~/Work/fpbook]$ ghci --version The Glorious Glasgow Haskell Compilation System, version 7.8.4 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10160> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9056: --make paths are not deduplicated
by GHC 19 Apr '15

19 Apr '15

#9056: --make paths are not deduplicated -------------------------+------------------------------------------------- Reporter: | Owner: evincarofautumn | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- I had a build script with an accidental duplicate dependency, which caused GHC to be run like so: {{{ ghc --make Main.hs Main.hs }}} This results in a spurious error from `GhcMake.checkDuplicates`: {{{ <no location info>: module ‘main:Main’ is defined in multiple files: Main.hs Main.hs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10021: Add "Error:" prefix for error-messages
by GHC 19 Apr '15

19 Apr '15

#10021: Add "Error:" prefix for error-messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Similar to what we have for "Warning:". E.g., we have: {{{ ➜ cat test.hs main = putStrLn "Hello!" ➜ ghc --make -fforce-recomp -Wall ./test.hs [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:1:1: Warning: Top-level binding with no type signature: main :: IO () Linking test ... ➜ cat test2.hs main = foo ➜ ghc --make -fforce-recomp -Wall ./test2.hs [1 of 1] Compiling Main ( test2.hs, test2.o ) test2.hs:1:8: Not in scope: ‘foo’ }}} And I propose having: {{{ ➜ cat test2.hs main = foo ➜ ghc --make -fforce-recomp -Wall ./test2.hs [1 of 1] Compiling Main ( test2.hs, test2.o ) test2.hs:1:8: Error: Not in scope: ‘foo’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10021> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

Re: [GHC] #7478: setSessionDynFlags does not always work
by GHC 18 Apr '15

18 Apr '15

#7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: ghc- Related Tickets: | api/T7478 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bherzog): I observe the same problem as [comment:8 thoughtpolice], also on a 32 bit Linux system (debian Wheezy), but with ghc master 7b042d5adabdb0fc06286db1a7f9cbf1e9fd1fbf. I have analysed it a bit and I think I have a solution or a least a work-around. On my system, the flags returned by `getSessionDynFlags` in `T7478.hs` are inconsistent with regard to dynamic vs. static linking. The `ways` list is empty, so in particular does not contain `WayDyn`, but at the same time, `Opt_Static` is not in `generalFlags`. This state of the flags is a bit contradictory, because AFAICT, there's some code that only looks at the presence of `WayDyn` when deciding whether a static or dynamic build has been requested while some other code only looks at `Opt_Static`. A missing `WayDyn` means to link statically, whereas a missing `Opt_Static` means linking dynamically. So the code expects this to be more consistent, which is also apparent from the fact that the `updateWays` function sets/unsets `Opt_Static` depending on the absence/presence of `WayDyn`. A workaround that works for me is to extend `defaultDynFlags` so that it applies `updateWays` to the `DynFlags` value it creates. I'm not sure that's the correct solution, though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7478#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9809: Overwhelming the TimerManager
by GHC 17 Apr '15

17 Apr '15

#9809: Overwhelming the TimerManager -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.9 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I was talking on IRC with davean about an issue that potentially could have been related to STM (I don't think it is at all after investigating) and I reduced the issue to the following program: {{{#!hs -- Main.hs module Main where import Control.Monad import Control.Concurrent import Control.Concurrent.STM import System.Environment main :: IO () main = do as <- getArgs case as of ["-f"] -> replicateM_ 100000 . void . forkIO . void $ registerDelay 10 _ -> replicateM_ 100000 . void $ registerDelay 10 threadDelay 1000 }}} This ends up registering a lot of events with the TimerManager. With the "-f" flag it does so from many threads and when run that way it appears to eventually overwhelm the TimerManager and causing over 350 MB total memory in use. {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.9.20141115 $ ghc -O2 -threaded -debug Main.hs -o Main-head ... $ ./Main-head -f +RTS -s 3,566,966,936 bytes allocated in the heap 4,200,021,784 bytes copied during GC 118,273,720 bytes maximum residency (96 sample(s)) 12,649,480 bytes maximum slop 354 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 6350 colls, 0 par 2.430s 2.434s 0.0004s 0.0073s Gen 1 96 colls, 0 par 7.438s 7.441s 0.0775s 0.2526s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.002s ( 0.002s elapsed) MUT time 0.461s ( 0.460s elapsed) GC time 9.869s ( 9.875s elapsed) EXIT time 0.003s ( 0.003s elapsed) Total time 10.336s ( 10.340s elapsed) Alloc rate 7,741,472,461 bytes per MUT second Productivity 4.5% of total user, 4.5% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 }}} Running without forking many threads and the total memory in use stays low (3 MB). {{{ 154,305,648 bytes allocated in the heap 16,922,272 bytes copied during GC 1,378,608 bytes maximum residency (3 sample(s)) 28,520 bytes maximum slop 3 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 298 colls, 0 par 0.056s 0.056s 0.0002s 0.0015s Gen 1 3 colls, 0 par 0.005s 0.005s 0.0017s 0.0047s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.001s ( 0.001s elapsed) MUT time 0.148s ( 0.148s elapsed) GC time 0.061s ( 0.061s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.211s ( 0.210s elapsed) Alloc rate 1,042,557,595 bytes per MUT second Productivity 70.8% of total user, 71.2% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 }}} Using 7.6.3, things don't get out of hand, also with 3 MB total memory use. {{{ $ ./Main-7.6.3 -f +RTS -s 213,519,392 bytes allocated in the heap 116,111,712 bytes copied during GC 505,080 bytes maximum residency (11 sample(s)) 113,032 bytes maximum slop 3 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 403 colls, 0 par 0.33s 0.33s 0.0008s 0.0028s Gen 1 11 colls, 0 par 0.01s 0.01s 0.0011s 0.0019s TASKS: 3 (1 bound, 2 peak workers (2 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.00s ( 0.00s elapsed) MUT time 1.99s ( 1.50s elapsed) GC time 0.34s ( 0.34s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 2.33s ( 1.84s elapsed) Alloc rate 107,426,859 bytes per MUT second Productivity 85.5% of total user, 108.1% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 }}} I looked for causes and eliminated any `STM` interactions causing problems (`STM` shows up in the `Unique` values and in creating a `TVar` for the registered delay) but did discover that the `emTimeouts` queue gets very large at some point when executing with "-f". If I print the size of `expired` on this line: https://github.com/ghc/ghc/blob/021b7978d14799bae779907faf7490cfd21b3f46/li… I end up seeing somewhere from 4 to 20 events for a while then eventually it jumps up to 80000 or so. Perhaps davean can chime in about the particular use case that he has that I reduced to this simple program for a more real world use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9809> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee
by GHC 17 Apr '15

17 Apr '15

#10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As suggested by SPJ in https://phabricator.haskell.org/D747?id=2498#inline-6057 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10180> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 17 Apr '15

17 Apr '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Fuuzetsu): Got the below in mail few days ago but I don't have time to investigate myself for next few weeks. Just putting it out there. Seems like a pretty big issue. -- Hi, trac seems to be down currently so I'm sending this directly to you. Using GHC 7.10, I reduced the code to this: {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} module Test where import Control.Monad.Trans.Reader newtype EventM a = EventM { unEventM :: ReaderT () IO a } deriving (Functor, Applicative, Monad) }}} Compiling with: {{{ ghc -i../.. test.hs -O ghc --show-iface test.hi > 1.hi ghc -i../.. test.hs -O -fforce-recomp ghc --show-iface test.hi > 2.hi }}} Now {{{1.hi}}} and {{{2.hi}}} differ, including in their ABI hash. I'm not sure if there are any other examples of nondeterminism in this module, since I continued reducing as long as GHC gave different interface hashes, I did not check whether the cause was actually the same. In this case, this seems to be the most significant difference: {{{ 512a513,517 "SPEC/Test $fApplicativeReaderT_$cpure @ () @ IO" [ALWAYS] forall $dFunctor :: Functor (ReaderT () IO) $dApplicative :: Applicative IO $fApplicativeReaderT_$cpure @ () @ IO $dFunctor $dApplicative = $fMonadEventM_$s$fApplicativeReaderT_$cpure 521,525d525 "SPEC/Test $fMonadReaderT_$creturn @ () @ IO" [ALWAYS] forall $dApplicative :: Applicative (ReaderT () IO) $dMonad :: Monad IO $fMonadReaderT_$creturn @ () @ IO $dApplicative $dMonad = $fMonadEventM_$s$fMonadReaderT_$creturn }}} If I read this correctly, it means that in one case, a specialization rule is generated for return, will in the other case, GHC generates one for pure. Looking further, there is also the following difference: {{{ $fMonadEventM_$s$fApplicativeReaderT :: Applicative (ReaderT () IO) {- HasNoCafRefs, Strictness: m, Inline: [ALWAYS] CONLIKE, Unfolding: DFun:. @ (ReaderT () IO) $fMonadEventM3 $fMonadEventM_$s$fMonadReaderT_$creturn ($fApplicativeReaderT_$c<*> @ () @ IO $fMonadEventM3 $fApplicativeIO) $fMonadEventM_$s$fApplicativeReaderT_$c*> $fMonadEventM_$s$fApplicativeReaderT_$c<* -} vs $fMonadEventM_$s$fApplicativeReaderT :: Applicative (ReaderT () IO) {- HasNoCafRefs, Strictness: m, Inline: [ALWAYS] CONLIKE, Unfolding: DFun:. @ (ReaderT () IO) $fMonadEventM3 $fMonadEventM_$s$fApplicativeReaderT_$cpure ($fApplicativeReaderT_$c<*> @ () @ IO $fMonadEventM3 $fApplicativeIO) $fMonadEventM_$s$fApplicativeReaderT_$c*> $fMonadEventM_$s$fApplicativeReaderT_$c<* -} }}} (Notice the pure vs return again) Regards, Benno -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:76> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10090: Building ghc with "make -j12" gives different ABI hashes for base to "make -j8"
by GHC 16 Apr '15

16 Apr '15

#10090: Building ghc with "make -j12" gives different ABI hashes for base to "make -j8" -------------------------------------+------------------------------------- Reporter: | Owner: juhpetersen | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Build | Operating System: Unknown/Multiple System | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- While building ghc-7.8.4 for Fedora 22 (devel) I found that doing highly parallel make builds of ghc affects the ABI hash of base, etc. The threshold seems to be between -j8 and -j12, which likely changes the build order of some modules causes changes to ABI hashes. While it is not hard to workaround, it is not really nice so it would be good to track this down IMHO. I haven't seen this kind of issue since 7.4.2 anyway so it may be an indirect buildsystem "regression" with ghc-7.8? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10090> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9180: New magic function `staticError`
by GHC 16 Apr '15

16 Apr '15

#9180: New magic function `staticError` ------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: feature request | 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: | ------------------------------------+------------------------------------- While playing games with `RULES`, I had the need for a way to tell the compiler “please spit out an error message”, in my case if list fusion fails where the user explicitly requested for it. Currently I put an `error "List did not fuse"` in the code using a `RULE`, but what I’d really like to do is to put in a `staticError "List did not fuse"` that, if appearing in Core (say, after the final simplification) causes GHC to abort and print this message. (I’m tempted to use type level strings somehow to make sure that the parameter to `staticError` is not present at the value level, and also that the string is easier to obtain. I’ll see.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9180> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5539: GHC panic - Simplifier ticks exhausted
by GHC 15 Apr '15

15 Apr '15

#5539: GHC panic - Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #8613, #9070, | Differential Revisions: #8319 | -------------------------------------+------------------------------------- Comment (by George): The preceding compiles for me on 7.10.1 on the Mac. Are there any options I need to give to ghc to make it fail? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5539#comment:61> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0