September 2018 - ghc-tickets

[GHC] #14907: Error message: (%, %) shows up when with accidental paren
by GHC 13 Oct '18

13 Oct '18

#14907: Error message: (%,%) shows up when with accidental paren -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I accidentally wrote an extra closing parens in instance declaration {{{#!hs $ ghci -ignore-dot-ghci -XRankNTypes GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Prelude> class (Category (Src f), forall xx. xx => Eq xx)) => Functor f <interactive>:1:8: error: Unexpected type ‘Category (Src f)’ In the class declaration for ‘GHC.Classes.(%,%)’ A class declaration should have form class GHC.Classes.(%,%) a b where ... Prelude> }}} `(%,%)` shouldn't show up here, same happens on 8.5.20180105 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14907> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function)
by GHC 12 Oct '18

12 Oct '18

#8763: forM_ [1..N] does not get fused (10 times slower than go function) ------------------------------+-------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Apparently idiomatic code like {{{forM_ [1.._N]}}} does not get fused away. This can give serious performance problems when unnoticed. {{{ -- Slow: forM_ [0.._N-1] $ \i -> do ... -- Around 10 times faster: loop _N $ \i -> do ... {-# INLINE loop #-} loop :: (Monad m) => Int -> (Int -> m ()) -> m () loop bex f = go 0 where go !n | n == bex = return () | otherwise = f n >> go (n+1) }}} Full code example: https://gist.github.com/nh2/8905997 - the relevant alternatives are commented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 86

[GHC] #15196: Invert floating point comparisons such that no extra parity check is required.
by GHC 12 Oct '18

12 Oct '18

#15196: Invert floating point comparisons such that no extra parity check is required. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (NCG) | Keywords: CodeGen | 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 comment pretty much explains it already: {{{ -- We have to worry about unordered operands (eg. comparisons -- against NaN). If the operands are unordered, the comparison -- sets the parity flag, carry flag and zero flag. -- All comparisons are supposed to return false for unordered -- operands except for !=, which returns true. -- -- Optimisation: we don't have to test the parity flag if we -- know the test has already excluded the unordered case: eg > -- and >= test for a zero carry flag, which can only occur for -- ordered operands. -- -- ToDo: by reversing comparisons we could avoid testing the -- parity flag in more cases. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15196> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15499: Panic in occurence analysis phase (?), getRuntimeRep
by GHC 12 Oct '18

12 Oct '18

#15499: Panic in occurence analysis phase (?), getRuntimeRep -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling this: {{{#!hs {-# LANGUAGE DataKinds, GADTs, KindSignatures #-} module Holo () where data ADT (p :: Integer) where ADT :: { a :: a , b :: Integer } -> ADT p foo = undefined {b=undefined} }}} ..yields: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): getRuntimeRep p_a29z :: Integer Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1967:18 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -v4 suggests this happend during the occurence analysis phase (log attached). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15499> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin
by GHC 12 Oct '18

12 Oct '18

#15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple typeable,knownnat | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #10348 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have the following Haskell code which uses `ghc-typelits-knownnat-0.5` package as a plugin: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -fplugin GHC.TypeLits.KnownNat.Solver #-} module Nats where import Data.Proxy (Proxy (..)) import Data.Typeable (Typeable) import GHC.TypeLits (KnownNat, type (+)) f :: forall n . (Typeable n, KnownNat n) => Proxy n -> () f _ = () f _ = f (Proxy :: Proxy (n + 1)) }}} When I try to compile this code I observe the following error message: {{{ • Could not deduce (Typeable (n + 1)) arising from a use of ‘f’ from the context: (Typeable n, KnownNat n) bound by the type signature for: f :: forall (n :: ghc-prim-0.5.2.0:GHC.Types.Nat). (Typeable n, KnownNat n) => Proxy n -> () at src/Nats.hs:13:1-57 • In the expression: f (Proxy :: Proxy (n + 1)) In an equation for ‘f’: f _ = f (Proxy :: Proxy (n + 1)) | 15 | f _ = f (Proxy :: Proxy (n + 1)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This code works for both GHC-8.2.2 and GHC-8.0.2. I found similar ticket with exactly this problem but looks like this is broken again: #10348 (bug). Originally reported at Github for `ghc-typelits-knownnat` package: * https://github.com/clash-lang/ghc-typelits-knownnat/issues/21 `ghc-typelits-knownnat` package correctly infers `KnownNat (n + 1)` constraint so GHC should be able to infer `Typeable (n + 1)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15322> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #15476: Add -fwarn-star-is-type to -Wcompat
by GHC 12 Oct '18

12 Oct '18

#15476: Add -fwarn-star-is-type to -Wcompat -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 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: -------------------------------------+------------------------------------- According to the accepted proposal https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0030-remove-star-kind.rst This change must be included in 8.8, but I think it won't do any harm to include it in GHC 8.6 as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15476> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff.
by GHC 12 Oct '18

12 Oct '18

#13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. --------------------------------------+--------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Currently GHC HEAD segfaults on Windows 64-bit when compiling `language-c-quote-0.11.7.1` package. It spits something like `Access violation in generated code when executing data at 0000000102fbcf40` (I'm using my #13108 patch here). After repeated run, when GHC hasn't recompile all files, but only part of them, it succeeds. If I delete intermediate files and repeat clean compilation, it segfaults again. Haddock always segfaults (since it always recompile all files), more details here: https://github.com/haskell/haddock/pull/568. Since these access violations consistently happen on executable data at virtual addresses above 4GB mark, this very much smells as a GHC bytecode generator/linker issue. I believe, GHC and Haddock succeed exactly when all executable addresses stay below 4GB mark. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #15603: ref6 example from StaticPointers documentation doesn't type check
by GHC 11 Oct '18

11 Oct '18

#15603: ref6 example from StaticPointers documentation doesn't type check -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- The [https://downloads.haskell.org/~ghc/8.4.3/docs/html/users_guide/glasgow_exts… #extension-StaticPointers documentation] for `StaticPointers` contains the following example. {{{ ref6 y = let x = 1 in static x }}} but this doesn't get accepted by the type checker. {{{ sp.hs:27:23: error: • ‘x’ is used in a static form but it is not closed because it has a non-closed type because it contains the type variables: ‘p_a7KP’ • In the expression: static x In the expression: let x = 1 in static x In an equation for ‘ref6’: ref6 y = let x = 1 in static x | 27 | ref6 y = let x = 1 in static x | ^^^^^^^ }}} I tested on 8.6.1, 8.4.3, 8.2.2, 8.02, 7.10.3 and all fail. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15603> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13923: Add a suppression flag to stop Typeable bindings being emitted with -ddump-simpl
by GHC 11 Oct '18

11 Oct '18

#13923: Add a suppression flag to stop Typeable bindings being emitted with -ddump- simpl -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) 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: -------------------------------------+------------------------------------- When reading core output, it is very distracting to always have to wade through a large number of bindings generated by `Typeable`. In most cases I don't care about any of these so it would be easier if there was some way to stop them being printed or being generated in the first place. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15332: lintIdUnfolding could be simpler
by GHC 11 Oct '18

11 Oct '18

#15332: lintIdUnfolding could be simpler -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4919 | Wiki Page: -------------------------------------+------------------------------------- I think that `lintIdUnfolding` could use `maybeUnfoldingTemplate` rather than the complicated linting of `DFunUnfolding`. Seeing as `maybeUnfoldingTemplate` is the thing which is used when inlining, it makes sense to use that rather than some ad-hoc reconstruction. See https://phabricator.haskell.org/D4919 for the patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15332> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1