July 2017 - ghc-tickets

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

04 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 winter): Wow, this is a good news! One thing makes situation complicated is that there're several versions of SIMD implementations out there(SSE4, AVX, AVX2...), and we seems don't have a clear plan to support which version, or provide user compile flag to do fallback. After thinking about this over. I think we'd be better split SIMD primitive into `GHC.Prim.SSE4`, `GHC.PrimAVX` modules to avoid this compatibility hell. Compiler should be able to produce whatever instructions programmer want it to. We also have to provide runtime detections in RTS, use some unsafe magic we should be able to provide SIMD supporting conditions as constants. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7741#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13894: isByteArrayPinned# should consider BF_LARGE
by GHC 04 Jul '17

04 Jul '17

#13894: isByteArrayPinned# should consider BF_LARGE -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- First of all, i want to make sure `isByteArrayPinned#` is intended to let user know if a given 'ByteArray#/MutableByteArray#' is movable during safe FFI call, isn't it? If that is the case, then the code for `stg_isByteArrayPinnedzh` is not enough, since not only bytes marked with `BF_PINNED` flag is not movable, but also the bytes which is marked with `BF_LARGE`. (I read the gc code and i'm confident this holds, but if it's not, please correct me). Currently i'm using a FFI trick[https://github.com/winterland1989/stdio/blob/master/cbits/bytes.c#L33] to get `isByteArrayPinned#` on older GHCs, i want to make sure if `BF_LARGE` works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13894> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification
by GHC 04 Jul '17

04 Jul '17

#13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- {{{#!hs -- Panic.hs {-# LANGUAGE ApplicativeDo #-} {-# LANGUAGE ExistentialQuantification #-} module Panic where import Data.STRef import Control.Monad.ST data A = forall a. A a st :: ST s () st = do A _ <- pure $ A True ref <- newSTRef 1 readSTRef ref pure () }}} {{{ $ ghc Panic.hs [1 of 1] Compiling Panic ( Panic.hs, Panic.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20170106 for x86_64-unknown-linux): StgCmmEnv: variable not found $dMonad_aGQ local binds for: $trModule $tcA $tc'A $tcA1_rSi $tc'A1_rSJ $trModule1_rSK $trModule2_rSL sat_sT5 sat_sT9 sat_sTa Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/codeGen/StgCmmEnv.hs:137:9 in ghc:StgCmmEnv Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The above module fails to compile, giving the pasted panic message. Without the ApplicativeDo pragma compilation succeeds. Reproduced with GHC 8.0.2 and a recent head, courtesy of nixpkgs: {{{ gp84vpgar3n3rqvkwj47yyhxvsvbsmi6-ghc-8.1.20170106 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13242> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

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

04 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 04 Jul '17

04 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 04 Jul '17

04 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