October 2014 - ghc-tickets

[GHC] #9616: Incorrect numbers from HpcMarkup.markup_plugin
by GHC 02 Oct '14

02 Oct '14

#9616: Incorrect numbers from HpcMarkup.markup_plugin -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Incorrect hour) | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `showBigNum` in the `openTick` function accidentally puts 0s in the wrong place when formatting large numbers. 12345 will be formatted as 120,345 instead of 012,345. The correct answer is probably to add some locale- specific numeric formatting stuff somewhere, but until then, I'll just fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9616> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 02 Oct '14

02 Oct '14

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Runtime | than a day) performance bug | Blocked By: Test Case: | Related Tickets: #8598 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: nomeata => Comment: I think the conclusion was that Nested CPR was not worth it. The branch is still there if someone wants to pick it up. Unassigning. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7490: ghc-stage1 panic when building a cross-compiler or cross-building a compiler
by GHC 02 Oct '14

02 Oct '14

#7490: ghc-stage1 panic when building a cross-compiler or cross-building a compiler -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: worksforme | Keywords: cross-compilation Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => worksforme -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7490#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7984: hsc2hs --cross-compile does not handle negative #enum
by GHC 02 Oct '14

02 Oct '14

#7984: hsc2hs --cross-compile does not handle negative #enum -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: hsc2hs | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by singpolyma): * status: new => patch * difficulty: => Unknown Comment: https://phabricator.haskell.org/D301 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7984#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9656: Process and thread init/deinit hooks for C libraries
by GHC 02 Oct '14

02 Oct '14

#9656: Process and thread init/deinit hooks for C libraries -------------------------------------+------------------------------------- Reporter: 3noch | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: FFI | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Haskell's FFI for C seems geared toward C as an optimization. But in many cases, we use the C FFI merely hook into a 3rd-party library. In this case, the FFI seems a bit lacking. In my specific case, I want to link against libmysqlclient_r to perform MySQL queries. However, the library requires global init and deinit. Worse, it requires init/deinit for *each* thread that wishes to interact with its API. This type of thing is not entirely uncommon among C libraries. Of course, we can bend over backward to inter-operate with such libraries (e.g. wrap the C API with our own versions that ensure proper initialization), but the process is painstaking and often requires decent performance overhead. I would like to request some sort of hook registration where the FFI can be used to accomplish these common tasks. Perhaps it's too difficult, but it doesn't hurt to ask! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9656> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7942: aarch64 support in ghc
by GHC 02 Oct '14

02 Oct '14

#7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by juhpetersen): * cc: juhp@… (removed) * cc: petersen@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9655: Do not UNPACK strict fields that are very wide
by GHC 02 Oct '14

02 Oct '14

#9655: Do not UNPACK strict fields that are very wide -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- John Lato [http://www.haskell.org/pipermail/ghc- devs/2014-September/006473.html writes} (a propos of another discussion): This is possibly unrelated, but the setup seems almost identical to a very similar problem we had in some code, i.e. very long compile times (6+ minutes for 1 module) and excessive memory usage when compiling generic serialization instances for some data structures. In our case, I also thought that INLINE functions were the cause of the problem, but it turns out they were not. We had a nested data structure, e.g. {{{ > data Foo { fooBar :: !Bar, ... } }}} with `Bar` a very wide product type (~150 fields). Even when we explicitly NOINLINE'd the function that serialized Bar, GHC still created a very large helper function of the form: {{{ > serialize_foo :: Int# -> Int# -> ... }}} where the arguments were the unboxed fields of the Bar structure, along with the other fields within Foo. It appears that even though the serialization function was NOINLINE'd, it simply created a Builder, and while combining the Builder's ghc saw the full structure. Our serializer uses blaze, but perhaps Binary's builder is similar enough the same thing could happen. Anyway, in our case the fix was to simply remove the bang pattern from the 'fooBar' record field. So the question is: '''should GHC auto-unpack a strict argument of a data constructor, if the argument type is a very wide product type?'''. I think "no". The unpacking can save allocation (by allocating one object instead of two) but it can also increase it (at a pattern matching site). So it should probably only happen automatically for sufficiently narrow types. How narrow? We need some testing, but my guess is three or four words. Maybe a flag to set the size? (Maybe not worth the pain.) Incidentally, the choice can already be manually controlled with `{-# UNPACK #-}` and `{-# NOUNPACK #-}` pragmas. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9655> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7942: aarch64 support in ghc
by GHC 02 Oct '14

02 Oct '14

#7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by juhpetersen): (another +1 for NCG for arm and arm64! :-) Likely I should open a new ticket, but I am having trouble with installing ghc-7.8.3 plus above patch on Fedora 21 ARM64 (aarch64). {{{ "inplace/bin/ghc-cabal" copy libraries/haskell2010 dist-install "strip" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' 'v dyn ' Installing library in /builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/haskell2010-1.1.2.0 "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg" --force --global-package-db "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/package.conf.d" update rts/dist/package.conf.install Reading package info from "rts/dist/package.conf.install" ... done. rts-1.0: Warning: library-dirs: /usr/lib64/ghc-7.8.3/rts-1.0 doesn't exist or isn't a directory rts-1.0: Warning: include-dirs: /usr/lib64/ghc-7.8.3/include doesn't exist or isn't a directory rts-1.0: cannot find any of ["libHSrts.a","libHSrts.p_a","libHSrts- ghc7.8.3.so","libHSrts-ghc7.8.3.dylib","HSrts-ghc7.8.3.dll"] on library path (ignoring) "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' NO Warning: cannot determine version of /builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg : "" Registering ghc-prim-0.3.1.0... "inplace/bin/ghc-cabal" register libraries/integer-gmp dist-install "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' NO Warning: cannot determine version of /builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg : "" ghc-cabal: Installed package ID not registered: "ghc-prim-0.3.1.0-inplace" ghc.mk:901: recipe for target 'install_packages' failed Makefile:64: recipe for target 'install' failed make[1]: *** [install_packages] Error 1 make: *** [install] Error 2 }}} The problem seems to be that the installed (dynlinked) ghc-pkg does no output anything! (eg "ghc-pkg --version" returns "", same for --help.) When I try the built binaries I find that ghc-7.8.3/utils/ghc-pkg/dist/build/tmp/ghc-pkg (which is statically linked) works normally (ie it outputs --help and --version) whereas $DESTDIR/$libdir/ghc-7.8.3/bin/ghc-pkg gives no output on stdout! Maybe I should try installing statically linked ghc and see if that makes difference. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7490: ghc-stage1 panic when building a cross-compiler or cross-building a compiler
by GHC 01 Oct '14

01 Oct '14

#7490: ghc-stage1 panic when building a cross-compiler or cross-building a compiler -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: cross-compilation Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by singpolyma): This is not longer happening for me. I think it might be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7490#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7998: Stage1Only does not work
by GHC 01 Oct '14

01 Oct '14

#7998: Stage1Only does not work -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by singpolyma): * status: new => closed * difficulty: => Unknown * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7998#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0