May 2015 - ghc-tickets

[GHC] #10413: Incorrect offsets for array size indexing
by GHC 23 Sep '15

23 Sep '15

#10413: Incorrect offsets for array size indexing -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- There are several cases in the array code generation where a byte offset is used when a word offset is needed. For example ([https://git.haskell.org/ghc.git/blob/eb6ca851f553262efe0824b8dcbe64952de496… context]): {{{#!hs emitPrimOp dflags [res] SizeofSmallArrayOp [arg] = emit $ mkAssign (CmmLocal res) (cmmLoadIndexW dflags arg (fixedHdrSizeW dflags + oFFSET_StgSmallMutArrPtrs_ptrs dflags) (bWord dflags)) }}} This only works because `oFFSET_StgSmallMutArrPtrs_ptrs dflags` is zero. I don't have time to fix this now, but I'm reporting it so it isn't forgotten. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10413> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9970: Export more types in GHC.RTS.Flags
by GHC 23 Sep '15

23 Sep '15

#9970: Export more types in GHC.RTS.Flags -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: feature | Milestone: request | Version: 7.10.1-rc1 Priority: normal | Operating System: Unknown/Multiple Component: | Type of failure: Other libraries/base | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- There are some ADTs in {{{GHC.RTS.Flags}}} that have arguments whose types are not exported. These types are: * {{{GiveGCStats}}} (found in {{{GCFlags}}}) * {{{DoCostCentres}}} (found in {{{CCFlags}}}) * {{{DoHeapProfile}}} (found in {{{ProfFlags}}}) * {{{DoTrace}}} (found in {{{TraceFlags}}}) This makes it pretty difficult to do anything useful with them, since they can't be pattern-matched. In addition, there are some unexported type synonyms: * {{{type Time = Word64}}} * {{{type Nat = #{type unsigned int} }}} (likely a {{{Word32}}}) The Haddock docs for {{{GHC.RTS.Flags}}} don't give much of an indication of what {{{Time}}} and {{{Nat}}} are, and since they're already documented in [https://phabricator.haskell.org/diffusion/GHC/browse/master/libraries/base/… the source], they should probably be exported. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9861: ghc readme provides out of date git clone directions
by GHC 23 Sep '15

23 Sep '15

#9861: ghc readme provides out of date git clone directions -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: phab:D555 -------------------------------------+------------------------------------- as first pass to fixing this, i've put a patch up on phab -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9861> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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] #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