May 2015 - ghc-tickets

[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 02 Feb '16

02 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] #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

[GHC] #9105: Profiling binary consumes CPU even when idle on Linux.
by GHC 27 Jan '16

27 Jan '16

#9105: Profiling binary consumes CPU even when idle on Linux. ----------------------------+--------------------------------- Reporter: robinp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------- The program is main = forever $ threadDelay 1000000 >> return () . Compiled with 32bit GHC 7.6.3 or 7.8.2 on Debian (inside a VM), GHC 7.4.1 on Ubuntu (not VM). The non-profiling binary doesn't consume CPU, the profiling does ~10% (of a 2Ghz machine). Running with +RTS -I0, so this is not the idle gc. When strace-ing, the profiling one seems to receive a constant flow of SIGVTALRM, while the normal receives one burst each second. I see I can switch off "master tick interval" with -V0, and then CPU is not used, but the consequences of this are not very well documented (apart from context switching becoming deterministic). Interestingly, if I compile using profiling on Windows (latest haskell- platform, 64bit), it doesn't use more CPU than the non-profiling. So, the question is, why does this happen on Linux, and if it can be avoided somehow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9105> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10324: our rts/ghc-prim/base shared library tricks don't work on Android
by GHC 26 Jan '16

26 Jan '16

#10324: our rts/ghc-prim/base shared library tricks don't work on Android -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.10.1 Component: Compiler | Operating System: Other Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I experimented with building dynamically linked executables on Android, and figured I should record my findings somewhere. (I'm interested in dynamic Haskell libraries because I'd like to eventually get ghci on Android, though obviously that would also require a bunch of packaging work!) Building a GHC with dynamic library support was no major problem, and I could build a dynamically linked "Hello, world" executable too. The problem arose when trying to actually run the executable: I got a message to the effect that there were unresolved symbols (that live in libHSrts) when loading libHSbase. I tried relinking the executable to put libHSrts before libHSbase in the list of NEEDED shared libraries, and now I instead got an error about missing symbols (that live in libHSbase) when loading libHSrts. I then tried rebuilding libHSrts against libHSbase... and then I got the first error again, about missing symbols (that live in libHSrts) when loading libHSbase, while loading libHSrts. I didn't try also rebuilding libHSbase against libHSrts, because at that point the base library would be dependent on the RTS flavor, which we don't really want. It appears based on these tests that the Android dynamic loader only looks for missing symbols in a shared library in the dependencies of that library in a depth-first fashion, while the Linux ld.so seems to do something more like loading every (direct and indirect) dependency of the executable first and then resolving symbol references between them all at once. I didn't fully characterize the Android loader behavior though, and it's possible that if we could remove the references from libHSrts to libHSbase and libHSghc-prim, then we could list libHSrts first among the dependencies of an executable, and hopefully once libHSrts has been loaded, the loader would then use its symbols to resolve references when loading the libHSghc-prim and libHSbase libraries, even without those libraries having NEEDED entries for libHSrts. Removing the references from libHSrts to libHSbase/libHSghc-prim should be fairly mechanical if we can use constructors in the latter libraries (basically emulate dynamic linking by adding a global variable to libHSrts which is a struct holding the addresses of the base/ghc-prim symbols it needs, and have constructors in those libraries fill in those addresses on load). If that doesn't work, another possibility may be to statically link libHSrts (or whatever part of it we need) into the executable and export libHSrts's dynamic symbols so that they can be used by libHSghc-prim (or other Haskell libraries). I also haven't tested whether this kind of mutual recursion between an executable and its shared library dependencies works on Android. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10324> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8287: exploring calling convention changes and related engineering for 7.10
by GHC 25 Jan '16

25 Jan '16

#8287: exploring calling convention changes and related engineering for 7.10 ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Rocket Science | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I'm creating this as a master ticket for systematically exploring and benchmarking (possibly breaking) changes to the GHC calling convention. This work will initially focus on x86/x86_64, but may have larger scope. Goals: 1. if possible, improve performance systematically for code run on recent CPU micro architecture generations (eg sandybridge, haswell, and future extensions like Knights Landing and Skylake), ideally without pessimizing code on other or older x86_64 micro-architectures 2. Try to bring native and llvm codegens closer to feature parity (or at the very least, do not widen their capability gap) 3. a few other pieces too, will amend this ticket as ideas / plans clarify -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8287> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10433: Fix load/store barriers in pre-ARMv7 builds
by GHC 25 Jan '16

25 Jan '16

#10433: Fix load/store barriers in pre-ARMv7 builds -------------------------------------+------------------------------------- Reporter: | Owner: simonmar thoughtpolice | Status: new Type: bug | Milestone: 7.12.1 Priority: high | Version: Component: Runtime | Operating System: Unknown/Multiple System | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: arm | Related Tickets: #10244 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As pointed out in #10244 and Phab:D894, the fix we committed for this problem isn't 100% correct - from 753b156dc6b0c38b106c390952750fb800bf27e7: {{{ #elif arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_ARMv7) // TODO FIXME: This case probably isn't totally correct - just because we // use a pre-ARMv7 toolchain (e.g. to target an old Android device), doesn't // mean the binary won't run on a newer ARMv7 system - in which case it // needs a proper barrier. So we should rethink this // - Reid __asm__ __volatile__ ("" : : : "memory"); }}} This is a reminder to fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10433> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9149: Description of openFileBlocking is wrong
by GHC 25 Jan '16

25 Jan '16

#9149: Description of openFileBlocking is wrong ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The documentation states: ''Like openFile, but opens the file in ordinary blocking mode. This can be useful for opening a FIFO for reading: if we open in non-blocking mode then the open will fail if there are no writers, whereas a blocking open will block until a writer appears. '' but I think this is the wrong way around, and should be: ''Like openFile, but opens the file in ordinary blocking mode. This can be useful for opening a FIFO for writing: if we open in non-blocking mode then the open will fail if there are no readers, whereas a blocking open will block until a reader appears. '' -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8325: Pattern guards in anonymous functions
by GHC 25 Jan '16

25 Jan '16

#8325: Pattern guards in anonymous functions ------------------------------------+------------------------------------- Reporter: mcollis | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- In the course of a project, I had an idea that would allow less cumbersome use of cases in anonymous functions. Here's a simple example of what I'm proposing: {{{ (\x y | x > y -> x | otherwise -> something else) }}} Currently, the only way to accomplish this is with if() then ... else syntax or the use of the MultiWayIf and LambdaCase extensions. The syntax I've proposed here matches with existing anonymous function syntax and doesn't conflict with any other GHC syntax. This would greatly improve the readability of complex anonymous functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8325> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5