January 2016 - ghc-tickets

[GHC] #10510: Testsuite driver does not run tests in parallel on Windows
by GHC 30 Nov '16

30 Nov '16

#10510: Testsuite driver does not run tests in parallel on Windows -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Test Suite | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `testsuite/driver/runtests.py` contains the following 3 lines: {{{ if windows: print("Warning: Ignoring request to use threads as running on Windows") config.use_threads = 0 }}} They were introduced in commit e9b3d6cc65c0b69bd4a50bfa7bc7e1d3536446a8: {{{ Author: Ian Lynagh <> Date: Wed Oct 28 17:54:21 2009 +0000 Don't use threads on Windows It seems to cause some sort of deadlock }}} I tried removing them (Windows 64 bit, using msys2), but then running validate doesn't get any further than: {{{ ... =====> Overlap3(normal) 1605 of 4525 [2, 7, 0] =====> Overlap4(normal) 1606 of 4525 [2, 7, 0] =====> Overlap5(normal) 1607 of 4525 [2, 7, 0] =====> Overlap6(normal) 1608 of 4525 [2, 7, 0] =====> Overlap7(normal) 1609 of 4525 [2, 7, 0] =====> Overlap9(normal) 1610 of 4525 [2, 7, 0] }}} It would be great if we could run the testsuite in parallel again, since running validate takes forever currently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10510> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults
by GHC 30 Nov '16

30 Nov '16

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------+---------------------------------- {{{ -- test.hs import System.Mem (performMajorGC) main = performMajorGC >> putStrLn "Done" }}} built with `ghc -pgmlo opt -pgmlc llc -fllvm --make test.hs` segfaults both for LLVM 3.4 and 3.5svn (taken from http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64) 32-bit ghc-7.9.20140404+llvm produces good executable. Adding `ArchX86_64` `OSMinGW32` case to `moduleLayout` in `compiler/llvmGen/LlvmCodeGen/Ppr.hs` improves things slightly (some code segfaulting without it starts to work) but still does not cure the code above. Also I've found the Cmm produced for LLVM CG differs from that produced for NCG. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8974> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 52

[GHC] #11219: Implement fine-grained `-Werror=...` facility
by GHC 30 Nov '16

30 Nov '16

#11219: Implement fine-grained `-Werror=...` facility -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 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: Design/Warnings -------------------------------------+------------------------------------- ...copied from Design/Warnings: Introduce variant of `-Werror` (c.f. GCC's `-Werror=*`) which allows to specify the individual warnings to be promoted to errors, e.g. - `-Wall -Werror=orphans` would only promote `-Worphans` warnings into errors - `-Wall -Werror -Wno-error=missing-methods` would promote all warnings //except// `-Wmissing-methods` into errors TODO: specify semantics a bit more exactly (the basic idea is to follow gcc/clang as much as sensible, and only deviate where it's necessary) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11219> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9007: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object
by GHC 29 Nov '16

29 Nov '16

#9007: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object ----------------------------------+---------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- Building HEAD on Debian wheezy with the Debian packaging setup fails: {{{ configure: Building in-tree ghc-pwd /usr/bin/ld: utils/ghc-pwd/dist-boot/Main.o: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object; recompile with -fPIC utils/ghc-pwd/dist-boot/Main.o: could not read symbols: Bad value collect2: error: ld returned 1 exit status configure: error: Building ghc-pwd failed }}} http://deb.haskell.org/dailies/2014-04-16/ghc_7.9.20140416-0.daily_amd64.bu… This is possibly related to the Hardening flags added by Debian: {{{ ~ $ dpkg-buildflags --get LDFLAGS -Wl,-z,relro ~ $ dpkg-buildflags --get CFLAGS -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror =format-security }}} Other related bug might be #3668 and https://bugs.debian.org/712228 I’ll disable the hardening flags and see if it helps. The error first occurred 2014-03-27. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9007> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial
by GHC 26 Nov '16

26 Nov '16

#11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Look at `CoreUtils.exprIsTrivial` and `CorePrep.cpe_ExprIsTrivial`. They are identical! The latter has a comment saying {{{ cpe_ExprIsTrivial :: CoreExpr -> Bool -- Version that doesn't consider an scc annotation to be trivial. }}} but the code does not treat ticks any differently. So the question is: '''are they supposed to be different'''? And if not, can we just combine them? Peter W, Simon M: this is your territory. I don't understand tick stuff well enough. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11158> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #8300: split-objs doesn't split on LLVM
by GHC 23 Nov '16

23 Nov '16

#8300: split-objs doesn't split on LLVM ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- `-split-objs` is allowed with `-fllvm`, but it doesn't really do anything. E.g. in my perf-llvm build I have a `libHSbase-4.7.0.0.a` with `Applicative__1.o`, `Arrow__1.o` etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8300> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8321: improve basic block layout on LLVM backend by predicting stack/heap checks
by GHC 18 Nov '16

18 Nov '16

#8321: improve basic block layout on LLVM backend by predicting stack/heap checks ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (LLVM) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently we don't give the LLVM optimizer any information about which branch of an `if` is likely to be taken. As a result, the optimizer is likely to produce a basic block layout which is not optimal. Improving the layout can improve performance through better instruction cache usage and better branch prediction by the hardware. We can control LLVM's idea of what is likely with the `llvm.expect` intrinsic function. Some obvious branches which we can predict accurately are the stack and heap checks that appear near the entry of many functions. Here's a small example of some Cmm code and the output of the LLVM optimizer/compiler. {{{ block_c2Lc_entry() // [R1, R2] { info_tbl: [(c2Lc, label: block_c2Lc_info rep:StackRep [])] stack_info: arg_space: 0 updfr_space: Nothing } {offset c2Lc: Hp = Hp + 24; if (Hp > HpLim) goto c2Lm; else goto c2Ll; c2Lm: HpAlloc = 24; R2 = R2; R1 = R1; call stg_gc_pp(R2, R1) args: 8, res: 8, upd: 24; c2Ll: I64[Hp - 16] = :_con_info; P64[Hp - 8] = R1; P64[Hp] = R2; R1 = Hp - 14; Sp = Sp + 8; call (P64[Sp])(R1) args: 24, res: 0, upd: 24; } }] }}} {{{ 00000000000002b8 <c2Lc_info>: 2b8: 4c 89 e0 mov %r12,%rax 2bb: 4c 8d 60 18 lea 0x18(%rax),%r12 2bf: 4d 3b a5 18 01 00 00 cmp 0x118(%r13),%r12 2c6: 76 10 jbe 2d8 <c2Lc_info+0x20> 2c8: 49 c7 85 48 01 00 00 movq $0x18,0x148(%r13) 2cf: 18 00 00 00 2d3: e9 00 00 00 00 jmpq 2d8 <c2Lc_info+0x20> 2d4: R_X86_64_PC32 stg_gc_pp+0xfffffffffffffffc 2d8: 48 c7 40 08 00 00 00 movq $0x0,0x8(%rax) 2df: 00 2dc: R_X86_64_32S ghczmprim_GHCziTypes_ZC_con_info 2e0: 48 89 58 10 mov %rbx,0x10(%rax) 2e4: 4c 89 70 18 mov %r14,0x18(%rax) 2e8: 48 8b 45 08 mov 0x8(%rbp),%rax 2ec: 48 83 c5 08 add $0x8,%rbp 2f0: 49 8d 5c 24 f2 lea -0xe(%r12),%rbx 2f5: ff e0 jmpq *%rax 2f7: 90 nop }}} It would likely be better to invert the branch at `2c6` to a `ja`, so that the common case is adjacent to the function entry, and when `llvm.expect` is used on the condition in the branch, the LLVM optimizer does produce this alternate layout. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8321> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9940: GHCi crashes when I hold down control-c for a short time, and then hold down any key that would normally result in typing.
by GHC 17 Nov '16

17 Nov '16

#9940: GHCi crashes when I hold down control-c for a short time, and then hold down any key that would normally result in typing. -------------------------------------------+------------------------------- Reporter: Dingus | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: crash, control-c | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- This is printed: (without the quotes at the beginning or end) " ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug " I am able to reproduce it by: 1. starting ghci (with no arguments, or a file as an argument) 2. holding down contol-c for 2 seconds 3. holding down spacebar/a letter key for 2 seconds The timing varies. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9940> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10771: Installation of Ivory - Static flags have not been initialised
by GHC 15 Nov '16

15 Nov '16

#10771: Installation of Ivory - Static flags have not been initialised -------------------------------------+------------------------------------- Reporter: stiege | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Unfortunately I'm a Haskell newbie and can't provide very good detail for this report (I struggled to pass the Captcha!). However I will attach the output from a "make all" from the Ivory repository: https://github.com/GaloisInc/ivory.git Commit: '7ecea5839898b65430ca298fd1f3af4d2272e3fb'. Basically from what I can see, looks like it didn't work, output ends with: examples\Coroutine.hs:26:50: Warning: Unticked promoted constructor: `:->'. Use ':-> instead of `:->'. ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-mingw32): Static flags have not been initialised! Please call GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10771> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11369: Suppress redundant-constraint warnings in case of empty classes
by GHC 07 Nov '16

07 Nov '16

#11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (Type checker) | 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 technique described in http://www.well-typed.com/blog/2015/07/checked-exceptions/ makes use of a class without any methods, i.e. {{{#!hs class Throws e }}} However, this by definition results in redundant constraints, e.g. {{{#!hs readFoo :: Throws IOError => FilePath -> IO Foo readFoo fn = {- ... -} }}} which GHC 8.0 warns about. I propose to suppress warnings in case a class which has no methods is used as seemingly redundant constraint. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11369> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18