August 2015 - ghc-tickets

[GHC] #10438: GHC 7.10.1 panic due to PartialTypeSignatures, TypeFamilies, and local bindings
by GHC 23 Sep '15

23 Sep '15

#10438: GHC 7.10.1 panic due to PartialTypeSignatures, TypeFamilies, and local bindings -------------------------------------+------------------------------------- Reporter: rpglover64 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE TypeFamilies #-} module Bad where foo f = g where g r = x where x :: _ x = r }}} When compiled, it produces the following output: {{{ [1 of 1] Compiling Bad ( src/Bad.hs, src/Bad.o ) src/Bad.hs:8:22: Warning: Found hole ‘_’ with type: w_1 Where: ‘w_1’ is a rigid type variable bound by the inferred type of g :: w_1 -> w_1 at src/Bad.hs:7:9 Relevant bindings include r :: w_1 (bound at src/Bad.hs:7:11) g :: w_1 -> w_1 (bound at src/Bad.hs:7:9) f :: t (bound at src/Bad.hs:6:5) foo :: t -> w_ -> w_ (bound at src/Bad.hs:6:1) In the type signature for ‘x’: _ In an equation for ‘g’: g r = x where x :: _ x = r In an equation for ‘foo’: foo f = g where g r = x where x :: _ x = r ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): StgCmmEnv: variable not found x_alC local binds for: f_sv5 r_sv6 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10438> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10652: Better cache performance in Array#
by GHC 23 Sep '15

23 Sep '15

#10652: Better cache performance in Array# -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: feature | Milestone: request | Version: 7.10.1 Priority: normal | Operating System: Unknown/Multiple Component: Compiler | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- A common use case for arrays is to loop over them, performing an operation on each element of the array. For `ByteArray#`s, this is guaranteed to have good cache performance: When element `i` is accessed, the CPU's prefetcher will ensure that the element `i+1` is already sitting in cache, so the next loop will not suffer a cache miss. Currently, the `Array#` and `SmallArray#` types do not significantly benefit from the prefetcher. This feature request asks for a few new primops that would improve the situation. My understanding is that the "raw" element in an `Array#` is actually a pointer to the region in memory associated with the "logical" element of the array. When looping, the subsequent pointers are guaranteed to get prefetched, but the subsequent logical element is not guaranteed to be prefetched. In particular, if we'll only get the benefits of prefetching on the logical elements if we're lucky enough that the memory manager happened to allocate these logical elements on the heap next to each other. I don't know enough about GHC internals to check the source code, but my experiments demonstrate that this is not currently happening in my use case, resulting in rather significant performance degradations. (The experiments are rather complicated, so I'm not attaching them.) I propose adding the primops: {{{ packArray# :: Array# a -> b -> b packSmallArray# :: SmallArray# a -> b -> b packMutableArray# :: MutableArray# s a -> State# s -> State# s packSmallMutableArray# :: SmallMutableArray# s a -> State# s -> State# s }}} These operations would have the semantic effect of noops, with the exception that they request that the logical elements in the arrays be arranged adjacently in memory. Thus, future loops over the arrays would benefit from CPU prefetching. There are a number of ways the memory manager could handle these requests, and I don't particular care which is chosen. For example, the memory manager could rearrange the memory immediately or wait until the next garbage collection pass and do it then. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10652> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8213: Bad error message when using lazy IO to read from closed handle
by GHC 22 Sep '15

22 Sep '15

#8213: Bad error message when using lazy IO to read from closed handle ------------------------------------+-------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- Today I accidentally wrote this code: {{{ filesEqual :: FilePath -> FilePath -> IO Bool filesEqual f1 f2 = do equal <- withBinaryFile f1 ReadMode $ \f1 -> withBinaryFile f2 ReadMode $ \f2 -> c1 <- BSL.hGetContents h1 c2 <- BSL.hGetContents h2 return (c1 == c2) return $! equal }}} The problem is that I should have done the forcing before the files are closed: {{{ return $! (c1 == c2) }}} I got the incredibly unhelpful error message {{{ myprogram: myfile.txt: illegal operation }}} It took me 2 hours and strace to find out what was going on, especially because around every file open() there are multiple things that map top IllegalOperation (e.g. the ENOTTY from the ioctl that checks whether the device is a TTY). Can we give a better error message here, at least mentioning that the problem has to do with closed (and GC'd) handles? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8213> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9927: Should simplifier try more iterations?
by GHC 22 Sep '15

22 Sep '15

#9927: Should simplifier try more iterations? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When compiling with the `devel1` build, we get debugging output while building libraries. I see a lot of warnings like this: {{{ WARNING: file compiler/simplCore/SimplCore.hs, line 592 Simplifier bailing out after 4 iterations [5024, 247, 22, 1] Size = {terms: 3,735, types: 3,028, coercions: 216} }}} It looks to me like the simplifier is doing quite a nice job and shouldn't give up so soon. Concretely, I propose: increase the cutoff and see what the effect is on timing of running the entire GHC build, at whatever settings a performance guru thinks appropriate (almost certainly ''not'' `devel1`!). Ideally, the testing would take place on ghcspeed, so that it's a controlled environment and can be compared nicely with historical performance. I have not carried out this proposal myself because I'm not sure if there are other issues at work here (I don't know the simplifier much at all), and I don't know if there is even a way to get ghcspeed to do this for us. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9927> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8665: RELEASE_LOCK: I do not own this lock
by GHC 21 Sep '15

21 Sep '15

#8665: RELEASE_LOCK: I do not own this lock ----------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- Got this error running the latest version of Yesod: {{{ Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 devel.hs: internal error: RELEASE_LOCK: I do not own this lock: rts/Capability.c 431 (GHC version 7.6.3 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Exit code: ExitFailure 6 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8665> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8645: Improper response from GHCI terminal after importing Gnuplot package
by GHC 21 Sep '15

21 Sep '15

#8645: Improper response from GHCI terminal after importing Gnuplot package ---------------------------------+------------------------------------- Reporter: pankajsejwal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: ghci, gnuplot | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ---------------------------------+------------------------------------- I recently tried one simple example on plotting using Haskell wrapper for Gnuplot on ubuntu using this example:[http://www.linuxquestions.org/questions/blog/hydramax-533365 /quick-and-dirty-plotting-with-haskell-gnuplot-35230/] . It works fine, but after I close the graph window and type anything in GHCI terminal, it doesn't show it being typed. On entering text and pressing return it executes it in a normal way. I tried with unloading all modules but to no avail. Has someone else faced it earlier ? GHC : 7.6.3 Linux : Ubuntu 12 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8645> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9615: GHC panic: Loading temp shared object failed
by GHC 21 Sep '15

21 Sep '15

#9615: GHC panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (Seemingly) Randomly happened when building with cabal (before many builds were fine in the same project): {{{ <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc6776_0/ghc6776_359.so: undefined symbol: ganetizm2zi12_GanetiziUtils_newUUID1_info }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9615> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9704: GHC fails with "Loading temp shared object failed"
by GHC 21 Sep '15

21 Sep '15

#9704: GHC fails with "Loading temp shared object failed" -------------------------------------+------------------------------------- Reporter: MaxGabriel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: 9074 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- While developing Yesod project on GHC 7.8.3, `cabal install --force- reinstalls` failed with the following error: {{{ [9 of 9] Compiling Application ( Application.hs, dist/dist-sandbox- e4ea4713/build/Application.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/qk/6s42bj3n6g30fyqf6mc2x_c80000gn/T/ghc13386_0/ghc13386_53.dylib, 9): Symbol not found: _aesonzm0zi8zi0zi1_DataziAesonziTypesziInternal_zdsfromList1_closure Referenced from: /var/folders/qk/6s42bj3n6g30fyqf6mc2x_c80000gn/T/ghc13386_0/ghc13386_53.dylib Expected in: flat namespace in /var/folders/qk/6s42bj3n6g30fyqf6mc2x_c80000gn/T/ghc13386_0/ghc13386_53.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: MyBlog-0.0.0 failed during the building phase. The exception was: ExitFailure 1 }}} (Full output at https://gist.github.com/MaxGabriel/847561107e4ee2e869f1. Verbose output at https://gist.github.com/MaxGabriel/10c2c3c253815b3f392a) Following compilation, both aeson-0.8.0.1 and aeson-0.8.0.2 are present in the sandbox. Running `cabal install` again yields the same error (full output at https://gist.github.com/MaxGabriel/9aa530105d68a613de11) The code for the project as it was when the panic happened is available here: https://github.com/MaxGabriel/MyBlog-GHC-Panic Is there more information I could provide to diagnose the bug? I'll probably wipe the sandbox and try recompiling in a bit. Version info: OS : OS X 10.10 (14A389) (Yosemite) Cabal: cabal-install version 1.20.0.3 using version 1.20.0.1 of the Cabal library GHC: The Glorious Glasgow Haskell Compilation System, version 7.8.3 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9906: Warning generated by hscpp code have unhelpful file names
by GHC 21 Sep '15

21 Sep '15

#9906: Warning generated by hscpp code have unhelpful file names -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've started seeing this when compiling cabal with 7.8.3: {{{ [64 of 80] Compiling Distribution.Simple.GHC ( Distribution/Simple/GHC.hs, dist/build/Distribution/Simple/GHC.o ) /var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp:270:1: Warning: The import of ‘LibraryName’ from module ‘Distribution.Simple.LocalBuildInfo’ is redundant /var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp:308:1: Warning: The import of ‘Language’ from module ‘Language.Haskell.Extension’ is redundant /var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp:318:1: Warning: The import of ‘getTemporaryDirectory, getDirectoryContents’ from module ‘System.Directory’ is redundant /var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp:325:1: Warning: The import of ‘System.IO’ is redundant except perhaps to import instances from ‘System.IO’ To import instances alone, use: import System.IO() /var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp:1092:5: Warning: Pattern match(es) are non-exhaustive In an equation for ‘supportRPaths’: Patterns not matched: Ghcjs [65 of 80] Compiling Distribution.Simple.GHCJS ( Distribution/Simple/GHCJS.hs, dist/build/Distribution/Simple/GHCJS.o ) }}} The `/var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp` file name isn't really helpful. I haven't seen this before so I'm guessing this is a regression. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9906> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9978: DEBUG is always replaced as 1 when CPP pragma is on
by GHC 21 Sep '15

21 Sep '15

#9978: DEBUG is always replaced as 1 when CPP pragma is on -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Trying to compile the following code: {{{ {-# LANGUAGE CPP #-} data Level = DEBUG }}} results in error: {{{ Test.hs:2:14: Illegal literal in type (use DataKinds to enable): 1 }}} which is of course an error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9978> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3