December 2013 - ghc-tickets

[GHC] #8609: Clean up block allocator
by GHC 31 Dec '13

31 Dec '13

#8609: Clean up block allocator -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.7 Keywords: patch | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Easy (less than 1 | performance bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- For fun, I was reimplementing GHC's block allocator in Rust, and I noticed that there are a number of things the current block allocator code does that result in extra, unnecessary work: * Upon a perfect match, `alloc_mega_group` initializes the returned block group (`initGroup`). This is unnecessary, because the caller of `alloc_mega_group` is responsible for initializing the block groups. * The `initGroup` function uses the `blocks` to figure out how many block descriptors it needs to initialize. However, in the case of a multi- megablock group, blocks will larger than BLOCKS_PER_MBLOCK, so this process will march into the first block and write information to block descriptors which will be later be overwritten by the user data. So, `initGroup` should cap at the block descriptors of the first megablock. One can go even further: if a block group spans multiple megablocks, then in practice, the only block descriptor we care about is the very first one, since we're not allowed to have internal GC'd pointers to the block group (as not every address in the group has a valid bdescr associated with it). * The commentary should add a bit about mblock groups. Essentially, the mblock free list has a different set of invariants: the first mblock's start pointers are guaranteed to be initialized (the mblock was `initMBlock` 'd), and the blocks and link fields of the first bdescr will be something appropriate; there are no other guarantees. Here are the proposed functional changes (obviously some extra documentation is necessary; replace the XXX marked expression with BLOCKS_PER_MBLOCK if you want to do the more conservative changes for larger than mblock block chains): {{{ diff --git a/rts/sm/BlockAlloc.c b/rts/sm/BlockAlloc.c index 18c167f..33530d8 100644 --- a/rts/sm/BlockAlloc.c +++ b/rts/sm/BlockAlloc.c @@ -170,7 +170,7 @@ initGroup(bdescr *head) bdescr *bd; W_ i, n; - n = head->blocks; + n = head->blocks > BLOCKS_PER_MBLOCK ? 1 /* XXX */ : head->blocks; head->free = head->start; head->link = NULL; for (i=1, bd = head+1; i < n; i++, bd++) { @@ -278,7 +278,6 @@ alloc_mega_group (StgWord mblocks) } else { free_mblock_list = bd->link; } - initGroup(bd); return bd; } else if (bd->blocks > n) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8609> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 31 Dec '13

31 Dec '13

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------ Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 5877 -------------------------------------+------------------------------------ Changes (by akio): * cc: tkn.akio@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8603: GHC crashes on some code using StateT monad transformer
by GHC 31 Dec '13

31 Dec '13

#8603: GHC crashes on some code using StateT monad transformer -------------------------------------+------------------------------------- Reporter: person1729 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Operating System: MacOS X Keywords: | Type of failure: Compile-time Architecture: x86_64 (amd64) | crash Difficulty: Unknown | Test Case: Attached Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- GHC version 7.6.3 on Mac OS X 10.9 crashes with the following message when compiling the attached file: {{{ ghc -c -v3 -dcore-lint DiscreteRandomVariableST.hs }}} {{{ Glasgow Haskell Compiler, Version 7.6.3, stage 2 booted by GHC version 7.4.2 Using binary package database: /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/package.conf.d/package.cache Using binary package database: /Users/***/.ghc/x86_64-darwin-7.6.3/package.conf.d/package.cache hiding package binary-0.5.1.1 to avoid conflict with later version binary-0.7.1.0 hiding package Cabal-1.16.0 to avoid conflict with later version Cabal-1.18.1.2 wired-in package ghc-prim mapped to ghc- prim-0.3.0.0-d5221a8c8a269b66ab9a07bdc23317dd wired-in package integer-gmp mapped to integer- gmp-0.5.0.0-2f15426f5b53fe4c6490832f9b20d8d7 wired-in package base mapped to base-4.6.0.1-6c351d70a24d3e96f315cba68f3acf57 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.8.0.0-c2c1b21dbbb37ace4b7dc26c966ec664 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: -static Created temporary directory: /var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0 *** C pre-processor: '/sw/bin/gcc-4' '-E' '-undef' '-traditional' '-m64' '-fno-stack-protector' '-m64' '-I' '/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/base-4.6.0.1/include' '-I' '/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/include' '-D__GLASGOW_HASKELL__=706' '-Ddarwin_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Ddarwin_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-U __PIC__' '-D__PIC__' '-x' 'c' 'DiscreteRandomVariableST.hs' '-o' '/var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0/ghc13041_0.hscpp' *** Checking old interface for main:DiscreteRandomVariableST: *** Parser: *** Renamer/typechecker: DiscreteRandomVariableST.hs:186:17: Couldn't match kind `* -> *' with `*' Expected type: [t1] -> StateT s RV t0 Actual type: [t1] -> StateT s RV t0 Kind incompatibility when matching types: [t_t14] :: * -> * [t1] :: * The function `lift'*** Deleting temp files: Deleting: /var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0/ghc13041_0.s /var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0/ghc13041_0.hscpp Warning: deleting non-existent /var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0/ghc13041_0.s *** Deleting temp dirs: Deleting: /var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0 ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug}}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8603> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #4210: LLVM: Dynamic Library Support
by GHC 30 Dec '13

30 Dec '13

#4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: patch Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bgamari): That is correct. Using `@object` prevents the linker from sending calls through the PLT. However, it would be nice to hear Simon confirm that his fears surrounding the efficiency of intra-package calls have been addressed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4210#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8607: Invalid location reported for type constructors
by GHC 30 Dec '13

30 Dec '13

#8607: Invalid location reported for type constructors ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Given {{{ module Example where data T = MkT }}} The locations as reported in 7.4 and 7.7 are different: * In 7.4 the ADT is represented as a `TyData`, itself part of an `HsGroup`. The `TyData` contains a `Located Name`; the location of this name is reported correctly as 3:6. The `SrcSpan` associated with the `Name` itself (which represents the def site) is also reported as 3:6, which is dubious. * In 7.8 the ADT is represented as a `DataDecl` (part of ` TyClGroup` inside a `HsGroup`). As before, the `DataDecl`contains a `Located Name`; the location now however is 3:1-12, which doesn't make sense. The def site associated with the name itself is also 3:1-12, which ''does'' make sense. It seems that when the def site was fixed, it also changed the location of the identifier itself. These two are separate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8607> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #8633: template haskell mkName parses operator ^.. as a qualified operator
by GHC 30 Dec '13

30 Dec '13

#8633: template haskell mkName parses operator ^.. as a qualified operator ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The operator `^..` (provided by lens) is parsed as the operator `.` from module `^`. In other words: {{{ import Language.Haskell.TH.Syntax main = case mkName "^.." of Name (OccName ".") (NameQ (ModName "^")) -> error "bug" Name (OccName "^..") NameS -> print "desired" }}} The context here is that I get `^..` out-of-scope when I try to use that operator in code that is handled by haskell-src-meta. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8633> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8637: Infix declaration on operators ending on backslash
by GHC 30 Dec '13

30 Dec '13

#8637: Infix declaration on operators ending on backslash ----------------------------+---------------------------------------------- Reporter: | Owner: jcristovao | Status: new Type: bug | Milestone: Priority: normal | Version: 7.7 Component: Compiler | Operating System: Linux Keywords: | Type of failure: GHC rejects valid program Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Hi, I was trying the latest GHC Head (version 7.7.20131227), when I noticed a regression. I don't know if this is intended behaviour or not. This compiled ok under 7.6.3 {{{ (?&&\) :: (Monoid a) => a -> (a -> Bool) -> a (?&&\) value f = if f value then value else mempty infixl 1 ?&&\ }}} Under 7.7, the infixl declaration only works if I double escape it. {{{ infixl 1 ?&&\\ }}} Is this intended? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8637> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4210: LLVM: Dynamic Library Support
by GHC 30 Dec '13

30 Dec '13

#4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: patch Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dterei): OK, so just to check, the issue to fix is just the one initially mentioned of using @object annotations instead of @function annotations? Sounds good to me -- I'll pull in the patches soon. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4210#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5412: dataTypeConstrs gives unhelpful error message
by GHC 29 Dec '13

29 Dec '13

#5412: dataTypeConstrs gives unhelpful error message -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: klangner Type: bug | Status: patch Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Case 1. A better error message here would be `"Data.Data.gunfold: Constructor " ++ show c ++ " is not of type Char"`. But if you don’t feel like working on that class of error message right now you can concentrate on the others and skip these for now. Case 2. Sounds good. Or maybe `"Data.Data.repConstr: The given ConstrRep does not fit to the given DataType"`, possibly extended with actually showing both parameters, or using `dataTypeName`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5412#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3990: UNPACK doesn't unbox data families
by GHC 29 Dec '13

29 Dec '13

#3990: UNPACK doesn't unbox data families --------------------------------------------+------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by sjoerd_visscher): What about closed data families? GHC could check that every instance is unpackable. Then this would work: {{{ data Nat = Z | S Nat data family Vec (size :: Nat) where Vec Z = Nil Vec (S n) = Cons {-# UNPACK #-} !Double {-# UNPACK #-} !(Vec n) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3990#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0