July 2017 - ghc-tickets

Re: [GHC] #847: Threaded RTS problems on FreeBSD
by GHC 24 Jul '17

24 Jul '17

#847: Threaded RTS problems on FreeBSD -----------------------------------+--------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.4.3 Component: Runtime System | Version: 6.4.2 Resolution: fixed | Keywords: Operating System: FreeBSD | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: -----------------------------------+--------------------------------- Changes (by Ben Gamari <ben@…>): * failure: => None/Unknown Comment: In [changeset:"d8051c6cf08f02331f98fed7d5e88a95bd76e534/ghc" d8051c6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d8051c6cf08f02331f98fed7d5e88a95bd76e534" Use libpthread instead of libthr on FreeBSD Since #847 we have used libthr due to reported hangs with FreeBSD's KSE-based M:N pthread implementation. However, this was nearly 12 years ago and today libpthread seems to work fine. Moreover, adding -lthr to the linker flags break when used in conjunction with -r when gold is used (since -l and -r are incompatible although BFD ld doesn't complain). Test Plan: Validate on FreeBSD Reviewers: kgardas, austin Subscribers: rwbarton, thomie GHC Trac Issues: #847 Differential Revision: https://phabricator.haskell.org/D3773 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/847#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13999: Simple function not inlined within declaration marked NOINLINE
by GHC 24 Jul '17

24 Jul '17

#13999: Simple function not inlined within declaration marked NOINLINE -------------------------------------+------------------------------------- Reporter: srb | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.2 Keywords: Inlining | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This seems so shallow that I feel like I must be missing something, but if I implement a function like {{{#!hs eq :: Bool -> Bool -> Bool eq x y = x == y {-# NOINLINE eq #-} }}} the boolean equality operator is not inlined in eq, even at -O2. The generated core is instead {{{#!hs eq = $fEqBool_$c== }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13999> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10064: Add support for "foo"## literals to MagicHash
by GHC 24 Jul '17

24 Jul '17

#10064: Add support for "foo"## literals to MagicHash -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm working on a high-performance library for building up buffers of data. Appending ByteStrings works pretty well, but, for bytestring literals, it's faster to avoid the CAF (and it's associated tag check + indirect jump) entirely and append a zero-terminate MagicHash string literal via Addr#. Then I discovered that it's 30% faster if you can avoid the strlen with an explicit length. See this benchmark: https://github.com/chadaustin /buffer- builder/blob/ac662962d6d3c21f206ab8e8121323b9f18677fa/bench/Bench.hs#L42 That API is not very pleasant, of course. :) Thus, here is a feature request: It would be great if "foo"## produced (# Int#, Addr# #), where the Int# is the length of the buffer in bytes. The compiler could enforce that the literal only contains 8-bit values. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9453: The example for GHC Generics is kinda broken
by GHC 24 Jul '17

24 Jul '17

#9453: The example for GHC Generics is kinda broken -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- From http://www.reddit.com/r/haskell/comments/2douzn/problem_with_popular_ghcgen…: The popular GHC.Generics serialization example at http://www.haskell.org/ghc/docs/latest/html/users_guide/generic- programming.html#idp25226064 illustrates how to serialize a sum datatype (a :+: b), with a 0 bit representing a and a 1 bit representing b. However, consider a :+: b :+: c. If the compiler treats this as (a :+: b) :+: c, then a is 00, b is 01, c is 1. If it's a :+: (b :+: c), then a is 0, b is 10, c is 11. The compiler's decision, even though (as I understand it) consistent for any given compile, could differ later. The manual, at http://hackage.haskell.org/package/generic- deriving-1.6.3/docs/Generics-Deriving-Base.html#g:9 states not to depend on the ordering, which the example does. I think this is a valid concern, and the manual should be at least updated to discuss this problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9453> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h"
by GHC 24 Jul '17

24 Jul '17

#8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2530 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => Comment: As noted in Phab:D3741, we need to reconsider the fix in comment:5. https://github.com/snowleopard/hadrian/issues/349 is also relevant here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8040#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14027: __GLASGOW_HASKELL__ / ProjectVersionInt is not set correctly in ghc 8.2.1
by GHC 24 Jul '17

24 Jul '17

#14027: __GLASGOW_HASKELL__ / ProjectVersionInt is not set correctly in ghc 8.2.1 -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- __GLASGOW_HASKELL__ is 802 with ghc-8.2.1. {{{ #if __GLASGOW_HASKELL__ >= 803 thisShouldFail #endif }}} Does not fail. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14027> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem
by GHC 24 Jul '17

24 Jul '17

#13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem -------------------------------------+------------------------------------- Reporter: sukhmel | 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: -------------------------------------+------------------------------------- I have tried both 8.0.1 and 8.0.2 versions of GHC. 7.10.3 runs just fine. Installation process is also much faster for 7.10.3, later versions have taken around 4 hours to be installed. Programs compiled with slow GHC are also slow. Sample program: {{{#!haskell main = putStrLn "Hello, world!" }}} GHC is installed with Stack. Windows version is 1607 build 15031.0 I believe this could be a bug in implementation of Ubuntu subsystem, but I'm not quite sure what part of it is failing. {{{ $ time stack ghc -- -e 'putStrLn ""' real 2m28.240s user 0m0.375s sys 3m30.078s $ time stack ghc -- --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 real 1m45.533s user 0m0.125s sys 2m46.516s time stack ghc --compiler ghc-8.0.1 -- --version The Glorious Glasgow Haskell Compilation System, version 8.0.1 real 2m54.764s user 0m0.234s sys 3m58.422s }}} {{{ $ time ghc -e 'putStrLn ""' real 0m0.872s user 0m0.109s sys 0m0.125s $ time ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 real 0m0.072s user 0m0.000s sys 0m0.031s time stack ghc --compiler ghc-7.10.3 -- -e 'putStrLn ""' real 0m0.876s user 0m0.234s sys 0m0.688s time stack ghc --compiler ghc-7.10.3 -- --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 real 0m0.832s user 0m0.109s sys 0m0.813s }}} {{{ $ echo 'main = putStrLn "Hello, world!"' > test.hs $ time stack ghc --compiler ghc-8.0.2 -- test [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... real 3m56.582s user 0m0.609s sys 5m8.125s $ time ./test Hello, world! real 0m27.540s user 0m0.000s sys 0m27.297s }}} {{{ $ echo 'main = putStrLn "Hello, world!"' > test.hs $ time stack ghc --compiler ghc-7.10.3 -- test [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... real 0m2.222s user 0m0.406s sys 0m1.406s $ time ./test Hello, world! real 0m0.030s user 0m0.000s sys 0m0.031s }}} Part of Stack output with timings: {{{ $ stack ghc --verbose -- -e 'putStrLn "Hello, world!"' Version 1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 hpack-0.15.0 ... 2017-02-19 21:13:05.756085: [debug] No project config file found, using defaults. 2017-02-19 21:13:05.759402: [debug] Run from outside a project, using implicit global project config 2017-02-19 21:13:05.761724: [debug] Using resolver: lts-8.0 from implicit global project's config file: /home/sukhmel/.stack/global- project/stack.yaml ... 2017-02-19 21:13:05.788855: [debug] Run process: /sbin/ldconfig -p 2017-02-19 21:13:05.816489: [debug] Process finished in 26ms: /sbin/ldconfig -p 2017-02-19 21:13:05.820648: [debug] Run process: /usr/bin/gcc -v 2017-02-19 21:13:05.844975: [debug] Process finished in 23ms: /usr/bin/gcc -v ... 2017-02-19 21:13:05.854997: [debug] Using standard GHC build 2017-02-19 21:13:05.856774: [debug] Getting global package database location ... 2017-02-19 21:13:05.867711: [debug] Run process: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no- user-package-db list --global 2017-02-19 21:13:05.888957: [debug] Run process: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc --numeric- version 2017-02-19 21:13:05.919968: [debug] Run process: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no- user-package-db field --simple-output Cabal version 2017-02-19 21:13:38.605653: [debug] Process finished in 32736ms: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no- user-package-db list --global 2017-02-19 21:14:11.930034: [debug] Process finished in 32792ms: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no- user-package-db field --simple-output Cabal version 2017-02-19 21:14:11.931071: [debug] Process finished in 32831ms: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc --numeric- version ... 2017-02-19 21:14:11.939817: [debug] Run process: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc -e "putStrLn \"Hello, world!\"" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14026: hs_init is not idempotent
by GHC 24 Jul '17

24 Jul '17

#14026: hs_init is not idempotent -------------------------------------+------------------------------------- Reporter: Feuerbach | 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: -------------------------------------+------------------------------------- hs_init tries to be idempotent by ignoring all calls but the first one. However, subsequent calls to hs_init do not set argc and argv correctly. Here's a test case: {{{ #include "HsFFI.h" #include "stdio.h" void try_init() { char *argv[] = { "./test", "+RTS", "-s", "-RTS", "arg", 0 }; char **argv_ptr = argv; int argc = sizeof(argv)/sizeof(argv[0]) - 1; hs_init(&argc, &argv_ptr); printf("%d\n", argc); } int main() { try_init(); try_init(); } }}} Result: {{{ 2 5 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14026> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14019: broken link to GHC.Compact
by GHC 23 Jul '17

23 Jul '17

#14019: broken link to GHC.Compact -------------------------------------+------------------------------------- Reporter: mauke | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/8.2.1-notes… #runtime-system contains a broken link: > For more details see the [https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc- compact-@LIBRARY_compact_VERSION@/GHC-Compact.html GHC.Compact] module. https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc- compact-@LIBRARY_compact_VERSION@/GHC-Compact.html is 404. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14019> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14015: DerivingStrategies dead link in documentation
by GHC 23 Jul '17

23 Jul '17

#14015: DerivingStrategies dead link in documentation -------------------------------------+------------------------------------- Reporter: mauke | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… #deriving-strategies says: > You can read the full algorithm at [http://ghc.haskell.org/trac/ghc/wiki/DerivingStrategies Wiki page]. 1. "Wiki page" is an awful link title. 2. The link goes nowhere: The https://ghc.haskell.org/trac/ghc/wiki/DerivingStrategies page doesn't exist -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14015> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2