- ghc-tickets - Haskell.org

Re: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files
by GHC 10 Jun '14

10 Jun '14

#1407: Add the ability to :set -l{foo} in .ghci files -------------------------------+------------------------------------------- Reporter: guest | Owner: archblob Type: feature | Status: patch request | Milestone: ⊥ Priority: normal | Version: 6.6.1 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by archblob): * owner: => archblob -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1407#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files
by GHC 10 Jun '14

10 Jun '14

#1407: Add the ability to :set -l{foo} in .ghci files -------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature | Status: patch request | Milestone: ⊥ Priority: normal | Version: 6.6.1 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by archblob): * cc: hvr (added) * status: new => patch Comment: There may be some nuances in the whole linking stuff that I don't understand, so please review. As far as I can tell the patch works as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1407#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 10 Jun '14

10 Jun '14

#7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by jstolarek): > They are subsets of xs: xs1 is the variables used by c, while xs2 is the > variables used by ss but not bound in p. So the command 'c' gets local > environment xs1 and stack (). The translations of statements are arrows that > take an environment (here xs2) as input. That starts to make sense :-) As I understand `x1` and `x2` need not be disjoint - is that correct? I am yet to understand the rules for encoding the input parameters to the arrows. Is there a general rule that says when and in what order things are put on the stack? Is it the case that elements on the stack are never accessed and need to be popped if they are to be used? I know all of this could be deduced from the source code, but sadly this is not straightforward (at least for me). > I don't understand that question - I don't see a bind expression in the generated code. What I meant is that desugaring of arrow bind is completely different from monadic bind (which is desugared to `>>=`+lambda) so perhaps it deserves its own internal representation. But in fact this is what my prototype implements ie. it distingushes arrow and monadic bind. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7942: aarch64 support in ghc
by GHC 10 Jun '14

10 Jun '14

#7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 7623, 8664 --------------------------------------------+------------------------------ Comment (by nomeata): Can we get this into 7.8.3 or 7.8.4? Debian will have to add this patch anyways, and I’m always keen on reducing delta. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2.
by GHC 10 Jun '14

10 Jun '14

#5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: daniel.is.fischer Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by tibbe): * cc: tibbe (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5615#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9188: quot with a power of two is not optimized to a shift
by GHC 10 Jun '14

10 Jun '14

#9188: quot with a power of two is not optimized to a shift ------------------------------+-------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- The follow code: {{{ module Test where f :: Int -> Int f n = n `quot` 2 }}} results in the following core: {{{ Test.f :: GHC.Types.Int -> GHC.Types.Int Test.f = \ (n_aeH :: GHC.Types.Int) -> case n_aeH of _ { GHC.Types.I# ww_aiQ -> GHC.Types.I# (GHC.Prim.quotInt# ww_aiQ 2) } }}} which in turn generates this Cmm {{{ sjI_ret() { Just sjI_info: const 0; const 32; } cjX: Hp = Hp + 16; if (Hp > I64[BaseReg + 144]) goto ck3; _sjH::I64 = %MO_S_Quot_W64(I64[R1 + 7], 2); I64[Hp - 8] = PicBaseReg + GHC.Types.I#_con_info; I64[Hp + 0] = _sjH::I64; R1 = Hp - 7; Sp = Sp + 8; jump (I64[Sp + 0]); // [R1] ck1: jump (I64[BaseReg - 16]); // [R1] ck3: I64[BaseReg + 192] = 16; goto ck1; } }}} which finally ends up as this assembly: {{{ sjI_info: _cjX: addq $16,%r12 cmpq 144(%r13),%r12 ja _ck3 movl $2,%ecx movq 7(%rbx),%rax cqto idivq %rcx movq %rax,%rbx leaq GHC.Types.I#_con_info(%rip),%rax movq %rax,-8(%r12) movq %rbx,0(%r12) leaq -7(%r12),%rbx addq $8,%rbp jmp *0(%rbp) }}} Ideally this should have turned into a shift, not a division. `compiler/nativeGen/X86/CodeGen.hs` lacks any peephole optimizations for division. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9188> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9178: improve orphan instance warning
by GHC 09 Jun '14

09 Jun '14

#9178: improve orphan instance warning ------------------------------------+------------------------------------- Reporter: fphh | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The current warning `Warning: orphan instance: instance ClassName TypeName` could be improved by suggesting three solutions: (i) Move the instance declaration to the file, where the class has been declared (ii) Move the instance declaration to the file, where the Type has been declared (iii) Wrap the type with a newtype and declare the instance on the new type. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9178> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #95: GHCi :edit command should jump to the the last error
by GHC 09 Jun '14

09 Jun '14

#95: GHCi :edit command should jump to the the last error -------------------------------+------------------------------------------- Reporter: | Owner: lortabac martijnislief | Status: patch Type: feature | Milestone: ⊥ request | Version: None Priority: normal | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: None | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by nomeata): Better! So time for the next round of suggestions. I found this code confusing {{{ let ... setGhciErrors e = writeIORef lastErrLocations (errs ++ e) setGhciErrors $ errLocation srcSpan }}} why not {{{ let ... writeIORef lastErrLocations (errs ++ errLocation srcSpan) }}} In fact I find the whole section there a bit strange. Some suggestions: * Use `modifyIORef` * Write something like {{{ case srcSpan of RealSrcSpan rsp -> modifyIORef lastErrLocations (++ [srcLocFile (realSrcSpanStart x) , srcLocLine (realSrcSpanStart x) ]) _ -> return () }}} so you don’t have to introduce so many local functions and do tricks with `++ []`. * `find (\(f, _) -> f == mkFastString file) errs` can even simplified to `lookup (mkFastSTring file)` I would put {{{ ghciState <- lift getGHCiState liftIO $ writeIORef (lastErrorLocations ghciState) [] }}} in a function `resetLastErrorLocations :: GHCi ()`. Naming that code also serves as documentation, and you don’t clutter the local name space of `doLoad` with the `ghciState` I wonder if things work well if the user uses a different path to the filename than GHC; maybe one wants to use a function that can check if two filenames point to the same file. But maybe that is a refinement that can be added later. Can you come up with a way to test this? Maybe by setting the editor to use to `/bin/echo`, which will put `+123` in the output that the test suite would check? See [Building/RunningTests/Adding] and shout if you need help creating a test case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/95#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4836: literate markdown not handled correctly by unlit
by GHC 09 Jun '14

09 Jun '14

#4836: literate markdown not handled correctly by unlit ----------------------------------------------+---------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7120 ----------------------------------------------+---------------------------- Comment (by elliottt): Moving CPP after unlit solves the problem with the sections defined by #, but it doesn't change the fact that in markdown, bird track blocks are actually quotations, not code [1]. What about this as a compromise (assuming my patch gets accepted): move unlit before CPP, to avoid problems with #, and keep the separate processing for .md/.markdown, allowing the distinction between bird tracks and code blocks in markdown. This way, you can write markdown in a .lhs file and use bird tracks for code blocks, and I can write haskell in a .md file using fenced code blocks, and still be able to write quotation blocks. [1] http://daringfireball.net/projects/markdown/syntax#blockquote -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4836#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #9061, #9071, #9096, #9102, #9106
by GHC 09 Jun '14

09 Jun '14

Batch modification to #9061, #9071, #9096, #9102, #9106 by thoughtpolice: milestone to 7.8.3 -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=9061%2C9071%2C9096%2C9102%2C9106> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0