July 2018 - ghc-tickets

[GHC] #10827: GHCi should support interpeting multiple packages/units with separate DynFlags
by GHC 07 Sep '18

07 Sep '18

#10827: GHCi should support interpeting multiple packages/units with separate DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHC API | Version: 7.11 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Stack and other tools are attempting to make the user-experience of developing multiple packages simultaneously better. Thus, if you have source packages p, q and r (which all depend on them), `stack build` builds all of them. They are quite interested in support `stack ghci` but there are problems: https://github.com/commercialhaskell/stack/issues/665 The essence of the problem is twofold: 1. If you ask GHCi to interpret modules from multiple packages (e.g. by having multiple source directories), GHCi currently only knows how to put all of them into the same home package. This will fail if two packages have a module with the same name; also, modules in the other packages will always see modules (even if they're supposed to be hidden). 2. A GHCi session only has one global set of dynamic flags, but each package may be compiled with its own set of DynFlags (e.g. package global LANGUAGE pragmas). This means the "default DynFlags" needs to be varied between packages. It's not too obvious to me how to fix (1) (at least, you'd have to make the HPT support sets of HomeModInfos from multiple packages), but (2) seems tractable: since we already track DynFlags on a per-module basis, we just have to arrange for a "package" level DynFlag to be applied to the correct ModSummarys. Similar functionality would be useful for Backpack. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10827> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12356: StaticPointers support in GHCi
by GHC 07 Sep '18

07 Sep '18

#12356: StaticPointers support in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.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: #12000 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently GHCi does not support `-XStaticPointers`, which is quite annoying for those of us who actually use `-XStaticPointers` in day-to-day development. It would be great if GHCi could grow support for this extension. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12356> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #14743: `UnsafeReenter` test hangs
by GHC 07 Sep '18

07 Sep '18

#14743: `UnsafeReenter` test hangs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- After a `./validate --slow` run `UnsafeReenter` process hangs forever, using CPU as well. Not sure if this happens in fast or normal validate yet, or which way do I need to reproduce. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14743> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9622: GHCi command to solve a constraint
by GHC 06 Sep '18

06 Sep '18

#9622: GHCi command to solve a constraint -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It would be nice to have a `:solve` command for ghci that took a class constraint and returned either its derivation or an error message. A possible interface could look like so: {{{ ghci> :solve Eq (Maybe Type1, Bool) 1) instance Eq Type1 -- Defined in ‘MyModule’ 2) instance Eq a => Eq (Maybe a) -- Defined in ‘GHC.Classes’ 3) instance Eq (Maybe Type1) -- Put a ~ Int in 2) and use 1) 4) instance Eq Bool -- Defined in ‘GHC.Classes’ 5) instance (Eq a, Eq b) => Eq (a,b) -- Defined in ‘GHC.Classes’ 6) instance Eq (Maybe Type1, Bool) -- Put a ~ Maybe Type1, b ~ Bool in 5) and use 3), 4) ghci> :solve Eq (Int -> Int) No instance for Eq (Int -> Int) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9622> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15427: Calling hs_try_putmvar from an unsafe foreign call can cause the RTS to hang
by GHC 06 Sep '18

06 Sep '18

#15427: Calling hs_try_putmvar from an unsafe foreign call can cause the RTS to hang -------------------------------------+------------------------------------- Reporter: syntheorem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.4.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- An unsafe foreign call which calls `hs_try_putmvar` can cause the RTS to hang, preventing any Haskell threads from making progress. However, compiling with `-debug` causes it instead to fail an assertion in the scheduler: {{{ internal error: ASSERTION FAILED: file rts/Schedule.c, line 510 (GHC version 8.4.3 for x86_64_apple_darwin) }}} Here is a minimal test case which reproduces the assertion. It needs to be built with `-debug -threaded` and run with `+RTS -N2` or higher. {{{#!hs import Control.Concurrent (forkIO, threadDelay) import Control.Concurrent.MVar (MVar, newEmptyMVar, takeMVar) import Control.Monad (forever) import Foreign.C.Types (CInt(..)) import Foreign.StablePtr (StablePtr) import GHC.Conc (PrimMVar, newStablePtrPrimMVar) foreign import ccall unsafe hs_try_putmvar :: CInt -> StablePtr PrimMVar -> IO () main = do mvar <- newEmptyMVar forkIO $ forever $ do takeMVar mvar forkIO $ forever $ do sp <- newStablePtrPrimMVar mvar hs_try_putmvar (-1) sp threadDelay 1 -- Let it spin a few times to trigger the bug threadDelay 500 }}} I actually checked out GHC and added this as a test case and did some debugging. The specific assertion that fails is `ASSERT(task->cap == cap)`. This seems to happen because of this code in `hs_try_putmvar`: {{{#!c Task *task = getTask(); // ... ACQUIRE_LOCK(&cap->lock); // If the capability is free, we can perform the tryPutMVar immediately if (cap->running_task == NULL) { cap->running_task = task; task->cap = cap; RELEASE_LOCK(&cap->lock); // ... releaseCapability(cap); } else { // ... } }}} Basically it assumes that the current thread's task isn't currently running a capability, so it takes a new one and then releases it without restoring the previous value of `task->cap`. Modifying the code to restore the value of `task->cap` after releasing the capability fixes the assertion. But I don't know enough about the RTS to be sure I'm not missing something here. In particular, is there a problem with the task basically holding two capabilities for a short time? My other thought is that maybe it should check if its task is currently running a capability, and in that case do something else. But I'm not sure what. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13499: "Panic: no skolem info" with StaticPointers and typed hole
by GHC 06 Sep '18

06 Sep '18

#13499: "Panic: no skolem info" with StaticPointers and typed hole -------------------------------------+------------------------------------- Reporter: Otini | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux StaticPointers, hole, skolem, | panic | Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling this minimal example: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE StaticPointers #-} import Data.Typeable (Typeable) import GHC.StaticPtr (StaticPtr) f :: Typeable a => StaticPtr (a -> a) f = static (\a -> _) main :: IO () main = return () }}} I get this output: {{{ Bug.hs:8:19: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): No skolem info: a_aJo[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Unlike similar reported bugs, this happens on both 8.0.1 and 8.0.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13499> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15345: Duplication between `CoreSubst` and `SimplEnv` is very unfortunate
by GHC 06 Sep '18

06 Sep '18

#15345: Duplication between `CoreSubst` and `SimplEnv` is very unfortunate -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- There are lots of very similar functions in `SimplEnv` and `CoreSubst`. For example, in `SimpleEnv` there is a function `substIdType` and likewise in `CoreSubst` but they are different to each other. There is also a `substIdBndr` function in both modules but the one in `SimplEnv` calls `SimpleEnv.substIdType`, the one in `CoreSubst` doesn't call `CoreSubst.substIdType` but has its own inlined version. This means there's at least three different versions of `substIdType` floating around. The correctness of this function is crucial so it would be better not to duplicate it. Can we remove this duplication? Help me Simon! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15345> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15384: Every implication should bump the TcLevel exactly once
by GHC 06 Sep '18

06 Sep '18

#15384: Every implication should bump the TcLevel exactly once -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- Simon recently added an assertion that every implication bumps the TcLevel exactly once. However, this turns out not to be true, and thus caused quite a few failures in a `DEBUG` compiler. I commented the check out, but we really should investigate and fix any deviations from this plan. Here is the suspect code in TcSimplify: {{{ -- Though sensible, this check causes lots of testsuite failures. It is -- remaining commented out for now. {- check_tc_level = do { cur_lvl <- TcS.getTcLevel ; MASSERT2( tclvl == pushTcLevel cur_lvl , text "Cur lvl =" <+> ppr cur_lvl $$ text "Imp lvl =" <+> ppr tclvl ) } -} }}} The goal is to uncomment this region without introducing failures. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15384> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14915: T2783 fails with the threaded1 way
by GHC 06 Sep '18

06 Sep '18

#14915: T2783 fails with the threaded1 way --------------------------------------+---------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: T2783 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- When running `./validate --slow` the other day, I saw the XXX test failing with the `threaded1` way. Instead of detecting the loop and aborting with an informative message, we get an assertion failure in the `rts/ThreadPaused.c:threadPaused` function. The program: {{{#!hs main = print $ do x <- [ 0 .. 5 ] ; let { y = 5 - y } ; return y }}} The output: {{{ =====> T2783(threaded1) 1 of 1 [0, 0, 0] cd "./rts/T2783.run" && "/home/alp/ghc/inplace/test spaces/ghc-stage2" -o T2783 T2783.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug cd "./rts/T2783.run" && ./T2783 Wrong exit code for T2783(threaded1)(expected 1 , actual 134 ) Stderr ( T2783 ): T2783: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 (GHC version 8.5.20180306 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) *** unexpected failure for T2783(threaded1) }}} The code for the corresponding assertion: {{{#!c // We should never have made it here in the event of blackholes that // we already own; they should have been marked when we blackholed // them and consequently we should have stopped our stack walk // above. ASSERT(!((bh_info == &stg_BLACKHOLE_info) && (((StgInd*)bh)->indirectee == (StgClosure*)tso))); }}} This seems to be an actual problem, hence this ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14915> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15445: SPCIALIZE one of two identical functions does not fire well
by GHC 05 Sep '18

05 Sep '18

#15445: SPCIALIZE one of two identical functions does not fire well --------------------------------------+--------------------------------- Reporter: nobrakal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Hi, I am playing with `SPECIALIZE` pragma: {{{#!hs module Todo where {-# SPECIALIZE plusTwoRec :: [Int] -> [Int] #-} plusTwoRec :: Num a => [a] -> [a] plusTwoRec [] = [] plusTwoRec (x:xs) = x+2:plusTwoRec xs plusTwoRec' :: Num a => [a] -> [a] plusTwoRec' [] = [] plusTwoRec' (x:xs) = x+2:plusTwoRec' xs }}} And wanted to benchmark it with (in `Main.hs`): {{{#!hs import Todo import Criterion.Main aListOfInt :: [Int] aListOfInt = [1..10000] main :: IO () main = defaultMain [ bench "plusTwoRec" $ nf plusTwoRec aListOfInt , bench "plusTwoRec'" $ nf plusTwoRec' aListOfInt ] }}} Sadly, the rule of specialization of `plusTwoRec` does not fire in Main.hs (I compiled with: `ghc Main.hs -O -dynamic -ddump-rule-firings` (the `-dynamic` part is due to my ArchLinux installaltion)). The result is: {{{ [1 of 2] Compiling Todo ( Todo.hs, Todo.o ) Rule fired: Class op + (BUILTIN) Rule fired: Class op fromInteger (BUILTIN) Rule fired: integerToInt (BUILTIN) Rule fired: SPEC plusTwoRec (Todo) [2 of 2] Compiling Main ( Main.hs, Main.o ) Rule fired: Class op enumFromTo (BUILTIN) Rule fired: unpack (GHC.Base) Rule fired: unpack (GHC.Base) Rule fired: eftIntList (GHC.Enum) Rule fired: unpack-list (GHC.Base) Rule fired: unpack-list (GHC.Base) Linking Main ... }}} I have inspected a bit the code produced after the simplifications passes (with `-ddump-simpl`) and here is the suspicious part: {{{ plusTwoRec :: forall a. Num a => [a] -> [a] [GblId, Arity=2, Caf=NoCafRefs, Str=<L,U(C(C1(U)),A,A,A,A,A,C(U))><S,1*U>, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] plusTwoRec = plusTwoRec' }}} I believe that `plusTwoRec` is inlined before the specialization has a chance to fire, but I am not sure at all ! Separating the two functions definitions in two different files works. So I don't know if this is a GHC bug, myself that does not read the right part of the GHC manual, if it is only a lack of documentation, or anything else. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15445> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8