August 2015 - ghc-tickets

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 27 Aug '15

27 Aug '15

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: | Segmentation fault, segfault, long | input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Revisions: D1180 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => D1180 Comment: I've opened Phab:D1180 reintroducing the compile-time check. It would however, be nice to know what would need to happen to fix the RTS. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 27 Aug '15

27 Aug '15

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: | Segmentation fault, segfault, long | input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Simonmar, what do we want to do about this? IMHO we should at least reinstate the compile-time warning before 7.12. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9447: Add support for resizing `MutableByteArray#`s
by GHC 27 Aug '15

27 Aug '15

#9447: Add support for resizing `MutableByteArray#`s -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: Phab:D133 -------------------------------------+------------------------------------- This is motivated by #9281 which changes how memory is allocated, and gives rise to the need to be able to efficiently shrink or grow `MutableByteArray#`s before they're frozen into `ByteArray#` while retaining their original byte content to avoid a major bottle-neck. This ticket is for tracking/documenting all changes related to this new facility. Here's the current road-map: 1. Implement {{{#!hs shrinkMutableByteArray# :: MutableByteArray# s -> Int# -> State# s -> State# s resizeMutableByteArray# :: MutableByteArray# s -> Int# -> State# s -> (# State# s, MutableByteArray# s #) }}} (see Phab:D133) 2. As suggested by Johan, {{{#!hs getSizeofMutableByteArray# :: MutableByteArray# s -> State# s -> (# State# s Int# #) }}} This is similar in spirit to `numCapabilities` and `getNumCapabilities`. Add a deprecate pragma (or equivalent) for `sizeofMutableByteArray#`. Add a note to `sizeofMutableByteArray#` stating that it's unsafe in the presence of calls to resize-operations on the same MBA. 3. Submit patches to upstream libraries replacing calls to `sizeofMutableByteArray#` with `getSizeofMutableByteArray#` 4. Investigate how to provide in-place (zero-copy) growing of MBAs (step 1. only implements in-place shrinking). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9447> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #4879: Deprecate exports
by GHC 27 Aug '15

27 Aug '15

#4879: Deprecate exports -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: feature request | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: deprecate | warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10071 #2119 | Differential Revisions: Phab:D638 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: It would be nice to see this for 7.12. However, in order for that to happen we should have a specification. The patch here is nice, but I agree with Simon that we really want to have a single easy-to-follow description of how this feature is supposed to work. Bas, perhaps you could take this up? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4879#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10032: --with-system-libffi not working on Solaris
by GHC 27 Aug '15

27 Aug '15

#10032: --with-system-libffi not working on Solaris -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.11 System | Operating System: Solaris Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hello, an attempt to configure ghc-7.10.1-rc2 with: {{{ $ ./configure --with-gmp-includes=/usr/include/gmp/ --with-gmp- libraries=/usr/lib/ --with-system-libffi --with-ffi- includes=/usr/lib/libffi-3.0.9/include/ --with-ffi-libraries=/usr/lib/ }}} results in kind of broken distribution, since gmake test_bindist fails with: {{{ bindisttest/"install dir"/bin/runghc bindisttest/HelloWorld > bindisttest/output diff -U 1 bindisttest/output bindisttest/expected_output No differences encountered bindisttest/"install dir"/bin/ghc --make bindisttest/HelloWorld [1 of 1] Compiling Main ( bindisttest/HelloWorld.lhs, bindisttest/HelloWorld.o ) Linking bindisttest/HelloWorld ... bindisttest/HelloWorld > bindisttest/output diff -U 1 bindisttest/output bindisttest/expected_output No differences encountered bindisttest/"install dir"/bin/ghc-pkg check --no-user-package-db There are problems in package rts-1.0: library-dirs: @FFILibDir@ is a relative path which makes no sense (as there is nothing for it to be relative to). You can make paths relative to the package database itself by using ${pkgroot}. include-dirs: @FFIIncludeDir@ is a relative path which makes no sense (as there is nothing for it to be relative to). You can make paths relative to the package database itself by using ${pkgroot}. The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. rts-1.0 ghc-7.10.0.20150123 haskeline-0.7.2.0 terminfo-0.4.0.1 xhtml-3000.2.1 transformers-0.4.2.0 hoopl-3.10.0.2 bin-package-db-0.0.0.0 Cabal-1.22.1.0 binary-0.7.3.0 template-haskell-2.10.0.0 pretty-1.1.2.0 hpc-0.6.0.2 process-1.2.2.0 directory-1.2.2.0 unix-2.7.1.0 time-1.5.0.1 containers-0.5.6.2 bytestring-0.10.6.0 deepseq-1.4.0.0 array-0.5.0.1 filepath-1.3.1.0 base-4.8.0.0 integer-gmp-1.0.0.0 ghc-prim-0.3.1.0 gmake[1]: *** [test_bindist] Error 1 gmake: *** [test_bindist] Error 2 }}} Honestly speaking I must add that even gmake binary-dist was not without issue since this expected ffi headers to be located in rts/dist/build directory but they were obviously not there. I've copied them manually and then binary-dist was able to run. I'm not sure if this is Solaris specific issue or if this also affects other Unix(-like) OSes. I mark that for 7.11 (HEAD) since I'm not sure I'll have a time to address this issue for 7.10.1-rc3/fcs. The workaround is easy, just let ghc use its own copy of ffi library and not the system provided one. In the long term however, having ghc using system provided one is better. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10032> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8096: Add fudge-factor for performance tests run on non-validate builds
by GHC 27 Aug '15

27 Aug '15

#8096: Add fudge-factor for performance tests run on non-validate builds ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Since I'm not going to get around to this immediately, Trac'ifying for posterity: These tests have been doing better than expected in the nightlies for some while. {{{ Unexpected failures: perf/compiler T3064 [stat too good] (normal) perf/compiler T3294 [stat too good] (normal) perf/compiler T5642 [stat too good] (normal) perf/haddock haddock.Cabal [stat too good] (normal) perf/haddock haddock.base [stat too good] (normal) }}} Unfortunately, fixing them is not a simple matter of shifting the ranges up, since the tests only exceed expectations on a /perf/ build, so on a normal build such as 'quick', these tests all pass normally. I could bump up the upper bounds so that the builder stops bleating about them; perhaps we could do something more complicated where the expected performance depends on what level of optimization GHC was built with (but I don't know how to implement this.) ---- The problem with just widening the bounds to cover 2 different types of build is that it increases the chance that performance changes won't actually be noticed by thge person responsible. Having different bounds for different build configurations is a pain, because (a) the testsuite has to work out which set of bounds to use, and (b) you now have even more wobbly values to keep up-to-date. I think perhaps the best thing would be to add some sort of (per-test?) fudge factor for non-validate builds. That way validate will still find performance regressions, like it does today, but other builds are less likely to give false positives. (Igloo) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8096> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9315: Weird change in allocation numbers of T9203
by GHC 27 Aug '15

27 Aug '15

#9315: Weird change in allocation numbers of T9203 ------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- While trying to improve our handle on allocation numbers, I’m stuck with the test case T9203. On some machines, it allocates roughly 95747304 bytes (this includes travis and my laptop), on others 42946176 bytes (e.g. on the machine where I monitor benchmark performance). All machines are 64 bit Linux machines. The output of `-ddump-simpl`, `-ddump-stg` and `-ddump-cmm` is identical (up to variable names). Even `-ddump-asm` looks the same, besides some jump target reordering. The binary runs too small to get a heap profile. I’m a bit stuck here: What can be the cause for these differences? (BTW, if have an up-to-date GHC tree, can you report the number you get? Run `make -C testsuite VERBOSE=4 TEST=9203` for that.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9315> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

Re: [GHC] #7152: Add flag to configure that skips overwriting of symlinks on install
by GHC 27 Aug '15

27 Aug '15

#7152: Add flag to configure that skips overwriting of symlinks on install -------------------------------------+------------------------------------- Reporter: tibbe | Owner: | thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): See also this thread: https://mail.haskell.org/pipermail/glasgow-haskell- users/2015-July/026020.html "simultaneous ghc versions", which [http://www.haskell.org/pipermail/glasgow-haskell-users/ concluded] with: > > > Come to think of it, shouldn't ghc include this, instead of > > > everyone creating their own shell scripts by hand? > > I don't think so. This is usually done in the userland -- at least in > > GNU+Linux distributions. > More to the point, various distribution methods already include such things > (e.g. NixOS, Debian's alternatives system, MacPorts' "port select") plus > there are various mechanisms for implementing this on an ad-hoc basis (GNU > stow, environment modules, etc.). Downstream packages implementing their > own versions of this except speicifically on an opt-in basis (e.g. > configure option) tend to interfere with these and complicate inclusion > into existing package systems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7152#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3354: binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger)
by GHC 26 Aug '15

26 Aug '15

#3354: binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger) -------------------------------------+------------------------------------- Reporter: bkomuves | Owner: Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Build System | Version: 6.10.1 Resolution: wontfix | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * failure: => None/Unknown * resolution: => wontfix -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3354#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9932: GHC fails to build when cross compiling for mingw with the message "Threads not supported"
by GHC 26 Aug '15

26 Aug '15

#9932: GHC fails to build when cross compiling for mingw with the message "Threads not supported" -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Keywords: Cross compiling | Operating System: Linux Architecture: x86 | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: 9542 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'm trying to build a mingw32 cross compiler. I configured with `./configure --target=x86_64-x64-mingw32`, then I built with `make -j 1`. The build then fails with the message ` # error "Threads not supported"` followed by some other errors. (The last part of the make log is attached) To bypass #9542, I deleted the following lines from utils/hsc2hs/Main.hs: {{{ #if defined(__GLASGOW_HASKELL__) && !defined(BUILD_NHC) #include "../../includes/ghcconfig.h" #endif }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9932> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1