August 2013 - ghc-tickets

Re: [GHC] #7978: Profiling broken
by GHC 12 Aug '13

12 Aug '13

#7978: Profiling broken --------------------------------------------+------------------------------ Reporter: gmainland | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): Edward: thanks for some great sleuthing. I think that points the finger at the RTS code for non-updatable selector thunks, which has probably never been tested before. I'll try to get around to looking at this, but feel free to dive in first. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7978#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7961: Remove restrictions on promoting GADT's
by GHC 11 Aug '13

11 Aug '13

#7961: Remove restrictions on promoting GADT's -------------------------------------+------------------------------------ Reporter: danharaj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #6024 -------------------------------------+------------------------------------ Comment (by danharaj): Adam Gundry has recently published his thesis which is wholly relevant to this ticket: https://personal.cis.strath.ac.uk/adam.gundry/thesis/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7961#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8108: getGroupEntryForID in multi-threaded applications
by GHC 10 Aug '13

10 Aug '13

#8108: getGroupEntryForID in multi-threaded applications ------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The following program {{{ #!haskell import Control.Monad import Control.Concurrent import System.Posix.User main = do void $ forkIO $ forever $ getGroupEntryForID 0 forever $ getGroupEntryForID 0 }}} segfaults when executed after less than a second. I've confirmed this with HP-2013.2.0.0/GHC-7.63/unix-2.6.0.1 in many different linuxes as well as Mac OS X 10.8. After some digging I found the reason for this failure. The underlying posix function used by getGroupEntryForID is: {{{ #!c int getgrgid_r(gid_t gid, struct group *grp, char *buf, size_t buflen, struct group **result); }}} getgrgid_r returns its result with its last argument which is a pointer to a struct. The struct has to be allocated by the caller as usual. The problem is that the struct contains several strings. This is what the char *buf argument is for; the caller is supposed to allocate a large enough buffer to be used by getgrgid_r to store those strings. Then the caller has to read the struct *before* the auxiliary string buffer is deallocated. What complicates things even more is that we don't know in advance the right size for that buffer; we have to pick an arbitrary size and then keep doubling it while getgrgid_r returns ERANGE. The current implementation of getGroupEntryForID uses allocaBytes to allocate that buffer but then it does not unpack the struct inside the allocaBytes block. The posix functions getgrnam_r, getpwuid_r and getpwnam_r (used by getGroupEntryForName, getUserEntryForID and getUserEntryForName respectively) operate in the same fashion and are susceptible to the same bug. I am really surprised that people haven't been hitting that issue earlier. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8108> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 10 Aug '13

10 Aug '13

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by carter): * type: feature request => task Comment: changing this from a feature request to a task since Ryan Newton is getting the ball rolling with preliminary C implementations for the proposed primops -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7883#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3452: Show type of most recent expression in GHCi
by GHC 10 Aug '13

10 Aug '13

#3452: Show type of most recent expression in GHCi -------------------------------------+------------------------------------ Reporter: ozy | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 7.6.2 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by osa1): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3452#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3452: Show type of most recent expression in GHCi
by GHC 10 Aug '13

10 Aug '13

#3452: Show type of most recent expression in GHCi -------------------------------------+------------------------------------ Reporter: ozy | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: GHCi | Version: 6.10.4 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 osa1): I'm a new contributor(preparing my first patch) and I'm working on this, currently my patch is this: https://github.com/osa1/ghc/commit/d542b418d913b4aba04e497fb63b70108b058f48 This is probably far from being finished, I'm looking for reviews/comments on this. I'm not very happy with the way it is implemented but for now this is only way I could think. If someone point me a batter way to do I'll happily change my patch. Here's an example output: https://gist.github.com/osa1/6201852 One thing I didn't like about this output is the _it_ part, to me it's not user friendly enough. I think we need to tell user that his value isn't showable so only it's type is shown. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3452#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3452: Show type of most recent expression in GHCi
by GHC 10 Aug '13

10 Aug '13

#3452: Show type of most recent expression in GHCi -------------------------------------+------------------------------------ Reporter: ozy | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * failure: => None/Unknown Comment: What should the output be in case `:set +t` was active? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3452#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5144: Pattern synonyms
by GHC 10 Aug '13

10 Aug '13

#5144: Pattern synonyms -------------------------------------+------------------------------------ Reporter: simonpj | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 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 cactus): Progress update: Code is in the `pattern-synonyms` branch at https://github.com/gergoerdi/ghc.git Until I am ready to submit for initial review, I will do all kinds of funky rebasing and history rewriting, so use it for read-only snapshots as of now. Using the names from the wiki link, pattern-only pattern synonyms and simple pattern synonyms now (mostly) work. There's a bug in the typing of pattern-synonyms-as-expressions, so e.g. with the following program: {{{ {-# LANGUAGE PatternSynonyms #-} pattern One x = [x] singleton :: a -> [a] singleton x = One x }}} I get an error that the type of `One` is too rigid; I expect this to be easy to fix: {{{ Couldn't match type ‛t0’ with ‛a’ because type variable ‛a’ would escape its scope This (rigid, skolem) type variable is bound by the type signature for singleton :: a -> [a] at /tmp/PatSyn.hs:18:14-21 Expected type: [a] Actual type: [t0] }}} The one big missing feature is exporting pattern synonyms. First of all, since pattern synonyms are in the namespace of constructors, not types, we need special syntax to export them; I propose the following: {{{ module M (pattern P) where pattern P x = _:_:x:_ }}} (note that you can have a type called `P` as well, but you'd get a clash if you had a constructor with that name). To be honest, I have no idea yet how to actually implement exporting, since I haven't looked at that part of GHC yet -- any pointers are appreciated. After I've fixed the bug mentioned and implemented exporting, I'll do a formal submission of my (clean-up) patch for review. After that baseline, the 'bidirectional pattern synonyms' proposal from the wiki page should fit right into it as well. I have no opinion yet how difficult adding associated patsyns will be, I'll need to do more research first. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5144#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8120: ghc: panic! (the 'impossible' happened)
by GHC 09 Aug '13

09 Aug '13

#8120: ghc: panic! (the 'impossible' happened) ------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Foo.hs:6:3:ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-linux): kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug The source file has to contain, merely: {{{ l :: m a -> t m a l = undefined f :: a -> f b f = do x <- undefined l $ x undefined main = return () }}} This panic reproduces on at least: 7.6.1, 7.6.2, 7.6.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8120> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7978: Profiling broken
by GHC 08 Aug '13

08 Aug '13

#7978: Profiling broken --------------------------------------------+------------------------------ Reporter: gmainland | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by ezyang): I've further narrowed down the bug to how selectors are compiled: {{{ --- a/compiler/codeGen/StgCmmBind.hs +++ b/compiler/codeGen/StgCmmBind.hs @@ -282,7 +282,7 @@ mkRhsClosure dflags bndr _cc _bi cgRhsStdThunk bndr lf_info [StgVarArg the_fv] where lf_info = mkSelectorLFInfo bndr offset_into_int - (isUpdatable upd_flag) + (isUpdatable Updatable) (_, _, params_w_offsets) = mkVirtConstrOffsets dflags (addIdReps params) -- Just want the layout maybe_offset = assocMaybe params_w_offsets (NonVoid selectee) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7978#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0