April 2014 - ghc-tickets

Re: [GHC] #7942: aarch64 support in ghc
by GHC 22 Apr '14

22 Apr '14

#7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 7623, 8664 --------------------------------------------+------------------------------ Changes (by thoughtpolice): * status: patch => closed * version: 7.6.3 => * resolution: => fixed * related: => 7623, 8664 * blockedby: 7623, 8664 => Comment: This has been merged in c29bf984dd20431cd4344e8a5c444d7a5be08389 - thank you Colin! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8141: Liberalising IncoherentInstances
by GHC 21 Apr '14

21 Apr '14

#8141: Liberalising IncoherentInstances ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As [http://www.haskell.org/pipermail/glasgow-haskell- users/2013-July/022651.html|SPJ argued], -XIncoherentInstances could be even more liberal. This ticket is to give the proposal a number; I am currently preparing a patch for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8141> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8987: TH: panic in reportWarning when the message throws an exception
by GHC 21 Apr '14

21 Apr '14

#8987: TH: panic in reportWarning when the message throws an exception -----------------------------------+--------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- `reportWarning` and `reportError` doesn't force it's argument, so `ghc` panics when printing the message. To reproduce: {{{#!haskell test :: Q [Dec] test = do reportWarning undefined return [] }}} Output: {{{ main.hs:5:3: Warning:ghc: panic! (the 'impossible' happened) (GHC version 7.8.1 for x86_64-unknown-linux): Prelude.undefined Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The fix could be: {{{ --- a/compiler/typecheck/TcSplice.lhs +++ b/compiler/typecheck/TcSplice.lhs @@ -875,8 +875,8 @@ instance TH.Quasi (IOEnv (Env TcGblEnv TcLclEnv)) where ; let i = getKey u ; return (TH.mkNameU s i) } - qReport True msg = addErr (text msg) - qReport False msg = addWarn (text msg) + qReport True !msg = addErr (text msg) + qReport False !msg = addWarn (text msg) qLocation = do { m <- getModule ; l <- getSrcSpanM }}} But possibly it should `deepseq` the argument? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8987> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles
by GHC 21 Apr '14

21 Apr '14

#7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by bernalex): * cc: ekmett (added) * status: new => patch Comment: I added my patches for this here per SPJ's suggestion. The signum patch does not work. I do not know why. It must be due to GHC internals, because the function itself is fine as may be verified by copying {{{ signumFix x | x == 0.0 = x | isNaN x = x | x > 0.0 = 1 | otherwise = negate 1 }}} into a file signumfix.hs and :l signumfix.hs into GHCi. signumFix (-0.0 :: Float) will now return -0.0, where Prelude.signum returns 0.0 with the same argument. Here is a core dump of me invoking my Prelude.signum after building GHC/GHCi with my patches: {{{ Prelude> abs (-0.0 :: Float) ==================== Simplified expression ==================== let { it_aqt :: GHC.Types.Float [LclId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=False, Arity=0, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 70 0}] it_aqt = GHC.Num.abs @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Num.negate @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Types.F# (__float 0.0))) } in GHC.Base.thenIO @ () @ [()] (System.IO.print @ GHC.Types.Float GHC.Float.$fShowFloat it_aqt) (GHC.Base.returnIO @ [()] (GHC.Types.: @ () (it_aqt `cast` (UnivCo representational GHC.Types.Float () :: GHC.Types.Float ~# ())) (GHC.Types.[] @ ()))) 0.0 Prelude> signum (-0.0 :: Float) ==================== Simplified expression ==================== let { it_aKQ :: GHC.Types.Float [LclId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=False, Arity=0, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 70 0}] it_aKQ = GHC.Num.signum @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Num.negate @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Types.F# (__float 0.0))) } in GHC.Base.thenIO @ () @ [()] (System.IO.print @ GHC.Types.Float GHC.Float.$fShowFloat it_aKQ) (GHC.Base.returnIO @ [()] (GHC.Types.: @ () (it_aKQ `cast` (UnivCo representational GHC.Types.Float () :: GHC.Types.Float ~# ())) (GHC.Types.[] @ ()))) 0.0 }}} Please note that the abs patch works well and is likely ready to go. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7858#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 20 Apr '14

20 Apr '14

#7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: Resolution: | Keywords: thread-local Operating System: MacOS X | state, TLS clang Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by thoughtpolice): For those who didn't follow the list: - Mark Seaborn, a !Chromium/NaCl engineer, stated that they have this exact same problem in Native Client on 64bit OS X. In particular, they came up with the same solution I did essentially: inline the fast path of `pthread_{get,set}specific`. Their code is more robust than my patch however, as it's actually paranoid enough to check the machine code and bail otherwise: https://src.chromium.org/viewvc/native_client/trunk/src/native_client/src/t… I think this is probably the best approach at the moment - Renato Golin, the proposer of the initial change, updated me to say that their updated proposal does include register variables for general purpose registers (GPRs), but it's only one part of the overall set of changes, which will take more time (their particular motivation now seems to be as a principled approach to defining `__builtin_return_address` and friends at the moment). However, they understand that proposal doesn't accommodate our design, and would like us to give more feedback as they evolve the work to support true register variables. So, in the long haul, I think things will get better here. In the mean time, I think this is a signal that we should go ahead and jump on the fast-path-inline change I spoke of in comment 13. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 19 Apr '14

19 Apr '14

#7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: Resolution: | Keywords: thread-local Operating System: MacOS X | state, TLS clang Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by thoughtpolice): I did not see Edward's reply. I instead posted my own summary for the LLVM people: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-April/072313.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 19 Apr '14

19 Apr '14

#7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: Resolution: | Keywords: thread-local Operating System: MacOS X | state, TLS clang Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by ezyang): I went ahead and posted mail; hasn't showed up in the archives yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7789: GHCI core dumps when used with VTY
by GHC 19 Apr '14

19 Apr '14

#7789: GHCI core dumps when used with VTY -------------------------------------+------------------------------------ Reporter: timthelion | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: GHCi | Version: 7.4.2-rc1 Resolution: | Keywords: core dump Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by George): * cc: george.colpitts@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7789#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7789: GHCI core dumps when used with VTY
by GHC 19 Apr '14

19 Apr '14

#7789: GHCI core dumps when used with VTY -------------------------------------+------------------------------------ Reporter: timthelion | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: GHCi | Version: 7.4.2-rc1 Resolution: | Keywords: core dump Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by George): * cc: hvr (added) Comment: On 7.8.2 on Mac OS 10.9.2 compiling and loading this gives: {{{ ghc(57163,0x10f787000) malloc: *** error for object 0x7f9ffa501270: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort trap: 6 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7789#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD)
by GHC 19 Apr '14

19 Apr '14

#7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by George): * cc: george.colpitts@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7651#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0