December 2017 - ghc-tickets

[GHC] #12245: Deriving Data at higher kinds
by GHC 01 Feb '18

01 Feb '18

#12245: Deriving Data at higher kinds -------------------------------------+------------------------------------- Reporter: simonpj | Owner: 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: -------------------------------------+------------------------------------- Here's what [https://mail.haskell.org/pipermail/generics/2016-June/000564.html Lennart Spitzner wanted to do]: {{{ > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE DeriveDataTypeable #-} > {-# LANGUAGE FlexibleInstances #-} > > import Data.Data ( Data ) > > data Foo f = Foo (f Bool) (f Int) > > deriving instance Data (Foo []) > deriving instance Data (Foo Maybe) }}} Of course you can't derive `Data` for `Foo` because we don't know what `f` is, so Lennart is making multiple instances, one for each instance of `f`. It's a bit clumsy. What we would really like is {{{ deriving instance (forall a. Data => Data (f a)) => Data (Foo f) }}} but we don't have higher order instances yet! So Lennart is manually making two instances. This should work, but he gets {{{ > Main.hs: line 45, column 1: > Multiple declarations of ‘$cr2C’ > Declared at: Main.hs:44:1 > Main.hs:45:1 > Main.hs: line 45, column 1: > Multiple declarations of ‘$tr2D’ > Declared at: Main.hs:44:1 > Main.hs:45:1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12245> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14594: 2 modules / 2500LOC takes nearly 3 minutes to build
by GHC 30 Jan '18

30 Jan '18

#14594: 2 modules / 2500LOC takes nearly 3 minutes to build -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tested this from a brand new MacBook 15" with 8 threads x 2.8 GHz Intel Core i7 / 16 GB RAM on OS X: {{{ $ time stack build WARNING: /Users/kvanb/git/github-webhooks/github-webhooks.cabal was generated with a newer version of hpack, please upgrade and try again. github-webhooks-1.0.0: unregistering (local file changes: github- webhooks.cabal package.yaml spec/DecodeEventsSpec.hs spec/Spec.hs src/GitHub/Data/Webhooks...) github-webhooks-1.0.0: configure (lib) Configuring github-webhooks-1.0.0... github-webhooks-1.0.0: build (lib) Preprocessing library github-webhooks-1.0.0... [1 of 3] Compiling Paths_github_webhooks ( .stack- work/dist/x86_64-osx/Cabal-1.24.2.0/build/autogen/Paths_github_webhooks.hs, .stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build/Paths_github_webhooks.o ) [2 of 3] Compiling GitHub.Data.Webhooks.Payload ( src/GitHub/Data/Webhooks/Payload.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.2.0/build/GitHub/Data/Webhooks/Payload.o ) [3 of 3] Compiling GitHub.Data.Webhooks.Events ( src/GitHub/Data/Webhooks/Events.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.2.0/build/GitHub/Data/Webhooks/Events.o ) github-webhooks-1.0.0: copy/register Installing library in /Users/kvanb/git/github-webhooks/.stack- work/install/x86_64-osx/lts-9.18/8.0.2/lib/x86_64-osx-ghc-8.0.2/github- webhooks-1.0.0-LDmeffpkXvwH6ZXCPE95ke Registering github-webhooks-1.0.0... real 2m49.342s user 2m42.441s sys 0m5.805s }}} Source code has about 30 derivations of the form: {{{#!hs type IssueState = Text data HookIssue = HookIssue { whIssueUrl :: !URL , whIssueLabelsUrl :: !URL , whIssueCommentsUrl :: !URL , whIssueEventsUrl :: !URL , whIssueHtmlUrl :: !URL , whIssueId :: !Int , whIssueNumber :: !Int , whIssueTitle :: !Text , whIssueUser :: !HookUser , whIssueLabels :: !(Vector HookIssueLabels) , whIssueState :: IssueState , whIssueIsLocked :: !Bool , whIssueAssignee :: !(Maybe HookUser) , whIssueMilestone :: !(Maybe HookMilestone) , whIssueCommentCount :: !Int , whIssueCreatedAt :: !UTCTime , whIssueUpdatedAt :: !UTCTime , whIssueClosedAt :: !(Maybe UTCTime) , whIssueBody :: !Text } deriving (Eq, Show, Typeable, Data, Generic) instance NFData HookIssue where rnf = genericRnf }}} Steps to reproduce 1. clone https://github.com/onrock-eng/github-webhooks 2. checkout sha 40a7ecc3a5845717055ee372b89e645a498cf1e2 3. time stack build This is really ''really'' ''**really**'' slow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14594> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10754: truncate /= double2Int
by GHC 29 Jan '18

29 Jan '18

#10754: truncate /= double2Int -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: truncate, | Operating System: Unknown/Multiple double2Int, rewrite, rule | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- There is a rule in libraries/base/GHC/Float.hs: {{{#!hs "truncate/Double->Int" truncate = double2Int }}} But it is not true for some values. Particularly, {{{#!hs let infinity = 1/0 :: Double truncate infinity :: Int == 0 double2Int infinity == -9223372036854775808 -- minBound }}} As a result, the value of {{{truncate (1/0 :: Double) :: Int}}} depends on optimization level. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10754> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12690: Segmentation fault in GHC runtime system under low memory with USE_LARGE_ADDRESS_SPACE
by GHC 28 Jan '18

28 Jan '18

#12690: Segmentation fault in GHC runtime system under low memory with USE_LARGE_ADDRESS_SPACE --------------------------------------+---------------------------------- Reporter: pggiarrusso | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- I have here a ~600MB core dump on GHC 8.0.1 x86_64 linux triggered under low memory (1GB RAM total, no swap, trying to build aeson with optimizations), with a stacktrace blaming the GHC runtime system. Based on code review, it appears that when requesting memory from the OS fails, the error is ignored and GHC segfaults as soon as it writes to the newly "allocated" memory. == Diagnosis == My diagnosis is that osCommitMemory calls the potentially failing `my_mmap` but returns void (hence not propagating failures); it should instead probably use `my_mmap_or_barf` or handle the failure anyhow: https://github.com/ghc/ghc/blob/a6111b8cc14a5dc019e2613f6f634dec4eb57a8a/rt… However, while I'm very convinced that's a bug, I'm only mostly confident that's the culprit, since the segfault happens later; I've just looked for bugs on allocation failures in the code ran shortly before the crash. == Raw data == The core dump is on a VM from the reporter of https://github.com/commercialhaskell/stack/issues/2575, https://github.com/jiakai0419, which graciously gave me access to the VM and bothered reporting in the first place—I'd like to thank her. I'd like to avoid copying the dump here unless strictly needed. == Reproduction == The bug is deterministic on that machine, but it requires a failure in mmap without triggering an OOM, so I'm not 100% sure how easy it is to reproduce but it should be easy on a VM with 1GB RAM and 1 core. Here's the output of `free`: {{{ $ free total used free shared buff/cache available Mem: 1015352 95864 71396 51244 848092 733132 Swap: 0 0 0 }}} Instructions to produce a dump. First, as root: {{{ echo /tmp/core > /proc/sys/kernel/core_pattern }}} that's needed because otherwise the core file is produced in a temporary folder that stack removes. Then (as non-root, root has privileged access to memory), install stack, and run: {{{ ulimit -c unlimited git clone https://github.com/jiakai0419/snowflake.git stack build --verbose }}} Below is some raw data from the core dump. In short, an initializer for newly allocated data segfaults, and gdb tells that the address it's trying to write (bd->start) to can't be accessed, even though it's lower than mblock_high_watermark so it should have been committed (mmap'ed) by getFreshMBlocks (I don't get getReusableMBlocks in detail, but it also calls `osCommitMemory`, so I guess there's the same invariant). The existence of mblock_high_watermark (beyond other reasons) should confirm this is using USE_LARGE_ADDRESS_SPACE. If this diagnosis is correct, the bug exists since USE_LARGE_ADDRESS_SPACE was introduced in https://github.com/ghc/ghc/commit/0d1a8d09f452977aadef7897aa12a8d41c7a4af0, so it's a regression in 8.0.1. {{{ (gdb) bt #0 initMBlock (mblock=0x225c00000) at rts/sm/BlockAlloc.c:676 #1 alloc_mega_group (mblocks=mblocks@entry=1) at rts/sm/BlockAlloc.c:328 #2 0x00007fe650438d98 in allocGroup (n=1) at rts/sm/BlockAlloc.c:379 #3 allocGroup (n=1) at rts/sm/BlockAlloc.c:336 #4 0x00007fe65043ed55 in allocBlock_sync () at rts/sm/GCUtils.c:38 #5 0x00007fe65043ef7d in alloc_todo_block (ws=ws@entry=0x13196b0, size=size@entry=3) at rts/sm/GCUtils.c:330 #6 0x00007fe65043f13a in todo_block_full (size=size@entry=3, ws=0x13196b0) at rts/sm/GCUtils.c:292 #7 0x00007fe65041baed in alloc_for_copy (gen_no=<optimized out>, size=3) at rts/sm/Evac.c:81 #8 copy_tag (tag=2, gen_no=<optimized out>, size=3, src=0x21b353868, info=<optimized out>, p=0x225b13f10) at rts/sm/Evac.c:99 #9 evacuate1 (p=p@entry=0x225b13f10) at rts/sm/Evac.c:596 #10 0x00007fe65041d65c in scavenge_block1 (bd=0x225b004c0) at rts/sm/Scav.c:570 #11 0x00007fe6504415dc in scavenge_find_work () at rts/sm/Scav.c:2040 #12 scavenge_loop1 () at rts/sm/Scav.c:2103 #13 0x00007fe65043cee2 in scavenge_until_all_done () at rts/sm/GC.c:968 #14 0x00007fe65043d75a in GarbageCollect (collect_gen=collect_gen@entry=1, do_heap_census=do_heap_census@entry=rtsFalse, gc_type=gc_type@entry=2, cap=cap@entry=0x7fe650669a80 <MainCapability>) at rts/sm/GC.c:403 #15 0x00007fe65042ff81 in scheduleDoGC (force_major=rtsFalse, task=0x13228a0, pcap=<optimized out>) at rts/Schedule.c:1652 #16 scheduleDoGC (pcap=<optimized out>, task=0x13228a0, force_major=rtsFalse) at rts/Schedule.c:1433 #17 0x00007fe650430c1a in schedule (initialCapability=initialCapability@entry=0x7fe650669a80 <MainCapability>, task=task@entry=0x13228a0) at rts/Schedule.c:551 #18 0x00007fe650431cf8 in scheduleWaitThread (tso=0x20000b388, ret=ret@entry=0x0, pcap=pcap@entry=0x7ffc4ee22c08) at rts/Schedule.c:2361 #19 0x00007fe65042c528 in rts_evalLazyIO (cap=cap@entry=0x7ffc4ee22c08, p=p@entry=0x7895c0, ret=ret@entry=0x0) at rts/RtsAPI.c:500 #20 0x00007fe65042e3a7 in hs_main (argc=96, argv=0x7ffc4ee22dc8, main_closure=0x7895c0, rts_config=...) at rts/RtsMain.c:64 #21 0x0000000000428414 in main () (gdb) info locals bd = 0x225c00100 block = 0x225c04000 <Address 0x225c04000 out of bounds> (gdb) print/x mblock_high_watermark $11 = 0x225d00000 (gdb) print bd->start Cannot access memory at address 0x225c00100 (gdb) print *bd Cannot access memory at address 0x225c00100 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12690> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14606: ghc-exactprint not up to date
by GHC 27 Jan '18

27 Jan '18

#14606: ghc-exactprint not up to date -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 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 created this ticket to track that ghc-exactprint has not yet been updated, and this should happen before a final release. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14606> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14526: GHC fails to configure on MacOS if Cuda is installed
by GHC 27 Jan '18

27 Jan '18

#14526: GHC fails to configure on MacOS if Cuda is installed -------------------------------------+------------------------------------- Reporter: nehal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.2 Keywords: Cuda | Operating System: MacOS X Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, I had the following issue trying to build ghc (indirectly via stack) {{{ [error] Running /usr/bin/make install in directory /Users/nehal/.stack/programs/x86_64-osx/ghc-8.0.2.temp/ghc-8.0.2/ exited with ExitFailure 2 mk/config.mk:521: *** missing separator. Stop. @(Stack/Setup.hs:991:21) 2017-10-16 07:16:01.831719: [error] Error: Error encountered while installing GHC with make install run in /Users/nehal/.stack/programs/x86_64-osx/ghc-8.0.2.temp/ghc-8.0.2/ }}} Here is the line from `mk/config.mk:521`: {{{ 519 WhatGccIsCalled = /usr/bin/gcc 520 GccVersion = 9.0.0 521 8.0 522 ifeq "$(phase)" "0" ... }}} output from gcc: {{{ nehal$ gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 9.0.0 (clang-900.0.37) Target: x86_64-apple-darwin16.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin Found CUDA installation: /usr/local/cuda, version 8.0 }}} It looks like the version detection is getting confused by the cuda installation (and so is thinking the version is something like `"9.0.0\n8.0"`) This could be something for further upstream (e.g. autotools mainainters), but I'm just rebooting my "try to grok Haskell" efforts, so I am going to take the lazy approach and report it here.... Thanks for ghc! (downstream bug report is here: https://github.com/commercialhaskell/stack/issues/1582#issuecomment-3469174… -- two others have hit this in the past month or so) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14526> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13352: Strange requirement for re-exported duplicate record fields
by GHC 26 Jan '18

26 Jan '18

#13352: Strange requirement for re-exported duplicate record fields -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the following example, {{{ module A(A(..)) where data A = A {x::Int} module B(B(..)) where data B = B {x::Bool} {-# LANGUAGE DuplicateRecordFields #-} module C(A(..),B(..)) where import A(A(..)) import B(B(..)) }}} I get an error about `conflicting exports for 'x'`. This doesn't seem right to me: I've got `-XDuplicateRecordFields` exactly where the duplicate occurs. However, I noticed that the if I move the pragma to A.hs, C.hs compiles without error: {{{ {-# LANGUAGE DuplicateRecordFields #-} module A(A(..)) where data A = A {x::Int} module B(B(..)) where data B = B {x::Bool} module C(A(..),B(..)) where import A(A(..)) import B(B(..)) }}} This is bizarre because it is asymmetric (I arbitrarily put the pragma in A.hs, but it need not occur in B.hs), and because no duplicate records exist in module A, but they ''do'' exist in module C, where the pragma isn't needed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13352> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14504: Nofib is broken on Windows
by GHC 25 Jan '18

25 Jan '18

#14504: Nofib is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: NoFib | Version: 8.2.1 benchmark suite | 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: -------------------------------------+------------------------------------- It seems like nofib is currently broken on Windows. Specifically, it fails for me with {{{ ... /home/ben/ghc/inplace/bin/ghc-stage2 -M -dep-suffix "" -dep-makefile .depend -osuf o -O2 -Rghc-timing -H32m -hisuf hi -rtsopts -XBangPatterns -O2 Main.hs <<ghc: 21000792 bytes, 9 GCs, 781824/1421072 avg/max bytes residency (2 samples), 26M in use, 0.000 INIT (0.000 elapsed), 0.031 MUT (0.037 elapsed), 0.016 GC (0.022 elapsed) :ghc>> Finished making boot in fannkuch-redux: 0 ------------------------------------------------------------------------ == make boot --no-print-directory; in /home/ben/ghc/nofib/shootout/fasta ------------------------------------------------------------------------ $topdir/../mingw/bin/gcc.exe -std=gnu99 -O3 -fomit-frame-pointer fasta-c.c -o fasta-c /bin/sh: /../mingw/bin/gcc.exe: No such file or directory }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14504> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11138: Kill the terrible LLVM Mangler
by GHC 24 Jan '18

24 Jan '18

#11138: Kill the terrible LLVM Mangler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since its introduction the LLVM backend has had a mangler which transforms assembler produced by LLVM. In the past this mangler was responsible for shuffling around code to make tables-next-to-code work, but the need for this has past with the resolution of #4213. At this point the only reason it exists is to mangle AVX instructions to 1. rewriting all symbols of type `@function` to `@object` to prevent symbol references from going through the PLT, which would be bad due to tables-next-to-code. 2. On x86_64, rewrite AVX instructions that require alignment to their unaligned counterparts, since the stack is only 16-byte aligned but these instructions require 32-byte alignment. While it's unclear that we will ever be able to discharge (1), it would be nice to investigate whether we can at least do something about (2) (there may even be performance to be gained!). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11138> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12470: Move LLVM code generator to LLVM bitcode format
by GHC 24 Jan '18

24 Jan '18

#12470: Move LLVM code generator to LLVM bitcode format -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (LLVM) | 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: -------------------------------------+------------------------------------- Currently GHC produces LLVM's textual intermediate representation. While this is easy to produce, it's not the path recommended by LLVM's developers. Instead, they [[http://llvm.org/docs/DeveloperPolicy.html#ir- backwards-compatibility|recommend]] that compilers produce LLVM bitcode, which they maintain much stronger backwards compatibility guarantees on. It seems sensible to move the backend over to this format. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12470> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3