- ghc-tickets - Haskell.org

Re: [GHC] #7942: aarch64 support in ghc
by GHC 09 Jan '14

09 Jan '14

#7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by carter): @karel, unregisterized builds use GCC specific C code, in which case you'll have to use GCC. GCC 4.8 and newer, when built with multi target support, seems to have aarch 64 support. clang/llvm wont work. cheers -Carter -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7942: aarch64 support in ghc
by GHC 09 Jan '14

09 Jan '14

#7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by carter): OK, so the near term is getting an unregisterized build working? thats still pretty awesome! please holler once you get that working! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #393: functions without implementations
by GHC 09 Jan '14

09 Jan '14

#393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type | Version: None checker) | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: None/Unknown | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by goldfire): I'd like this, for one. As someone said previously, GHC should surely emit a warning when compiling an undefined function. And, I like the suggestion above of an informative `error` call instead of just using `undefined`. Thanks for rolling up your sleeves! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/393#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #393: functions without implementations
by GHC 09 Jan '14

09 Jan '14

#393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type | Version: None checker) | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: None/Unknown | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by jgallag8): I am new to GHC, and I am interested in tackling this as my first task. Is there still interest in adding this feature? If so, I'll dive right in. Any pointers are appreciated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/393#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7942: aarch64 support in ghc
by GHC 09 Jan '14

09 Jan '14

#7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by kgardas): Replying to [comment:13 carter]: > sounds reasonable. Will the arm 32 bit ghc calling convention make sense for AArch64? We may need to get a patch into llvm before having a distinct aarch64 abi. (and we should probably do some pretty thorough benchmarking before picking any such ABI) Not at all! aarch64 abi is completely different with completely different (or better nicely extended) register stack! So basically aarch64 is completely different beast than arm and I'm also doing it separately instead of extending current arm support. W.r.t. benchmarking, I've also had such discussion with David few year ago, but then Stephen comes with work done so no benchmarking was done. The point is to find some sweet-spot inbetween using callee-saved regs for STG regs pinning and between leaving them for LLVM business usage... Anyway, as I said, we're not there yet, although I already do have some code here. The problem is LLVM/AArch64 is not there yet as you can see from my bug report here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-January/069248.html and that is just unregisterised build... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5916: runST isn't free
by GHC 09 Jan '14

09 Jan '14

#5916: runST isn't free -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | 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: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I think the Right Thing here is to add a case to `CorePrep` that (in effect) inlines `runSTRep` on the spot. At that point there are no further transformations to worry about. Also it occurs to me that the C-- code for these two code fragments will be nearly identical {{{ (1) case st_rep s of (# _, r #) -> r (2) st_rep s }}} The latter will be a tail call; the former will push a return frame, call, and then simply return after that. So we could maybe code-gen (1) just like (2). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5916#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell
by GHC 09 Jan '14

09 Jan '14

#7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by simonpj): I rather agree with Richard: make `Pred` and `Type` into synonyms. That's what GHC does internally, and it works pretty well. However that would be a bit of a bump: people's programs would break. A possible half-way house would be to have {{{ data Pred = TypeP Type | ClassP Name [Type] | EqualP Type Type }}} and then deprecated `ClassP` and `EqualP` in favour of the equivalents in `Type`. Once that has settled down, making `Pred` into a synonym would still be a breaking change, but a very routine one to absorb. Or it might be better to do it all at once. I'm not sure, and would welcome opinions. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7021#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8658: Document Proxy#
by GHC 09 Jan '14

09 Jan '14

#8658: Document Proxy# ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: | ------------------------------------+------------------------------------- Commit [https://github.com/ghc/ghc/commit/17112084f87d7ccebf639068b85948190d52c6ba 17112084f87d7ccebf639068b85948190d52c6ba] introduced a new type `Proxy#` to `GHC.Prim`. However, I don't see any documentation for this type in the `GHC.Prim` haddock docs, or anywhere else. We should add this. A little poking around tells me that `compiler/prelude/primops.txt.pp` is the place to do it. But, I'm not familiar with that file's syntax, nor am I 100% familiar with `Proxy#`, so I don't think I'm the one to do it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8658> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function
by GHC 09 Jan '14

09 Jan '14

#1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: 4258 Blocking: | Related Tickets: 8326 -------------------------------------+------------------------------------- Changes (by nh2): * cc: mail@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1498#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell
by GHC 08 Jan '14

08 Jan '14

#7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by goldfire): Do you mean `TypeP` in your example? For my suggestion about making `Pred` a synonym of `Type`, we would need to add something like `EqualityT` to represent the poly-kinded equality predicate. Although this isn't a Haskell type, strictly speaking, there is already precedent for that in the constructors `StarT` and `ConstraintT` (which aren't types either). I'm not sure which of these options (the `TypeP` or the synonym approach) is the better and would love to hear others' thoughts. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7021#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0