October 2014 - ghc-tickets

Re: [GHC] #5966: getAppUserDataDirectory does not respect XDG specification
by GHC 25 Oct '14

25 Oct '14

#5966: getAppUserDataDirectory does not respect XDG specification -------------------------------------+------------------------------------- Reporter: ordcoder | Owner: ekmett Type: bug | Status: upstream Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.4.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: 6077 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: core-libraries-committee@… (added) * status: new => upstream Comment: Filed this upstream as https://github.com/haskell/directory/issues/6 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5966#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9721: RecordWildCards panic
by GHC 24 Oct '14

24 Oct '14

#9721: RecordWildCards panic -------------------------------------+------------------------------------- Reporter: jorgemendes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- GHC 7.4.1 (Debian 7.7 and Ubuntu 12.04.5 LTS) panics with: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for i386-unknown-linux): compiler/rename/RnPat.lhs:535:39-79: Irrefutable pattern failed for pattern gres@(gre : _) }}} I found a minimal test case to exemplify this issue: {{{#!hs module Foo where import Bar (Bar (Bar)) foo :: Bar -> () foo Bar {..} = () }}} {{{#!hs module Bar where data Bar = Bar { barA :: Int, barB :: Int } }}} A workaround is to import all data fields in module Foo: {{{#!hs import Bar (Bar (..)) }}} I also tried this with GHC 7.6.3 (Mac OS X), with no warnings nor errors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9721> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #2132: Optimise nested comparisons
by GHC 24 Oct '14

24 Oct '14

#2132: Optimise nested comparisons -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by TomSchrijvers): * cc: tom.schrijvers@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2132#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7378: Identical alts/bad divInt# code
by GHC 24 Oct '14

24 Oct '14

#7378: Identical alts/bad divInt# code -------------------------------------+------------------------------------- Reporter: | Owner: daniel.is.fischer | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: 7360 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by TomSchrijvers): * cc: tom.schrijvers@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7378#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9422: EPT caching on --make can make spurious instances visible
by GHC 24 Oct '14

24 Oct '14

#9422: EPT caching on --make can make spurious instances visible -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | accepts invalid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This is perhaps best demonstrated by way of an example. Suppose we have a package a with the following two modules, with A defining a type class and data type, and I defining an orphan instance. {{{#!hs module A where data A = A class C a where cop :: a -> a }}} {{{#!hs module I where import A instance C A where cop = id }}} Then, when compiling this module: {{{#!hs module N where import A x = cop A }}} I might reasonably expect to be told that the instance `C` is not in scope (since I didn't import `I`, nor did any of my dependencies import `I`). However, suppose I have another module: {{{#!hs module M where import I }}} and I use `--make` to compile both of these modules in one go, with `M` being compiled first (`ghc --make N.hs M.hs` does that for me), then `N` will incorrectly type check and compile! This should not happen. The reason for this behavior is that we do not clear the EPT (external package table) between compilations of a file in batch compilation mode; this saves us from having to repeatedly read instances from the external files. Thus, `M`, having loaded the instances into the EPT when type- checking, `N` will automatically pick them up. Note that `I` and `A` have to be in a separate package; otherwise `--make` puts them in the HPT (home package table) and everything works fine. (Note also that one-shot compilation puts home modules in the EPT, but since that gets thrown out everything is fine as well, although perhaps a user of the GHC API could get bitten by this.) As for the fix, it's probably not right to clear the EPT either, since we get quite good time savings from not having to parse interface files repeatedly. Perhaps we could do something clever by partitioning up the EPT, but maybe it's not worth it and we should keep this bug as a known infelicity until the next time this part of the compiler gets rewritten. I'll submit a test-case (marked as failing) anyhoo. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9422> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #1473: isSpace is too slow
by GHC 23 Oct '14

23 Oct '14

#1473: isSpace is too slow -------------------------------------+------------------------------------- Reporter: igloo | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 6.6.1 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed Comment: Replying to [comment:11 nomeata]: > dfeuer, is 31571270625a690410b794b7cfe48d866c084e74/ghc sufficient to close this ticket or is there more to be done here? I think it's probably best to close it for now, and deal with any other `isSpace` improvements as part of a broader character-classification overhaul. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1473#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9711: Confusing errors when compiling text-1.2.0.0
by GHC 22 Oct '14

22 Oct '14

#9711: Confusing errors when compiling text-1.2.0.0 ----------------------------------+--------------------------------------- Reporter: asvyazin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------------- I was trying to install text-1.2.0.0 on my system (Mac OS X 10.7.5 Lion) through cabal (cabal-install-1.20.0.3, cabal-1.20.0.2) and got some compile errors: [29 of 43] Compiling Data.Text.IO ( Data/Text/IO.hs, dist/build/Data/Text/IO.o ) Data/Text/IO.hs:236:29: The last statement in a 'do' block must be an expression n1 <- writeCharBuf raw n '\r' writeCharBuf raw n1 '\n' >>= inner s' Data/Text/IO.hs:237:49: Not in scope: ‘n1’ Perhaps you meant one of these: ‘n’ (line 230), ‘s1’ (line 228) Let's see what we have at 236 line of Data/Text/IO.hs: {{{#!hs writeBlocksCRLF :: Handle -> Buffer CharBufElem -> Stream Char -> IO () writeBlocksCRLF h buf0 (Stream next0 s0 _len) = outer s0 buf0 where outer s1 Buffer{bufRaw=raw, bufSize=len} = inner s1 (0::Int) where inner !s !n = case next0 s of Done -> commit n False{-no flush-} True{-release-} >> return () Skip s' -> inner s' n Yield x s' | n + 1 >= len -> commit n True{-needs flush-} False >>= outer s | x == '\n' -> do n1 <- writeCharBuf raw n '\r' -- 236 line is here!!! writeCharBuf raw n1 '\n' >>= inner s' | otherwise -> writeCharBuf raw n x >>= inner s' commit = commitBuffer h raw len }}} Seems legit… And if I rewrite this two lines as {{{#!hs | x == '\n' -> do n1 <- writeCharBuf raw n '\r'; writeCharBuf raw n1 '\n' >>= inner s' }}} then ghc compiles them fine. Even more interesting - if I rewrite this lines as {{{#!hs | x == '\n' -> do n1 <- writeCharBuf raw n '\r' writeCharBuf raw n1 '\n' >>= inner s' }}} then it compiles them too! Again, with context, look carefully: {{{#!hs Yield x s' | n + 1 >= len -> commit n True{-needs flush-} False >>= outer s | x == '\n' -> do n1 <- writeCharBuf raw n '\r' writeCharBuf raw n1 '\n' >>= inner s' | otherwise -> writeCharBuf raw n x >>= inner s' }}} doesn't work. {{{#!hs Yield x s' | n + 1 >= len -> commit n True{-needs flush-} False >>= outer s | x == '\n' -> do n1 <- writeCharBuf raw n '\r' writeCharBuf raw n1 '\n' >>= inner s' | otherwise -> writeCharBuf raw n x >>= inner s' }}} works! Weird… P.S. GHC version 7.8.3, installed through homebrew -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9711> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9660: unnecessary indirect jump when returning a case scrutinee
by GHC 22 Oct '14

22 Oct '14

#9660: unnecessary indirect jump when returning a case scrutinee -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I happened to be looking at the Cmm for this code (ghc 7.8.3, -O2) {{{#!hs f :: Int -> Int f x = if x < 0 then x else x+1 }}} and I noticed something a bit funny about it: {{{ c12e: if ((Sp + -8) < SpLim) goto c12z; else goto c12A; c12z: R2 = R2; R1 = Test.f_closure; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; c12A: I64[Sp - 8] = c12b; R1 = R2; Sp = Sp - 8; if (R1 & 7 != 0) goto c12b; else goto c12c; c12c: call (I64[R1])(R1) returns to c12b, args: 8, res: 8, upd: 8; c12b: Hp = Hp + 16; if (Hp > HpLim) goto c12y; else goto c12x; c12y: HpAlloc = 16; R1 = R1; call stg_gc_unpt_r1(R1) returns to c12b, args: 8, res: 8, upd: 8; c12x: _s11Q::I64 = I64[R1 + 7]; if (%MO_S_Lt_W64(_s11Q::I64, 0)) goto c12u; else goto c12v; c12u: Hp = Hp - 16; R1 = R1 & (-8); /* <--- */ Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; /* <--- */ c12v: I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = _s11Q::I64 + 1; R1 = Hp - 7; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; }}} On the two marked lines, we untag R1 (which is `x`) and enter it. However, we know at this point that `x` is already in WHNF so we could simply return it by replacing the two lines with `call (P64[Sp])(R1)`, if I'm not mistaken. That will save a load and an indirect jump (which we actually know is to `I#_con_info`, which would just retag R1 and return to the address on the stack anyways). I think the same optimization should be available any time we do an algebraic `case` and in a branch simply return the scrutinee. I looked at what it would take to fix this. It looks almost easy: if we add a new `LambdaFormInfo` constructor `LFUnknownCon` meaning that we know the identifier is bound to a saturated application of an unknown constructor, then we could set the `cg_lf` of the case binder variable of an algebraic case statement to `LFUnknownCon`, and return `ReturnIt` for `LFUnknownCon` variables in `getCallMethod`. I think that would do it. Does that sound right? Is there a better way? (In my original example we actually know the constructor has to be `I#`. But if the case was on a type with more than one constructor we wouldn't know statically which one we got, just that it has to be one of them.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9660> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #1473: isSpace is too slow
by GHC 22 Oct '14

22 Oct '14

#1473: isSpace is too slow -------------------------------------+------------------------------------- Reporter: igloo | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 6.6.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): dfeuer, is 31571270625a690410b794b7cfe48d866c084e74/ghc sufficient to close this ticket or is there more to be done here? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1473#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9537: concatMap does not participate in list fusion
by GHC 22 Oct '14

22 Oct '14

#9537: concatMap does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: libraries/base | Version: 7.9 Keywords: fusion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Joachim Breitner raised this issue in an [http://www.haskell.org/pipermail /haskell-cafe/2011-December/097228.html email to haskell-cafe] in 2011, but he never got a response. For some reason, list comprehensions desugar to `concatMap` forms written to fuse, but the actual `concatMap` function is not written so. Unless there is a good reason for this, we should make it fuse. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9537> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3