May 2015 - ghc-tickets

[GHC] #9184: Allow the use of Python 3 when building GHC
by GHC 01 Dec '16

01 Dec '16

#9184: Allow the use of Python 3 when building GHC -------------------------------------------+------------------------------- Reporter: aspidites | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: python | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- According to the [https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows wiki], it is preferred that a user have Python 2.7 installed before attempting to build GHC. As I'm on Arch Linux the default Python version is 3.4. As such, rather than simply changing the shebang line to explicitly ask for version 2, I made it so that the scripts all use syntax that works properly for versions 2.7 to 3.4. I don't think I've used anything that disallows 2.6, but don't have that version available to check against. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[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] #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] #8300: split-objs doesn't split on LLVM
by GHC 22 Nov '16

22 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 17 Nov '16

17 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 16 Nov '16

16 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] #9010: TemplateHaskell leads to an "unknown symbol" error
by GHC 04 Nov '16

04 Nov '16

#9010: TemplateHaskell leads to an "unknown symbol" error ------------------------------------+------------------------------------- Reporter: Feuerbach | 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: | ------------------------------------+------------------------------------- Code: {{{ {-# LANGUAGE TemplateHaskell #-} module M where import System.Console.Editline import Data.Lens.Template data S = S { _a :: EditLine } makeLens ''S }}} When compiled with `ghc link.hs`, everything is fine; {{{ [1 of 1] Compiling M ( link.hs, link.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package tagged-0.7.1 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package transformers-compat-0.1.1.1 ... linking ... done. Loading package contravariant-0.4.4 ... linking ... done. Loading package distributive-0.4.3.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package text-1.1.0.1 ... linking ... done. Loading package hashable-1.2.1.0 ... linking ... done. Loading package nats-0.1.2 ... linking ... done. Loading package unordered-containers-0.2.3.3 ... linking ... done. Loading package semigroups-0.12.2 ... linking ... done. Loading package comonad-4.0.1 ... linking ... done. Loading package semigroupoids-4.0.1 ... linking ... done. Loading package data-lens-2.10.4 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package data-lens-template-2.1.8 ... linking ... done. }}} However, when compiling with `ghc -package-id editline-0.2.1.1-ef91ae78e7ea1b9142c2fb0b84e85c11 link.hs`, I get {{{ [1 of 1] Compiling M ( link.hs, link.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package editline-0.2.1.1 ... linking ... ghc: /home/feuerbach/work /.cabal-sandbox/lib/i386-linux- ghc-7.6.3/editline-0.2.1.1/HSeditline-0.2.1.1.o: unknown symbol `el_reset' ghc: unable to load package `editline-0.2.1.1' }}} This is a problem because that's how cabal invokes ghc. This looks similar to #4899, except there's nothing "non-standard" here (no profiling or dynamic linking). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9010> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #10221: LLVM does not work on OSX
by GHC 01 Nov '16

01 Nov '16

#10221: LLVM does not work on OSX -------------------------------------------+---------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+---------------------------- I can't seem to be able to use the LLVM backend on OSX. I get the error: {{{ error: unknown directive .macosx_version_min 10, 0 ^ <no location info>: Error running clang! you need clang installed to use theLLVM backend (or GHC tried to execute clang incorrectly) <no location info>: ghc: phase `Clang (Assembler)' failed (exitcode = 1) }}} This is on GHC 7.10.1 {{{ % clang --version Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix yongqli@auxiliary ~/secrets/projects/stocvol % opt --version LLVM (http://llvm.org/) LLVM version 3.5.1 Optimized build with assertions. Built Jan 15 2015 (18:24:46). Default target: x86_64-apple-darwin14.1.0 Host CPU: core-avx2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9858: Typeable instance for datatype and its promoted constructor is the same
by GHC 26 Oct '16

26 Oct '16

#9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable data A = A main = print $ typeRep (Proxy :: Proxy A) == typeRep (Proxy :: Proxy 'A) }}} This returns `True`, but it should return `False`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9858> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 119

[GHC] #9494: Probable data corruption with GHCi 7.8.* and Zlib
by GHC 15 Oct '16

15 Oct '16

#9494: Probable data corruption with GHCi 7.8.* and Zlib -------------------------------------+------------------------------------- Reporter: nominolo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following program causes Zlib data corruption errors when run from inside GHCi. It launches two threads which then concurrently read a file, compress it, and immediately decompress it. You need libraries `zlib`, `SHA`, and `async`. {{{ module Main where import qualified Codec.Compression.Zlib as Zlib import qualified Data.ByteString.Lazy as BL import qualified Data.ByteString.Internal as BI import Control.Exception (bracket) import Control.Concurrent import Control.Monad import Control.Exception ( evaluate) import Data.Digest.Pure.SHA ( sha1) -- from the 'SHA' package import Control.Concurrent.Async ( mapConcurrently) import System.Mem ( performGC ) import Debug.Trace test :: Int -> IO String test _ = do tid <- myThreadId -- testdata is: dd if=/dev/urandom of=/tmp/testdata bs=100k count=100 -- Could also be replaced by: (BL.take (10^7) "/dev/urandom") dat <- BL.readFile "/tmp/testdata" let cbuf = Zlib.compress $ traceChunks tid $ dat s <- evaluate $ sha1 $ Zlib.decompress $ cbuf return $ show s where -- We used this to check whether buffers were reused by different threads, but that -- doesn't seem to be the case. Removing the call to traceChunks, however, makes it -- harder to reproduce possibly because of scheduler effects. In a much larger program -- it could be reproduced more easily without the trace, but in this small example -- tracing seems to cause the right amount of nondeterminism. traceChunks tid bs = BL.fromChunks $ zipWith (\n x -> trace (show tid ++ ":" ++ showBS x) x) [1..] $ BL.toChunks bs showBS (BI.PS ptr off len) = show ptr main = do r <- withGCThread $ mapConcurrently (test) ([1..2] :: [Int]) putStrLn $ show $ r where -- Regularly forcing the GC makes the test-case more reproducible. withGCThread io = bracket (forkIO $ forever $ performGC >> threadDelay 1000) killThread (const io) }}} The output should be something like: {{{ ... ThreadId 51:0x00000001091ee010 ThreadId 49:0x00000001091a7010 ... ThreadId 49:0x000000010986f010 zlib-test-case.hs: user error (Codec.Compression.Zlib: incorrect data check) }}} You'll get different Zlib errors, depending on where it detects the inconsistency. Sometimes Zlib doesn't throw an error, but the checksums are different. So far we've only been able to reproduce this using GHCi 7.8.3 on both Linux (NixOS) and Mac. We haven't been able to trigger it with a compiled executable, nor with GHCi 7.6.3. It '''was''' reproducable with HEAD from Jan 30 (I had that lying around somewhere). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9494> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9