October 2014 - ghc-tickets

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

04 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 slyfox): Replying to [comment:42 juhpetersen]: > Unfortunately the DYNAMIC_GHC_PROGRAMS=NO build fails already in the build phase: > > Redundant modules: Bitmap BlockId ... With #9552 being hopefully fixed as https://git.haskell.org/ghc.git/commitdiff/2a8ea4745d6ff79d6ce17961a64d9013… you should pass that stage. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7780: GHC HEAD dll fails to build on Windows
by GHC 04 Oct '14

04 Oct '14

#7780: GHC HEAD dll fails to build on Windows ----------------------------------------+---------------------------------- Reporter: rassilon | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by Sergei Trofimovich <slyfox@…>): In [changeset:"2a8ea4745d6ff79d6ce17961a64d9013243fc3c6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2a8ea4745d6ff79d6ce17961a64d9013243fc3c6" ghc.mk: fix list for dll-split on GHCi-less builds To reproduce build failure it's enough to try to build GHC on amd64 with the following setup: $ cat mk/build.mk # for #9552 GhcWithInterpreter = NO It gives: Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Redundant modules: Bitmap BlockId ... <list of 42 modules> <make error> dll-split among other things makes sure all mentioned modules are used by DynFlags. '#ifdef GHCI' keeps is from happening. Patch moves those 42 modules under 'GhcWithInterpreter' guard. Fixes Issue #9552 Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7780#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

04 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 slyfox): Looks like dll-split fails on ghci-less build on almost everything #9552. I propose to disable fatal error there in disabled ghci case (I'll try to come with a patch this weelend for it). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

03 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 02 Oct '14

02 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 02 Oct '14

02 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