- ghc-tickets - Haskell.org

Re: [GHC] #5302: Unused arguments in join points
by GHC 02 Feb '17

02 Feb '17

#5302: Unused arguments in join points -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: => 8.4.1 Comment: This does ''not'' appear to be fixed by the join point update. The second argument is still boxed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5302#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11568: Regression in nofib/shootout/k-nucleotide
by GHC 02 Feb '17

02 Feb '17

#11568: Regression in nofib/shootout/k-nucleotide -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Fixing the `sizeExpr` bug in #11564 caused a regression in `nofib/shootout/k-nucleotide`. We don't know yet exactly which function was affected. See Phab:D1900 for details and some `-ddump-simpl` and `-ticky` dumps. We should investigate this before merging Phab:D1900 into a release. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11568> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13217: configure script uses different CFLAGS from the actual build
by GHC 02 Feb '17

02 Feb '17

#13217: configure script uses different CFLAGS from the actual build -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Keywords: autoconf | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `configure` fails to set `CFLAGS` to the value that will actually be used. This can result in checks giving wrong results. I discovered this when working on Phab:D2996, where it led to a build failure using Clang. Note that `-Werror` cannot be used during most checks in `configure`, but is necessary for `FP_CHECK_FLAG`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13217> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12817: Degraded performance with constraint synonyms
by GHC 01 Feb '17

01 Feb '17

#12817: Degraded performance with constraint synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached bug demonstrates how using constraint synonyms can negatively impact performance. I have two functions which are identical, except that one uses a constraint synonym: {{{ type CElt r = (Num r, Eq r) fooSlow :: (CElt r) => Bar r -> Bar r {-# INLINABLE fooSlow #-} fooSlow (C1 u) = either (fromEitherBar . eitherFoo) (fromEitherBar . eitherFoo) u fooSlow (C2 c) = C2 $ fooSlow c fooFast :: (Num r, Eq r) => Bar r -> Bar r {-# INLINABLE fooFast #-} fooFast (C1 u) = either (fromEitherBar . eitherFoo) (fromEitherBar . eitherFoo) u fooFast (C2 c) = C2 $ fooFast c }}} Using criterion, `fooSlow` is about 3x slower than `fooFast`. Main.hs needs `criterion` and `deepseq`, but the problem should be evident just from inspecting the core of Bar.hs, which only relies on `base`. Code was compiled with GHC-8.0.1 with `-O2`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12817> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13056: Deriving Foldable causes GHC to take a long time (GHC 8.0 ONLY)
by GHC 01 Feb '17

01 Feb '17

#13056: Deriving Foldable causes GHC to take a long time (GHC 8.0 ONLY) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This file never finishes compiling on GHC 8.0.1, and GHC 8.0.2 (dated 20161213): {{{ {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE DeriveFoldable #-} module Bug where import Data.Typeable import GHC.Generics import Data.Data data Condition v = Condition deriving (Functor, Foldable) data CondTree v c a = CondNode { condTreeData :: a , condTreeConstraints :: c , condTreeComponents :: [CondBranch v c a] } deriving (Functor, Foldable) data CondBranch v c a = CondBranch { condBranchCondition :: Condition v , condBranchIfTrue :: CondTree v c a , condBranchIfFalse :: Maybe (CondTree v c a) } deriving (Functor, Foldable) }}} The problem seems to be fixed in HEAD but I haven't looked for the commit that fixed it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13213: Lifting thunks out of thunks to reduce their size.
by GHC 01 Feb '17

01 Feb '17

#13213: Lifting thunks out of thunks to reduce their size. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a spin off of this thread: ticket:10980#comment:12 The idea is to add a transformation to STG (or Core) that replaces {{{ let t1 = let t2 = e1 in e2 in e3 }}} with {{{ let t2 = e1 t1 = e2 in e3 }}} Can we give an easy criterion when this transformation is beneficial? The problem is that this will increase allocation in the case when `t1` is not called, as it is more space efficient to pack the union of the free variables of `e1` and `e2` into one closure, instead of having one for the free variables of `e1` and one for those of `e2`. We could say “Do this transformation if the free variables of `e2` and `e1`” are disjoint. Then we’d allocate two extra words (one for the info table of `t2`, and one pointer to that in the closure for `t1`), but have some nice gains if `t1` is indeed called. But this rule would not fire in the [ticket:10980#comment:12 original example], because the `Num a` dictionary is also a free variable, which would now have to be copied into both closures! I guess one could try and see whether real-world programs benefit from this transformation, and how many shared free variables between `e1` and `e2` are heuristically ok. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13213> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 01 Feb '17

01 Feb '17

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: rwbarton Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: fixed | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3044 Wiki Page: | -------------------------------+-------------------------------------- Comment (by Doug310): Thank you team, I look forward to trying this in the next release!! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:60> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13198: incorrect links and file names in GHC user's guide
by GHC 01 Feb '17

01 Feb '17

#13198: incorrect links and file names in GHC user's guide -------------------------------------+------------------------------------- Reporter: takenobu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are some incorrect links and file names in GHC user's guide. * docs/users_guide/glasgow_exts.rst - GHC/Base.lhs - GHC/List.lhs * docs/users_guide/ffi-chap.rst - :base-ref:`Foreign` - :base-ref:`Control.Concurrent` I'll send the patch soon on phab. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13198> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10052: Panic (something to do with floatExpr?)
by GHC 01 Feb '17

01 Feb '17

#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Loading {{{ main = let (x :: String) = "hello" in putStrLn x }}} using a very simple driver for the GHC API (see T145.hs) causes a ghc panic: {{{ [1 of 1] Compiling Main ( T145-input.hs, interpreted ) T145: T145: panic! (the 'impossible' happened) (GHC version 7.10.0.20150128 for x86_64-apple-darwin): floatExpr tick <<details unavailable>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This panic is arising in our test case for #8333, so it may be related to that bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #11444: 8.0 rc1 panics in applyTypeToArgs
by GHC 01 Feb '17

01 Feb '17

#11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To reproduce, clone https://github.com/rrnewton/haskell-lockfree and switch to ghc-8.0 branch. Then run {{{cabal install atomic-primops/}}} (note the trailing slash, we don't want to install it from Hackage). It should fail with a message like this: {{{ ➜ haskell-lockfree git:(ghc-8.0) ✗ cabal install atomic-primops/ Warning: The package list for 'hackage.haskell.org' is 25.1 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... Notice: installing into a sandbox located at /home/omer/haskell/haskell-lockfree/.cabal-sandbox Configuring primitive-0.6.1.0... Building primitive-0.6.1.0... Warning: /tmp/pkgConf-primitive-0.6.110252023621350490027.0: Unrecognized field abi on line 21 Installed primitive-0.6.1.0 Configuring atomic-primops-0.8.0.2... Building atomic-primops-0.8.0.2... Failed to install atomic-primops-0.8.0.2 Build log ( /home/omer/haskell/haskell-lockfree/.cabal-sandbox/logs /atomic-primops-0.8.0.2.log ): [1 of 1] Compiling Main ( atomic-primops/dist/dist-sandbox- ad71ba7e/setup/setup.hs, atomic-primops/dist/dist-sandbox- ad71ba7e/setup/Main.o ) Linking atomic-primops/dist/dist-sandbox-ad71ba7e/setup/setup ... Configuring atomic-primops-0.8.0.2... Building atomic-primops-0.8.0.2... Preprocessing library atomic-primops-0.8.0.2... [1 of 3] Compiling Data.Atomics.Internal ( Data/Atomics/Internal.hs, dist /dist-sandbox-ad71ba7e/build/Data/Atomics/Internal.o ) Data/Atomics/Internal.hs:69:20: warning: Defined but not used: data constructor ‘Ticket’ [2 of 3] Compiling Data.Atomics.Counter ( Data/Atomics/Counter.hs, dist /dist-sandbox-ad71ba7e/build/Data/Atomics/Counter.o ) [3 of 3] Compiling Data.Atomics ( Data/Atomics.hs, dist/dist-sandbox- ad71ba7e/build/Data/Atomics.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160111 for x86_64-unknown-linux): applyTypeToArgs Expression: readMutVar# eta_s4sC st_s4sD Type: forall d_15 a_12. MutVar# d_15 a_12 -> State# d_15 -> (# State# d_15, a_12 #) Args: [eta_s4sC, st_s4sD] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: atomic-primops-0.8.0.2 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11444> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21