March 2018 - ghc-tickets

[GHC] #12903: SIGINT is not handled in forked process
by GHC 14 Jun '18

14 Jun '18

#12903: SIGINT is not handled in forked process -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 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: -------------------------------------+------------------------------------- If haskell program is forked in a toplevel hander that sends UserInterrupt in the main thread doesn't work, because Thread 1 doesn't exists in forked program, so that action is noop. Minimal example: {{{#!hs import Control.Concurrent import Control.Exception import System.Posix main = do pid <- forkProcess $ do handle (\UserInterrupt{} -> putStrLn "caught") $ threadDelay 2000000 signalProcess sigINT pid threadDelay 2000000 }}} Expected result: "caught" printed to stdout. Actual result: nothing is printed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12903> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13564: Why does memory usage increase so much during CoreTidy?
by GHC 13 Jun '18

13 Jun '18

#13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I made GHC display the live data size before and after each pass and while compiling DynFlags, the live data size increased by almost 50% during the CoreTidy pass, even though the Core program size hardly changed: {{{ ... Result size of Simplifier = {terms: 104,494, types: 264,683, coercions: 15,760, joins: 58/680} !!! Simplifier [DynFlags]: 19.69 221248736: finished in 5337.48 milliseconds, allocated 4416.624 megabytes *** Demand analysis [DynFlags]: 19.69 221248152: Result size of Demand analysis = {terms: 104,494, types: 264,683, coercions: 15,760, joins: 58/680} !!! Demand analysis [DynFlags]: 20.77 248604416: finished in 1349.45 milliseconds, allocated 2298.950 megabytes *** CoreTidy [DynFlags]: 20.77 248603432: Result size of Tidy Core = {terms: 104,440, types: 264,565, coercions: 15,700, joins: 58/679} !!! CoreTidy [DynFlags]: 21.43 342594336: finished in 1124.37 milliseconds, allocated 736.209 megabytes }}} I find the amount of this increase surprising considering what CoreTidy does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13564> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9539: TQueue can lead to thread starvation
by GHC 12 Jun '18

12 Jun '18

#9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.2 Keywords: stm | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For background, please see [http://stackoverflow.com/questions/25536604 /huge-memory-consumption-for-simple-multithreaded- haskell/25560047#25560047 this SO question] When using TQueue, a sufficiently fast/persistent writer can result in the reader never getting scheduled, causing the queue to continually grow and lost concurrency. I believe the issue is caused by the definition of readTQueue: {{{ readTQueue :: TQueue a -> STM a readTQueue (TQueue read write) = do xs <- readTVar read case xs of (x:xs') -> do writeTVar read xs' return x [] -> do ys <- readTVar write case ys of [] -> retry _ -> case reverse ys of [] -> error "readTQueue" (z:zs) -> do writeTVar write [] writeTVar read zs return z }}} Note that the last `case` needs to traverse the write-end of the queue within the STM transaction. If the list is sufficiently large, a writer can commit a new transaction much more quickly, invalidating the read transaction. If threads continue to write to the queue, the reader will never get an opportunity to commit (and the list will grow, exacerbating the problem). This alternative definition seems to fix the problem, but I don't know if there are other drawbacks to using it. {{{ readTQueue' :: TQueue a -> STM a readTQueue' (TQueue read write) = do xs <- readTVar read case xs of (x:xs') -> do writeTVar read xs' return x [] -> do ys <- readTVar write case ys of [] -> retry _ -> do writeTVar write [] let (z:zs) = reverse ys writeTVar read zs return z }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9539> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #14737: Improve performance of Simplify.simplCast
by GHC 11 Jun '18

11 Jun '18

#14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #11735 #14683 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Splitting off task 3 from #11735. When compiling [https://ghc.haskell.org/trac/ghc/attachment/ticket/14683/Grammar.hs] `simplCast` eats up more execution time than we think it should. From [https://ghc.haskell.org/trac/ghc/ticket/11735#comment:10] > Something is clearly wrong with `Simplify.simplCast`. I think I know what it is. Given > {{{ > (fun |> co) @t1 @t2 ... @tn > }}} > we will call `pushCoTyArg` `n` times, and hence does `n` singleton substitutions, via the `n` calls to `piResultTy`. > > Solution: gather up those type arguments (easy) and define > {{{ > pushCoTyArgs :: Coercion -> [Type] -> Maybe ([Type], Coercion) > }}} And [https://ghc.haskell.org/trac/ghc/ticket/11735#comment:41] > OK. I looked at `pushCoTyArg` and friends, and I have a very simple solution: just move the `isReflexiveCo` case in `addCoerce` (a local function within `Simplify.simplCast`) to the top. That should do it. Then `pushCoTyArg` is never called with a reflexive coercion, and so the `piResultTy` case won't happen. > > Now, `pushCoArgs` might still call `pushCoTyArg` with a reflexive coercion, but it can be taught not to as well: Have `pushCoArgs` return a `Maybe ([CoreArg], Maybe Coercion)` and `pushCoArg` return a `Maybe (CoreArg, Maybe Coercion)`. If the second return values are `Nothing`, that means that there is no cast (i.e., that the cast would have been reflexive). The only client of `pushCoArg(s)` is `exprIsConApp_maybe`, which simply omits a cast if `pushCoArgs` returns `Nothing`. Then, we never have to bother creating the reflexive coercions. > > This should be an easy win all around. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14737> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34

[GHC] #13154: Standalone-derived anyclass instances aren't as permissive as empty instances
by GHC 11 Jun '18

11 Jun '18

#13154: Standalone-derived anyclass instances aren't as permissive as empty instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- Note that these are accepted: {{{#!hs class Foo (a :: TYPE ('TupleRep '[])) instance Foo (a :: TYPE ('TupleRep '[])) instance Foo (##) }}} But if you try to write these same instances using `DeriveAnyClass` and `StandaloneDeriving`, they'll be rejected for no good reason: {{{#!hs deriving instance Foo (a :: TYPE ('TupleRep '[])) {- • Can't make a derived instance of ‘Foo a’: The last argument of the instance must be a data or newtype application -} deriving instance Foo (##) {- • Can't make a derived instance of ‘Foo (# #)’: The last argument of the instance cannot be an unboxed tuple -} }}} The latter error is a vestige of #12512, and should be easy enough to rectify. The former error is a bit tricker to fix, since much of the code in `TcDeriv`/`TcDerivInfer` assumes that the type to which the class is applied to in the instead head is a datatype or newtype `TyCon`. It's apparent that this doesn't hold true in the presence of `DeriveAnyClass`, however, so that code should be refactored to reflect this. For practical reasons, however, it might be best to wait until after #12144 is fixed to tackle this one, since that splits out some logic in `TcDerivInfer` for `DeriveAnyClass` so as to make it no longer rely on the aforementioned `TyCon` invariant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13154> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #14945: Compiling error related to rts/Stats.c
by GHC 10 Jun '18

10 Jun '18

#14945: Compiling error related to rts/Stats.c -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.5 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm receiving the following error message when compiling ghcHEAD: {{{ "inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc- Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc- Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc- Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc- Iincludes/dist-derivedconstants/header -optc-Iincludes/dist- ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_p\" -optc-ffunction- sections -optc-fdata-sections -static -prof -eventlog -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/Stats.c -o rts/dist/build/Stats.p_o rts/Stats.c: In function 'report_summary': rts/Stats.c:741:39: error: error: 'RTSSummaryStats {aka const struct RTSSummaryStats_}' has no member named 'rc_cpu_ns'; did you mean 'rp_cpu_ns'? TimeToSecondsDbl(sum->rc_cpu_ns), ^ | 741 | TimeToSecondsDbl(sum->rc_cpu_ns), | ^ rts/Stats.c:29:39: error: note: in definition of macro 'TimeToSecondsDbl' #define TimeToSecondsDbl(t) ((double)(t) / TIME_RESOLUTION) ^ | 29 | #define TimeToSecondsDbl(t) ((double)(t) / TIME_RESOLUTION) | ^ rts/Stats.c:742:39: error: error: 'RTSSummaryStats {aka const struct RTSSummaryStats_}' has no member named 'rc_elapsed_ns'; did you mean 'rp_elapsed_ns'? TimeToSecondsDbl(sum->rc_elapsed_ns)); ^ | 742 | TimeToSecondsDbl(sum->rc_elapsed_ns)); | ^ rts/Stats.c:29:39: error: note: in definition of macro 'TimeToSecondsDbl' #define TimeToSecondsDbl(t) ((double)(t) / TIME_RESOLUTION) ^ | 29 | #define TimeToSecondsDbl(t) ((double)(t) / TIME_RESOLUTION) | ^ rts/Stats.c: In function 'report_machine_readable': rts/Stats.c:904:58: error: error: 'RTSSummaryStats {aka const struct RTSSummaryStats_}' has no member named 'hp_cpu_ns'; did you mean 'rp_cpu_ns'? MR_STAT("hc_cpu_seconds", "f", TimeToSecondsDbl(sum->hp_cpu_ns)); ^ | 904 | MR_STAT("hc_cpu_seconds", "f", TimeToSecondsDbl(sum->hp_cpu_ns)); | ^ rts/Stats.c:867:62: error: note: in definition of macro 'MR_STAT' statsPrintf(" ,(\"" field_name "\", \"%" format "\")\n", value) ^~~~~ | 867 | statsPrintf(" ,(\"" field_name "\", \"%" format "\")\n", value) | ^ rts/Stats.c:904:36: error: note: in expansion of macro 'TimeToSecondsDbl' MR_STAT("hc_cpu_seconds", "f", TimeToSecondsDbl(sum->hp_cpu_ns)); ^~~~~~~~~~~~~~~~ | 904 | MR_STAT("hc_cpu_seconds", "f", TimeToSecondsDbl(sum->hp_cpu_ns)); | ^ rts/Stats.c:905:59: error: error: 'RTSSummaryStats {aka const struct RTSSummaryStats_}' has no member named 'hp_elapsed_ns'; did you mean 'rp_elapsed_ns'? MR_STAT("hc_wall_seconds", "f", TimeToSecondsDbl(sum->hp_elapsed_ns)); ^ | 905 | MR_STAT("hc_wall_seconds", "f", TimeToSecondsDbl(sum->hp_elapsed_ns)); | ^ rts/Stats.c:867:62: error: note: in definition of macro 'MR_STAT' statsPrintf(" ,(\"" field_name "\", \"%" format "\")\n", value) ^~~~~ | 867 | statsPrintf(" ,(\"" field_name "\", \"%" format "\")\n", value) | ^ rts/Stats.c:905:37: error: note: in expansion of macro 'TimeToSecondsDbl' MR_STAT("hc_wall_seconds", "f", TimeToSecondsDbl(sum->hp_elapsed_ns)); ^~~~~~~~~~~~~~~~ | 905 | MR_STAT("hc_wall_seconds", "f", TimeToSecondsDbl(sum->hp_elapsed_ns)); | ^ `cc' failed in phase `C Compiler'. (Exit code: 1) make[1]: *** [rts/ghc.mk:295: rts/dist/build/Stats.p_o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:127: all] Error 2 builder for '/nix/store/qvidsmhk6a1a1h96q85dx1dalgqgph4l- ghc-8.5.20180319.drv' failed with exit code 2 error: build of '/nix/store/qvidsmhk6a1a1h96q85dx1dalgqgph4l- ghc-8.5.20180319.drv' failed }}} I suspect it's related to the recent commit 2d4bda2e4ac68816baba0afab00da6f769ea75a7. Currently compiling the previous revision to confirm. Has anyone confirmed similar error in another environment? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14945> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11798: Recompiling with -fhpc flag added does nothing
by GHC 10 Jun '18

10 Jun '18

#11798: Recompiling with -fhpc flag added does nothing -------------------------------------+------------------------------------- Reporter: drathier | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When you recompile without modifiying any source code, nothing happens, as expected. The file is already compiled, after all. If you then add the -fhpc flag, it still doesn't recompile, even though it now should generate .tix files. These files are now unexpectedly missing, until the source files are modified or the .o and .hi files are deleted, and the code is recompiled again with the -fhpc flag. reproduce: 1. compile program 2. compile program with -fhpc note: missing .tix file 3. delete .hi and .o files 4. compile program with -fhpc 5. success; .tix file is generated -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14815: -XStrict prevents code inlining.
by GHC 10 Jun '18

10 Jun '18

#14815: -XStrict prevents code inlining. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Hi, let's consider the following code: {{{ {-# LANGUAGE Strict #-} -- Comment/uncommenting this {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} module K where import Control.Monad.Trans import qualified Control.Monad.State.Strict as S import Control.Monad.Primitive newtype StateT s m a = StateT (S.StateT s m a) -- S is Control.Monad.State.Strict deriving (Functor, Applicative, Monad, MonadTrans) instance PrimMonad m => PrimMonad (StateT s m) where type PrimState (StateT s m) = PrimState m primitive ~a = lift (primitive a) ; {-# INLINE primitive #-} }}} If compiled with `-XStrict` this code is not inlined properly and it badly affects the performance. While discussing it on Haskell IRC `lyxia` helped very much with discovering the CORE differences. The lazy version has couple of things which the strict version is missing in form of `[InlPrag=INLINE (sat-args=0)]` on toplevel identifiers. Core: https://gist.github.com/Lysxia/34684c9ca9fe4772ea38a5065414f542 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14815> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #14804: hGetLine does not document whether newline is returned.
by GHC 10 Jun '18

10 Jun '18

#14804: hGetLine does not document whether newline is returned. -------------------------------------+------------------------------------- Reporter: akfp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Current documentation on hackage: hGetLine :: Handle -> IO String Computation hGetLine hdl reads a line from the file or channel managed by hdl. This operation may fail with: isEOFError if the end of file is encountered when reading the first character of the line. If hGetLine encounters end-of-file at any other point while reading in a line, it is treated as a line terminator and the (partial) line is returned. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14804> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications
by GHC 08 Jun '18

08 Jun '18

#11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Originally reported [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010915.html here]. When applying types via `-XTypeApplications`, the type/kind that gets instantiated seems to be different depending on whether you're using functions, datatypes, or typeclasses. Here's an example contrasting functions and datatypes: {{{ $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20160106: http://www.haskell.org/ghc/ :? for help λ> :set -fprint-explicit-kinds -XTypeApplications -XTypeInType λ> data Prox a = Prox λ> prox :: Prox a; prox = Prox λ> :t prox prox :: forall k (a :: k). Prox k a λ> :t prox @Int prox @Int :: Prox * Int λ> :t Prox Prox :: forall k (a :: k). Prox k a λ> :t Prox @Int Prox @Int :: Prox Int a }}} This is the core of the problem: with a function, `Int` seems to be applied to type variable `a`, whereas with data types, `Int` appears to be applied to the kind variable `k`. This confuses me, since `k` wasn't specified anywhere in the definition of `Prox`. Andres Löh also [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010916.html observed] a similar discrepancy between functions and typeclasses: {{{ λ> :set -XScopedTypeVariables λ> class C a where c :: () λ> d :: forall a. C a => (); d = c @_ @a λ> :t d d :: forall k (a :: k). C k a => () λ> :t d @Int d @Int :: C * Int => () λ> :t c c :: forall k (a :: k). C k a => () λ> :t c @Int c @Int :: C Int a => () λ> :t c @_ @Int c @_ @Int :: C * Int => () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11376> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37