April 2013 - ghc-tickets

[GHC] #7759: iOS patch no 14: libraries/base changes
by GHC 22 Apr '13

22 Apr '13

#7759: iOS patch no 14: libraries/base changes --------------------------------+------------------------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.6.2 | Keywords: Os: Other | Architecture: arm Failure: Building GHC failed | Blockedby: Blocking: 7724 | Related: --------------------------------+------------------------------------------- In this patch there are two changes to apply to libraries/base. 'GHC/Event/KQueue.hsc': The issue here is that the #defines EVFILT_READ and EVFILT_WRITE have the values -1 and -2. The original code translates that to {{{filterRead = Filter -1}}} which is wrong Haskell and fails to compile. The modified code produces the correct code {{{filterRead = Filter (-1)}}} 'cbits/DarwinUtils.c': This code is needed for iOS as well as Darwin, and on iOS we need to explicitly include <mach/mach_time.h> which is the correct file for Mac OS/X too. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7759> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7719: System.Timeout.timeout may leak <<timeout>> exceptions
by GHC 22 Apr '13

22 Apr '13

#7719: System.Timeout.timeout may leak <<timeout>> exceptions -------------------------+-------------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.7 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- The current implementation of {{{timeout}}} can leak {{{Timeout}}} exceptions if an asynchronous exception is delivered at the wrong time. The most worrysome such case is another {{{Timeout}}} exception raised by surrounding call to {{{timeout}}}. The following program reproduces the issue reliably for me: {{{ import System.Timeout import Control.Monad import Control.Concurrent t d = timeout d $ timeout d $ timeout d $ timeout d $ timeout d $ timeout (10^9) $ threadDelay 100 main = forever $ mapM_ t [1..200] -- > ghc -O2 -rtsopts -threaded --make TT.hs -- > ./TT +RTS -N1 -- TT: <<timeout>> }}} Context: A recent thread on {{{ghc-users}}}, starting with http://www.haskell.org/pipermail/glasgow-haskell- users/2013-February/023811.html, got me thinking about corner cases of timeout handling again. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7719> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #7760: iOS patch no 15: remove HSC2HS_EXTRA from hsc2hs's stage0 wrapper
by GHC 22 Apr '13

22 Apr '13

#7760: iOS patch no 15: remove HSC2HS_EXTRA from hsc2hs's stage0 wrapper --------------------------------+------------------------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 7.7 | Keywords: Os: Other | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- hsc2hs gets built in stage0 and stage1. The stage0 binary is used during the build, and the stage1 binary is the one that get released. The hsc2hs that gets built in stage0 is used during the build in both in stage0 and in stage1. Currently some options specific to the platform are encoded into the hsc2hs wrapper script (inplace/bin/hsc2hs) in a variable called HSC2HS_EXTRA. The problem with this is that in stage0 and stage1 we need different options. The solution is very simple: Just don't put these options into the stage0 wrapper. The build system passes the right options for whatever stage it's up to anyway when it invokes it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7760> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7844: Panic messages raised from GHCi don't include details
by GHC 22 Apr '13

22 Apr '13

#7844: Panic messages raised from GHCi don't include details -----------------------------+---------------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- In GHC built the `devel2` way, compiling the following source file through GHC causes a compiler panic: {{{ f :: (Num Int => Num) () => () f = undefined }}} {{{ [1 of 1] Compiling Main ( tmp/xxx.hs, tmp/xxx.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130416 for x86_64-unknown-linux): ASSERT failed! file compiler/types/Type.lhs line 1623 base:GHC.Num.Num{tc 2b} ghc-prim:GHC.Types.Int{(w) tc 3J} => base:GHC.Num.Num{tc 2b} ghc-prim:GHC.Prim.*{(w) tc 34d} -> ghc-prim:GHC.Prim.Constraint{(w) tc 34s} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} However, if you try to compile the same file through GHCi, you get a panic message but without the important details: {{{ Prelude> :load tmp/xxx.hs [1 of 1] Compiling Main ( tmp/xxx.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130416 for x86_64-unknown-linux): ASSERT failed! <<details unavailable>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7844> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #2132: Optimise nested comparisons
by GHC 22 Apr '13

22 Apr '13

#2132: Optimise nested comparisons --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Changes (by carter): * cc: carter.schonwald@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2132#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4101: Primitive constant unfolding
by GHC 22 Apr '13

22 Apr '13

#4101: Primitive constant unfolding -------------------------+-------------------------------------------------- Reporter: malosh | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Keywords: | Os: Unknown/Multiple Architecture: x86 | Failure: Runtime performance bug Difficulty: | Testcase: Blockedby: | Blocking: Related: | -------------------------+-------------------------------------------------- Changes (by carter): * cc: carter.schonwald@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4101#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2.
by GHC 22 Apr '13

22 Apr '13

#5615: ghc produces poor code for `div` with constant powers of 2. -------------------------+-------------------------------------------------- Reporter: Lennart | Owner: daniel.is.fischer Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1-rc1 Keywords: | Os: Unknown/Multiple Architecture: x86 | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------+-------------------------------------------------- Changes (by carter): * cc: carter.schonwald@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5615#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7848: Missing parentheses and backticks
by GHC 22 Apr '13

22 Apr '13

#7848: Missing parentheses and backticks ----------------------------------------------+----------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: ----------------------------------------------+----------------------------- In several cases, GHC does not output parentheses or backticks in error messages. For example, compiling this contrived file {{{ data A = (:&&) Int Int | A Int Int x (+) ((&)@z) ((:&&) a b) (c :&& d) (e `A` f) (A g h) = y where infixl 3 `y` y _ = (&) {-# INLINE (&) #-} {-# SPECIALIZE (&) :: a #-} (&) = x }}} gives an error message containing: {{{ x + (&@z) (:&& a b) (c :&& d) (e A f) (A g h) = y where infixl 3 y y _ = (&) {-# INLINE & #-} {-# SPECIALIZE & :: a #-} }}} Attached patch fixes this issue in several places. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7764: Link Error on windows
by GHC 21 Apr '13

21 Apr '13

#7764: Link Error on windows ------------------------+--------------------------------------------------- Reporter: Ericson2314 | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.2 | Keywords: Os: Windows | Architecture: x86 Failure: Other | Blockedby: Blocking: | Related: ------------------------+--------------------------------------------------- specific commit in question: https://github.com/Ericson2314/Codec.Archive.CnCMix/commit/eb9c843e4d56068c… When I try to compile my project I get these I get errors at link-time: {{{ C:\Program Files\Haskell Platform\2012.4.0.0\lib\base-4.5.1.0/libHSbase-4.5.1.0.a(Data__683.o):fake:(.text+0x22): undefined reference to `base_DataziData_aonsConstr_closure' C:\Program Files\Haskell Platform\2012.4.0.0\lib\base-4.5.1.0/libHSbase-4.5.1.0.a(Data__683.o):fake:(.data+0x4): undefined reference to `base_DataziData_aonsConstr_closure' collect2: ld returned 1 exit status }}} I am not using any foreign functions, and unresolved symbol seems to be part of GHC so it looks like a bug to me. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7764> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7363: runghc leaks space in IO
by GHC 21 Apr '13

21 Apr '13

#7363: runghc leaks space in IO --------------------------------------+------------------------------------- Reporter: Jafet | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: None | Version: 7.6.1 Resolution: worksforme | Keywords: Os: Unknown/Multiple | Architecture: x86_64 (amd64) Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: I can reproduce the memory usage with runghc, but also with {{{ ghc q.hs -e main }}} (perhaps when you tested, you were picking up compiled code rather than interpreting?) so I think this is just the memory usage of interpreted, non-optimised code. If you still think there's something fishy going on, please reopen and give exactly what sources you're using and what commands you're running, so that I can try to reproduce it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7363#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0