- ghc-tickets - Haskell.org

[GHC] #13863: -fno-code is broken on package:language-c-quote
by GHC 03 Jul '17

03 Jul '17

#13863: -fno-code is broken on package:language-c-quote -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- reported by awson here: [https://github.com/haskell/haddock/issues/640#issuecomment-310442454] I think this is because QuasiQuotes should trigger object code generation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13863> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13914: -fignore-asserts flag not handled by recompilation checker
by GHC 03 Jul '17

03 Jul '17

#13914: -fignore-asserts flag not handled by recompilation checker -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As demonstrated below, `-fignore-asserts` is not stored in .hi files and not checked by recompilation checker. {{{ $ cat main.hs module Main where import Control.Exception main = do assert False (putStrLn "OK") $ ghc main.hs [1 of 1] Compiling Main ( main.hs, main.o ) Linking main ... $ ./main main: Assertion failed CallStack (from HasCallStack): assert, called at main.hs:6:5 in main:Main $ ghc main.hs -fignore-asserts $ ./main main: Assertion failed CallStack (from HasCallStack): assert, called at main.hs:6:5 in main:Main }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13914> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7741: Add SIMD support to x86/x86_64 NCG
by GHC 03 Jul '17

03 Jul '17

#7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3557 | Differential Rev(s): Wiki Page: wiki:SIMD | -------------------------------------+------------------------------------- Comment (by bgamari): In response to recent interest in SIMD support, I pondered this for a bit while wandering in the woods yesterday. I think there's a pretty straightforward path to introducing SIMD (including AVX) support in the NCG. Here's my proposed plan, * Introduce a few types, {{{#!hs -- | The format of a vector value data VecFormat = VecFormat { vecWidth :: Width -- ^ vector width (e.g. how many scalars?) , vecFormat :: ScalarFormat -- ^ the format of each scalar } -- | What type of quantity is a scalar? data ScalarFormat = FmtInt | FmtFloat -- | The width of a scalar in bits data ScalarWidth = Width8 | Width16 | Width32 | Width64 -- this already exists type Width = Int }}} * Rework the instructions in `nativeGen/X86/Instr.hs` to carry a `VecFormat` instead of a `Format`. Perhaps just start with `ADD` before moving on to the others just to make sure this plan works. * For the purposes for register allocation pretend there are only ZMM registers (e.g. ignoring XMM and YMM). This saves us from having to worry about register aliasing. We can then use the `VecFormat` to determine what kind of register we really mean. I believe this can be done in `nativeGen/X86/Regs.hs:allocatableRegs`. * I think the calling convention logic (e.g. in `cmm/CmmCallConv.hs`) should require no change. * Add the necessary pretty-printing logic (in `nativeGen/X86/Ppr.hs`) to produce the new instructions * Add the necessary logic to the code generator to implement the `MachOps` (e.g. `nativeGen/X86/CodeGen.hs`) All-in-all this seems quite feasible and likely no more than a day or two of work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7741#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10648: Some 64-vector SIMD primitives are absolutely useless
by GHC 03 Jul '17

03 Jul '17

#10648: Some 64-vector SIMD primitives are absolutely useless -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The primitives `packInt8X64#`, `packWord8X64#`, `unpackInt8X64#`, `unpackWord8X64#` cannot be used because their types include unboxed 64-tuples, but any haskell code using them does not compile due to the 62-tuple limitation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10648> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12610: Emit tab warning promptly
by GHC 03 Jul '17

03 Jul '17

#12610: Emit tab warning promptly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs p = let x = 4 [tab]y = 5 in 12 }}} produces `error: parse error on input ‘y’` and nothing else. The problem is caused by a tab appearing to the user to line up `x` with `y` but actually placing `y` in the wrong column. The user typically will scratch their head and then post a question on StackOverflow. There they'll be told to use `-fwarn-tabs`, but ''that option won't help'' (and it's probably already on) because GHC will exit with a parse error before it gets around to giving the warning. I suspect the solution is probably to emit the tab warning in the lexer, but one of the parsing gurus will probably know better. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12610> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13906: ApplicativeDo doesn't handle existentials as well as it could
by GHC 03 Jul '17

03 Jul '17

#13906: ApplicativeDo doesn't handle existentials as well as it could -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: ApplicativeDo | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `ApplicativeDo` doesn't work nicely with existentials or GADTs. This was first considered in #13242, but I think it's worth reconsidering in light of #13875. In particular, we no longer need to think specially about whether a particular pattern match reveals evidence, as any pattern match that does so must necessarily be strict. Simon Marlow explains (in revised, I-think-unmerged, documentation) that {{{#!hs data T where A :: forall a . Eq a => a -> T test = do A x <- undefined _ <- return 'a' _ <- return 'b' return (x == x) }}} will not typecheck because it is first rearranged to {{{#!hs test = (\x _ -> x == x) <$> do A x <- undefined; _ <- return 'a'; return x <*> return 'b' }}} This is weird! The more human-obvious rearrangement would work just fine: {{{#!hs test = do A x <- undefined (\_ _ -> x == x) <$> return 'a' <*> return 'b' }}} How can we get there? I think it's actually easy. Suppose we have {{{#!hs do p1 <- e1 p2 <- e2 p3 <- e3 p4 <- e4 p5 <- e5 e6 }}} Before starting the detailed dependency analysis and such, let's look just at ''which patterns are strict''. If a pattern is strict, then ''every'' following action must be seen as depending on it, and therefore its bindings and evidence can scope over everything else. Let's say that `p3` is strict. Then we can immediately transform the expression to {{{#!hs do p1 <- e1 p2 <- e2 e3 >>= \case p3 -> do p4 <- e4 p5 <- e5 e6 -- if refutable _ -> fail ... }}} and then continue the process in the inner `do` block. If this is done as an initial pass, then further rearrangement doesn't need to consider the possibility of strict patterns; there won't be any. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13906> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #3205: Generalized isomorphic deriving
by GHC 03 Jul '17

03 Jul '17

#3205: Generalized isomorphic deriving -------------------------------------+------------------------------------- Reporter: ajd | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: language Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3205#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13905: ApplicativeDo is too strict with newtype patterns
by GHC 03 Jul '17

03 Jul '17

#13905: ApplicativeDo is too strict with newtype patterns -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The fix to #13875 went a little too far, and interprets newtype constructor patterns as strict. It's not clear to me how to fix this, as the `Name` of the constructor doesn't seem to give any clue as to whether it is a newtype constructor or a data constructor. The comment at the top of `basicTypes/Name.hs` indicates {{{ -- * 'Name.Name' is the type of names that have had their scoping and binding resolved. They -- have an 'OccName.OccName' but also a 'Unique.Unique' that disambiguates Names that have -- the same 'OccName.OccName' and indeed is used for all 'Name.Name' comparison. Names -- also contain information about where they originated from, see "Name#name_sorts" }}} which suggests that this information should be available, but I don't know what's involved in propagating it to the right place. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13905> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13893: Improved Help for Control.Concurrent and Control.Exception when "variable not in scope"
by GHC 03 Jul '17

03 Jul '17

#13893: Improved Help for Control.Concurrent and Control.Exception when "variable not in scope" -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The piece of code that bgamari wrote in {{{#13891}}} is interesting from the point of view of the error messages.\\ {{{ main = do putStrLn "forking" forkIO $ bracket (putStrLn "forked") (const $ putStrLn "finalize") (const $ putStrLn "hello" >> threadDelay 100000000) threadDelay 10000 putStrLn "done" }}} When the imports are not written GHC answers.\\ {{{ Prelude> :l testfork [1 of 1] Compiling Main ( testfork.hs, interpreted ) testfork.hs:6:5: error: Variable not in scope: forkIO :: t0 -> IO a0 testfork.hs:6:14: error: Variable not in scope: bracket :: IO () -> (b1 -> IO ()) -> (b0 -> IO b2) -> t0 testfork.hs:6:101: error: Variable not in scope: threadDelay :: Integer -> IO b2 testfork.hs:7:5: error: Variable not in scope: threadDelay :: Integer -> IO a1 Failed, modules loaded: none. Prelude> }}} It would be advisable to complete by:\\ {{{Perhaps you intended to import Control.Concurrent}}} for {{{forkIO}}} and {{{threadDelay}}}.\\ {{{Perhaps you intended to import Control.Exception}}} for {{{bracket}}}.\\ I hope you have a way to write it once for all the variables involved. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13893> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13912: Disparity in error message in GHCi with : load vs writing directly in GHCi
by GHC 02 Jul '17

02 Jul '17

#13912: Disparity in error message in GHCi with : load vs writing directly in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ module Maintest where a:: Int a = 'a' main = print "b" }}} If I load this program with the command {{{:load}}} its answer is\\ {{{ Prelude> :l maintest [1 of 1] Compiling Maintest ( maintest.hs, interpreted ) maintest.hs:4:5: error: * Couldn't match expected type `Int' with actual type `Char' * In the expression: 'a' In an equation for `a': a = 'a' | 4 | a = 'a' | ^^^ Failed, modules loaded: none. Prelude> }}} If I write this program directly in GHCi, its answer is\\ {{{ Prelude> :{ Prelude| module Maintest where Prelude| a:: Int Prelude| a = 'a' Prelude| main = print "b" Prelude| :} <interactive>:20:5: error: * Couldn't match expected type `Int' with actual type `Char' * In the expression: 'a' In an equation for `a': a = 'a' Prelude> }}} This information has disappeared\\ {{{ | 4 | a = 'a' | ^^^ }}} The version of GHCi used is this one {{{GHCi, version 8.2.0.20170507}}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13912> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0