- ghc-tickets - Haskell.org

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

27 Jan '13

#7354: Panic with recursion-schemes package and unit -------------------------------+-------------------------------------------- Reporter: amplitwist | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown | Testcase: indexed_types/T7354a, T7354b Blockedby: | Blocking: Related: | -------------------------------+-------------------------------------------- Comment(by shachaf): For what it's worth, elliott in #haskell came across this bug in a different context. Here are two simpler cases (7.6.1): * Panics: {{{ type family T :: * -> * x :: () x = undefined :: T a }}} * Doesn't panic, but type-checks when it shouldn't: {{{ type family T :: * -> * x :: () x = undefined :: (b ~ T a) => b }}} Note that if you make an instance of T (e.g. `newtype Id a = Id a; type instance T = Id`), then even uses of Id unrelated to `x` cause a panic, as long as `x` exists. `-dcore-lint` catches the first case before it gets to a "real" panic. None of this is problematic in HEAD. Note: I haven't managed to get `unsafeCoerce` out of this, but that doesn't mean it's impossible. It's important to keep in mind that in the presence of SafeHaskell, type checker bugs can have security implications. Maybe `-XSafe` should imply/suggest `-dcore-lint`, or something along those lines? That's come up in a few other places, like #7453. Using SafeHaskell safely should be as easy as possible, not rely on obscure folklore and "compiler debugging options". -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7354#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

27 Jan '13

#7457: printf's * doesn't like negative numbers ---------------------------------+------------------------------------------ Reporter: elaforge | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by elaforge): I was really confused until I realized the patch is backwards. It *adds* the 'abs n' line, not removes. I think the tabs patch was also messed up. I replaced the patches with less backwards ones. Sorry for the confusion! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7457#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1589: Process creation and communication doesn't scale linearly
by GHC 27 Jan '13

27 Jan '13

#1589: Process creation and communication doesn't scale linearly -------------------------------+-------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Moderate (less than a day) Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by ezyang@…): commit 6ff3c31888e614d1f6f78449e41d293612a855be {{{ Author: Edward Z. Yang <ezyang(a)mit.edu> Date: Sun Jan 27 18:25:34 2013 -0800 Fix documentation bug: TSOs are *not* unconditionally kept on the mutable list. The bug where TSOs were unconditionally kept on the mutable list was #1589 which was fixed in 04cddd339c000df6d02c90ce59dbffa58d2fe166. Curiously enough, the commit that changed this comment 0417404f5d1230c9d291ea9f73e2831121c8ec99 occurred *after* this change was made; I can only assume Simon Marlow accidentally forgot that he had fixed this bug. :-) Signed-off-by: Edward Z. Yang <ezyang(a)mit.edu> rts/sm/Scav.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1589#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1589: Process creation and communication doesn't scale linearly
by GHC 27 Jan '13

27 Jan '13

#1589: Process creation and communication doesn't scale linearly -------------------------------+-------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Moderate (less than a day) Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by ezyang): * failure: => None/Unknown Comment: For reference, the fix was: {{{ commit 04cddd339c000df6d02c90ce59dbffa58d2fe166 Author: Simon Marlow <simonmarhaskell(a)gmail.com> Date: Wed Apr 16 23:39:51 2008 +0000 Add a write barrier to the TSO link field (#1589) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1589#comment:10> 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 27 Jan '13

27 Jan '13

#2435: Qualified name required when defining type family instance in instance declaration ---------------------------------+------------------------------------------ Reporter: rl | Owner: chak Type: bug | Status: new 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: | ---------------------------------+------------------------------------------ Changes (by morabbin): * failure: => None/Unknown Comment: Doesn't seem to happen any more: {{{ Orac:~/work/tickets $ ghci T2435Foo.hs T2435Bar.hs ... [1 of 2] Compiling Foo ( T2435Foo.hs, interpreted ) [2 of 2] Compiling Bar ( T2435Bar.hs, interpreted ) Ok, modules loaded: Foo, Bar. }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2435#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

27 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: --------------------------+------------------------------------------------- Changes (by morabbin): * failure: => None/Unknown Comment: Current version of `System.Time` doesn't suffer from this: {{{ Orac:~/work/tickets $ ghci ... Prelude> :m System.Time Prelude System.Time> TOD 214748365333 0 Loading package old-locale-1.0.0.5 ... linking ... done. Loading package old-time-1.1.0.1 ... linking ... done. Sat Feb 8 03:42:13 PST 8775 Prelude System.Time> }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2425#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

27 Jan '13

#2440: Bad code with type families ---------------------------------+------------------------------------------ Reporter: rl | Owner: 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 morabbin): Since #2859 is closed as fixed, ought this be also? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2440#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

27 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 morabbin): For the original example, `-fdicts-strict` seems to make no difference now (i.e., it seems the "right" code is now produced even without `-fdicts- strict`): {{{ Foo.sum' :: forall a_aeH. GHC.Num.Num a_aeH => [a_aeH] -> a_aeH [GblId, Arity=2, Caf=NoCafRefs] Foo.sum' = \ (@ a_c) ($dNum_afi :: GHC.Num.Num a_c) (xs_afb :: [a_c]) -> let { f_af2 :: a_c -> a_c -> a_c [LclId] f_af2 = GHC.Num.+ @ a_c $dNum_afi } in case GHC.Num.fromInteger @ a_c $dNum_afi (__integer 0) of z_Xf9 { __DEFAULT -> letrec { loop_aff [Occ=LoopBreaker] :: a_c -> [a_c] -> a_c [LclId, Arity=2] loop_aff = \ (z1_af6 :: a_c) (ds_dfG :: [a_c]) -> case z1_af6 of z2_Xfg { __DEFAULT -> case ds_dfG of _ { [] -> z2_Xfg; : x_af8 xs1_af9 -> loop_aff (f_af2 z2_Xfg x_af8) xs1_af9 } }; } in loop_aff z_Xf9 xs_afb } }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2439#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2346: Compilation of large source files requires a lot of RAM
by GHC 27 Jan '13

27 Jan '13

#2346: Compilation of large source files requires a lot of RAM -------------------------+-------------------------------------------------- Reporter: choener | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 Keywords: | Os: Linux Architecture: x86 | Failure: Compile-time performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------+-------------------------------------------------- Comment(by morabbin): These all compile on an 8Gb RAM Macbook Pro without running out of memory. RF00549.hs produces a 52Mb .o! Sure, they take a few hours to compile, but they don't fail, nor do they appear to eat all the memory (i.e., my machine was not rendered useless). It seemed quite acceptable to me, given the sizes of the files. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2346#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1168: Optimisation sometimes decreases sharing in IO code
by GHC 27 Jan '13

27 Jan '13

#1168: Optimisation sometimes decreases sharing in IO code ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: nofib/spectral/calendar Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): See also #7561 for another example. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1168#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0