March 2014 - ghc-tickets

Re: [GHC] #5925: Add inline version of newArray#
by GHC 08 Mar '14

08 Mar '14

#5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): I got this working I think, except that the Cmm optimizer does such a poor job on the Cmm I generate (which is simple) that I'm not sure if we can get anywhere here without first fixing that problem. See e.g #8860. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5925#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 08 Mar '14

08 Mar '14

#6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.8.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by dmcclean): * cc: douglas.mcclean@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8824: cloning from https://github.com/ghc/ghc.git is broken
by GHC 08 Mar '14

08 Mar '14

#8824: cloning from https://github.com/ghc/ghc.git is broken ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Specifically the clone works, but then `./sync-all get` fails; {{{ Cloning into 'libraries/Cabal'... fatal: repository 'https://github.com/ghc/packages/Cabal.git/' not found Clone of 'https://github.com/ghc/packages/Cabal.git' into submodule path 'libraries/Cabal' failed }}} It was broken by b755c7bd6af9f2bee47427b1eaa6c29c72b2b17a which (around lines 587-588) assumes the protocol is `git://`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8824> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8678: Derivin `Functor` complains about existential type
by GHC 07 Mar '14

07 Mar '14

#8678: Derivin `Functor` complains about existential type ------------------------------------+------------------------------------- Reporter: heisenbug | 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: | ------------------------------------+------------------------------------- When deriving a functor with !DataKinds enabled {{{ {-# LANGUAGE DataKinds, DeriveFunctor, FlexibleInstances, GADTs, KindSignatures, StandaloneDeriving #-} data {- kind -} Nat = Z | S Nat data NonStandard :: Nat -> * -> * where Standard :: a -> NonStandard (S n) a Non :: NonStandard n a -> a -> NonStandard (S n) a deriving instance Show a => Show (NonStandard n a) deriving instance Functor (NonStandard n) }}} I get following error message {{{ NonStandard.hs:10:1: Can't make a derived instance of ‛Functor (NonStandard n)’: Constructor ‛Standard’ must not have existential arguments In the stand-alone deriving instance for ‛Functor (NonStandard n)’ }}} But the `Standard` constructor is not at all existential in the last type argument! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8678> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #7316: GHC segfaults on ARM
by GHC 07 Mar '14

07 Mar '14

#7316: GHC segfaults on ARM -------------------------------------+--------------------------- Reporter: laney | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: 7623 | Related Tickets: -------------------------------------+--------------------------- Changes (by bgamari): * priority: high => normal Comment: At this point it seems like dynamic linking works pretty well with the LLVM backend on ARM. We can keep this bug open as the bug likely still lurks in GHC's linker, but it's not nearly as critical now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7316#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD)
by GHC 07 Mar '14

07 Mar '14

#7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): Which does "fail" mean, freeze (non stopping) or stop with an error? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7651#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD)
by GHC 07 Mar '14

07 Mar '14

#7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by George): wrt building GHC on Mac sometimes fails, see #8620, building in parallel on Mavericks is failing for some users -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7651#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5925: Add inline version of newArray#
by GHC 06 Mar '14

06 Mar '14

#5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by jberryman): Replying to [comment:12 tibbe]: > ...So the task at this point is to come up with some good benchmarks. There are essentially two ways to attack that problem. Either we can try to show a speed-up in allocation or we can try to show a speed-up due to the better locality (e.g. constructor wrapping an array can now be allocated next to the array.) I don't understand this issue very well, but I wonder if you'd see any difference in running something like this through criterion: {{{ do let payload = P.newArray 32 0 :: IO (P.MutableArray (PrimState IO) Int) x <- newEmptyMVar y <- newEmptyMVar forkIO $ (replicateM_ 500 payload) >> putMVar x () forkIO $ (replicateM_ 500 payload) >> putMVar y () -- ... etc, for number of cores - 1 or so takeMVar x takeMVar y }}} ..using `payload = return ()` as the baseline measurement? Or maybe microbenchmark newArray followed by a read? Re. better locality, I have a real application: a Chan-like IORef linked list of small `MutableArray`s. Maybe creating/traversing a structure like that would show some improvement? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5925#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8854: Missing class method not caught at compile time, program freezes when missing method is called.
by GHC 06 Mar '14

06 Mar '14

#8854: Missing class method not caught at compile time, program freezes when missing method is called. ----------------------------------+---------------------------------- Reporter: RaminHAL9001 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7633 | ----------------------------------+---------------------------------- I created a type class where two of four functions must be satisfied for a minimal complete definition. GHC did not catch an instance where the minimal complete definition was not satisfied, the program compiled without an error or warning. When running the compiled program it would freeze when calling the missing method. Also when running the program in GHCi and stepping up to the use of the missing method, GHCi would freeze before reaching the missing function. This made it very difficult to debug. It '''did not''' throw a "NoMethodError" exception, and there '''was no''' segment violation caught by the operating system, nor does the program terminate with the "<<loop>>" message output on the command line. Compiling with language extensions: {{{ -XTemplateHaskell -XScopedTypeVariables -XRankNTypes -XMultiParamTypeClasses -XFunctionalDependencies -XFlexibleInstances -XFlexibleContexts -XDeriveDataTypeable }}} Using compiler flags: {{{ -prof -fprof-auto -threaded -Wall -fno-warn-name-shadowing -fno-warn- unused-do-bind -fno-warn-auto-orphans }}} '''To Reproduce the Issue''' I tried to reproduce the issue with a miniature program that isolates the problem, but GHC successfully detects a problem and terminates with the "<<loop>>" message written on the command line. My program is much larger and simply froze. However the code I wrote looks similar to the following situation... First I tried this, which gave me no problems at all: {{{ class A x where f1 :: x f1 = f2 f2 :: x f2 = f1 }}} We have two functions f1 and f2, if f1 is not defined it defaults to f2, if f2 is not defined it defaults to f1, so you must define either f1 or f2, or you could also define both. Then I add two more methods: {{{ class A x where f1 :: x f1 = f2 f2 :: x f2 = f1 g1 :: x g1 = g2 g2 :: x g2 = g1 }}} Just like with f1 f2, the g1 g2 functions each use their counterpart to define their default method. But this caused a huge problem. The minimal complete definition should be (f1 | f2) & (g1 | g2), but the compiler does not report any warning when I have not satisfied the minimal complete definition. Maybe one of my compiler flags disabled a would-be warning, I don't know yet. This was a red-flag to me, but I went on to test my program. As it turns out, there was a place in my code where I forgot to write an instance for g1 or g2 but I had not realize it. I only found out when I ran my test program and it froze. No "unsatisfied method" exception, not segment violations, it just froze. Although the program was still running and consuming a small amount of CPU resources, and I could cancel with CTRL-C in the command line. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8854> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5925: Add inline version of newArray#
by GHC 06 Mar '14

06 Mar '14

#5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): I've done some work on this branch: [https://github.com/tibbe/ghc/tree /alloc-inline]. I've also attached the changes to this ticket so they don't get lost if I lose the branch. The current status is that I have something that seems to generate the assembly I want, but I haven't managed to write a benchmark that shows any speed-up, even though I've eliminated two branches and one function call, if I recall correctly. So the task at this point is to come up with some good benchmarks. There are essentially two ways to attack that problem. Either we can try to show a speed-up in allocation or we can try to show a speed-up due to the better locality (e.g. constructor wrapping an array can now be allocated next to the array.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5925#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0