January 2013 - ghc-tickets

Re: [GHC] #2425: Crash constructing a ClockTime too far into the future
by GHC 28 Jan '13

28 Jan '13

#2425: Crash constructing a ClockTime too far into the future --------------------------+------------------------------------------------- Reporter: wagstaff | Type: bug Status: new | Priority: normal Milestone: _|_ | Component: libraries/old-time Version: 6.8.3 | Keywords: Os: Windows | Architecture: x86 Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- Comment(by morabbin): Dang; 64bit overflow. D'oh! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2425#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2439: Missed optimisation with dictionaries and loops
by GHC 28 Jan '13

28 Jan '13

#2439: Missed optimisation with dictionaries and loops ---------------------------------+------------------------------------------ Reporter: rl | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.9 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): The `-fdicts-strict` flag exists but it has had no love for years, and I doubt it works right. One obstacle is that at the moment we implement a ''single-method'' type class with a newtype rather than a data type. We don't want to make that strict, lest we force the method rather than the dictionary. I rather think we sould remove the special case, so that all dictionaries are data types; then we could be uniformly strict. But we should do some bemchmarking to check that nothing slows down. Just awaiting someone with a bit of time and benchmarking bandwidth... Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2439#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7354: Panic with recursion-schemes package and unit
by GHC 28 Jan '13

28 Jan '13

#7354: Panic with recursion-schemes package and unit -------------------------------------------+-------------------------------- Reporter: amplitwist | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.1 Resolution: fixed | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: GHCi crash | Difficulty: Unknown Testcase: indexed_types/T7354a, T7354b | Blockedby: Blocking: | Related: -------------------------------------------+-------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: OK well, I'll close this ticket as fixed, because it is, and we have a regression test. You make a separate suggestion about Safe Haskell; doing `-dcore-lint` when compiling with Safe Haskell would be a good belt-and- braces move. But it's one for a separate ticket, if you want to open one. (And discuss with David Terei, of course.) Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7354#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2440: Bad code with type families
by GHC 28 Jan '13

28 Jan '13

#2440: Bad code with type families --------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.9 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Well #2859 concerns optimising coercions, which was a sideline on this ticket, and is indeed fixed. However, I tried compiling `T2440` with `-O` and got this resonably good code. In particular, the worker for `foo` has arity 3 as desired. So I'll close. {{{ Foo.$wa :: forall s_agY. Foo.Vec s_agY -> GHC.Prim.Int# -> GHC.Prim.State# s_agY -> (# GHC.Prim.State# s_agY, GHC.Types.Int #) [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType <L,U(U(U))><S,U><L,U>, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=3, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 0 0] 142 0}] Foo.$wa = \ (@ s_agY) (w_sr0 :: Foo.Vec s_agY) (ww_sr3 :: GHC.Prim.Int#) (w1_sr5 :: GHC.Prim.State# s_agY) -> letrec { $wa1_sr8 [Occ=LoopBreaker] :: GHC.Prim.Int# -> GHC.Prim.State# s_agY -> (# GHC.Prim.State# s_agY, GHC.Types.Int #) [LclId, Arity=2, Str=DmdType <S,U><L,U>] $wa1_sr8 = \ (ww1_sqT :: GHC.Prim.Int#) (w2_sqV :: GHC.Prim.State# s_agY) -> case ww1_sqT of ds_Xok { __DEFAULT -> case w_sr0 of _ { Foo.Vec r_afI -> case r_afI of _ { GHC.STRef.STRef var#_apW -> case GHC.Prim.readMutVar# @ s_agY @ GHC.Types.Int var#_apW w2_sqV of _ { (# ipv_aph, ipv1_api #) -> case ipv1_api of _ { GHC.Types.I# x_aoV -> $wa1_sr8 (GHC.Prim.+# x_aoV ds_Xok) ipv_aph } } } }; 0 -> (# w2_sqV, Foo.foo2 #) }; } in $wa1_sr8 ww_sr3 w1_sr5 Foo.foo1 [InlPrag=INLINE[0]] :: forall s_agY. Foo.Vec s_agY -> GHC.Types.Int -> GHC.Prim.State# s_agY -> (# GHC.Prim.State# s_agY, GHC.Types.Int #) [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType <L,U(U(U))><S(S),U(U)><L,U>, Unf=Unf{Src=Worker=Foo.$wa, TopLvl=True, Arity=3, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=False) Tmpl= \ (@ s_agY) (w_sr0 [Occ=Once] :: Foo.Vec s_agY) (w1_sr1 [Occ=Once!] :: GHC.Types.Int) (w2_sr5 [Occ=Once] :: GHC.Prim.State# s_agY) -> case w1_sr1 of _ { GHC.Types.I# ww_sr3 [Occ=Once] -> Foo.$wa @ s_agY w_sr0 ww_sr3 w2_sr5 }}] Foo.foo1 = \ (@ s_agY) (w_sr0 :: Foo.Vec s_agY) (w1_sr1 :: GHC.Types.Int) (w2_sr5 :: GHC.Prim.State# s_agY) -> case w1_sr1 of _ { GHC.Types.I# ww_sr3 -> Foo.$wa @ s_agY w_sr0 ww_sr3 w2_sr5 } Foo.foo :: forall s_afc. Foo.Vec s_afc -> GHC.Types.Int -> GHC.ST.ST s_afc GHC.Types.Int [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType <L,U(U(U))><S(S),U(U)><L,U>, Unf=Unf{Src=InlineStable, TopLvl=True, Arity=0, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True) Tmpl= Foo.foo1 `cast` (forall s_agY. <Foo.Vec s_agY> -> <GHC.Types.Int> -> Sym <(GHC.ST.NTCo:ST[0] <s_agY> <GHC.Types.Int>)> :: (forall s_agY. Foo.Vec s_agY -> GHC.Types.Int -> GHC.ST.STRep s_agY GHC.Types.Int) ~# (forall s_agY. Foo.Vec s_agY -> GHC.Types.Int -> GHC.ST.ST s_agY GHC.Types.Int))}] Foo.foo = Foo.foo1 `cast` (forall s_agY. <Foo.Vec s_agY> -> <GHC.Types.Int> -> Sym <(GHC.ST.NTCo:ST[0] <s_agY> <GHC.Types.Int>)> :: (forall s_agY. Foo.Vec s_agY -> GHC.Types.Int -> GHC.ST.STRep s_agY GHC.Types.Int) ~# (forall s_agY. Foo.Vec s_agY -> GHC.Types.Int -> GHC.ST.ST s_agY GHC.Types.Int)) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2440#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #709: "Fixup too large" error with -fasm on PowerPC
by GHC 28 Jan '13

28 Jan '13

#709: "Fixup too large" error with -fasm on PowerPC ----------------------------------+----------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: low | Milestone: 6.8.1 Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: powerpc Failure: Building GHC failed | Difficulty: Moderate (less than a day) Testcase: | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Comment(by PHO): Thanks for tidying up, but I think we don't have to worry about section alignment because PPC is an architecture where every instruction has a fixed length of `word_size` (unlike e.g. x86), and the size of info table is always a multiple of `word_size`. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/709#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2435: Qualified name required when defining type family instance in instance declaration
by GHC 28 Jan '13

28 Jan '13

#2435: Qualified name required when defining type family instance in instance declaration ------------------------------------------+--------------------------------- Reporter: rl | Owner: chak Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.9 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: rename/should_compile/T2435 | Blockedby: Blocking: | Related: ------------------------------------------+--------------------------------- Changes (by simonmar): * status: new => closed * testcase: => rename/should_compile/T2435 * resolution: => fixed Comment: Added as a test; thanks! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2435#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7457: printf's * doesn't like negative numbers
by GHC 28 Jan '13

28 Jan '13

#7457: printf's * doesn't like negative numbers -----------------------------------------+---------------------------------- Reporter: elaforge | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: libraries/base/tests/T7457 | Blockedby: Blocking: | Related: -----------------------------------------+---------------------------------- Changes (by simonmar): * status: new => closed * testcase: => libraries/base/tests/T7457 * resolution: => fixed Comment: Committed; thanks {{{ commit 63202b9df64041e1c17603ad5f06fec3c51f357d Author: Simon Marlow <marlowsd(a)gmail.com> Date: Mon Jan 28 09:38:06 2013 +0000 fix negative numbers for * modifiers (#7457) commit 2c52ae2eb3720da2a01f6d6cb08c1a6449819a29 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Mon Jan 28 09:38:19 2013 +0000 tabs -> spaces }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7457#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2260: Non-ideal error message for misplaced LANGUAGE pragma
by GHC 28 Jan '13

28 Jan '13

#2260: Non-ideal error message for misplaced LANGUAGE pragma ----------------------------------+----------------------------------------- Reporter: TomMD | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler (Parser) | Version: 6.8.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ----------------------------------+----------------------------------------- Comment(by shelarcy): GHC 7.x hide T2260.hs' problem. Because GHC 7.0.1 or higher uses Haskell 2010 in default, and Haskell 2010 supports EmptyDataDecls. * http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/release-7-0-1.html * http://hackage.haskell.org/trac/haskell- prime/query?group=status&milestone=Haskell+2010 We should use Haskell98 to check this ticket's problem. {{{ $ghci T2260.hs -XHaskell98 GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( T2260.hs, interpreted ) T2260.hs:5:1: `A' has no constructors (-XEmptyDataDecls permits this) In the data type declaration for `A' Failed, modules loaded: none. Prelude> :q Leaving GHCi. }}} {{{ $ ghci T2260_2.hs GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( T2260_2.hs, interpreted ) T2260_2.hs:6:1: `A' has no constructors (-XEmptyDataDecls permits this) In the data type declaration for `A' Failed, modules loaded: none. Prelude> :q Leaving GHCi. }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2260#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1693: Make distclean (still) doesn't
by GHC 28 Jan '13

28 Jan '13

#1693: Make distclean (still) doesn't ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: igloo Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Build System | Version: 6.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): Those files have moved, e.g. `compiler/parser/Parser.hs` is now `compiler/stage1/parser/Parser.hs`. I agree they should not be removed by `make distclean` though. Or perhaps we are changing the policy, and you need Happy & Alex even when building from a source dist? I guess that would be ok, it's a bit of a pain to arrange to keep these generated files around for a source dist. Ian? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1693#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2354: NOINLINE pragma ignored
by GHC 28 Jan '13

28 Jan '13

#2354: NOINLINE pragma ignored ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: patch Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.9 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): Fine, except that "driver" is not the right place - perhaps `simplCore`? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2354#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0