March 2017 - ghc-tickets

[GHC] #13427: Per-function code-generation options
by GHC 14 Mar '17

14 Mar '17

#13427: Per-function code-generation options -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- On ghc-devs Ed Kmett has [[https://mail.haskell.org/pipermail/ghc- devs/2017-March/013923.html|asked]] for some way to more precisely specify code generation options (e.g. should AVX be used?). This idea has taken a few different shapes in the thread, but I suspect that the most sensible approach is add something like a `TARGET` pragma, which the user could attach to a top-level binding. Since the interactions with inlining are non-trivial, I suspect you would want to require that this only be applied to `NOINLINE` bindings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13396: thread blocked when running `deepseq` with infinite list
by GHC 14 Mar '17

14 Mar '17

#13396: thread blocked when running `deepseq` with infinite list -------------------------------------+------------------------------------- Reporter: Forec | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: thread | Operating System: Unknown/Multiple blocked | Architecture: x86_64 | Type of failure: GHCi crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs ghci> :m +Control.Deepseq ghci> let x = [1..] ghci> x `deepseq` () Ctrl^C Interrupted. ghci> ghc.exe: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13396> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11450: Associated types at wrong type in instance
by GHC 14 Mar '17

14 Mar '17

#11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Consider {{{ class C x where type T x instance C (Either a b) where type T (Either b a) = b -> a }}} This is bogus, because the equation for `T` has the parameters to `Either` reversed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11450> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #13405: Reimplement unsafeInterleaveIO using runRW#
by GHC 14 Mar '17

14 Mar '17

#13405: Reimplement unsafeInterleaveIO using runRW# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Core | Version: 8.1 Libraries | 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: -------------------------------------+------------------------------------- Currently, we have {{{#!hs {-# INLINE unsafeInterleaveIO #-} unsafeInterleaveIO :: IO a -> IO a unsafeInterleaveIO m = unsafeDupableInterleaveIO (noDuplicate >> m) {-# NOINLINE unsafeDupableInterleaveIO #-} unsafeDupableInterleaveIO :: IO a -> IO a unsafeDupableInterleaveIO (IO m) = IO ( \ s -> let r = case m s of (# _, res #) -> res in (# s, r #)) }}} This all seems a bit weird from a semantic standpoint, and also seems likely to get in the way of the best idea I have so for for converting precise exceptions to imprecise ones in unsafe functions. === The substantial semantic weirdness === `unsafeDupableInterleaveIO` takes the current state of the world, `s`, and passes it to `m`. But it passes it to `m` at some time when the actual real world has most likely moved on! That is, we pass `m` a moment of the ''past''. Strange indeed. === The exception handling matter === I would like to separate precise exceptions (thrown using `raiseIO#`) from imprecise ones (thrown using `raise#`). In particular, I want to offer an operation that catches only precise exceptions. But `unsafePerformIO` and `unsafeInterleaveIO` and such need to convert precise exceptions into imprecise ones to avoid breaking the more aggressive demand analysis of the hypothetical `catchThrowIO`. === The fix === I believe the fix is pretty simple: rather than holding a piece of the past in our pocket, start a new timeline: {{{#!hs unsafeDupableInterleaveIO :: IO a -> IO a unsafeDupableInterleaveIO (IO m) = IO (\ s -> (# s, runRW# (\s2 -> case m s2 of (# _, res #) -> res) #)) }}} This seems to me to get the point across a lot better, and it ''may'' even allow us to remove the `NOINLINE`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13405> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #3207: readMutVar# is inlined/duplicated
by GHC 14 Mar '17

14 Mar '17

#3207: readMutVar# is inlined/duplicated -------------------------------------+------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | codeGen/should_run/3207 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): This was closed by commit 8a3ed3364fbc74b1f1b87b049737da2b251f92df, which made a slew of "I/O-like" primops `has-side-effects`, even though they were "read-only". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3207#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13421: Confusing error when using BangPatterns without pragma
by GHC 14 Mar '17

14 Mar '17

#13421: Confusing error when using BangPatterns without pragma -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- If you have something like this {{{ putTagType :: TagType -> Put putTagType !x = putWord8 $! fromIntegral $! fromEnum x {-# INLINE putTagType #-} }}} and forget to put the pragma for BangPatterns you get this: {{{ /Users/kvanb/git/mineserver/mineserver- nbt/src/Mineserver/NBT/TagType.hs:40:1: error: The type signature for ‘putTagType’ lacks an accompanying binding /Users/kvanb/git/mineserver/mineserver- nbt/src/Mineserver/NBT/TagType.hs:42:12: error: The INLINE pragma for ‘putTagType’ lacks an accompanying binding Warning: File listed in mineserver-nbt/mineserver-nbt.cabal file does not exist: README.md }}} which leaves you very confused thinking you made a typo. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13382: Join ceilings incorrectly getting placed outside value lambdas by SetLevels
by GHC 13 Mar '17

13 Mar '17

#13382: Join ceilings incorrectly getting placed outside value lambdas by SetLevels -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a latent bug, so there's no test case. Given code like {{{ let f = \x y z -> e1 in e2 }}} we have `SetLevels` put a “join ceiling” around `e1` to be sure that we don't let a join point float out, since any jump to that join point from `e1` would be invalid. However, an oversight in `lvlFloatRhs` has us putting the join ceiling around the lambdas instead—in other words, it appears that we might produce {{{ let f = join j = ... in \x y z -> ... jump j ... in e2 }}} (which is wrong because you can't jump out of a lambda) rather than {{{ let f = \x y z -> join j = ... in ... jump j ... in e2 }}} As it happens, this bug is latent because of the way `FloatOut` and `SetLevels` interact. `FloatOut` correctly understands where the join ceiling //should// be. Then, at each join ceiling, `FloatOut` drops all bindings marked “float me to the nearest join ceiling,” so if `j` is so marked, the latter example (the correct one) is the result and not the former. Nonetheless, `lvlFloatRhs` as written is clearly wrong. (This of course illustrates a shortcoming of the “join ceiling” scheme, at least as implemented: we rely on `FloatOut` and `SetLevels` agreeing on where the join ceilings are. It's easy to specify where they //should// be, but since there are two modules implementing them, we have twice the opportunities to get it wrong.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13382> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13326: Implement `-ferror-limit` for GHC
by GHC 13 Mar '17

13 Mar '17

#13326: Implement `-ferror-limit` for GHC -------------------------------------+------------------------------------- Reporter: coopercm | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- Clang has an option `-ferror-limit=n` which is very handy for development since it lets you focus on the first error message when there is a long list of errors. A similar flag for GHC would be very helpful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13326> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13414: shebang + literate haskell causes line numbering skew
by GHC 13 Mar '17

13 Mar '17

#13414: shebang + literate haskell causes line numbering skew -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Noticed on doctest's Setup.lhs file. Minimal example: {{{#!hs #!/usr/bin/env runhaskell > main = return () }}} {{{ $ inplace/bin/ghc-stage2 -fforce-recomp -Wall Setup [1 of 1] Compiling Main ( Setup.lhs, Setup.o ) Setup.lhs:1:3: warning: [-Wmissing-signatures] Top-level binding with no type signature: main :: IO () | 1 | #!/usr/bin/env runhaskell | ^^^^ }}} Notice how it points 4 characters a line before '''main'''. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13414> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13298: Compact API design improvements
by GHC 13 Mar '17

13 Mar '17

#13298: Compact API design improvements -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: | Version: 8.0.1 libraries/compact | 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: -------------------------------------+------------------------------------- I took a look at the compact API today and I realized that there are a lot of improvements we should make to it: 1. `fmap getCompact . compact` is a pretty common thing to do, if you don't actually care about the compact pointer. We should make a helper function for this. 2. The `SerializedCompact` data structure needs a bunch of instances. Especially, a user who wants to serialize the compact region needs to save this metadata somewhere, but we don't offer any help for doing this. 3. `importCompact` will always print a message to stderr saying pointer fixup is happening. Need to be able to suppress this message. 4. The serialization API is really unsafe; we should make it more safe by default by including some sort of fingerprint, at least. 5. There should be a convenience function for serializing to and from a file, and serializing to and from a handle. RDMA is always going to be delicate business (so keep the old API around) but for these cases we should pave the cowpaths. Here is some sample code that might help: {{{ {-# LANGUAGE ScopedTypeVariables #-} import System.Environment (getArgs) import qualified Data.Set as Set import System.IO import Data.Compact import Data.Compact.Serialized import Foreign.Ptr import Foreign.Storable import Foreign.Marshal.Alloc import Control.Monad main = do [dict_file, out_file] <- getArgs dict <- readFileLatin1 dict_file c <- compact (Set.fromList (words dict)) withBinaryFile out_file WriteMode $ \h -> withSerializedCompact c $ \sc -> do -- Write out the metadata header hPutStorable h (serializedCompactRoot sc) forM_ (serializedCompactBlockList sc) $ \(ptr, l) -> do hPutStorable h ptr hPutStorable h l hPutStorable h nullPtr -- Write out the payload forM_ (serializedCompactBlockList sc) $ \(ptr, l) -> hPutBuf h ptr (fromIntegral l) mb_r <- withBinaryFile out_file ReadMode $ \h -> do -- Read out the metadata header root <- hGetStorable h let go h xs = do ptr <- hGetStorable h if ptr == nullPtr then return (reverse xs) else do l <- hGetStorable h go h ((ptr, l):xs) blocks <- go h [] let sc = SerializedCompact { serializedCompactBlockList = blocks, serializedCompactRoot = root } -- Read the payload into memory importCompact sc $ \ptr l -> void $ hGetBuf h ptr (fromIntegral l) print (fmap getCompact mb_r == Just (getCompact c)) hPutStorable :: forall a. Storable a => Handle -> a -> IO () hPutStorable h a = alloca $ \ptr -> do poke ptr a hPutBuf h ptr (sizeOf (undefined :: a)) hGetStorable :: forall a. Storable a => Handle -> IO a hGetStorable h = alloca $ \ptr -> do hGetBuf h ptr (sizeOf (undefined :: a)) peek ptr readFileLatin1 f = do h <- openFile f ReadMode hSetEncoding h latin1 hGetContents h }}} I'm happy to do these but I want to make sure I'm not stepping on FB's toes, also I don't know if bgamari wants to take patches along these lines so late in the release cycle. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4