- ghc-tickets - Haskell.org

[GHC] #9623: Use Data.List.dropWhileEnd
by GHC 04 Oct '14

04 Oct '14

#9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The GHC tree has many instances of `reverse . dropWhile ... . reverse`. As well as being harder to read and work with (searching for those forms led me to discover #9616) this approach is less efficient than `dropWhileEnd`. I think I've found all the places this is used, and I'll submit a patch to fix all the instances except for tests and nofib. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9623> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

Re: [GHC] #5462: Deriving clause for arbitrary classes
by GHC 03 Oct '14

03 Oct '14

#5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:34 simonpj]: > * Make it possible for a library author to make a class `C` which can be used in `..deriving( C )` just like built-in classes. > * Ultimately: remove the built-in code for deriving `Eq`, `Ord` etc with generic code. IMHO the value of theses two goals should not be underestimated, as this feature would allow for custom Prelude to provide (for instance) custom `Eq`/`Ord` instances different from the default ones generated by GHC while allowing to use automatic derivation as if they were built-ins (which I don't think `RebindableSyntax` already allows at this point). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5462#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5462: Deriving clause for arbitrary classes
by GHC 03 Oct '14

03 Oct '14

#5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Goals: * Save a few characters: say `deriving( C )` rather than `deriving instance C a => C (T a)` * Make it possible for a library author to make a class `C` which can be used in `..deriving( C )` just like built-in classes. * Ultimately: remove the built-in code for deriving `Eq`, `Ord` etc with generic code. Concerns * Conflict between this feature and GND for newtypes. * Current proposal is that this new feature is not available for `newtype`s. * An alternative: a declared property of the class says "do not use GND" in `deriving` clauses. (Examples: `Show`, `Read`, and one or two others.) Maybe we don't even need to make this user-controllable; a handful of built-in classes may suffice. * Another alternative: fail if there ambiguity. * Richard wants it to be a property of the class ''and'' over-rideable at the `deriving` site. * For a top-level instance `instance C a => C (T a)`, this is always an empty instance, filled in by generic defaults if they exist. But what about `deriving instance C a => C (T a)`. Does that mean precisely the same thing? * If you say `data T a = ... deriving( C )`, and change to `data T a = ...; deriving instance C a => C (T a)`, does that make a difference? * Possible principle. Use per-class control for `newtype ... deriving( C )` situation, but per-instance control for `deriving instance` and `instance` declarations. Another question: * Just having one generic default method may not be enough. Maybe two are needed to give a well-founded instance. * Better: class author writes an explicit `MINIMAL` pragma with an empty minimal set. That says, fully explicitly, that the class author is happy with instances that have no explicit methods. * I think we converged on the latter. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5462#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 03 Oct '14

03 Oct '14

#6135: Unboxed Booleans -------------------------------------+------------------------------------- Reporter: benl | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 8103, 8103 Type of failure: | Related Tickets: #605 None/Unknown | Test Case: | primops/should_run/T6135 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed Comment: Per jstolarek's request, opening a separate ticket for `==#`, #9661 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6135#comment:94> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7942: aarch64 support in ghc
by GHC 03 Oct '14

03 Oct '14

#7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by juhpetersen): Replying to [comment:40]: > Maybe I should try installing statically linked ghc and see if that makes difference. Unfortunately the DYNAMIC_GHC_PROGRAMS=NO build fails already in the build phase: {{{ : cat utils/hpc/hpc.wrapper >> inplace/bin/hpc chmod +x inplace/bin/hpc Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Redundant modules: Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 FastBool Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream compiler/ghc.mk:640: recipe for target 'compiler/stage2/dll-split.stamp' failed make[1]: *** [compiler/stage2/dll-split.stamp] Error 1 make[1]: *** Waiting for unfinished jobs.... Makefile:64: recipe for target 'all' failed make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 03 Oct '14

03 Oct '14

#6135: Unboxed Booleans -------------------------------------+------------------------------------- Reporter: benl | Owner: Type: feature | Status: new request | Milestone: 7.8.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 8103, 8103 Type of failure: | Related Tickets: #605 None/Unknown | Test Case: | primops/should_run/T6135 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: jstolarek => * status: closed => new * resolution: fixed => Comment: It appears that this works as intended for `<#`, `>#`, `<=#`, and `>=#`, but not for `==#`. If I write something like {{{#!hs foo x = tagToEnum# ((x <# 3#) `orI#` (x ># 100#) `orI#` (x ==# 12#) `orI#` (x ==# 15#)) }}} I get (in 7.8.3) Core doing something like {{{#!hs foo x = case x of 12# -> True 15# -> True _ -> tagToEnum# ((x <# 3#) `orI#` (x ># 100#)) }}} (with different syntax, or course) and branching assembly to match. If this transformation is important in some other context, it would be great to have something that acts just like `==#` but that doesn't do that, for the times when we actually don't want it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6135#comment:93> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9659: Offer branchless conditional (CMOV) primop
by GHC 03 Oct '14

03 Oct '14

#9659: Offer branchless conditional (CMOV) primop -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'd like to see something similar to C's `?:`, like {{{#!hs ifInt#, boolInt# :: Int# -> Int# -> Int# -> Int# }}} We could then write things like {{{#!hs ifInt# (x <# y) 12# (x +# 17#) boolInt# potato cannon (y ># 2) }}} When the value of the test is difficult to predict, this would be better than the usual branching `if` or `case`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9659> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9616: Incorrect numbers from HpcMarkup.markup_plugin
by GHC 03 Oct '14

03 Oct '14

#9616: Incorrect numbers from HpcMarkup.markup_plugin -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Incorrect hour) | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `showBigNum` in the `openTick` function accidentally puts 0s in the wrong place when formatting large numbers. 12345 will be formatted as 120,345 instead of 012,345. The correct answer is probably to add some locale- specific numeric formatting stuff somewhere, but until then, I'll just fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9616> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 03 Oct '14

03 Oct '14

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Runtime | than a day) performance bug | Blocked By: Test Case: | Related Tickets: #8598 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: nomeata => Comment: I think the conclusion was that Nested CPR was not worth it. The branch is still there if someone wants to pick it up. Unassigning. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7490: ghc-stage1 panic when building a cross-compiler or cross-building a compiler
by GHC 03 Oct '14

03 Oct '14

#7490: ghc-stage1 panic when building a cross-compiler or cross-building a compiler -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: worksforme | Keywords: cross-compilation Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => worksforme -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7490#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0