February 2013 - ghc-tickets

Re: [GHC] #3781: Improve inlining for local functions
by GHC 06 Feb '13

06 Feb '13

#3781: Improve inlining for local functions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.12.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by nfrisby): For the record, we re-discovered this while investigating a late lambda float. If we move forward with that, it would partially achieve the functionality of discounting FVs, as discussed in #7664 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3781#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3990: UNPACK doesn't unbox data families
by GHC 06 Feb '13

06 Feb '13

#3990: UNPACK doesn't unbox data families ---------------------------------+------------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: See #7647 re polymorphic unpacking. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3990#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7657: "unsafePerfromIO" typo in Safe Haskell user's guide
by GHC 06 Feb '13

06 Feb '13

#7657: "unsafePerfromIO" typo in Safe Haskell user's guide ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Documentation bug | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- In http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/safe-haskell.html it says: > This includes disallowing `unsafePerfromIO` [...] It should say `unsafePerformIO` instead. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7657> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5793: make nofib awesome
by GHC 05 Feb '13

05 Feb '13

#5793: make nofib awesome --------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: _|_ Component: NoFib benchmark suite | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: 5794 Related: | --------------------------------------+------------------------------------- Description changed by dterei: Old description: > Nofib is the standard tool GHC developers use to benchmark changes to the > compiler. Its a known fact though that nofib sucks. Its overall design is > OK but it's had no love and care for many years and has bittrotted into > near uselessness in a lot of situations. > > This task isn't to implement an awesome, really useful benchmark suite > for Haskell. That would be great but is a huge undertaking. This task is > just about making nofib useful again. > > The breakdown for this is something like: > > 1. Think and maybe fix nofib framework design. It has 'ways' which I > think correspond to compilation method but more in the sense of 'dynamic' > vs 'static', seems it may not suite being able to use ways for 'fasm' vs > 'fllvm'. There is also the concept of 'modes' which corresponds to > different benchmark input. So 'normal' and 'slow' for getting different > run-times. At moment no easy way to select which benchmark groups to run, > so may want to change that. I guess we should just decide, what knobs do > we want to be able to easily tweak, and see how well the current design > allows that. > > 2. Fixup the runtimes for benchmarks to be significant. (A lot of them > run in < 1 or < 0.1 seconds). I think trying to get all of them to run in > around 10s is a good target. > > 3. Above task is to fix normal but we may want to fixup slow as well and > perhaps add a 'fast' mode where benchmarks run in around 1 second. > > 4. Maybe add more benchmarks to the suite (text, bytestring, performance > regressions from ghc testsuite, vector....) New description: Nofib is the standard tool GHC developers use to benchmark changes to the compiler. Its overall design is OK but it's had no love and care for many years and has bittrotted such that it isn't useful in a lot of situations. This task is about making nofib useful again. The breakdown for this is something like: 1. Think and maybe fix nofib framework design. It has 'ways' which I think correspond to compilation method but more in the sense of 'dynamic' vs 'static', seems it may not suite being able to use ways for 'fasm' vs 'fllvm'. There is also the concept of 'modes' which corresponds to different benchmark input. So 'normal' and 'slow' for getting different run-times. At moment no easy way to select which benchmark groups to run, so may want to change that. I guess we should just decide, what knobs do we want to be able to easily tweak, and see how well the current design allows that. 2. Fixup the runtimes for benchmarks to be significant. (A lot of them run in < 1 or < 0.1 seconds). I think trying to get all of them to run in around 10s is a good target. 3. Above task is to fix normal but we may want to fixup slow as well and perhaps add a 'fast' mode where benchmarks run in around 1 second. 4. Maybe add more benchmarks to the suite (text, bytestring, performance regressions from ghc testsuite, vector....) -- -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5793#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7639: Fix installation issues with cross compiling + honour Stage1Only properly
by GHC 05 Feb '13

05 Feb '13

#7639: Fix installation issues with cross compiling + honour Stage1Only properly ----------------------------------+----------------------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Installing GHC failed | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- This patch fixes three problems that occur during a cross compile to embedded Linux (details below): 1. arm-ldu-linux-gnueabi-ghc-pkg gets a symlink but no wrapper script upon installation, and this causes the installation to break later when it tries to run it. 2. hp2ps doesn't get the prefix like the other commands do (i.e. arm-ldu- linux-gnueabi-ghc- is missing from the name of the executable). This is just for consistency. 3. The stage2 compiler is built when Stage1Only is set to YES (though it does not get installed). This makes the build take longer than it needs to. mk/build.mk: SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO INTEGER_LIBRARY = integer-simple Stage1Only = YES configure command: ./configure --target=arm-ldu-linux-gnueabi --prefix=/usr/local/ghc-ldu -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7639> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #7656: qsemn001 randomly fails on OS X x86
by GHC 04 Feb '13

04 Feb '13

#7656: qsemn001 randomly fails on OS X x86 ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ `qsemn001` randomly fails on OS X x86 (119 times out of 1000), but never on Linux amd64 (tried 1000 times). e.g.: {{{ $ make CLEANUP=1 TEST=qsemn001 WAY=normal python ../../../testsuite/driver/runtests.py -e ghc_compiler_always_flags ="'-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts '" -e ghc_debugged=False -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e ghc_with_dynamic=1 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=1 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e ghc_dynamic_by_default=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=False -e darwin=True -e in_tree_compiler=True -e clean_only=False --rootdir=. --config=../../../testsuite/config/ghc -e 'config.confdir="../../../testsuite/config"' -e 'config.compiler="/Users/ian/ghc/git/val32/inplace/bin/ghc-stage2"' -e 'config.ghc_pkg="/Users/ian/ghc/git/val32/inplace/bin/ghc-pkg"' -e 'config.hp2ps="/Users/ian/ghc/git/val32/inplace/bin/hp2ps"' -e 'config.hpc="/Users/ian/ghc/git/val32/inplace/bin/hpc"' -e 'config.gs="gs"' -e 'config.platform="i386-apple-darwin"' -e 'config.os="darwin"' -e 'config.arch="i386"' -e 'config.wordsize="32"' -e 'default_testopts.cleanup="1"' -e 'config.timeout=int() or config.timeout' -e 'config.timeout_prog="../../../testsuite/timeout/install- inplace/bin/timeout"' -e 'config.exeext=""' -e 'config.top="/Users/ian/ghc/git/val32/testsuite"' \ --only=qsemn001 \ \ --way=normal \ \ \ Timeout is 300 Found 6 .T files... Beginning test run at Sun Feb 3 21:52:50 GMT 2013 ====> Scanning ./all.T ====> Scanning ./Concurrent/all.T ====> Scanning ./IO/all.T ====> Scanning ./Numeric/all.T ====> Scanning ./System/all.T ====> Scanning ./Text.Printf/all.T =====> qsemn001(normal) 69 of 156 [0, 0, 0] cd . && '/Users/ian/ghc/git/val32/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o qsemn001 qsemn001.hs >qsemn001.comp.stderr 2>&1 cd . && ./qsemn001 </dev/null >qsemn001.run.stdout 2>qsemn001.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: test semn test semn2 Stderr: qsemn001: "acb" /= "abc" *** unexpected failure for qsemn001(normal) OVERALL SUMMARY for test run started at Sun Feb 3 21:52:50 GMT 2013 156 total tests, which gave rise to 1068 test cases, of which 0 caused framework failures 1067 were skipped 0 expected passes 0 had missing libraries 0 expected failures 0 unexpected passes 1 unexpected failures Unexpected failures: . qsemn001 [bad exit code] (normal) }}} The actual failure varies: {{{ $ grep "qsemn001:" out | sort | uniq -c 30 qsemn001: "acb" /= "abc" 34 qsemn001: "ba" /= "ab" 55 qsemn001: "bac" /= "abc" }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7656> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7646: resource busy (file is locked) with multi-threaded file ops
by GHC 04 Feb '13

04 Feb '13

#7646: resource busy (file is locked) with multi-threaded file ops ----------------------------------------+----------------------------------- Reporter: StefanWehr | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- The sample program attached creates 10 worker threads, each of which takes a different file name. Each worker thread then writes the file, reads the file, writes the file and so on. File operations use *strict IO*. When compiled without `-threaded` everything is ok, that is, the program goes on forever without any error messages. But with `-threaded`, the program quickly fails with `ERROR in worker 4: 4: openBinaryFile: resource busy (file is locked)`. Tested under Mac OSX 10.8.2 and Linux. Tested with both GHC 7.6.1 and 7.6.2. I could reproduce the bug without +RTS -N -RTS and with this RTS option. A colleague of mine reports that it needs +RTS -N2 -RTS to reproduce the bug. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7646> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #709: "Fixup too large" error with -fasm on PowerPC
by GHC 04 Feb '13

04 Feb '13

#709: "Fixup too large" error with -fasm on PowerPC ----------------------------------+----------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.8.1 Component: Compiler (NCG) | Version: 7.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: powerpc Failure: Building GHC failed | Difficulty: Moderate (less than a day) Testcase: | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Changes (by simonmar): * status: patch => closed * resolution: => fixed Comment: pushed, thanks! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/709#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #709: "Fixup too large" error with -fasm on PowerPC
by GHC 04 Feb '13

04 Feb '13

#709: "Fixup too large" error with -fasm on PowerPC ----------------------------------+----------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: low | Milestone: 6.8.1 Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: powerpc Failure: Building GHC failed | Difficulty: Moderate (less than a day) Testcase: | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Comment(by marlowsd@…): commit 8a6e330ac9c2dde11b0641dce69bb809af6a494c {{{ Merge: ca5d15a... 3cedbfb... Author: Simon Marlow <marlowsd(a)gmail.com> Date: Mon Feb 4 11:19:33 2013 +0000 Merge commit '3cedbfb49996da2f029b4a84ca39f4d21f309813' * commit '3cedbfb49996da2f029b4a84ca39f4d21f309813': AsmCodeGen.NcgImpl.ncgMakeFarBranches should take account of info tables (#709) Move AsmCodeGen.makeFarBranches to PPC.Instr (#709) compiler/nativeGen/AsmCodeGen.lhs | 47 ++++--------------------------------- compiler/nativeGen/PPC/Instr.hs | 42 ++++++++++++++++++++++++++++++++- 2 files changed, 46 insertions(+), 43 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/709#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #709: "Fixup too large" error with -fasm on PowerPC
by GHC 04 Feb '13

04 Feb '13

#709: "Fixup too large" error with -fasm on PowerPC ----------------------------------+----------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: low | Milestone: 6.8.1 Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: powerpc Failure: Building GHC failed | Difficulty: Moderate (less than a day) Testcase: | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Comment(by pho@…): commit 3cedbfb49996da2f029b4a84ca39f4d21f309813 {{{ Author: PHO <pho(a)cielonegro.org> Date: Thu Dec 20 08:13:37 2012 +0900 AsmCodeGen.NcgImpl.ncgMakeFarBranches should take account of info tables (#709) We have to reduce the maximum number of instructions to jump over depending on the number of info tables in a proc. compiler/nativeGen/AsmCodeGen.lhs | 8 ++++---- compiler/nativeGen/PPC/Instr.hs | 16 +++++++++------- 2 files changed, 13 insertions(+), 11 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/709#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0