April 2017 - ghc-tickets

[GHC] #12951: Remove __USE_MINGW_ANSI_STDIO define from PosixSource.h
by GHC 16 Jun '18

16 Jun '18

#12951: Remove __USE_MINGW_ANSI_STDIO define from PosixSource.h -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- This was a stop-gap measure to allow users to build GHC 8.2 with 7.10.1 and 7.10.2. It can be removed for 8.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12951> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13008: Cleanup backwards compatibility ifdefs due to stage1 external interpreter work
by GHC 16 Jun '18

16 Jun '18

#13008: Cleanup backwards compatibility ifdefs due to stage1 external interpreter work -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- https://phabricator.haskell.org/D2826 and https://phabricator.haskell.org/D2884 make some code paths that were incompatible with GHC 7.10.x newly built by the stage0 compiler, requiring some CPP hackery to keep our compatibility guarantees. When we can drop that dependency, we should be sure to remove the old code paths. Specifically, the checks for MIN_VERSION_base(4,9,0) and MIN_VERSION_process(1,4,2) can be removed once we're able to assume ghc 8.0.x as stage0. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13008> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12999: Investigate use of floating-point arithmetic in I/O Event-handler
by GHC 16 Jun '18

16 Jun '18

#12999: Investigate use of floating-point arithmetic in I/O Event-handler -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: | Version: 8.0.1 libraries/base | 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 was asked/made aware of some questionable use of floating-point arithmetic in `GHC.Event.TimerManager`; Specifically, I can't explain why `getMonotonicTime` first gets a timestamp as `Word64`, only to perform a not-necessarily cheap floating- point division, and returns a `Double`... {{{#!hs -- | Return monotonic time in seconds, since some unspecified starting point getMonotonicTime :: IO Double getMonotonicTime = do w <- getMonotonicNSec return (fromIntegral w / 1000000000) foreign import ccall unsafe "getMonotonicNSec" getMonotonicNSec :: IO Word64 }}} which then gets used e.g. by {{{#!hs updateTimeout :: TimerManager -> TimeoutKey -> Int -> IO () updateTimeout mgr (TK key) us = do now <- getMonotonicTime let expTime = fromIntegral us / 1000000.0 + now editTimeouts mgr (Q.adjust (const expTime) key) wakeManager mgr }}} Whereas, the priority queue (`GHC.Event.PSQ`) then uses `Double`s for its priorities... For correctness and performance reasons, I'd expect the use of fixed-width integers (i.e. `Word64` or `Int64`) for such codepaths... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12999> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11259: Use system runtime linker in GHCi on PowerPC 64 bit
by GHC 14 Jun '18

14 Jun '18

#11259: Use system runtime linker in GHCi on PowerPC 64 bit -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.11 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: GHCi crash Test Case: ghcilink004, | Blocked By: prog001, and 11 more | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Teach GHCi to use the system runtime linker to load Haskell libraries on powerpc64. See the following test failures. ghcilink004: {{{ ghc-stage2: dir004/libfoo.a: unknown architecture (e_machine == 21) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151219 for powerpc64-unknown-linux): loadArchive "dir004/libfoo.a": failed CallStack (from ImplicitParams): error, called at libraries/ghci/GHCi/ObjLink.hs:91:21 in ghci-0.0:GHCi.ObjLink Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} prog001: {{{ ghc-iserv.bin: /home/peter/ghc/libraries/ghc-prim/dist-install/build /libHSghc-prim-0.5.0.0.a: unknown architecture (e_machine == 21) ghc-iserv.bin: loadArchive "/home/peter/ghc/libraries/ghc-prim/dist- install/build/libHSghc-prim-0.5.0.0.a": failed CallStack (from ImplicitParams): error, called at libraries/ghci/GHCi/ObjLink.hs:91:21 in ghci-0.0:GHCi.ObjLink ghc-stage2: ghc-iserv terminated (1) }}} Using the system runtime linker fixes 13 failing tests. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11259> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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] #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] #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] #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