June 2018 - ghc-tickets

[GHC] #14815: -XStrict prevents code inlining.
by GHC 10 Jun '18

10 Jun '18

#14815: -XStrict prevents code inlining. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Hi, let's consider the following code: {{{ {-# LANGUAGE Strict #-} -- Comment/uncommenting this {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} module K where import Control.Monad.Trans import qualified Control.Monad.State.Strict as S import Control.Monad.Primitive newtype StateT s m a = StateT (S.StateT s m a) -- S is Control.Monad.State.Strict deriving (Functor, Applicative, Monad, MonadTrans) instance PrimMonad m => PrimMonad (StateT s m) where type PrimState (StateT s m) = PrimState m primitive ~a = lift (primitive a) ; {-# INLINE primitive #-} }}} If compiled with `-XStrict` this code is not inlined properly and it badly affects the performance. While discussing it on Haskell IRC `lyxia` helped very much with discovering the CORE differences. The lazy version has couple of things which the strict version is missing in form of `[InlPrag=INLINE (sat-args=0)]` on toplevel identifiers. Core: https://gist.github.com/Lysxia/34684c9ca9fe4772ea38a5065414f542 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14815> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #15115: `Numeric.showEFloat` does not honor precision with 0 digits
by GHC 10 Jun '18

10 Jun '18

#15115: `Numeric.showEFloat` does not honor precision with 0 digits -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: | Version: 8.4.2 libraries/base | 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: -------------------------------------+------------------------------------- Hello, `Numeric.showEFloat` should display a number of digit after the dot depending on the `Maybe Int` argument. It works for values > 0: {{{#!haskell Prelude Numeric> Numeric.showEFloat (Just 5) pi "" "3.14159e0" Prelude Numeric> Numeric.showEFloat (Just 1) pi "" "3.1e0" }}} But for `0` it shows the same result as with `1`: {{{#!haskell Prelude Numeric> Numeric.showEFloat (Just 0) pi "" "3.1e0" }}} I was expecting `3e0` or `3e0`. As a matter of comparison, here is the behavior with `Numeric.showFFloat`: {{{#!haskell Prelude Numeric> Numeric.showFFloat (Just 5) pi "" "3.14159" Prelude Numeric> Numeric.showFFloat (Just 1) pi "" "3.1" Prelude Numeric> Numeric.showFFloat (Just 0) pi "" "3" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15115> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15243: -ddump-splices shenanigans: promoted tycons aren't ticked
by GHC 10 Jun '18

10 Jun '18

#15243: -ddump-splices shenanigans: promoted tycons aren't ticked -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: -------------------------------------+------------------------------------- Consider the following program with a type family that contains four different promoted (i.e., ticked) type constructors: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where data Unit = Unit $([d| type family F (a :: k) :: k where F 'Unit = 'Unit F '(,) = '(,) F '[] = '[] F '(:) = '(:) |]) }}} {{{ $ /opt/ghc/8.4.3/bin/ghci Bug3.hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug3.hs, interpreted ) Bug3.hs:(10,3)-(15,6): Splicing declarations [d| type family F_a1xJ (a_a1xL :: k_a1xK) :: k_a1xK where F_a1xJ 'Unit = 'Unit F_a1xJ '(,) = '(,) F_a1xJ '[] = '[] F_a1xJ '(:) = '(:) |] ======> type family F_a49g (a_a49i :: k_a49h) :: k_a49h where F_a49g Unit = Unit F_a49g GHC.Tuple.(,) = GHC.Tuple.(,) F_a49g '[] = '[] F_a49g (GHC.Types.:) = (GHC.Types.:) Ok, one module loaded. }}} The `-ddump-splices` output is quite strange: `'[]` is ticked, but the other three are not! This seems off. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7741: Add SIMD support to x86/x86_64 NCG
by GHC 10 Jun '18

10 Jun '18

#7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: abhir00p Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3557 | Differential Rev(s): Wiki Page: wiki:SIMD | -------------------------------------+------------------------------------- Changes (by abhir00p): * owner: (none) => abhir00p -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7741#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14804: hGetLine does not document whether newline is returned.
by GHC 10 Jun '18

10 Jun '18

#14804: hGetLine does not document whether newline is returned. -------------------------------------+------------------------------------- Reporter: akfp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Current documentation on hackage: hGetLine :: Handle -> IO String Computation hGetLine hdl reads a line from the file or channel managed by hdl. This operation may fail with: isEOFError if the end of file is encountered when reading the first character of the line. If hGetLine encounters end-of-file at any other point while reading in a line, it is treated as a line terminator and the (partial) line is returned. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14804> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15251: Add support for _mm_shuffle_pi8 intrinsic
by GHC 09 Jun '18

09 Jun '18

#15251: Add support for _mm_shuffle_pi8 intrinsic -------------------------------------+------------------------------------- Reporter: newhoggy | 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: -------------------------------------+------------------------------------- {{{!#c __m64 _mm_shuffle_pi8 (__m64 a, __m64 b) }}} See: https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm_shuf… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15247: Use empty types for TTG extension constructors
by GHC 09 Jun '18

09 Jun '18

#15247: Use empty types for TTG extension constructors -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: TTG | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I happened to be looking at `AmbiguousFieldOcc` and noticed that it has gained an `XAmbiguousFieldOcc` extension constructor for Trees That Grow, but lots of the destructor functions in `HsTypes` panic if they see this constructor (which is understandable, because they aren't expecting extensions). In general, perhaps it should be the case that for concrete phase descriptors (e.g. `GhcRn`) where extension constructors are not expected, the extension constructor argument type should be empty? It would then be clear that they should not be expected (barring abuse of laziness) and pattern matching on them could eliminate the empty type. That is, instead of the existing {{{#!hs data NoExt = NoExt type instance XXAmbiguousFieldOcc (GhcPass _) = NoExt }}} we would define {{{#!hs data NoExtConstructor -- empty data type noExtConstructor :: NoExtConstructor -> a noExtConstructor x = case x of {} type instance XXAmbiguousFieldOcc (GhcPass _) = NoExtConstructor }}} and similarly for other `XX...` type families. Alan, Shayan, is there any reason this couldn't work? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15247> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15248: Coercions from plugins cannot be stopped from floating out
by GHC 08 Jun '18

08 Jun '18

#15248: Coercions from plugins cannot be stopped from floating out -------------------------------------+------------------------------------- Reporter: goldfire | 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: -------------------------------------+------------------------------------- Suppose we have {{{#!hs type family (a :: Nat) <? (b :: Nat) :: Bool }}} that computes whether `a` is less than `b`, where a type checker plugin does the proof work. For some `a`, `b`, and `c`, if we assume `(a <? b) ~ True` and `(b <? c) ~ True`, the plugin can prove `(a <? c) ~ True`. However, GHC currently provides no way for the plugin to indicate that the proof of `(a <? c) ~ True` depends on the assumptions. This means that the plugin-produced proof evidence could potentially float out of its desired context, inviting disaster. In term of `Coercion`s, I propose that the `PluginProv` constructor of `UnivCoProvenance` be allowed to include a `TyCoVarSet` of "free variables" (that is, assumptions) in the proof. Computing the free variables of the enclosing `UnivCo` would returns these variables, too. It is, of course, up to the plugin to provide the right information here, but plugins generally have enough information to do this correctly (or, at least, to conservatively list all free variables of assumptions as free variables of the conclusion). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15248> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications
by GHC 08 Jun '18

08 Jun '18

#11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Originally reported [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010915.html here]. When applying types via `-XTypeApplications`, the type/kind that gets instantiated seems to be different depending on whether you're using functions, datatypes, or typeclasses. Here's an example contrasting functions and datatypes: {{{ $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20160106: http://www.haskell.org/ghc/ :? for help λ> :set -fprint-explicit-kinds -XTypeApplications -XTypeInType λ> data Prox a = Prox λ> prox :: Prox a; prox = Prox λ> :t prox prox :: forall k (a :: k). Prox k a λ> :t prox @Int prox @Int :: Prox * Int λ> :t Prox Prox :: forall k (a :: k). Prox k a λ> :t Prox @Int Prox @Int :: Prox Int a }}} This is the core of the problem: with a function, `Int` seems to be applied to type variable `a`, whereas with data types, `Int` appears to be applied to the kind variable `k`. This confuses me, since `k` wasn't specified anywhere in the definition of `Prox`. Andres Löh also [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010916.html observed] a similar discrepancy between functions and typeclasses: {{{ λ> :set -XScopedTypeVariables λ> class C a where c :: () λ> d :: forall a. C a => (); d = c @_ @a λ> :t d d :: forall k (a :: k). C k a => () λ> :t d @Int d @Int :: C * Int => () λ> :t c c :: forall k (a :: k). C k a => () λ> :t c @Int c @Int :: C Int a => () λ> :t c @_ @Int c @_ @Int :: C * Int => () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11376> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37

[GHC] #14783: Initializing record with similarly named field from a different record results in warning rather than error
by GHC 08 Jun '18

08 Jun '18

#14783: Initializing record with similarly named field from a different record results in warning rather than error -------------------------------------+------------------------------------- Reporter: | Owner: (none) ulrikrasmussen | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: records | Operating System: Unknown/Multiple DuplicateRecordFields | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When a record is initialized using a similarly named field from another record, the compiler ignores the initialization and generates a warning instead of throwing an error. I believe this is a bug introduced in GHC 8.0.1 (and probably related to `DuplicateRecordFields`), since earlier versions of GHC would refuse to compile the code. Consider the following example: {{{ -- A.hs module A where data A = A { a :: (), b :: () } -- B.hs module B where data B = B { a :: (), b :: () } -- Main.hs module Main where import A hiding (a) import B x = A { a = (), b = () } main = case x of A () () -> return () }}} On GHC 8.0.1, this compiles (with a warning), and the program throws an exception when run: {{{ $ stack ghc --compiler ghc-8.0.1 -- --make Main.hs [1 of 3] Compiling B ( B.hs, B.o ) [2 of 3] Compiling A ( A.hs, A.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Main.hs:5:7: warning: [-Wmissing-fields] • Fields of ‘A’ not initialised: a • In the expression: A {a = (), b = ()} In an equation for ‘x’: x = A {a = (), b = ()} Linking Main ... $ ./Main Main: Main.hs:5:7-26: Missing field in record construction a }}} On GHC 7.10.3, the program will not compile: {{{ $ stack ghc --compiler ghc-7.10.3 -- --make Main.hs [1 of 3] Compiling B ( B.hs, B.o ) [2 of 3] Compiling A ( A.hs, A.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Main.hs:5:7: Constructor ‘A’ does not have field ‘a’ In the expression: A {a = (), b = ()} In an equation for ‘x’: x = A {a = (), b = ()} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14783> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6