March 2014 - ghc-tickets

[GHC] #8153: Implement AES intrinsics
by GHC 10 Apr '14

10 Apr '14

#8153: Implement AES intrinsics ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- LLVM has the following intrinsics for working with AES encryption; @llvm.x86.aesni_{aesimc,aesenc,aesenclast,aesdec,aesdeclast,aeskeygenassist} It would be nice if at some stage these are supported through primops/intrinsics, as it would mean the crypto libraries can be rewritten to not use C and we'd get some nicer inlining on these. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8153> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8157: Add a broader set of (C/CMM-based) atomic memory operations
by GHC 10 Apr '14

10 Apr '14

#8157: Add a broader set of (C/CMM-based) atomic memory operations ------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- This task is a precursor to ticket #7883. The goal is to standardize a broader set of atomic ops -- mainly CAS and fetch-and-add -- and then in #7883 we will optimize those primops to have native support in the LLVM backend and thus avoid the extra C calls. Currently, the goal is only to support word-sized (4 or 8 byte) compare-and-swap and fetch-and-add operations. In the future, this goal could be expanded to support 16-byte CAS, implemented by CMPXCHG16B on x86. Even supporting word sized CAS requires three different primops for operating on `MutVar`, `MutableArray`, and `MutableByteArray`, respectively. Here are signatures for those primOps: {{{ #!C gcptr stg_casMutVarzh ( gcptr mv, gcptr old, gcptr new ) /* MutVar# s a -> a -> a -> State# s -> (# State#, Int#, Any a #) */ gcptr stg_casArrayzh ( gcptr arr, W_ ind, gcptr old, gcptr new ); /* MutableArray# s a -> Int# -> a -> a -> State# s -> (# State# s, Int#, Any a #) */ W_ stg_casIntArrayzh( gcptr arr, W_ ind, W_ old, W_ new ); /* MutableByteArray# s -> Int# -> Int# -> Int# -> State# s -> (# State# s, Int# #) */ }}} Fetch-and-add, on the other hand, only makes sense on a `MutableByteArray`: {{{ #!C W_ stg_fetchAddIntArrayzh( gcptr arr, W_ ind, W_ incr ); /* MutableByteArray# s -> Int# -> Int# -> State# s -> (# State# s, Int# #) */ }}} Some systems, such as gcc and LLVM, provide other variants, such as "fetch-and-multiply". However, these do not have direct support on x86 and are usually just simulated with CAS. For example, see the [http://llvm.org/docs/Atomics.html#atomics-and-codegen LLVM documentation here]. User-exposed Haskell libraries for atomic operations may employ the same approach using the CAS primOps above to simulate other fetch-and-X operations. Finally, a design question which bears thinking about is how to implement opaque "ticket" approach to CAS. The basic idea is that a user does NOT present a regular pointer-based data value (e.g. `Int`) to CAS as the "old" value. Rather, observations of prior values are kept in an opaque form (`Any` type) to prevent the compiler changing the pointer identity by, for example, unboxing and reboxing the value. The way this affects the **primOp** design is as follows. The current implementation of casMutVar# and casArray# returns the NEW value rather than the old one if the CAS is successful. The Haskell code that imports the primOps treats this new value as the opaque ticket. The user can in fact safely retrieve the real value from the `Any`-based "ticket" with a `peekTicket :: Ticket a -> a` operation. But [http://hackage.haskell.org/packages/archive/atomic-primops/0.4/doc/html /Data-Atomics.html#g:1 peekTicket] MUST [https://github.com/rrnewton /haskell-lockfree- queue/blob/880fb11de354d84f6c9a8ee06d5d4a887bd449a4/AtomicPrimops/Data/Atomics.hs#L114 be marked NOINLINE] to hide the `unsafeCoerce` operation inside it from compiler optimizations. Otherwise, the code path that carries the ticket from one CAS operation to the next is subject to optimization [1]. In particular, `unsafeCoerce` simply becomes a type-level operation, not a function call with the usual constraints on control and dataflow. Returning to the issue of primOp design, if we wished to avoid the somewhat non-standard design of returning the new value from CAS, we //could// allow users to create `Ticket` values themselves, rather retrieving them as the result of previous read and CAS IO operations. Yet this would entail an additional `NOINLINE` (unsafeCoerce) function call, and I believe it would be prone to error. Further, if you look at [https://github.com/ghc/ghc/blob/25ad01533aaaf1ccf69e1b7216e66de025b8131b/rt… the primOp implementation for stg_casMutVarzh], you will see that there is //already// a branch, which is necessary for updating GC-related meta-data. Thus there is no additional overhead to return the new rather than the old value from CAS operations in the successful case. Haskell-level CAS is already a compound operation, not merely a single machine code instruction. By contrast, the C intrinsic `__sync_val_compare_and_swap` can become only a single machine operation, and it returns the "old" value irrespective of whether the CAS succeeded or failed. In fact, an equality comparison on that old value is necessary to determine if the operation succeeded. In contrast, the Haskell CAS primOps above return an unboxed tuple with an explicit success bit. Thus returning the old value in the success case is completely redundant, and returning the new value instead allows us to acheive two goals (the CAS and the opacifying coercion) with one operation at no additional cost. [1] P.S. As a concrete example of what happens when `unsafeCoerce` is not hidden, consider the following code as a starting point: {{{ x = unsafeCoerce y z = f y }}} `x` would seem to have nothing to do with `f`, and yet later in the compiler, one can end up with Core like this: {{{ z = f x }}} This exposes the type information and activates optimizations, which was the source of [https://github.com/rrnewton/haskell-lockfree- queue/issues/5 one bug] with the `lockfree-queue` package that was fixed by adding NOINLINE to `peekTicket`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8157> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8937: Wrong jump target in stg_maskUninterruptiblezh
by GHC 07 Apr '14

07 Apr '14

#8937: Wrong jump target in stg_maskUninterruptiblezh ------------------------------------+------------------------------------- Reporter: hsjunn | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | 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: | ------------------------------------+------------------------------------- The stack check there reads: STK_CHK_P_LL (WDS(1)/* worst case */, stg_maskAsyncExceptionszh, R1); Isn't that supposed to be STK_CHK_P_LL (WDS(1)/* worst case */, stg_maskUninterruptiblezh, R1); ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8937> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8931: The type defaulting in GHCi with Typeable
by GHC 07 Apr '14

07 Apr '14

#8931: The type defaulting in GHCi with Typeable -------------------------------------+------------------------------------- Reporter: skata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Operating System: Unknown/Multiple Keywords: type defaulting, | Type of failure: GHC rejects Typeable | valid program Architecture: Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- The type defaulting in GHCi works in less cases with GHC 7.8.1-rc2 than with older versions, though there is no change in the related part of the documentation (i.e., "2.4.7 Type defaulting in GHCi"). {{{ skata@kata58:~$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228 skata@kata58:~$ ghci GHCi, version 7.8.0.20140228: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :m +Data.Typeable Prelude Data.Typeable> let {f :: Read a => (a->Bool) -> Char; f = undefined} Prelude Data.Typeable> f (\x -> (x == 3)) *** Exception: Prelude.undefined <== This is the expected result. Prelude Data.Typeable> let {f :: Typeable a => (a->Bool) -> Char; f = undefined} Prelude Data.Typeable> f (\x -> (x == 3)) <== Type defaulting does not work in this case. <interactive>:6:1: No instance for (Typeable a0) arising from a use of ‘f’ The type variable ‘a0’ is ambiguous Note: there are several potential instances: instance [overlap ok] Typeable () -- Defined in ‘Data.Typeable.Internal’ instance [overlap ok] Typeable Bool -- Defined in ‘Data.Typeable.Internal’ instance [overlap ok] Typeable Char -- Defined in ‘Data.Typeable.Internal’ ...plus 14 others In the expression: f (\ x -> (x == 3)) In an equation for ‘it’: it = f (\ x -> (x == 3)) <interactive>:6:13: No instance for (Eq a0) arising from a use of ‘==’ The type variable ‘a0’ is ambiguous Relevant bindings include x :: a0 (bound at <interactive>:6:5) Note: there are several potential instances: instance Eq a => Eq (GHC.Real.Ratio a) -- Defined in ‘GHC.Real’ instance Eq Integer -- Defined in ‘integer-gmp:GHC.Integer.Type’ instance Eq () -- Defined in ‘GHC.Classes’ ...plus 33 others In the expression: (x == 3) In the first argument of ‘f’, namely ‘(\ x -> (x == 3))’ In the expression: f (\ x -> (x == 3)) <interactive>:6:16: No instance for (Num a0) arising from the literal ‘3’ The type variable ‘a0’ is ambiguous Relevant bindings include x :: a0 (bound at <interactive>:6:5) Note: there are several potential instances: instance Num Double -- Defined in ‘GHC.Float’ instance Num Float -- Defined in ‘GHC.Float’ instance Integral a => Num (GHC.Real.Ratio a) -- Defined in ‘GHC.Real’ ...plus 7 others In the second argument of ‘(==)’, namely ‘3’ In the expression: (x == 3) In the first argument of ‘f’, namely ‘(\ x -> (x == 3))’ }}} On the other hand, {{{ skata@kata58:~$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.1 skata@kata58:~$ ghci GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :m +Data.Typeable Prelude Data.Typeable> let {f :: Read a => (a->Bool) -> Char; f = undefined} Prelude Data.Typeable> f (\x -> (x == 3)) *** Exception: Prelude.undefined Prelude Data.Typeable> let {f :: Typeable a => (a->Bool) -> Char; f = undefined} Prelude Data.Typeable> f (\x -> (x == 3)) *** Exception: Prelude.undefined }}} I think the old behavior is compliant with the documentation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8931> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8834: 64-bit windows cabal.exe segfaults in GC
by GHC 04 Apr '14

04 Apr '14

#8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+--------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: None | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- `cabal.exe` built with 64-bit windows GHC segfaults doing `cabal configure` or `cabal install` or probably something else. This occurs *both* for cabal-install 1.18.0.2 built against Cabal 1.18.1.2 and for cabal-install 1.18.0.3 built against Cabal 1.18.1.3. This occurs only for 64-bit build, 32-bit build is fine. 64-bit GHC-7.6.3 build is also fine. During debugging I see segfault occurs inside `evacuate` somewhere near `get_itbl` call I guess. If I make `cabal.exe` to not trigger some presumably bad GC compiling it with `-rtsopts` and running it as (for example) {{{cabal +RTS -H256m -m50 -RTS ...}}} the problem disappears. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8834> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 85

[GHC] #8945: GHC produces grouped declarations in a weird order
by GHC 03 Apr '14

03 Apr '14

#8945: GHC produces grouped declarations in a weird order ------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider very simple module like {{{#!haskell module J where class A a where f, g, h, i :: a -> () }}} Now when we ask GHC about declarations in the module and extract function signatures, we don't get {{{f, g, h, i :: a -> ()}}} as we could expect. We instead get {{{f, i, h, g :: a -> ()}}}. The pattern is that the first name is in a correct position and the rest is reversed. This leads to whatever uses the API get the names in order different than that in the source file. See http://trac.haskell.org/haddock/ticket/188 for an example when this matters. I have prepared an example using GHC API which you can run on your machine with your own test files and see the results for yourselves. {{{#!haskell -- GHC.Paths requires the very small ghc-paths package. -- if you don't want it, libdir = ghc --print-libdir module Main where import Control.Monad (ap, liftM2) import Data.Functor ((<$>)) import System.Environment (getArgs) import Digraph (flattenSCCs) import GHC import GHC.Paths (libdir) import Outputable (text, ppr, showSDoc, (<>), (<+>)) main :: IO () main = do (dfs, modules) <- getArgs >>= withGhc Nothing . processModules let r = map (showSDoc dfs . (\(x,y) -> text x <> text ":" <+> ppr y) . f) modules putStrLn $ unlines r where f (s, t) = (ms_hspp_file s, (\(x,_,_,_) -> x) <$> tm_renamed_source t) type ModuleName' = String withGhc :: Maybe DynFlags -> Ghc a -> IO (DynFlags, a) withGhc d act = runGhc (Just libdir) $ do dynflags <- case d of Nothing -> getSessionDynFlags Just d' -> return d' _ <- setSessionDynFlags dynflags liftM2 (,) getSessionDynFlags act processModules :: [ModuleName'] -> Ghc [(ModSummary, TypecheckedModule)] processModules modules = do mg <- depAnalysis let sortedMods = flattenSCCs $ topSortModuleGraph False mg Nothing mapM (\x -> return (\y -> (x,y)) `ap` (parseModule x >>= typecheckModule >>= loadModule)) sortedMods where depAnalysis :: Ghc ModuleGraph depAnalysis = do targets <- mapM (\f -> guessTarget f Nothing) modules setTargets targets depanal [] False }}} In this case, using the tiny module I posted at the beginning, I get: {{{ *Main> :main "/tmp/J.hs" /tmp/J.hs: Just class J.A a where J.f, J.i, J.h, J.g :: a -> () }}} It looks to me like it's just an oversight somewhere in the API and should be an easy fix for someone familiar with that part. I'd rather save myself many hours trying to find it on my own. PS: Are the rules for when grouping happens documented somewhere? Grouping functions in class definitions is the only sure-fire way I can get a grouped signature but I'm sure there were others in the past that no longer work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8945> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7066: isInstance does not work for compound types
by GHC 31 Mar '14

31 Mar '14

#7066: isInstance does not work for compound types -------------------------------------+------------------------------------ Reporter: edsko | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.4.2 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 mojojojo): I've just released "fixed" versions of {{{reifyInstances}}} and {{{isInstance}}} as the [http://hackage.haskell.org/package/th-instance- reification th-instance-reification library], which work as edsko and I expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7066#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7066: isInstance does not work for compound types
by GHC 31 Mar '14

31 Mar '14

#7066: isInstance does not work for compound types -------------------------------------+------------------------------------ Reporter: edsko | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.4.2 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 mojojojo): I just got hit by this issue. I would expect {{{ isInstance clss typs }}} to return True if and only if I can safely generate code (in my Template Haskell code) that relies on 'typs' being an instance of 'clss'. In the example above, I can not safely generate code that relies on a Show instance for (Int, A) because there is no Show instance for A. I expected exactly the same. That's why I believe that the current behaviour of the function is unintuitive to say the least. The documentation has no info concerning such behaviour either. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7066#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7730: :info and polykinds
by GHC 31 Mar '14

31 Mar '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Changes (by archblob): * related: => #8776 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7730: :info and polykinds
by GHC 31 Mar '14

31 Mar '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by archblob): Yes I am willing but this is my first time looking into the GHC codebase and I think it will take some time before we can have a meaningful discussion and not just waste your time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0