June 2015 - ghc-tickets

[GHC] #10426: matchGroupArity panic with PatternSynonyms
by GHC 23 Dec '15

23 Dec '15

#10426: matchGroupArity panic with PatternSynonyms ---------------------------------------+--------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+--------------------------------- {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns, EmptyCase #-} pattern Id <- (id -> _) where }}} which gives: {{{#!hs % ghc -ignore-dot-ghci tmp.FbbzjZ48OO.hs [1 of 1] Compiling Main ( tmp.FbbzjZ48OO.hs, tmp.FbbzjZ48OO.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20150316 for i386-unknown-linux): matchGroupArity Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10426> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument
by GHC 21 Dec '15

21 Dec '15

#10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: feature | Milestone: request | Version: 7.8.4 Priority: normal | Operating System: Unknown/Multiple Component: | Type of failure: None/Unknown libraries/base | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Is there any reason why `Const` isn't kind polymorphic? {{{#!hs newtype Const a (b :: k) = Const { getConst :: a } deriving (Generic, Generic1) }}} An example where I need it is for [[http://wiki.ocharles.org.uk/Name%20Binding%20in%20EDSLs|interpreting typed PHOAS]], the following fails to compile complaining that `The first argument of ‘PTerm’ should have kind ‘Ty -> *’, but ‘Const Char’ has kind ‘* -> *’`: {{{#!hs {-# LANGUAGE DataKinds, KindSignatures, GADTs, RankNTypes, PolyKinds #-} import Control.Applicative data Ty = TyBool | TyArr Ty Ty data PTerm :: (Ty -> *) -> Ty -> * where Var :: v t -> PTerm v t Tru :: PTerm v 'TyBool Fals :: PTerm v 'TyBool App :: PTerm v ('TyArr t1 t2) -> PTerm v t1 -> PTerm v t2 Abs :: (v t1 -> PTerm v t2) -> PTerm v ('TyArr t1 t2) newtype Term t = Term (forall v. PTerm v t) showT :: Term t -> String showT (Term pterm) = show' 'a' pterm where show' :: Char -> PTerm (Const Char) t -> String show' _ (Var (Const c)) = [c] show' _ Tru = "True" show' _ Fals = "False" show' s (App x y) = "(" ++ show' s x ++ ") " ++ show' s y show' s (Abs f) = [s] ++ ". " ++ show' (succ s) (f (Const s)) }}} but it compiles if one defines a bespoke form of `Const` with kind `* -> Ty -> *` (or the more general suggestion at the beginning of the ticket), I implemented all the related instances from `Control.Applicative` and the compiled without a hitch. Relevant discussion: a [[http://stackoverflow.com/questions/2023052/haskell-specifying-kind-in- data-declaration|question on StackOverflow]] that predates the `PolyKinds` extension effectively wants to define `type Const' (a :: * -> *) = Const Integer a` which would be possible if it were kind polymorphic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10039> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #10372: panic! compiling Y combinator with optimizations
by GHC 21 Dec '15

21 Dec '15

#10372: panic! compiling Y combinator with optimizations -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: panic, | Operating System: Unknown/Multiple simplifier | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following causes GHC 7.6.3, 7.8.3 and 7.10.1 (at least) to panic when compiling with optimizations: {{{#!hs module Y (y) where newtype Rec a = Rec { out :: Rec a -> a} k x = out x x y f = (f . k) (Rec (f . k)) }}} {{{ /tmp ««« ghc -O y.hs -fforce-recomp [1 of 1] Compiling Y ( y.hs, y.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone a_sof 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: 5282 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10372> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform
by GHC 19 Dec '15

19 Dec '15

#10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform -------------------------------------+------------------------------------- Reporter: kgardas | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.11 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hello, ghc-prim is using GCC's {{{__builtin_ctz(ll)/clz(ll)}}} functions to implement functionality to count leading or trailing zeros in provided integer type variable. The problem with those GCC's builtins is that on platform which does not implement either of the operation in ISA, such function call can't be replaced by simple ISN, but needs to be replaced by the call to the libgcc library which then implements the missing operation in generic C. In ghc- prim you can already see a workaround for missing *ll functions on i386. The problem is that generic SPARC (v9) does not provide ISNs in its ISA to implement those builtins effectively so any call to builtins above is replaced by the call to the libgcc. The inserted functions calls are {{{__ctzsi2/__ctzdi2/__clzsi2/__clzdi2}}} in this case. Unfortunately this makes a lot of GHCi testcases (if not all!) failing with the error: {{{ ghc-stage2: /home/karel/src/obj-ghc-sparc-reg_ncg- head-2015-04-07-debug/libraries/ghc-prim/dist-install/build/HSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3.o: unknown symbol `__clzdi2' ghc-stage2: unable to load package `ghc-prim-0.4.0.0' }}} Please note, this happens only on platforms which does not support shared libs for GHC. On platforms with GHC shared libs support, ghc-prim is shared library which is correctly linked against the libgcc shared library and such error does not happen. (example Solaris/i386). Unfortunately we can't link ghc-prim*.o with libgcc -- it does effectively nothing so there are two solution for this issue IMHO: 1) on problematic platform implement hs_ctz*/hs_clz* functions in pure C without usage of GNU C builtin functions. or 2) enforce linking of shared libgcc with produced application binary. Such linking needs to be enforced with -shared-libgcc parameter passed to the GNU C in linking step and also by usage of either builtins in the application C code (not library code). My experimental code below shows that this is possible (tested on Solaris/SPARC). Please note that by default on static platform, the static version of libgcc is used and this does not help here. Also please note that usage of builtin in let say RTS library does not help either. I've tested RtsMain.c. The reason is the same like why it's not working in ghc-prim. We can't link *.o or *.a against shared libgcc. {{{ diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index c86667c..7c615d1 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -1651,6 +1651,7 @@ mkExtraObjToLinkIntoBinary dflags = do | gopt Opt_NoHsMain dflags = Outputable.empty | otherwise = vcat [ text "#include \"Rts.h\"", + text "#include <stdio.h>", text "extern StgClosure ZCMain_main_closure;", text "int main(int argc, char *argv[])", char '{', @@ -1662,6 +1663,10 @@ mkExtraObjToLinkIntoBinary dflags = do Just opts -> ptext (sLit " __conf.rts_opts= ") <> text (show opts) <> semi, text " __conf.rts_hs_main = rtsTrue;", + text " printf(\"ctz(argc): %d\\n\", __builtin_ctz(argc));", text " return hs_main(argc,argv,&ZCMain_main_closure,__conf);", char '}', char '\n' -- final newline, to keep gcc happy }}} of course this is just a proof of concept. For real code we would need some place to save the result of the called builtin to prevent GCC from removing the call as an unused value. I guess one added value in {{{__conf}}} just for this case should do the job here. I'm free to implement either of those two solutions or even completely different one, I just need to know your preference in this case. BTW: I'm ccing people from #9340 which looks really related to this issue. If you are not interested in this issue discussion, please un-cc yourself. Thanks! Karel PS: as this is IMHO general issue, I'm not setting SPARC/Solaris as Architecture/OS here... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10334> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10272: hsc2hs : directive let cannot be handled in cross-compilation mode
by GHC 19 Dec '15

19 Dec '15

#10272: hsc2hs : directive let cannot be handled in cross-compilation mode -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: hsc2hs | Version: 7.11 Keywords: cross- | Operating System: Unknown/Multiple compiling | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #10070 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Attempting to cross-compile from linux to windows (after an in-progress fix to #10070) and ran into: {{{ libraries/haskeline/System/Console/Haskeline/Backend/Win32.hsc:170 directive let cannot be handled in cross-compilation mode }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10272> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9394: Show data/type family instances with ghci's :info command
by GHC 18 Dec '15

18 Dec '15

#9394: Show data/type family instances with ghci's :info command -------------------------------------+------------------------------------- Reporter: s9gf4ult | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: ghci | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Current version of ghci (7.6.3) does not show data instances. For example, I have some Yesod application and I want to see all data constructors of (Route App) data family instance: {{{#!hs *Application> :info Route App class Eq (Route a) => yesod-routes-1.2.0.6:Yesod.Routes.Class.RenderRoute a where data family Route a1 ... -- Defined in `yesod-routes-1.2.0.6:Yesod.Routes.Class' instance Eq (Route App) -- Defined at Foundation.hs:48:1 instance Read (Route App) -- Defined at Foundation.hs:48:1 ................. }}} It just shows info about `Route`, then info about `App` separately. When I try this: {{{#!hs *Application> :info (Route App) <interactive>:1:2: parse error on input `Route' }}} I am getting parse error. I offer to use this syntax (with parentheses) to show info about instance of data/type family, namely, data constructors and such stuff, just like for ordinal `data`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9394> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10034: Regression in mapM_ performance
by GHC 16 Dec '15

16 Dec '15

#10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.10.1-rc2 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D632 | -------------------------------------+------------------------------------- The current `mapM_` is sometimes worse than the version in 7.8.3. This can be fixed easily by eta-expansion, matching `mapM`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9276: audit ghc floating point support for IEEE (non)compliance
by GHC 16 Dec '15

16 Dec '15

#9276: audit ghc floating point support for IEEE (non)compliance ------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As best I can determine, ghc has never been closely audited for conformance to IEEE-754 (floating point) standard and currently is a bit far from providing a compliant implementation. This impacts both a number of other tasks i wish to do for ghc **and** much of my own use of haskell is in a floating point heavy workloads, I will do a bit of leg work to: a) improve test suite support for checking for compliance b) write some patches to provide portable compliant primops for the operations which need compiler support c) try to determine how to allow ghc optimizer to be a bit more aggressive in a sound way in the presence of floating point. (this may grow into a few subtickets, we'll see) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9304: Floating point woes; Different behavior on Mac vs Linux
by GHC 16 Dec '15

16 Dec '15

#9304: Floating point woes; Different behavior on Mac vs Linux ------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Keywords: floating point | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've the following snippet: {{{ x, y, r :: Double x = -4.4 y = 2.4999999999999956 r = x * y }}} Using GHC 7.8.3, on a Mac, I get the following response from ghci: {{{ *Main> decodeFloat r (-6192449487634421,-49) }}} Using GHC 7.8.3, on a Linux machine, I get the following response: {{{ *Main> decodeFloat r (-6192449487634422,-49) }}} Note that off-by-one difference in the first component of the output. I'm not 100% sure as to which one is actually correct; but the point is that these are IEEE floating point numbers running on the same architecture (Intel X86), and thus should decode in precisely the same way. While I observed this with 7.8.3; I don't think this is a new regression; I suspect it'll show up in older versions as well. Also, for full disclosure: I ran the Mac version naively; but the Linux version on top of a VirtualBox image. I'd very much doubt that would make a difference, but there might be 32/64-bit concerns. So, if someone can validate the Linux output on a true 64-bit Linux machine, that would really help track down the issue further. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 32

[GHC] #9306: Crash when shifting Integers too much
by GHC 16 Dec '15

16 Dec '15

#9306: Crash when shifting Integers too much ------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When shifting an Integer by `fromIntegral (maxBound::Int) + 2` or more, the RTS crashes. The attached program gives the following output (on x86_64, at least): [dfeuer@lemur src]$ ./shiftcrash Okay 0 gmp: overflow in mpz type Aborted I found the bug in 7.6.3, but it's been verified to be present also in 7.8.3. The crash also occurs when running similar code in GHCi. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9306> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5