December 2017 - ghc-tickets

[GHC] #13422: INLINE CONLIKE sometimes fails to inline
by GHC 20 Feb '18

20 Feb '18

#13422: INLINE CONLIKE sometimes fails to inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #7206 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I got surprisingly poor results from the `cheapBuild` experiment (see #7206), so I decided to try a simple example. {{{#!hs foo :: Int -> Int foo n = s + p where nums = [1..n] s = sum nums p = product nums }}} The idea is that we want `nums` to inline into `s` and `p`; the lost sharing is unimportant. Unfortunately, this didn't fuse. I got {{{ -- RHS size: {terms: 44, types: 31, coercions: 0, joins: 2/3} $wfoo :: Int# -> Int# $wfoo = \ (ww_s2HT :: Int#) -> let { nums_s2Gq :: [Int] nums_s2Gq = eftInt 1# ww_s2HT } in joinrec { $wgo_s2HP :: [Int] -> Int# -> Int# $wgo_s2HP (w_s2HJ :: [Int]) (ww1_s2HN :: Int#) = case w_s2HJ of { [] -> joinrec { $wgo1_s2HI :: [Int] -> Int# -> Int# $wgo1_s2HI (w1_s2HC :: [Int]) (ww2_s2HG :: Int#) = case w1_s2HC of { [] -> +# ww1_s2HN ww2_s2HG; : y_a2F9 ys_a2Fa -> case y_a2F9 of { I# y1_a2Gf -> jump $wgo1_s2HI ys_a2Fa (*# ww2_s2HG y1_a2Gf) } }; } in jump $wgo1_s2HI nums_s2Gq 1#; : y_a2F9 ys_a2Fa -> case y_a2F9 of { I# y1_a2EX -> jump $wgo_s2HP ys_a2Fa (+# ww1_s2HN y1_a2EX) } }; } in jump $wgo_s2HP nums_s2Gq 0# -- RHS size: {terms: 10, types: 4, coercions: 0, joins: 0/0} foo :: Int -> Int foo = \ (w_s2HQ :: Int) -> case w_s2HQ of { I# ww1_s2HT -> case $wfoo ww1_s2HT of ww2_s2HX { __DEFAULT -> I# ww2_s2HX } } }}} I verified that `cheapBuild` actually appeared (in `-dverbose-core2core`), but it didn't fuse, and ultimately inlined. Interestingly, forcing the argument manually fixed the problem: {{{#!hs foo :: Int -> Int foo !n = s + p where nums = [1..n] s = sum nums p = product nums }}} produces {{{#!hs $wfoo :: Int# -> Int# $wfoo = \ (ww_s2Ia :: Int#) -> case tagToEnum# (># 1# ww_s2Ia) of { False -> joinrec { $wgo_s2I6 :: Int# -> Int# -> Int# $wgo_s2I6 (w_s2I0 :: Int#) (ww1_s2I4 :: Int#) = case tagToEnum# (==# w_s2I0 ww_s2Ia) of { False -> jump $wgo_s2I6 (+# w_s2I0 1#) (+# ww1_s2I4 w_s2I0); True -> let { x_X2Fz :: Int# x_X2Fz = +# ww1_s2I4 w_s2I0 } in joinrec { $wgo1_s2HY :: Int# -> Int# -> Int# $wgo1_s2HY (w1_s2HS :: Int#) (ww2_s2HW :: Int#) = case tagToEnum# (==# w1_s2HS ww_s2Ia) of { False -> jump $wgo1_s2HY (+# w1_s2HS 1#) (*# ww2_s2HW w1_s2HS); True -> +# x_X2Fz (*# ww2_s2HW w1_s2HS) }; } in jump $wgo1_s2HY 1# 1# }; } in jump $wgo_s2I6 1# 0#; True -> 1# } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13422> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11427: TypeSynonyms not deduced
by GHC 20 Feb '18

20 Feb '18

#11427: TypeSynonyms not deduced -------------------------------------+------------------------------------- Reporter: phadej | 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: -------------------------------------+------------------------------------- {{{ class (AllF f xs, SListI xs) => All (f :: k -> Constraint) (xs :: [k]) instance #if __GLASGOW_HASKELL__ >= 710 {-# OVERLAPPING #-} #endif All SListI xss => SingI (xss :: [[k]]) where sing = sList }}} fails with {{{ • Could not deduce (SListI xss) arising from the superclasses of an instance declaration from the context: All SListI xss bound by the instance declaration at src/Generics/SOP/Constraint.hs:141:3-40 • In the instance declaration for ‘SingI xss’ }}} See https://travis-ci.org/well-typed/generics-sop/jobs/102388817 and https://github.com/phadej/generics-sop/tree/ghc-8.0.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #14312: Head does not build on Windows with the default make config.
by GHC 19 Feb '18

19 Feb '18

#14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Cloning head and just running: {{{ ./boot ./configure --enable-tarballs-autodownload make }}} Fails since at least two weeks and still does as of a4ee28978acbcf68da9dfb6f198cb6e1ff38ccca The main issue is the directory library fails to build. Creating a build.mk file and setting the Flavour to quick GHC does build as expected. What triggers the failure seems to be the windows.h file created by the directory library which in some way includes itself in a loop until the preprocessor/c-compiler gives up. Renaming the file locally seems to be a viable workaround. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14312> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #11791: Remove the `isInlinePragma prag` test
by GHC 19 Feb '18

19 Feb '18

#11791: Remove the `isInlinePragma prag` test -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11781, #5928 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a spin off of tickjet:11781#comment:9, where simonpjs writes: > What is more mysterious to me is why the unfolding for `$fApplicativeIO_$c*>` doesn't have `bindIO`, and then `bindIO` inlined into it, which would allow a cascade of further improvements, which would, I think, produce essentially the same code as `thenIO`. > > The offending corner is this > {{{ > active_unfolding_gentle id > = isInlinePragma prag -- WHY?? > && isEarlyActive (inlinePragmaActivation prag) > }}} > So I tried removing the `isInlinePragma prag` test, and indeed the code becomes identical. > > Conclusion: > * I'd love to make the above change to `active_unfolding_gentle` and see if any other performance numbers budge. I doubt that anything will change a lot -- it really only affects whether optimisation happens before or after inlining -- but it should improve compiler performance a bit for that very reason. This could be a separate ticket > > Incidentally, see #5928 which is somewhat related. This ticket tracks that idea. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11791> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13994: STG lint failure on master
by GHC 18 Feb '18

18 Feb '18

#13994: STG lint failure on master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- As of 4700baaf8f9bf3c44a53a595d840c7c14cfd6f98 building with this `build.mk` results in an STG lint failure, {{{ BuildFlavour = devel2 include mk/flavours/$(BuildFlavour).mk GhcLibHcOpts += -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lint GhcRtsHcOpts += -g3 GhcStage2HcOpts += -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lint }}} The failures occurs while building `libraries/integer-gmp/dist- install/build/GHC/Integer/Type.o` and are of the form, {{{ *** Stg Lint ErrMsgs: in Stg2Stg *** <no location info>: warning: [in body of lambda with binders m0_scBi :: State# s_a2Ej -> State# s_a2Ej, s1_scBj :: State# s_a2Ej] s'_scBk is out of scope <no location info>: warning: [RHS of $j1_sdij :: (# BigNat, GmpLimb# #)] Let(rec) binder ‘$j1_sdij’ has unlifted type ‘(# BigNat, GmpLimb# #)’ RHS: (elided for brevity) <no location info>: warning: [RHS of $j4_sdQ1 :: (# BigNat, BigNat #)] Let(rec) binder ‘$j4_sdQ1’ has unlifted type ‘(# BigNat, BigNat #)’ RHS: (elided) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13994> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened)
by GHC 18 Feb '18

18 Feb '18

#13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: build | Blocked By: relational-query with ghc 8.0.2 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, this seems a regression of ghc 8.0.2 since 8.0.1 was building it fine: https://launchpadlibrarian.net/303858976/buildlog_ubuntu-zesty-amd64 .haskell-relational-query_0.8.3.2-2build1_BUILDING.txt.gz as you can see in the build log: Preprocessing test suite 'sqls' for relational-query-0.8.3.2... [1 of 3] Compiling Model ( test/Model.hs, dist-ghc/build/sqls /sqls-tmp/Model.o ) [2 of 3] Compiling Lex ( test/Lex.hs, dist-ghc/build/sqls /sqls-tmp/Lex.o ) [3 of 3] Compiling Main ( test/sqlsEq.hs, dist-ghc/build/sqls /sqls-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone runReaderT To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 405365 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug /usr/share/cdbs/1/class/hlibrary.mk:147: recipe for target 'build-ghc- stamp' failed make: *** [build-ghc-stamp] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 thanks, Gianfranco -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13185> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #9429: Alternative to type family Any
by GHC 18 Feb '18

18 Feb '18

#9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 9097, 9380 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In GHC HEAD, `Any` is no longer a datatype. There are good reasons for this change, one of which was explained in #9097, the original ticket, and another in #9380. Unfortunately, a casualty of this change is that it is no longer easy to generalize the [https://hackage.haskell.org/package/rank1dynamic|rank1dynamic package] to rank-1 types with type variables of arbitrary kind (not just `*`). We submitted a way to do so [here], that exploits the fact that `Any` has the very magical property of inhabiting *all* kinds, including closed ones. This works for GHC 7.8, but won't work in HEAD, because we require that there exists a `Typeable` instance for `Any`, just as there are `Typeable` instances for any other type one wishes to have instances for. The reason is that now that `Any` is a type family, `Any` is no longer a legal instance head. There are several possible solutions that I see: * while it's clearly dangerous for the compiler to be inserting the old `Any` during typechecking from the moment that we have computation in types over closed kinds, we may still want the old `Any`, say under a different name, as a backdoor. It wouldn't be used by the compiler during type checking - only by packages such as rank1dynamic. I believe that furthermore, if we restrict the old `Any` to not inhabit closed kinds, then none of the problems cited in the above tickets arise. * Instead of making the new `Any` a type family, keep it a datatype, but ban it from inhabiting closed kinds. I don't know if such an `Any` would be sufficient for the purposes of GHC, however. * Hardwire a `Typeable` instance for the `Any` type family (not sure if this makes sense). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #13852: Can we have more SIMD primops, corresponding to the untapped AVX etc. instructions?
by GHC 17 Feb '18

17 Feb '18

#13852: Can we have more SIMD primops, corresponding to the untapped AVX etc. instructions? -------------------------------------+------------------------------------- Reporter: | Owner: (none) leftaroundabout | Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (LLVM) | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [http://hackage.haskell.org/package/ghc-prim-0.5.0.0/docs/GHC- Prim.html#g:28 GHC.Prim] contains a good couple of vectorised instructions, which can be [http://hackage.haskell.org/package/primitive- simd-0.1.0.0/docs/Data-Primitive-SIMD.html used by libraries] for generating nice fast e.g. sums of floating-point vectors. However, several instructions that modern processors could vectorise are missing there. In particular, I would like to be able to use the VPSLLVD...VPSRAVD shifting operations, and at some point perhaps VPMAXSQ...VPMINUQ maximum/minimum operations. It would be great if corresponding primops could be added. Else I would like to know – where is this stuff even defined? [http://hackage.haskell.org/package/ghc- prim-0.5.0.0/docs/src/GHC.Prim.html GHC.Prim] as such seems to be merely an automatically-generated dummy module, mostly for Haddock. (On the other hand, I find it also a bit strange that there are primops for [http://hackage.haskell.org/package/ghc-prim-0.5.0.0/docs/GHC- Prim.html#v:quotInt8X16-35- integer division], which is apparently [https://stackoverflow.com/questions/16822757/sse-integer-division not supported by SSE/AVX] at all!) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13852> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13943: Compiler infinite loop with GHC-8.2
by GHC 15 Feb '18

15 Feb '18

#13943: Compiler infinite loop with GHC-8.2 -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 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: -------------------------------------+------------------------------------- GHC-8.0.1 compile this module in less than one seconds on my machine. Both GHC-8.2rc2 and GHC-8.2rc3 eat all 8GB of memory and don't show any signs of stopping. -dshow-passes shows this: {{{ [1 of 1] Compiling Data.List.Unrolled ( unrolled.hs, unrolled.o ) *** Parser [Data.List.Unrolled]: !!! Parser [Data.List.Unrolled]: finished in 0.00 milliseconds, allocated 3.434 megabytes *** Renamer/typechecker [Data.List.Unrolled]: }}} and then nothing. Only memory consumption grows. Code: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE GADTs #-} module Data.List.Unrolled where import GHC.TypeLits -- | Drop @n@ elements from a list class Drop (n :: Nat) where drop :: [a] -> [a] instance {-# OVERLAPPING #-} Drop 0 where drop xs = xs {-# INLINE drop #-} instance {-# OVERLAPPABLE #-} (Drop (n - 1)) => Drop n where drop [] = [] drop (_ : xs) = drop @(n - 1) xs {-# INLINE drop #-} -- | Take @n@ elements from a list class Take (n :: Nat) where take :: [a] -> [a] instance {-# OVERLAPPING #-} Take 0 where take _ = [] {-# INLINE take #-} instance {-# OVERLAPPABLE #-} (Take (n - 1)) => Take n where take [] = [] take (x : xs) = x : take @(n - 1) xs {-# INLINE take #-} -- | Split list at @n@-th element. splitAt :: forall (n :: Nat) a. (Take n, Drop n) => [a] -> ([a], [a]) splitAt xs = (take @n xs, drop @n xs) -- | Split list into chunks of the given length @c@. @n@ is length of the list. class ChunksOf (n :: Nat) (c :: Nat) where chunksOf :: [a] -> [[a]] instance {-# OVERLAPPING #-} ChunksOf 0 0 where chunksOf _ = [] {-# INLINE chunksOf #-} instance {-# OVERLAPPABLE #-} ChunksOf 0 c where chunksOf _ = [] {-# INLINE chunksOf #-} instance {-# OVERLAPPABLE #-} ChunksOf n 0 where chunksOf _ = [] {-# INLINE chunksOf #-} instance {-# OVERLAPPABLE #-} (Take c, Drop c, ChunksOf (n - 1) c) => ChunksOf n c where chunksOf xs = let (l, r) = splitAt @c xs in l : chunksOf @(n - 1) @c r {-# INLINE chunksOf #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13943> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8258: GHC accepts `data Foo where` in H2010 mode
by GHC 14 Feb '18

14 Feb '18

#8258: GHC accepts `data Foo where` in H2010 mode --------------------------+------------------------------------------------ Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 7.8.1 Component: | Version: 7.0.4 Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC accepts invalid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ According to the Haskell2010 report, The grammar productions relevant for `data` declarations are the following: {{{ topdecl → data [context =>] simpletype [= constrs] [deriving] }}} (from [http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-680004.2 4.2.1 Algebraic Datatype Declarations]) However, GHC 7.0.4/7.4.2/7.6.3/HEAD all happily compile the following Haskell module without any warning when using `-XHaskell2010 -Wall`, even though this is not valid Haskell2010 afaik: {{{#!hs module Foo where data Foo where }}} The trailing `where` in the `data` declaration is not valid Haskell2010 (without language extensions such as `GADT`). At the very least, this divergence from the Haskell Report should be mentioned in [http://www.haskell.org/ghc/docs/latest/html/users_guide /bugs-and-infelicities.html#haskell-standards-divergence 14.1.1. Divergence from Haskell 98 and Haskell 2010]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5