July 2013 - ghc-tickets

Re: [GHC] #5687: Friendly Interface for auto-completion of GHCi
by GHC 06 Jul '13

06 Jul '13

#5687: Friendly Interface for auto-completion of GHCi -------------------------------------+------------------------------------ Reporter: linsumang | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: GHCi | Version: 7.2.1 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 igloo): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5687#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8039: RTS linker: unloadObj() does not actually unload the code
by GHC 06 Jul '13

06 Jul '13

#8039: RTS linker: unloadObj() does not actually unload the code -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | 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: -------------------------------------+------------------------------------ Comment (by igloo): Replying to [comment:5 simonmar]: > > Anyway, for the application I need this for, we're using the RTS linker and not shared libraries. So please don't make the RTS linker go away :-) My plan was to leave it in 7.8, but not used by default, and then to remove it from HEAD shortly after 7.8.1 is released. The goal is to stop maintaining the ghci linker, after all! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8039#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8035: STM transaction left open if there is an orElse on the path between throwSTM and catchSTM
by GHC 06 Jul '13

06 Jul '13

#8035: STM transaction left open if there is an orElse on the path between throwSTM and catchSTM -------------------------------------+------------------------------------ Reporter: errge | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: stm rts Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by igloo): * priority: normal => high * milestone: => 7.8.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8035#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8021: Multiple constraint classes - the alternative to superclass
by GHC 06 Jul '13

06 Jul '13

#8021: Multiple constraint classes - the alternative to superclass -----------------------------+---------------------------------------------- Reporter: wvv | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- This is alternative to SuperClasses - multiple constraint Classes Now: {{{ class Monoid a where ... class Monad m => MonadPlus m where ... }}} It could be: {{{ class Monoid a where ... class Monad m => Monoid m where ... class Arrow c => Monoid c where ... foo :: Monad m => Monoid m => m a }}} all classes must have same functions with same kind. And if you wish to write superclass, it would be easy to write {{{ class BeforeNum a where .... class BeforeNum a => Num a where ... foo :: BeforeNum a => Num a => a }}} '''Backward compatibility''' If class have single constraint, you could write without it. If class have many constrains, you could write without it, if it is empty one. {{{ bar :: MonadPlus m => m a <<==>> bar :: Monad m => MonadPlus m => m a foo :: Monoid a => a <<==>> foo :: () => Monoid a => a }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8021> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h"
by GHC 06 Jul '13

06 Jul '13

#8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" -----------------------------+---------------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Component: GHC API Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The header file `${PREFIX}/lib/ghc-7.6.3/ghc-7.6.3/include/HsVersions.h` of a GHC installation, contains the following `#include` {{{ #!C /* Pull in the autoconf defines (HAVE_FOO), but don't include * ghcconfig.h, because that will include ghcplatform.h which has the * wrong platform settings for the compiler (it has the platform * settings for the target plat instead). */ #include "../includes/ghcautoconf.h" }}} however, there is no `../includes/` folder; the `ghcautoconf.h` does actually exist, but is located in the same folder as `HsVersions.h`. This makes it impossible to use `HsVersion.hs` without patching the GHC installation. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8040> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5550: GHC infinite loop when compiling vector
by GHC 06 Jul '13

06 Jul '13

#5550: GHC infinite loop when compiling vector ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: merge Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.2.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: simplCore/should_compile/T5550 Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by carter): Is this fixed in head? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5550#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5550: GHC infinite loop when compiling vector
by GHC 06 Jul '13

06 Jul '13

#5550: GHC infinite loop when compiling vector ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: merge Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.2.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: simplCore/should_compile/T5550 Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by carter): I hit this bug recently, see https://github.com/mokus0/random-fu/issues/13#issuecomment-20546431 step to repro: ghc 7.6.3, and using cabal / cabal-install head modify cabal settings to have "optimization: 2" in the ~/.cabal/config file (so libraries are built with -O2) then when i try to install random-fu, ghc gets stuck on specconstr as this ticket discusses -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5550#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8039: RTS linker: unloadObj() does not actually unload the code
by GHC 05 Jul '13

05 Jul '13

#8039: RTS linker: unloadObj() does not actually unload the code ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ We've known about this for a long time, but it hasn't been a pressing issue in GHCi. The problem with actually unloading code is that there might be pointers into it from the heap or other RTS data structures, so we need to do a full heap traversal to discover whether it is safe to unload code or not. This is an issue for a project at Facebook that needs to have long running processes that regularly unload and load code using the RTS linker, and right now the process grows over time. This ticket is to track the issue, and I'm also working on a fix. The same problem affects the dynamic linker, although I'm not planning to fix that (yet). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8039> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8033: add AVX register support to llvm calling convention
by GHC 05 Jul '13

05 Jul '13

#8033: add AVX register support to llvm calling convention -----------------------------+---------------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- GHC HEAD currently has support for SSE 128bit registers (XMM), and it would be very little additional work to add 256bit AVX2 operations (when available) PROVIDED that the llvm calling convention for ghc is modified to support them when available the current definition in LLVM can be seen here https://github.com/llvm- mirror/llvm/blob/master/lib/Target/X86/X86CallingConv.td#L279-L291 the current definition is {{{ def CC_X86_64_GHC : CallingConv<[ // Promote i8/i16/i32 arguments to i64. CCIfType<[i8, i16, i32], CCPromoteToType<i64>>, // Pass in STG registers: Base, Sp, Hp, R1, R2, R3, R4, R5, R6, SpLim CCIfType<[i64], CCAssignToReg<[R13, RBP, R12, RBX, R14, RSI, RDI, R8, R9, R15]>>, // Pass in STG registers: F1, F2, F3, F4, D1, D2 CCIfType<[f32, f64, v16i8, v8i16, v4i32, v2i64, v4f32, v2f64], CCIfSubtarget<"hasSSE1()", CCAssignToReg<[XMM1, XMM2, XMM3, XMM4, XMM5, XMM6]>>>, ]>; }}} I believe the update should read {{{ def CC_X86_64_GHC : CallingConv<[ // Promote i8/i16/i32 arguments to i64. CCIfType<[i8, i16, i32], CCPromoteToType<i64>>, // Pass in STG registers: Base, Sp, Hp, R1, R2, R3, R4, R5, R6, SpLim CCIfType<[i64], CCAssignToReg<[R13, RBP, R12, RBX, R14, RSI, RDI, R8, R9, R15]>>, // Pass in STG registers for floats,doubles and 128bit simd vectors CCIfType<[f32, f64, v16i8, v8i16, v4i32, v2i64, v4f32, v2f64], CCIfSubtarget<"hasSSE1()", CCAssignToReg<[XMM1, XMM2, XMM3, XMM4, XMM5, XMM6]>>>, // Pass in STG registers for first 7 256bit simd vectors CCIfType<[v32i8, v16i16, v8i32, v4i64, v8f32, v4f64], CCIfSubtarget<"hasAVX()", CCAssignToReg<[YMM0, YMM1, YMM2, YMM3, YMM4, YMM5, YMM6]>>> ]>; }}} Note that this is FULLY backwards compatible with current GHC, it merely means that we can have 256bit simd values if we so choose. if I get the go ahead from y'all, i'm happy to see about getting that patch into llvm -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8033> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8027: Adding one call to getNumCapabilities triggers performance nose dive (6X slowdown)
by GHC 05 Jul '13

05 Jul '13

#8027: Adding one call to getNumCapabilities triggers performance nose dive (6X slowdown) ------------------------------------+--------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- This is a strange one. I'm in the process of writing an efficient routine for reading large files of decimal/ASCII numbers, in order to make reasonable Haskell versions of the PBBS benchmarks. The following reproducer reads a file and parses the numbers inside it. Simply calling "getNumCapabilities" BEFORE reading the file makes it leap from taking 4.5 seconds to 25-30 seconds: https://github.com/iu- parfunc/lvars/blob/cfb5110eb172b9a9dd10e9863b2f87420d1dadf6/haskell- prototype/Util/PBBS.hs#L30 The file is a standalone reproducer and there's a Makefile in that directory that will build and run it in the bugged and unbugged modes. When you run "make" you should see output as in the following Gist: https://gist.github.com/rrnewton/5901965 ...... time ./unbugged.exe Using parReadNats + readFile Time to read file sequentially: 0.311108s SKIPPING read of num capabilities... Now this is getting ridiculous... Result: 1 segments of output <segment, length 69568627> 4.59 real 3.89 user 0.66 sys time ./bugged.exe Using parReadNats + readFile Time to read file sequentially: 0.342555s Read num capabilities as 1 Now this is getting ridiculous... Result: 1 segments of output <segment, length 69568627> 38.79 real 37.57 user 1.18 sys Currently I'm running it on a 550Mb file containing 69 million numbers. Any file of whitespace-separated positive numbers will do, but if you want the exact file I'm using you can download it here: http://www.cs.indiana.edu/~rrnewton/temp/3Dgrid_J_10000000 Or you can download the PBBS benchmark suite and run the generator to produce that file (http://www.cs.cmu.edu/~pbbs/) Anyway, it should have nothing to do with the file. One thing that is interesting is that calling certain OTHER system functions appears to create the same performance effect as "getNumCapabilities". Namely, getEnvironment and setNumCapabilities cause the problem, but getEnv and writeFile don't. I've attached the Core produced in the bugged and unbugged case to the Gist as well: https://gist.github.com/rrnewton/5901965#file-pbbs_bugged-dump-simpl https://gist.github.com/rrnewton/5901965#file-pbbs_unbugged-dump-simpl Finally, the above numbers are from my mac laptop, GHC 7.6.2. But the problem is exactly the same on the Linux/GHC-7.6.3 machine I tried, and I'm in the process of building a fresh GHC head to check it there... -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8027> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9