July 2017 - ghc-tickets

[GHC] #13792: Allow building using distro GCC on Windows
by GHC 22 Jul '17

22 Jul '17

#13792: Allow building using distro GCC on Windows ----------------------------------------+--------------------------------- Reporter: Phyx- | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Allow the building of GHC on Windows using distro compiler (msys2) instead of using a bundled GCC. This should make testing new GCCs and binutils easier but also make it easier to build the msys2 variant of GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13792> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #12913: Port SplitSections to Windows
by GHC 22 Jul '17

22 Jul '17

#12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 #13939 | Differential Rev(s): Phab:D3382 Wiki Page: | Phab:D3383 Phab:D3523 -------------------------------------+------------------------------------- Comment (by bgamari): I have cherry-picked comment:15 into `ghc-8.2` and it will be present in 8.2.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12913#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14002: Defining a function in GHCi results in different strictness behavior than defining it in a file
by GHC 21 Jul '17

21 Jul '17

#14002: Defining a function in GHCi results in different strictness behavior than defining it in a file -------------------------------------+------------------------------------- Reporter: cocreature | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- When defining a strict composition function in GHCi using {{{ let f .:. g = seq f (seq g (\x -> f (g x))) }}} (omitting the let makes no difference) and then executing {{{ seq (undefined .:. undefined) () }}} this evaluates to {{{()}}} instead of bottom as I would have expected. If {{{.:.}}} is defined an a file and then loaded in GHCi the same statement evaluates to bottom. This also holds when {{{.:.}}} is introduced via a let+in instead of a separate let statement. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14002> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13970: Segmentation fault inside threadPaused
by GHC 21 Jul '17

21 Jul '17

#13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1-rc3 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: -------------------------------------+------------------------------------- A multithreaded program generated by latest release candidate occasionally segfaults inside the runtime system. It is always at the same instruction: {{{ (gdb) bt #0 0x00007f25ca77fde3 in threadPaused () from /nix/store/995xifyvjlbvd138r0gpq008nyxls6hr- ghc-8.2.0.20170704/lib/ghc-8.2.0.20170704/rts/libHSrts_thr- ghc8.2.0.20170704.so #1 0x00007f25ca795068 in stg_returnToSched () from /nix/store/995xifyvjlbvd138r0gpq008nyxls6hr- ghc-8.2.0.20170704/lib/ghc-8.2.0.20170704/rts/libHSrts_thr- ghc8.2.0.20170704.so #2 0x0000000000000000 in ?? () (gdb) disassemble Dump of assembler code for function threadPaused: 0x00007f25ca77fda0 <+0>: push %r15 0x00007f25ca77fda2 <+2>: push %r14 0x00007f25ca77fda4 <+4>: push %r13 0x00007f25ca77fda6 <+6>: push %r12 0x00007f25ca77fda8 <+8>: mov %rdi,%r12 0x00007f25ca77fdab <+11>: push %rbp 0x00007f25ca77fdac <+12>: push %rbx 0x00007f25ca77fdad <+13>: mov %rsi,%rbp 0x00007f25ca77fdb0 <+16>: sub $0x28,%rsp 0x00007f25ca77fdb4 <+20>: callq 0x7f25ca77a640 <maybePerformBlockedException> 0x00007f25ca77fdb9 <+25>: cmpw $0x3,0x20(%rbp) 0x00007f25ca77fdbe <+30>: je 0x7f25ca77fe1d <threadPaused+125> 0x00007f25ca77fdc0 <+32>: mov 0x18(%rbp),%rax 0x00007f25ca77fdc4 <+36>: mov 0x8(%rax),%edx 0x00007f25ca77fdc7 <+39>: mov 0x10(%rax),%rbx 0x00007f25ca77fdcb <+43>: lea 0x18(%rax,%rdx,8),%r13 0x00007f25ca77fdd0 <+48>: cmp %rbx,%r13 0x00007f25ca77fdd3 <+51>: jbe 0x7f25ca77fe16 <threadPaused+118> 0x00007f25ca77fdd5 <+53>: xor %r9d,%r9d 0x00007f25ca77fdd8 <+56>: xor %r14d,%r14d 0x00007f25ca77fddb <+59>: xor %r15d,%r15d 0x00007f25ca77fdde <+62>: xor %ecx,%ecx 0x00007f25ca77fde0 <+64>: mov (%rbx),%rdx => 0x00007f25ca77fde3 <+67>: mov -0x8(%rdx),%eax 0x00007f25ca77fde6 <+70>: cmp $0x21,%eax 0x00007f25ca77fde9 <+73>: je 0x7f25ca77ff10 <threadPaused+368> 0x00007f25ca77fdef <+79>: jb 0x7f25ca77fed0 <threadPaused+304> 0x00007f25ca77fdf5 <+85>: lea -0x23(%rax),%esi 0x00007f25ca77fdf8 <+88>: cmp $0x1,%esi 0x00007f25ca77fdfb <+91>: ja 0x7f25ca77fed0 <threadPaused+304> 0x00007f25ca77fe01 <+97>: cmp $0x8,%r15d 0x00007f25ca77fe05 <+101>: setbe %dl 0x00007f25ca77fe08 <+104>: test %ecx,%ecx 0x00007f25ca77fe0a <+106>: setne %al 0x00007f25ca77fe0d <+109>: test %al,%dl 0x00007f25ca77fe0f <+111>: jne 0x7f25ca77fe30 <threadPaused+144> 0x00007f25ca77fe11 <+113>: cmp %r15d,%ecx 0x00007f25ca77fe14 <+116>: ja 0x7f25ca77fe30 <threadPaused+144> 0x00007f25ca77fe16 <+118>: andl $0xffffff7f,0x24(%rbp) 0x00007f25ca77fe1d <+125>: add $0x28,%rsp 0x00007f25ca77fe21 <+129>: pop %rbx 0x00007f25ca77fe22 <+130>: pop %rbp 0x00007f25ca77fe23 <+131>: pop %r12 0x00007f25ca77fe25 <+133>: pop %r13 0x00007f25ca77fe27 <+135>: pop %r14 0x00007f25ca77fe29 <+137>: pop %r15 0x00007f25ca77fe2b <+139>: retq 0x00007f25ca77fe2c <+140>: nopl 0x0(%rax) 0x00007f25ca77fe30 <+144>: lea 0x3e2c9(%rip),%rax # 0x7f25ca7be100 <RtsFlags> 0x00007f25ca77fe37 <+151>: cmpb $0x0,0x4c(%rax) 0x00007f25ca77fe3b <+155>: je 0x7f25ca77fe16 <threadPaused+118> 0x00007f25ca77fe3d <+157>: mov 0x18(%rbp),%rax 0x00007f25ca77fe41 <+161>: mov 0x10(%rax),%r14 0x00007f25ca77fe45 <+165>: cmp %rbx,%r14 0x00007f25ca77fe48 <+168>: lea -0x10(%r14),%r13 0x00007f25ca77fe4c <+172>: ja 0x7f25ca780082 <threadPaused+738> 0x00007f25ca77fe52 <+178>: xor %ecx,%ecx 0x00007f25ca77fe54 <+180>: jmp 0x7f25ca77fe70 <threadPaused+208> 0x00007f25ca77fe56 <+182>: nopw %cs:0x0(%rax,%rax,1) 0x00007f25ca77fe60 <+192>: add $0x1,%ecx 0x00007f25ca77fe63 <+195>: add $0x10,%r14 0x00007f25ca77fe67 <+199>: cmp %rbx,%r14 0x00007f25ca77fe6a <+202>: ja 0x7f25ca780060 <threadPaused+704> 0x00007f25ca77fe70 <+208>: mov (%r14),%rdx 0x00007f25ca77fe73 <+211>: mov -0x8(%rdx),%eax 0x00007f25ca77fe76 <+214>: cmp $0x21,%eax 0x00007f25ca77fe79 <+217>: je 0x7f25ca77fe60 <threadPaused+192> 0x00007f25ca77fe7b <+219>: cmp $0x1,%ecx 0x00007f25ca77fe7e <+222>: jbe 0x7f25ca77fe9b <threadPaused+251> 0x00007f25ca77fe80 <+224>: lea -0x10(%r14),%rdx 0x00007f25ca77fe84 <+228>: mov %r13,%r8 0x00007f25ca77fe87 <+231>: mov %rbp,%rsi 0x00007f25ca77fe8a <+234>: mov %r12,%rdi 0x00007f25ca77fe8d <+237>: callq 0x7f25ca77fce0 <updateAdjacentFrames> 0x00007f25ca77fe92 <+242>: mov (%r14),%rdx 0x00007f25ca77fe95 <+245>: mov %rax,%r13 0x00007f25ca77fe98 <+248>: mov -0x8(%rdx),%eax 0x00007f25ca77fe9b <+251>: cmp $0x1f,%eax 0x00007f25ca77fe9e <+254>: je 0x7f25ca780048 <threadPaused+680> 0x00007f25ca77fea4 <+260>: cmp $0x20,%eax 0x00007f25ca77fea7 <+263>: je 0x7f25ca780038 <threadPaused+664> 0x00007f25ca77fead <+269>: cmp $0x1d,%eax 0x00007f25ca77feb0 <+272>: je 0x7f25ca780020 <threadPaused+640> ... }}} Which I believe is the same place as reported in #9130. Apart from this error, the program also crashes, occasionally, with: {{{ sigym4-propag: internal error: scavenge_stack: weird activation record found on stack: -1717986919 (GHC version 8.2.0.20170704 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} (The activation record number changes between runs). I believe these to be related since I've found (after a long git-bisect session) that they both began manifesting themselves after the same GHC commit: c1c0985416a6f9766c03d361449f556905bf8e1d -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

[GHC] #13803: Panic while forcing the thunk for TyThing IsFile (regression)
by GHC 21 Jul '17

21 Jul '17

#13803: Panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Apologies in advance for the very non-minimal testcase. I have been unsuccessfully trying to reduce the testcase for a few hours now, but I am flying blind, and the bug seems to depend on the interaction of various modules. The panic is very reproducible for me, so I figured that better reporting even if I failed to obtain a simplified testcase. Maybe someone else has more luck isolating the issue.) When compiling `gi-gio-2.0.12` I consistently get the following GHC panic: {{{ [259 of 293] Compiling GI.Gio.Interfaces.File ( GI/Gio/Interfaces/File.hs, dist/build/GI/Gio/Interfaces/File.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-unknown-linux): tcIfaceGlobal (local): not found You are in a maze of twisty little passages, all alike. While forcing the thunk for TyThing IsFile which was lazily initialized by initIfaceCheck typecheckLoop, I tried to tie the knot, but I couldn't find IsFile in the current type environment. If you are developing GHC, please read Note [Tying the knot] and Note [Type-checking inside the knot]. Consider rebuilding GHC with profiling for a better stack trace. Contents of current type environment: [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/iface/TcIface.hs:1689:23 in ghc:TcIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} To compile this code you will need the `glib2-devel` package installed. To compile {{{ $ cabal get gi-gio-2.0.12 $ cd gi-gio-2.0.12 $ cabal sandbox init $ cabal install --dependencies-only $ cabal build }}} I am running version `8.2.0.20170507`, from https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.2.1/ . The same code compiles in versions `7.8.x`, `7.10.x` and `8.0.x`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13803> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #13960: Ticks exhausted with 8.0.2
by GHC 21 Jul '17

21 Jul '17

#13960: Ticks exhausted with 8.0.2 -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- This is unfortunately a closed-source codebase I'm experiencing this with, but we get a GHC panic with a small/not-doing-anything-crazy codebase: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired Class op return To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 118123 }}} When upping to `-fsimpl-tick-factor=150`, the error is a little different: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $ To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 177190 }}} Upping to 200 makes the issue go away. We're building with `ghc-options: -fhpc` Before each build, we remove all .tix files and the .hpc directory At the point this error fires, we're compiling the 6th module of 9. The first 6 modules to compile only have a total of 635 lines of code. To address issues I've seen in other similar tickets: - There are no recursive module imports - We don't use any `{-# INLINE #-}` or similar pragmas - There is no Template Haskell other than a `makeLenses ''App` for a small Snaplet. - We don't have any "very"/exponentially recursive code - We don't use any unboxed tuples (there *is* ST code in a module that's compiled, but not the one ghc panics on) - We don't use type families - We don't use TypeRep or Typeable - We don't use Generic When this error occurs, it fails on a module which has very little code in it. It's mainly a list of ~200-300 Query[0] values, using OverloadedStrings. I notice Query's `mappend`, which we use, is `INLINE`d. Please let me know if I can provide more detail! [0] http://hackage.haskell.org/package/postgresql-simple-0.5.3.0/docs /Database-PostgreSQL-Simple-Types.html#t:Query -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13960> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #13967: Simplifier ticks exhausted (when trying UnfoldingDone) from using lots of ByteString Builder literals
by GHC 21 Jul '17

21 Jul '17

#13967: Simplifier ticks exhausted (when trying UnfoldingDone) from using lots of ByteString Builder literals -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've tried to port Cabal's `Distribution.Simple.Build.PathsModule` from `String`s to `Data.ByteString.Builder`. The module uses lot's of string literals combined via `++`. After enabling `OverloadedStrings` and changing `++` to `Data.Semigroup.<>` I got an error message like in the subject. I have reproduced the issue on self-contained example, attached. ``` $ cd "/tmp/ghc-ticks-exhausted-bug/" && stack build test-0.1.0.0: configure (lib) Configuring test-0.1.0.0... test-0.1.0.0: build (lib) Preprocessing library test-0.1.0.0... [1 of 1] Compiling Test ( Test.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.2.0/build/Test.o ) /tmp/ghc-ticks-exhausted-bug/Test.hs:17:21: warning: [-Wunused-top-binds] Defined but not used: data constructor ‘Linux’ /tmp/ghc-ticks-exhausted-bug/Test.hs:22:29: warning: [-Wunused-top-binds] Defined but not used: data constructor ‘Arm’ <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $ To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 184333 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building package test-0.1.0.0 using: /home/sergey/.stack/setup-exe-cache/x86_64-linux/Cabal- simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.2.0 build lib:test --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 ``` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13967> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13984: Panic when using a TH splice in a do bind pattern
by GHC 21 Jul '17

21 Jul '17

#13984: Panic when using a TH splice in a do bind pattern -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Keywords: panic | Operating System: Unknown/Multiple template-haskell | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling this file with HEAD (f656fba19d0cefe05643ddea35d080ea332a6584): {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Panic where import Language.Haskell.TH expr :: IO Exp expr = runQ $ do name <- newName "foo" [| do $(varP name) <- pure (); pure () |] }}} I get this message: {{{ [1 of 1] Compiling Panic ( Panic.hs, Panic.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170713 for x86_64-unknown-linux): isIrrefutableHsPat: $(varP name) Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/hsSyn/HsPat.hs:643:15 in ghc:HsPat Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It compiles normally with GHC 8.2.1-rc2 (20170507). The bug exists in rc3 (20170704). I am unable to perform a more precise bisect. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13984> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13979: Don't use gtar to produce FreeBSD binary distribution
by GHC 21 Jul '17

21 Jul '17

#13979: Don't use gtar to produce FreeBSD binary distribution -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | 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: #13974 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Mentioned in #13974. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13979> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13977: ExnStr doesn't propagate "outwards"
by GHC 21 Jul '17

21 Jul '17

#13977: ExnStr doesn't propagate "outwards" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- While looking into #8091 (see ticket:8091#comment:9) and #13916, I noticed something that I found rather surprising. Consider this program, {{{#!hs hello :: STR Char -> STM Char hello a = a `orElse` pure 'a' }}} Recall that `catchRetry#` (which `orElse` is defined in terms of) has the following demand signature, {{{ <xC(S),1*C1(U)><L,1*C1(U)><L,U> }}} Note the `x` here: this means it is `ExnStr`, since it doesn't bottom even if the first argument does (despite the fact that it's strict). So, the question is this: What demand should `hello` place on its first argument? I would have thought that it should be precisely the same as the demand that `catchRetry#` places on **its** first argument. However, the demand analyser seems to conclude this: {{{ <C(S),1*C1(U)> }}} Not the lack of an `x`. I believe this may be what causes #13916. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13977> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9