November 2015 - ghc-tickets

[GHC] #8842: Make sure msys2 builds non emulating binaries
by GHC 06 Feb '16

06 Feb '16

#8842: Make sure msys2 builds non emulating binaries ------------------------------------+--------------------------------- Reporter: schyler | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- I came across this in my own project. MSys2 doesn't enter #ifdef blocks which test for _WIN32. Instead, it pretends to be Linux and has a set of headers which emulate things like mmap. These emulation functions are really really slow -- in my personal tests about 10x slower than calling the WINAPI -- so this ticket is just a reminder (it may already be done) for someone to check that MSys2 builds things non-emulated in GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8842> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9686: Link option detection does not work for incremental builds on Windows
by GHC 06 Feb '16

06 Feb '16

#9686: Link option detection does not work for incremental builds on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- ghc on Linux embeds link options into the resulting binary in order to be able to tell when a binary needs to be recompiled because different link options have been passed in to ghc. This functionality is not present on Windows, forcing users to pass in -fforce-recomp. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9686> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10289: compiling huge HashSet hogs memory
by GHC 05 Feb '16

05 Feb '16

#10289: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Compiling a huge (~2.5k elements) set with GHC-7.10.1 or GHC-head and unordered-containers-0.2.5.1 or unordered-containers-head takes way too much memory. Here is a [https://github.com/zudov/html5-entity/blob/unordered- containers/src/Text/Html/Entity/Data/EntitySet.hs file] which I am trying to compile. I've also set up a [https://travis- ci.org/zudov/html5-entity/builds/58063328 travis build] which demonstrates the behaviour with different versions of GHC and unordered-containers. Further I would be referring to [https://travis- ci.org/zudov/html5-entity/jobs/58063332 this build-job] which uses GHC-7.10.1 and unordered-containers-0.2.5.1. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L397 Compilation] with default optimization options takes around [https ://travis-ci.org/zudov/html5-entity/jobs/58063332#L408 12GB] of memory. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L367 Compilation] with `-O0` takes around [https://travis- ci.org/zudov/html5-entity/jobs/58063332#L378 400MB]. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L457 Compilation] with `-O2` takes around [https://travis- ci.org/zudov/html5-entity/jobs/58063332#L468 12GB] of memory. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L487 Compilation] with `-O2 -fignore-interface-pragmas` takes around [https ://travis-ci.org/zudov/html5-entity/jobs/58063332#L498 500MB] of memory, which solves the problem. When the build uses GHC-7.8.4, neither of this hogging [https://travis- ci.org/zudov/html5-entity/jobs/58063330 occurs]. Another interesting observation is that [https://travis- ci.org/zudov/html5-entity/jobs/58063330#L339 compiling] [https://github.com/zudov/html5-entity/blob/unordered- containers/src/Text/Html/Entity/Data/EntityMap.hs HashMap] of the same size, doesn't cause memory hogging even with `-O2`. This attracted my attention as `HashSet` is implemented in terms of `HashMap`. I reported the issue to `unordered-containers` as well: [https://github.com/tibbe/unordered-containers/issues/100 link]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10289> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9638: Speed up Data.Char.isDigit
by GHC 05 Feb '16

05 Feb '16

#9638: Speed up Data.Char.isDigit -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | 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: Runtime hour) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `isDigit` is currently defined like this: {{{#!hs isDigit :: Char -> Bool isDigit c = c >= '0' && c <= '9' }}} This will short-circuit the right way if you're looking for digits mixed with spaces, but the wrong way if you're looking for digits mixed with letters. It also requires a conditional jump to do that short-circuiting (confirmed by inspecting the assembly). It should be better to use an unsigned comparison instead: {{{#!hs isDigit :: Char -> Bool isDigit c = (fromIntegral (ord c) :: Word) - 48 <= 9 }}} The interesting section looks like this {{{ movq 7(%rbx),%rax addq $-48,%rax cmpq $9,%rax setbe %al movzbl %al,%eax shlq $3,%rax movq ghczmprim_GHCziTypes_Bool_closure_tbl(%rax),%rbx addq $8,%rbp jmp *(%rbp) }}} or like this with -fllvm: {{{ movq 7(%rbx), %rax addq $-48, %rax cmpq $10, %rax sbbq %rax, %rax andq $8, %rax movq ghczmprim_GHCziTypes_Bool_closure_tbl(%rax), %rbx movq 8(%rbp), %rax addq $8, %rbp jmpq *%rax # TAILCALL }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9638> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10284: Create a dedicated `TypeError` exception type
by GHC 03 Feb '16

03 Feb '16

#10284: Create a dedicated `TypeError` exception type -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Ticket #10283 discusses using `-fdefer-type-errors` to test that certain programs do not type check. In practice, this involves evaluating certain expressions to WHNF at run- time can checking whether they trigger an exception. Currently, it seems the exception to catch is an `ErrorCall` exception. It would be nice if we could very specifically catch type errors though. It's entirely possible that a critical test case that I want to be a type error mistakenly type- checks and then calls `error`. In such a situation, it's hard to distinguish such a true run-time error from a deferred type error. It would be much nicer if something like `TypeError` would be thrown instead of `ErrorCall`. Yes, it's currently possible to look at the text of the `ErrorCall` and check for certain text fragments in there, but that sounds extremely fragile to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10284> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10345: Testsuite timeout_multiplier setting does not work as expected
by GHC 03 Feb '16

03 Feb '16

#10345: Testsuite timeout_multiplier setting does not work as expected -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I have a test case that - if failed - sends GHC into an infinite loop. The test case is small so I don't want to wait for default timeout (currently that's 5 minutes). The testsuite provides `timeout_multiplier` function to modify the default timeout but that setting seems to be ignored and the test is killed only after the default timeout time. I added my test to `all.T` file like this: {{{ test('tc265', timeout_multiplier(0.01), compile, ['']) }}} I also tried putting timeout setting into an array (`[timeout_multiplier(0.01)]`) but with no result. Merijn reports having same problems and bypassing them by writing a test that forks itself and kills the child process after a given timeout - see [[GhcFile(libraries/base/tests/T8089.hs)]]. I am adding a note on [[wiki:Building/RunningTests/Adding#Thesetupfield]] that this field does not work currently. Once this bug is fixed we need to remove that note. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10345> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8746: Crosscompiling
by GHC 03 Feb '16

03 Feb '16

#8746: Crosscompiling -------------------------------------+------------------------------------- Reporter: Visionstar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Keywords: Crosscompile | Operating System: Linux cross compile failed ncurses | Type of failure: Building GHC setupterm not found | failed Architecture: Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Hello! I tried to crosscompile from linux i386 to arm-linux-gnueabihf, but i cant make it happen, because it gives me this weird error while running 'make': {{{ checking ncurses.h usability... yes checking ncurses.h presence... yes checking for ncurses.h... yes checking for setupterm in -ltinfo... no checking for setupterm in -lncursesw... no checking for setupterm in -lncurses... no checking for setupterm in -lcurses... no configure: error: in '/home/edi/ghc_cross/ghc/libraries/terminfo': configure: error: curses library not found, so this package cannot be built See 'config.log' for more details make[2]: *** [libraries/terminfo/dist-install/package-data.mk] Error 1 make[1]: *** [all_libraries/terminfo] Error 2 make[1]: Leave Directory '/home/edi/ghc_cross/ghc' make: *** [all] Error 2 }}} What have i done: -) Compiled 7.8.0 from github (The log says 'That should have been 7.8.0', i chose 7.8 because i thought it would be more stable for crosscompiling) to my i386 (normal boot, configure, make, make install). This worked fine -) installed newest llvm from svn (LLVM version 3.5svn) -) replaced the libffi-3.0.11.tar.gz in ghc/libffi-tarballs with libffi-3.0.13 -) added this version of mk/build.mk: {{{ SRC_HC_OPTS = -H32m _o -fasm -Rghc-timing GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O0 -DDEBUG -Wall GhcLibHcOpts = -O -fasm -XGenerics GhcLibWays = v dyn SplitObjs = NO Stage1Only = YES }}} -) downloaded the sourcecode of ncurses from http://ftp.de.debian.org/debian/pool/main/n/ncurses/ncurses_5.9.orig.tar.gz and builded it with "./configure arm-linux-gnueabihf --with-gcc=arm-linux- gnueabihf-gcc --target=arm-linux-gnueabihf --prefix=/usr/arm-linux- gnueabihf " + "make". afterwards i added the folder to my $PATH -)did "perl boot", "./configure --target=arm-linux-gnueabihf --with-gcc =arm-linux-gnueabihf-gcc --prefix=/usr/arm-linux-gnueabihf" and "make". ./configure worked, but make gives me this weird error. I also tried copying all included files from ncurses to the libraries/terminfo folder, but that also didn't work. I think the mistake is somewhere in the building process, but i'm not exactly sure, so thats why i'm posting this bug. Does anyone have an idea about that? PS: i also made sure that i met the prerequirements mentioned in https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux and https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling Greetings, Edi -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8746> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11100: Remote GHCi
by GHC 02 Feb '16

02 Feb '16

#11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | 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: -------------------------------------+------------------------------------- This task is to implement Remote GHCi, i.e. running interpreted code in a separate process. For more details see [wiki:RemoteGHCi]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #11082: Tweak workflow around overlong lines
by GHC 29 Jan '16

29 Jan '16

#11082: Tweak workflow around overlong lines -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | 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: -------------------------------------+------------------------------------- [https://mail.haskell.org/pipermail/ghc-devs/2015-November/010373.html This thread] discussed potential changes to the way the GHC dev workflow deals with overlong lines. This ticket summarizes the discussion. '''Initial complaint:''' arc/Phab is too heavy-handed about overlong lines. Almost all patchers have to write a vacuous "explanation" for them, and the overlong line warnings clutter code reviews. '''Initial suggestion:''' After `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of {{{ Before your patch, 15 of the edited lines were over 80 characters. Now, a whopping 28 of them are. Can't you do better? Please? }}} '''Reactions:''' * +1 * Even the delta in overlong lines is bad, because perhaps a small refactor added to the length of an identifier. * We might just want to reject code with overlong lines. Then the problem would really go away. It favors one-time work over many-time maintenance burden. (Austin's point, +1 by Alexander Berntsen) * This would cause more work and would increase the barrier to contribution. And sometimes it's appropriate/more readable to have overlong lines. * 80 is too small. 120 (SPJ)? 132 (Ed Kmett)? * And a small limit discourages informative identifiers. * Just drop the column limit entirely. * Why 80? Because two 80-column buffers fit nicely side-by-side on small laptop screens. Three such columns fit nicely on monitors. Several (4 emails) echoed this point. Bottom line: no one expressed liking the status quo (though Simon M called it "not terrible"). If we're to choose a limit, a choice of 80 seemed to appease the plurality of respondents. Two respondents advocate enforcing the limit. I count four respondents rejecting hard enforcement. In my (surely biased) view, this means that we should implement my original proposal. :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10310: MakingReleases outdated or build system problems
by GHC 29 Jan '16

29 Jan '16

#10310: MakingReleases outdated or build system problems -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hey, I have some problems following https://ghc.haskell.org/trac/ghc/wiki/MakingReleases with HEAD. I'll collect them here, maybe we can update the Wiki page together, or fix the corresponding problems in the build system if they are problems. 1) `make sdist` fails with the problem that `ghc-tarballs` doesn't exist. I've heard that's only needed on Windows, and that some people seem to get it by cloning a submodule when they are on Windows. A `mkdir ghc-tarballs` fixed it. Maybe that directory should be created by the build system? 2) When I `make` in the unpacked sdist tarball, I get {{{ "" -P 'filename.as.url=0' utils/haddock/doc/haddock.xml --ps -o utils/haddock/doc/haddock.ps "" -P 'filename.as.url=0' utils/haddock/doc/haddock.xml --pdf -o utils/haddock/doc/haddock.pdf /bin/bash: : command not found /bin/bash: : command not found make[1]: *** [utils/haddock/doc/haddock.ps] Error 127 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [utils/haddock/doc/haddock.pdf] Error 127 }}} Looks like some program was set to the empty string here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10310> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2