February 2017 - ghc-tickets

[GHC] #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer
by GHC 25 Feb '17

25 Feb '17

#12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've just taken over an existing haskell package and in the process of getting it to work with ghc 8.0 discovered that when compiling one file ghc tires to use all my ram. It basically ends up using 40% of 16 Gig before being killed by the OOM (out-of-memory) killer. The project is at: https://github.com/erikd/conduit-find.git The problem can be reproduced by: {{{ git clone https://github.com/erikd/conduit-find.git cd conduit-find git checkout test/ghc-8.0 cabal sandbox init cabal install --dependencies-only cabal build }}} which on two of my machines fails building the `Data.Cond` module. This is regression, because this code compiles fine with ghc-7.10.3 and ghc-7.8.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12425> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O
by GHC 25 Feb '17

25 Feb '17

#12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc version: 41ec722d71 with assertion that fails in https://ghc.haskell.org/trac/ghc/ticket/12926 commented out {{{#!hs {-# LANGUAGE TypeFamilies #-} module Numeric.Polynomial.Log () where class AdditiveGroup v where (^+^) :: v -> v -> v negateV :: v -> v (^-^) :: v -> v -> v v ^-^ v' = v ^+^ negateV v' class AdditiveGroup v => VectorSpace v where type Scalar v :: * (*^) :: Scalar v -> v -> v data Poly1 a = Poly1 a a data IntOfLog poly a = IntOfLog !a !(poly a) instance Num a => AdditiveGroup (Poly1 a) where {-# INLINE (^+^) #-} {-# INLINE negateV #-} Poly1 a b ^+^ Poly1 a' b' = Poly1 (a + a') (b + b') negateV (Poly1 a b) = Poly1 (negate a) (negate b) instance (AdditiveGroup (poly a), Num a) => AdditiveGroup (IntOfLog poly a) where {-# INLINE (^+^) #-} {-# INLINE negateV #-} IntOfLog k p ^+^ IntOfLog k' p' = IntOfLog (k + k') (p ^+^ p') negateV (IntOfLog k p) = IntOfLog (negate k) (negateV p) {-# SPECIALISE instance Num a => AdditiveGroup (IntOfLog Poly1 a) #-} instance (VectorSpace (poly a), Scalar (poly a) ~ a, Num a) => VectorSpace (IntOfLog poly a) where type Scalar (IntOfLog poly a) = a s *^ IntOfLog k p = IntOfLog (s * k) (s *^ p) }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.1.20161206 for x86_64-unknown-linux): ASSERT failed! $dAdditiveGroup_aIU Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1114:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1163:22 in ghc:Outputable assertPprPanic, called at compiler/stgSyn/CoreToStg.hs:967:78 in ghc:CoreToStg Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1114:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1118:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1161:5 in ghc:Outputable assertPprPanic, called at compiler/stgSyn/CoreToStg.hs:967:78 in ghc:CoreToStg Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12944> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #12776: Panic Simplifier ticks exhausted since ghc 8
by GHC 25 Feb '17

25 Feb '17

#12776: Panic Simplifier ticks exhausted since ghc 8 -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: 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: -------------------------------------+------------------------------------- I'm getting a panic! in GHC 8.0.1 and in 8.1.20161028 {{{ sjoosten:ghcCompileBug sjc$ ghc-8.1.20161028 --make Main.hs -O2 [1 of 2] Compiling Factorize ( Factorize.hs, Factorize.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20161028 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $slast_s_s1IU To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 18241 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Attached is some code which I tried to make as small as possible (it therefore does not make sense, but it reproduces the panic). The panic! only occurs with -O2 (I need the -O2 switch to optimise the automatically generated Haskell code). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12776> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13246: hPutBuf issues unnecessary empty write syscalls for large writes
by GHC 25 Feb '17

25 Feb '17

#13246: hPutBuf issues unnecessary empty write syscalls for large writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.0.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #13245 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To get good performance, it is better to use few system calls that write lots of data in batch. I found a bug in hPutBuf that makes this concept not work: When using `hPutBuf` with a buffer size greater than 8095 (this number it self is a bug, #13245) bytes, two syscalls are issued instead of one: one empty `write("")` (a zero-bytes-write, which can't do anything useful), and after that the actual useful `write()` of the data. Example code: {{{ main = do withBinaryFile "testfile2" WriteMode $ \ hTo -> do let bufferSize = 8096 allocaBytes bufferSize $ \buffer -> do Main.hPutBuf hTo buffer bufferSize }}} In `strace -f -T` on the compiled binary, we see the syscalls: {{{ write(3, "", 0) = 0 <0.000004> write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8096) = 8096 <0.000017> }}} As you can see in the timings, this also has a fairly large performance overhead (20% in this case). When using `bufferSize = 8095`, the `write("")` disappears. The problem is this code for `bufWrite` (called by `hPutBuf`): {{{ bufWrite :: Handle__-> Ptr Word8 -> Int -> Bool -> IO Int bufWrite h_@Handle__{..} ptr count can_block = seq count $ do -- strictness hack old_buf@Buffer{ bufRaw=old_raw, bufR=w, bufSize=size } <- readIORef haByteBuffer -- enough room in handle buffer? hPutStrLn System.IO.stderr (show (size, w, count)) if (size - w > count) -- There's enough room in the buffer: -- just copy the data in and update bufR. then do debugIO ("hPutBuf: copying to buffer, w=" ++ show w) copyToRawBuffer old_raw w ptr count writeIORef haByteBuffer old_buf{ bufR = w + count } return count -- else, we have to flush else do debugIO "hPutBuf: flushing first" old_buf' <- Buffered.flushWriteBuffer haDevice old_buf -- TODO: we should do a non-blocking flush here writeIORef haByteBuffer old_buf' -- if we can fit in the buffer, then just loop if count < size then bufWrite h_ ptr count can_block else if can_block then do writeChunk h_ (castPtr ptr) count return count else writeChunkNonBlocking h_ (castPtr ptr) count }}} The check `if (size - w > count)` should be `if (size - w >= count)` instead, because we can do the write all fine if it fits exactly. In the adversarial case, `size - w == count`, we go into the `hPutBuf: flushing first` branch, thus emitting the `write("")`. See https://github.com/ghc/ghc/blame/876b00ba25a615423f48b0cf9d443a9fd5dbd6f4/l… for the full code. Simon Marlow has confirmed this on IRC, I'll submit a patch for it that switches to `>=`. It would be nice if the fix could be released in both GHC 8.2 and and 8.0.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13246> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13245: Default FD buffer size is not a power of 2
by GHC 25 Feb '17

25 Feb '17

#13245: Default FD buffer size is not a power of 2 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System | 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: -------------------------------------+------------------------------------- From https://hackage.haskell.org/package/base-4.9.1.0/docs/src/GHC.IO.FD.html {{{ -- We used to use System.Posix.Internals.dEFAULT_BUFFER_SIZE, which is -- taken from the value of BUFSIZ on the current platform. This value -- varies too much though: it is 512 on Windows, 1024 on OS X and 8192 -- on Linux. So let's just use a decent size on every platform: dEFAULT_FD_BUFFER_SIZE :: Int dEFAULT_FD_BUFFER_SIZE = 8096 }}} 8096 is not a power of two, and does not agree with the original commit message that sets it to 8KB (https://github.com/ghc/ghc/blame/master/libraries/base/GHC/IO/FD.hs#L119) Confirmed by Simon Marlow on IRC that this is a typo, a mix between 8192 and 4096. I'll send a patch to set it to 8192. It would be nice if the fix could be released in both GHC 8.2 and and 8.0.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13245> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] Batch modify: #12100, #12776, #12944, #13242, #7411, #11606, ...
by GHC 25 Feb '17

25 Feb '17

Batch modification to #12100, #12776, #12944, #13242, #7411, #11606, #11959, #12150, #12425, #12610, #1851, #6132, #11525, #11731, #11827, #11954, #12021, #12090, #12193, #12234, #12737, #12846, #12885, #12921, #12940, #12985, #13025, #13035, #13043, #13050, #13056, #13083, #13135, #13245, #13246, #13285, #12055 by bgamari: milestone to 8.2.1 Comment: At this point it is rather unlikely that there will be an 8.0.3. Re-milestoning. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=12100%2C12776%2C12944%2C13242%2C74…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12680: Permit type equality instances in signatures
by GHC 24 Feb '17

24 Feb '17

#12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- David Christiansen requested this, and I want to record it so I don't forget. What he wants to be able to do is say things like this in signatures: {{{ signature A where data T data S type family F a instance T ~ S instance F Int ~ S }}} This is currently rejected by GHC because you are not allowed to define instances of type equality. But really all this is saying is that the type equality must hold when we eventually implement the module; easy to check. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12680> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #13250: Backpack: matching newtype selectors doesn't work
by GHC 24 Feb '17

24 Feb '17

#13250: Backpack: matching newtype selectors doesn't work -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ unit p where signature A where newtype F a = F { mkF :: a } unit q where module A where newtype F a = F { mkF :: a } unit r where dependency p[A=q:A] }}} fails with {{{ ezyang@sabre:~$ ghc-head --backpack selector.bkp -dppr-debug [1 of 3] Processing p [2 of 3] Processing q Instantiating q [1 of 1] Compiling A ( q/A.hs, q/A.o ) [3 of 3] Processing r Instantiating r [1 of 1] Including p[A=q:A] Instantiating p[A=q:A] [1 of 1] Compiling A[sig] ( p/A.hsig, p/p-HVmFlcYSefiK5n1aDP1v7x/A.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20170123 for x86_64-unknown-linux): TcIface.find_lbl missing: mkF{v} known labels: [mkF{q:A.mkF{v rb}}] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1166:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1170:37 in ghc:Outputable pprPanic, called at compiler/iface/TcIface.hs:841:41 in ghc:TcIface }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13250> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13334: Constant folding for repeated integer operation of unknown value
by GHC 24 Feb '17

24 Feb '17

#13334: Constant folding for repeated integer operation of unknown value -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While looking at Phab:D3197 I noticed that currently there is nothing to turn an expression of the form `n+n+...+n` into `n*m`. It seems like some rules like, {{{ forall x. x +# x = 2*x forall n x. n*x + x = (n+1) * x forall n x. x + n*x = (n+1) * x }}} Might fix this. Of course, it's quite possible that a string of additions **is** sometimes faster than a multiplication, but it seems to me that we should (for integer types) perform the rewrite to multiplication and then teach the code generator to lower to addition if it deems it advantageous. Naturally, this also applies to other integer operators as well. Regardless, I doubt that this is hurting anyone too badly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13334> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13305: static: check for identifiers should only consider term level variables
by GHC 24 Feb '17

24 Feb '17

#13305: static: check for identifiers should only consider term level variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StaticPointers #-} module Main where import Data.Proxy import GHC.StaticPtr foo :: forall a. StaticPtr (Proxy a) foo = static (Proxy :: Proxy a) main :: IO () main = putStrLn "Hi" }}} This yields {{{ Only identifiers of top-level bindings can appear in the body of the static form: static (Proxy :: Proxy a) but the following identifiers were found instead: a }}} but `a` is a type-level variable and therefore by definition static. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13305> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15