June 2014 - ghc-tickets

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

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 lortabac): I followed your suggestions and I also fixed a small mistake. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/95#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

09 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 ross): Replying to [comment:20 jstolarek]: > Can I once again ask for help in reading the comments? > > {{{ > -- D; xs1 |-a c : () --> t > -- D; xs' |-a do { ss } : t' xs2 = xs' - defs(p) > -- ----------------------------------- > -- D; xs |-a do { p <- c; ss } : t' > -- > -- ---> premap (\ (xs) -> (((xs1),()),(xs2))) > -- (first c >>> arr (\ (p, (xs2)) -> (xs'))) >>> ss > }}} > I'm totally confused by `(\ (xs) -> (((xs1),()),(xs2)))`. Where do `xs1` and `xs2` come from, if we only bind `xs` as the input to `do { p <- c; ss }`? 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. > Also, do I understand correctly that bind expression generated in desugaring of arrow do-notation does not have a source-level equivalent? If so is it even correct to represent it using the !BindStmt constructor? > > In my prototype I'm ignoring Ross' proposal of the new desugaring. I don't understand that question - I don't see a bind expression in the generated code. Do you mean the `BindStmt` emitted by the type checker? No, that wouldn't correspond to something one could write in the command sublanguage. Part of the motivation for my proposal is that the desugaring of do notation would have a source-level equivalent, albeit still in the command sublanguage, but it could be checked using the existing rules for commands. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9127: Don't warn about pattern-bindings of the form `let !_ = rhs`
by GHC 09 Jun '14

09 Jun '14

#9127: Don't warn about pattern-bindings of the form `let !_ = rhs` ------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- With GHC 7.8.2, code like {{{ let !_ = rqPostParams rq let !_ = rqParams rq }}} triggers the following warnings: {{{ src/Snap/Internal/Test/RequestBuilder.hs:150:13: Warning: This pattern-binding binds no variables: !_ = rqPostParams rq src/Snap/Internal/Test/RequestBuilder.hs:151:13: Warning: This pattern-binding binds no variables: !_ = rqParams rq }}} I think that `let !_ = rhs` shouldn't trigger a warning, just like `let _ = rhs` doesn't. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9127> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8753: Import constructor but not the data type
by GHC 09 Jun '14

09 Jun '14

#8753: Import constructor but not the data type ------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- How do I import a constructor but not its data type? The constructor might have the name of a data type which I do not want to bring into scope. Use case: Library (A) defines a parametrized data type (D a) which I want to use in my code (B) in instantiated form (D Int) but with the same name (D). I want to pattern match against inhabitants of type D, so I need the constructor(s) in scope. Here is how it could look like if import lists let me specify whether I want to import a type or a constructor with name "D". module A where data D a = D a module B where import A (constructor D) import qualified A D = A.D Int f :: D -> Int f (D x) = x Haskell has different name spaces for type and constructors, but does not let the user talk about these name spaces where it matters, namely in import/export lists. At least I found no documentation instructing me how to do this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8753> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11