September 2018 - ghc-tickets

Re: [GHC] #1: Implicit parameters cause strange behavi
by GHC 06 Sep '18

06 Sep '18

#1: Implicit parameters cause strange behavi --------------------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.0 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Comment (by Ömer Sinan Ağacan <omeragacan@…>): In [changeset:"c6fbac6a6a69a2f4be89701b2c386ae53214f9a3/ghc" c6fbac6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c6fbac6a6a69a2f4be89701b2c386ae53214f9a3" Fix a race between GC threads in concurrent scavenging While debugging #15285 I realized that free block lists (free_list in BlockAlloc.c) get corrupted when multiple scavenge threads allocate and release blocks concurrently. Here's a picture of one such race: Thread 2 (Thread 32573.32601): #0 check_tail (bd=0x940d40 <stg_TSO_info>) at rts/sm/BlockAlloc.c:860 #1 0x0000000000928ef7 in checkFreeListSanity () at rts/sm/BlockAlloc.c:896 #2 0x0000000000928979 in freeGroup (p=0x7e998ce02880) at rts/sm/BlockAlloc.c:721 #3 0x0000000000928a17 in freeChain (bd=0x7e998ce02880) at rts/sm/BlockAlloc.c:738 #4 0x0000000000926911 in freeChain_sync (bd=0x7e998ce02880) at rts/sm/GCUtils.c:80 #5 0x0000000000934720 in scavenge_capability_mut_lists (cap=0x1acae80) at rts/sm/Scav.c:1665 #6 0x000000000092b411 in gcWorkerThread (cap=0x1acae80) at rts/sm/GC.c:1157 #7 0x000000000090be9a in yieldCapability (pCap=0x7f9994e69e20, task=0x7e9984000b70, gcAllowed=true) at rts/Capability.c:861 #8 0x0000000000906120 in scheduleYield (pcap=0x7f9994e69e50, task=0x7e9984000b70) at rts/Schedule.c:673 #9 0x0000000000905500 in schedule (initialCapability=0x1acae80, task=0x7e9984000b70) at rts/Schedule.c:293 #10 0x0000000000908d4f in scheduleWorker (cap=0x1acae80, task=0x7e9984000b70) at rts/Schedule.c:2554 #11 0x000000000091a30a in workerStart (task=0x7e9984000b70) at rts/Task.c:444 #12 0x00007f99937fa6db in start_thread (arg=0x7f9994e6a700) at pthread_create.c:463 #13 0x000061654d59f88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 32573.32573): #0 checkFreeListSanity () at rts/sm/BlockAlloc.c:887 #1 0x0000000000928979 in freeGroup (p=0x7e998d303540) at rts/sm/BlockAlloc.c:721 #2 0x0000000000926f23 in todo_block_full (size=513, ws=0x1aa8ce0) at rts/sm/GCUtils.c:264 #3 0x00000000009583b9 in alloc_for_copy (size=513, gen_no=0) at rts/sm/Evac.c:80 #4 0x000000000095850d in copy_tag_nolock (p=0x7e998c675f28, info=0x421d98 <Main_Large_con_info>, src=0x7e998d075d80, size=513, gen_no=0, tag=1) at rts/sm/Evac.c:153 #5 0x0000000000959177 in evacuate (p=0x7e998c675f28) at rts/sm/Evac.c:715 #6 0x0000000000932388 in scavenge_small_bitmap (p=0x7e998c675f28, size=1, bitmap=0) at rts/sm/Scav.c:271 #7 0x0000000000934aaf in scavenge_stack (p=0x7e998c675f28, stack_end=0x7e998c676000) at rts/sm/Scav.c:1908 #8 0x0000000000934295 in scavenge_one (p=0x7e998c66e000) at rts/sm/Scav.c:1466 #9 0x0000000000934662 in scavenge_mutable_list (bd=0x7e998d300440, gen=0x1b1d880) at rts/sm/Scav.c:1643 #10 0x0000000000934700 in scavenge_capability_mut_lists (cap=0x1aaa340) at rts/sm/Scav.c:1664 #11 0x00000000009299b6 in GarbageCollect (collect_gen=0, do_heap_census=false, gc_type=2, cap=0x1aaa340, idle_cap=0x1b38aa0) at rts/sm/GC.c:378 #12 0x0000000000907a4a in scheduleDoGC (pcap=0x7ffdec5b5310, task=0x1b36650, force_major=false) at rts/Schedule.c:1798 #13 0x0000000000905de7 in schedule (initialCapability=0x1aaa340, task=0x1b36650) at rts/Schedule.c:546 #14 0x0000000000908bc4 in scheduleWaitThread (tso=0x7e998c0067c8, ret=0x0, pcap=0x7ffdec5b5430) at rts/Schedule.c:2537 #15 0x000000000091b5a0 in rts_evalLazyIO (cap=0x7ffdec5b5430, p=0x9c11f0, ret=0x0) at rts/RtsAPI.c:530 #16 0x000000000091ca56 in hs_main (argc=1, argv=0x7ffdec5b5628, main_closure=0x9c11f0, rts_config=...) at rts/RtsMain.c:72 #17 0x0000000000421ea0 in main () In particular, dbl_link_onto() which is used to add a freed block to a doubly-linked free list is not thread safe and corrupts the list when called concurrently. Note that thread 1 is to blame here as thread 2 is properly taking the spinlock. With this patch we now take the spinlock when freeing a todo block in GC, avoiding this race. Test Plan: - Tried slow validate locally: this patch does not introduce new failures. - circleci: https://circleci.com/gh/ghc/ghc-diffs/283 The test got killed because it took 5 hours but T7919 (which was previously failing on circleci) passed. Reviewers: simonmar, bgamari, erikd Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15285 Differential Revision: https://phabricator.haskell.org/D5115 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2: rewrite rules, forall, no -fglasgow-exts
by GHC 06 Sep '18

06 Sep '18

#2: rewrite rules, forall, no -fglasgow-exts -------------------------------------+---------------------- Reporter: nobody | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: None Resolution: Fixed | Keywords: Type of failure: None/Unknown | -------------------------------------+---------------------- Comment (by Ömer Sinan Ağacan <omeragacan@…>): In [changeset:"c6fbac6a6a69a2f4be89701b2c386ae53214f9a3/ghc" c6fbac6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c6fbac6a6a69a2f4be89701b2c386ae53214f9a3" Fix a race between GC threads in concurrent scavenging While debugging #15285 I realized that free block lists (free_list in BlockAlloc.c) get corrupted when multiple scavenge threads allocate and release blocks concurrently. Here's a picture of one such race: Thread 2 (Thread 32573.32601): #0 check_tail (bd=0x940d40 <stg_TSO_info>) at rts/sm/BlockAlloc.c:860 #1 0x0000000000928ef7 in checkFreeListSanity () at rts/sm/BlockAlloc.c:896 #2 0x0000000000928979 in freeGroup (p=0x7e998ce02880) at rts/sm/BlockAlloc.c:721 #3 0x0000000000928a17 in freeChain (bd=0x7e998ce02880) at rts/sm/BlockAlloc.c:738 #4 0x0000000000926911 in freeChain_sync (bd=0x7e998ce02880) at rts/sm/GCUtils.c:80 #5 0x0000000000934720 in scavenge_capability_mut_lists (cap=0x1acae80) at rts/sm/Scav.c:1665 #6 0x000000000092b411 in gcWorkerThread (cap=0x1acae80) at rts/sm/GC.c:1157 #7 0x000000000090be9a in yieldCapability (pCap=0x7f9994e69e20, task=0x7e9984000b70, gcAllowed=true) at rts/Capability.c:861 #8 0x0000000000906120 in scheduleYield (pcap=0x7f9994e69e50, task=0x7e9984000b70) at rts/Schedule.c:673 #9 0x0000000000905500 in schedule (initialCapability=0x1acae80, task=0x7e9984000b70) at rts/Schedule.c:293 #10 0x0000000000908d4f in scheduleWorker (cap=0x1acae80, task=0x7e9984000b70) at rts/Schedule.c:2554 #11 0x000000000091a30a in workerStart (task=0x7e9984000b70) at rts/Task.c:444 #12 0x00007f99937fa6db in start_thread (arg=0x7f9994e6a700) at pthread_create.c:463 #13 0x000061654d59f88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 32573.32573): #0 checkFreeListSanity () at rts/sm/BlockAlloc.c:887 #1 0x0000000000928979 in freeGroup (p=0x7e998d303540) at rts/sm/BlockAlloc.c:721 #2 0x0000000000926f23 in todo_block_full (size=513, ws=0x1aa8ce0) at rts/sm/GCUtils.c:264 #3 0x00000000009583b9 in alloc_for_copy (size=513, gen_no=0) at rts/sm/Evac.c:80 #4 0x000000000095850d in copy_tag_nolock (p=0x7e998c675f28, info=0x421d98 <Main_Large_con_info>, src=0x7e998d075d80, size=513, gen_no=0, tag=1) at rts/sm/Evac.c:153 #5 0x0000000000959177 in evacuate (p=0x7e998c675f28) at rts/sm/Evac.c:715 #6 0x0000000000932388 in scavenge_small_bitmap (p=0x7e998c675f28, size=1, bitmap=0) at rts/sm/Scav.c:271 #7 0x0000000000934aaf in scavenge_stack (p=0x7e998c675f28, stack_end=0x7e998c676000) at rts/sm/Scav.c:1908 #8 0x0000000000934295 in scavenge_one (p=0x7e998c66e000) at rts/sm/Scav.c:1466 #9 0x0000000000934662 in scavenge_mutable_list (bd=0x7e998d300440, gen=0x1b1d880) at rts/sm/Scav.c:1643 #10 0x0000000000934700 in scavenge_capability_mut_lists (cap=0x1aaa340) at rts/sm/Scav.c:1664 #11 0x00000000009299b6 in GarbageCollect (collect_gen=0, do_heap_census=false, gc_type=2, cap=0x1aaa340, idle_cap=0x1b38aa0) at rts/sm/GC.c:378 #12 0x0000000000907a4a in scheduleDoGC (pcap=0x7ffdec5b5310, task=0x1b36650, force_major=false) at rts/Schedule.c:1798 #13 0x0000000000905de7 in schedule (initialCapability=0x1aaa340, task=0x1b36650) at rts/Schedule.c:546 #14 0x0000000000908bc4 in scheduleWaitThread (tso=0x7e998c0067c8, ret=0x0, pcap=0x7ffdec5b5430) at rts/Schedule.c:2537 #15 0x000000000091b5a0 in rts_evalLazyIO (cap=0x7ffdec5b5430, p=0x9c11f0, ret=0x0) at rts/RtsAPI.c:530 #16 0x000000000091ca56 in hs_main (argc=1, argv=0x7ffdec5b5628, main_closure=0x9c11f0, rts_config=...) at rts/RtsMain.c:72 #17 0x0000000000421ea0 in main () In particular, dbl_link_onto() which is used to add a freed block to a doubly-linked free list is not thread safe and corrupts the list when called concurrently. Note that thread 1 is to blame here as thread 2 is properly taking the spinlock. With this patch we now take the spinlock when freeing a todo block in GC, avoiding this race. Test Plan: - Tried slow validate locally: this patch does not introduce new failures. - circleci: https://circleci.com/gh/ghc/ghc-diffs/283 The test got killed because it took 5 hours but T7919 (which was previously failing on circleci) passed. Reviewers: simonmar, bgamari, erikd Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15285 Differential Revision: https://phabricator.haskell.org/D5115 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15609: No skolem info panic: Static pointers and holes
by GHC 06 Sep '18

06 Sep '18

#15609: No skolem info panic: Static pointers and holes -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- The following program panics: {{{ {-# LANGUAGE StaticPointers #-} {-# LANGUAGE GADTs #-} module Panic where data Closure a where foo :: (Closure a -> Closure b) -> Closure (a -> b) foo f = static _ }}} {{{ src/Panic.hs:8:16: error:ghc: panic! (the 'impossible' happened) (GHC version 8.6.0.20180810 for x86_64-unknown-linux): No skolem info: [a_a5rt[sk:1], b_a5ru[sk:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:2851:5 in ghc:TcErrors Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15609> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[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] #15604: Profiling RTS flag `-po` does not work
by GHC 06 Sep '18

06 Sep '18

#15604: Profiling RTS flag `-po` does not work -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | 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: -------------------------------------+------------------------------------- The RTS flag documentation says this about `-po`: {{{ empty: -p Time/allocation profile in tree format empty: (output file <output prefix>.prof) empty: -po<file> Override profiling output file name prefix (program name by default) }}} However it current doesn't work as advertised in 8.4 and HEAD. When I use `-po<file>` no file is generated. Reproducer: {{{ $ cat empty.hs main = return () $ ghc-stage2 empty.hs -fforce-recomp -rtsopts -prof [1 of 1] Compiling Main ( empty.hs, empty.o ) Linking empty ... $ ./empty +RTS -poprof $ ls | grep prof $ }}} Just `-p` works: {{{ $ ./empty +RTS -p $ ls | grep prof empty.prof $ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15604> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15595: Stack overflow in withArgs leads to infinite memory-consuming loop
by GHC 06 Sep '18

06 Sep '18

#15595: Stack overflow in withArgs leads to infinite memory-consuming loop --------------------------------------+---------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- Given the program: {{{#!hs import System.Environment main :: IO () main = do putStrLn "Starting" withArgs (replicate 1000 "") $ return () }}} When run with: {{{ ghc --make WithArgsBug.hs -rtsopts && WithArgsBug +RTS -K1K }}} The program prints out "Starting", then loops forever, taking 1 CPU core and allocating memory (approx 1Gb per min), until the computer is unresponsive. The program does not respond to Ctrl-C and has to be killed from the task manager. The {{{-K1K}}} flag limits the stack to approx 33Kb. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15595> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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

[GHC] #15576: Hadrian puts its build tree in the wrong place
by GHC 05 Sep '18

05 Sep '18

#15576: Hadrian puts its build tree in the wrong place -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- I have a source tree in my slow, network-mounted backed-up filestore `/home/simonpj/ghc`, and a separate link-tree in my fast, physically- connected, non-backed up filestore `/playpen/ghc`. Every file in `/playpen/ghc` is a symlink to the corresponding source file in `/home/simonpj/ghc`. But when I do {{{ $ cd /playpen/ghc $ hadrian/build.sh -c -j4 --flavour=quick }}} I find a new `_build` director in `/home/simonpj/ghc`. This is bad! It should be in `/playpen/ghc`. Otherwise (a) it's slower, (b) it creates backup churn and (c) as it happens, I ran out of space on the backed-up filestore. Can this be fixed? It's a bad Hadrian shortcoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15576> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12