- ghc-tickets - Haskell.org

[GHC] #15091: Better occurrence analysis for join points
by GHC 10 Feb '19

10 Feb '19

#15091: Better occurrence analysis for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: JoinPoints | 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 this {{{ let x = ... in join j y = x+y in case v of A -> x B -> j 1 C -> j 2 D -> 3 }}} What does `OccAnal` say about `x`'s usage? It says `ManyOccs`! But it's plain as a pikestaff that `x` is used at most once: * Either in the `A` branch, * or in the `B` or `C` branches via `j`. If instead we had inlined `j` we'd have {{{ let x = ... in join j y = x+y in case v of A -> x B -> x + 1 C -> x + 2 D -> 3 }}} and now it's all more obvious: `x`'s occurrence info should be `OneOcc { occ_one_br = False }`, not `ManyOccs`. Does this matter? Not a great deal, but there is a reason for having `OneOcc` with `occ_one_br = False`, and it seems a shame not to take advantage. One case in point is the definition of `SimplUtils.isExitJoinId {{{ isExitJoinId :: Var -> Bool isExitJoinId id = isJoinId id && isOneOcc (idOccInfo id) && occ_in_lam (idOccInfo id) }}} Something does not cease to be an exit-join-point if it is mentioned in multiple places as above. Another use for this info is `postInlineUnconditionally`. Could we improve this situation? I think it'd be quite easy. For non- recursive join points `j = rhs` * Gather occurrence info from the RHS * Bind `j` to its occurrence info * Unleash that occurrence info at each jump-site for `j`, just as if it had been inlined. See Trac #14152, comment:40. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15091> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16301: Additions to Control.Exception: withException, displaySomeExceptionType
by GHC 10 Feb '19

10 Feb '19

#16301: Additions to Control.Exception: withException, displaySomeExceptionType -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.6.3 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: -------------------------------------+------------------------------------- Requires RankNTypes though. {{{#!haskell -- | Apply a function to whatever @Exception@ type is inside a -- @SomeException@. withException :: forall r. (forall e. Exception e => e -> r) -> SomeException -> r withException f (SomeException e) = f e -- | Use 'withException' to obtain the exception's type name. displaySomeExceptionType :: SomeException -> String displaySomeExceptionType = withException (show . typeOf) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16301> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16298: Awful(?) code in AArch64 stg_BLACKHOLE entry code
by GHC 09 Feb '19

09 Feb '19

#16298: Awful(?) code in AArch64 stg_BLACKHOLE entry code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: Runtime | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It's been a while since I've look at ARM assembler but this doesn't look right: {{{ Dump of assembler code for function stg_BLACKHOLE_info$def: 0x0000ffffb66d6118 <+0>: mov x23, x22 0x0000ffffb66d611c <+4>: ldr x22, [x22, #8] 0x0000ffffb66d6120 <+8>: tst x22, #0x7 0x0000ffffb66d6124 <+12>: b.ne 0xffffb66d6224 <stg_BLACKHOLE_info$def+268> // b.any 0x0000ffffb66d6128 <+16>: adrp x25, 0xffffb66fb000 0x0000ffffb66d612c <+20>: adrp x26, 0xffffb66fb000 0x0000ffffb66d6130 <+24>: adrp x27, 0xffffb66fb000 0x0000ffffb66d6134 <+28>: adrp x29, 0xffffb66fb000 0x0000ffffb66d6138 <+32>: ldr x25, [x25, #3880] 0x0000ffffb66d613c <+36>: ldr x26, [x26, #3888] 0x0000ffffb66d6140 <+40>: ldr x27, [x27, #3896] 0x0000ffffb66d6144 <+44>: ldr x29, [x29, #3904] 0x0000ffffb66d6148 <+48>: sub x24, x19, #0x18 0x0000ffffb66d614c <+52>: ldr x8, [x22] 0x0000ffffb66d6150 <+56>: cmp x8, x25 ... }}} Why do we `adrp` four times? Couldn't this be reused, with each `ldr` result going to a separate register? This was generated by LLVM 7. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1
by GHC 09 Feb '19

09 Feb '19

#15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: aarch64 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC releases 8.2.1 through 8.4.3 exhibit various crashes when invoked with '-jn' where n > 1. GHCHQ's binary releases have this behavior, as well as GHCs I've cross-built on my own. In order to reproduce this issue there must be some parallelism in the module dependency graph; I've attached a test package for easily reproducing this. Use of deriving in the test modules isn't necessary to trigger this; it merely gives the compiler some work to do. The 'hscolour' package also triggers this issue reliably. To trigger the bad behavior, simply run: ghc --make -jn Main.hs -o test with n > 1 in the test-package. Running this repeatedly (removing .hi and .o files in between runs, of course), I've observed these outcomes with varying frequencies: - Segmentation fault. - Bus fault. - Compiler process sleeps indefinitely. - {{{ <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for aarch64-unknown-linux): Binary.UserData: no put_binding_name }}} - {{{ ghc: internal error: MUT_VAR_CLEAN object entered! (GHC version 8.4.3 for aarch64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} - And most strangely: {{{ A.hs:3:1: error: • Kind signature on data type declaration has non-* return kind * • In the data declaration for ‘A’ | 3 | data A = A | ^^^^^^^^^^... }}} I have not noticed issues with any other concurrent Haskell programs on aarch64. I'm using the NVIDIA Jetson TX2 for these tests. I have not yet tried GHC 8.0.x, 8.6.x, or HEAD. I'm having trouble reproducing this in GDB; I'll report back when I've got that working. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15449> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #12658: GHC 7.10.3 sometimes reports unimplemented/strange closure type 63270
by GHC 09 Feb '19

09 Feb '19

#12658: GHC 7.10.3 sometimes reports unimplemented/strange closure type 63270 --------------------------------+--------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------------- This happened when building http-link-header. {{{ ghc: internal error: scavenge: unimplemented/strange closure type 63270 @ 0xf36de0a8ghc: internal error: scavenge: unimplemented/strange closure type 63270 @ 0xf36de0a8 (GHC version 7.10.3 for powerpc_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Sometimes it segfaults instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12658> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16150: Data races in itimer_thread_func reported by ThreadSanitizer
by GHC 09 Feb '19

09 Feb '19

#16150: Data races in itimer_thread_func reported by ThreadSanitizer -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.4.4 System | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Our local environment allows running Haskell programs under ThreadSanitizer. Even though the GHC runtime and compiled Haskell code are not instrumented, ThreadSanitizer still found a bug through interceptor instrumentation. I'll try to minimize the case and create a reproducer, but in case somebody wants to look at this with just the report, here it is (mildly massaged to remove irrelevant addresses): {{{ ================== WARNING: ThreadSanitizer: data race (pid=2367) Write of size 1 at 0x55986a3e4f10 by thread T1: #0 pthread_mutex_destroy llvm/compiler- rt/lib/tsan/rtl/tsan_interceptors.cc:1245:3 #1 itimer_thread_func vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:152:5 Previous atomic read of size 1 at 0x55986a3e4f10 by main thread: #0 pthread_mutex_lock llvm/compiler- rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:4097:3 #1 startTicker vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:184:5 #2 exitTicker vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:206 #3 __libc_start_main <null> (libc.so.6+0x38bbc) Location is global 'mutex' of size 40 at 0x55986a3e4f10 Thread T1 'ghc_ticker' (tid=2369, running) created by main thread at: #0 pthread_create llvm/compiler- rt/lib/tsan/rtl/tsan_interceptors.cc:980:3 #1 initTicker vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:171:11 #2 __libc_start_main <null> (libc.so.6+0x38bbc) SUMMARY: ThreadSanitizer: data race vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:152:5 in itimer_thread_func ================== ================== WARNING: ThreadSanitizer: data race (pid=2367) Write of size 8 at 0x55986a3e4ee0 by thread T1: #0 pthread_cond_destroy llvm/compiler- rt/lib/tsan/rtl/tsan_interceptors.cc:1216:3 #1 itimer_thread_func vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:153:5 Previous read of size 8 at 0x55986a3e4ee0 by main thread (mutexes: write M146179626018688784): #0 pthread_cond_signal llvm/compiler- rt/lib/tsan/rtl/tsan_interceptors.cc:1202:3 #1 signalCondition vendor_src/v8_4_4/rts/posix/OSThreads.c:111:11 #2 __libc_start_main <null> (libc.so.6+0x38bbc) Location is global 'start_cond' of size 48 at 0x55986a3e4ee0 Mutex M146179626018688784 is already destroyed. Thread T1 'ghc_ticker' (tid=2369, running) created by main thread at: #0 pthread_create llvm/compiler- rt/lib/tsan/rtl/tsan_interceptors.cc:980:3 #1 initTicker vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:171:11 #2 __libc_start_main <null> (libc.so.6+0x38bbc) SUMMARY: ThreadSanitizer: data race vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:153:5 in itimer_thread_func ================== ThreadSanitizer: reported 2 warnings }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16150> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64]
by GHC 09 Feb '19

09 Feb '19

#16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- On current HEAD ghc fails build on powerpc32: {{{ $ ./configure --target=powerpc-unknown-linux-gnu $ make ... "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=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/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181223 for powerpc-unknown-linux): getRegister(ppc) I64[I32[BaseReg + 812] + 64] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable pprPanic, called at compiler/nativeGen/PPC/CodeGen.hs:693:24 in ghc:PPC.CodeGen }}} {{{ $ inplace/bin/ghc-stage1 --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","powerpc-unknown-linux-gnu-gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags"," -fuse-ld=gold") ,("C compiler supports -no-pie","YES") ,("Haskell CPP command","powerpc-unknown-linux-gnu-gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","powerpc-unknown-linux-gnu-ld.gold") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","powerpc-unknown-linux-gnu-ar") ,("ar flags","q") ,("ar supports at file","YES") ,("ranlib command","powerpc-unknown-linux-gnu-ranlib") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","YES") ,("target os","OSLinux") ,("target arch","ArchPPC") ,("target word size","4") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("target has RTS linker","YES") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("LLVM clang command","clang") ,("Project version","8.7.20181223") ,("Project Git commit id","bd8a6bde2ee73e599800137b9428a401bc105985") ,("Booter version","8.4.4") ,("Stage","1") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","powerpc-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn thr_debug_p debug_p") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Support Backpack","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Uses unit IDs","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","NO") ,("GHC Profiled","NO") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/home/slyfox/dev/git/ghc-ppc/inplace/lib") ,("Global Package DB","/home/slyfox/dev/git/ghc- ppc/inplace/lib/package.conf.d") ] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16094> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15336: ./System/IO.hs accidentally overridden when running ghci
by GHC 08 Feb '19

08 Feb '19

#15336: ./System/IO.hs accidentally overridden when running ghci -------------------------------------+------------------------------------- Reporter: luqui | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running ghci fails if there is a System/IO.hs module present in the current directory. Doesn't seem like desirable behavior. {{{ % mkdir System % touch System/IO.hs % ghci GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help <interactive>:1:19: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:43: error: Not in scope: ‘System.IO.stdin’ No module named ‘System.IO’ is imported. <interactive>:1:60: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:99: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:123: error: Not in scope: ‘System.IO.stdout’ No module named ‘System.IO’ is imported. <interactive>:1:140: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:179: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:203: error: Not in scope: ‘System.IO.stderr’ No module named ‘System.IO’ is imported. <interactive>:1:220: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15336> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9370: large blowup in memory usage and time when doing parallel build of xmlhtml package
by GHC 08 Feb '19

08 Feb '19

#9370: large blowup in memory usage and time when doing parallel build of xmlhtml package -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've observed a blowup in ghc memory usage when invoked with parallel build flags. to reproduce {{{ cabal get xmlhtml-0.2.3.2 cabal install xmlhtml-0.2.3.2 --only-dependencies cd xmlhtml-0.2.3.2 }}} then {{{ cabal clean ; cabal configure --ghc-options="-j4" ; time cabal build -j4 -v3 }}} will take quite a while and use > 1gb of ram whereas {{{ cabal clean ; cabal configure --ghc-options="-j1 ; time cabal build -j1 -v3 }}} will use < 150mb of ram. Based upon the output of cabal build -j4 -v3, it looks like the parallel build is spending a lottt more time in the simplifier passes. I'm not sure what changes between the parallel and sequential builds to change this. I'll try to dig into this more in a few days, but recording this problem now before i forget. (though of course any insights would be appreciated) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9370> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #8635: GHC optimisation flag ignored when importing a local module with derived type classes
by GHC 08 Feb '19

08 Feb '19

#8635: GHC optimisation flag ignored when importing a local module with derived type classes ------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Given Foo.hs and Bar.hs: {{{ module Foo where data Food = Food -- deriving Eq {-# OPTIONS_GHC -O2 -ddump-simpl #-} module Bar where import Foo bar :: Int -> Bool bar x = x == 72 }}} If I run: {{{ ghc --make Bar -fforce-recomp }}} I get (snipped): {{{ Bar.bar = \ (x_afk :: GHC.Types.Int) -> case x_afk of _ { GHC.Types.I# x1_alo -> case x1_alo of _ { __DEFAULT -> GHC.Types.False; 72 -> GHC.Types.True } } }}} `bar` now looks pretty well optimised. However, if I uncomment the `deriving Eq` I get: {{{ Bar.bar1 = GHC.Types.I# 72 Bar.bar2 = GHC.Classes.== @ GHC.Types.Int GHC.Classes.$fEqInt Bar.bar = \ (x_amD :: GHC.Types.Int) -> Bar.bar2 x_amD Bar.bar1 }}} Now `bar` looks like terrible code, using dictionaries, boxing etc. It seems adding `deriving` in the imported and unused module makes it ignore the optimisation level. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8635> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6