- ghc-tickets - Haskell.org

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

03 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 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: 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 02 Oct '14

02 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

[GHC] #9546: filterM is not a good consumer for list fusion
by GHC 02 Oct '14

02 Oct '14

#9546: filterM is not a good consumer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This one shouldn't cause any wonkiness; it just updates `filterM` to fuse is much the same way `mapM` does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9546> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9502: mapAccumL does not participate in foldr/build fusion
by GHC 02 Oct '14

02 Oct '14

#9502: mapAccumL does not participate in foldr/build fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This can probably be fixed in much the same way as `scanl`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9502> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9434: GHC.List.reverse does not fuse
by GHC 02 Oct '14

02 Oct '14

#9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | 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: -------------------------------------+------------------------------------- As Edward Kmett speculated could be the case a couple months ago, Joachim Breitner's call arity analysis makes the Prelude version of `reverse` better than GHC's version. It's less clear to me whether it's beneficial to wrap it in `build`, but I think the answer is ''probably'' yes, based on the fact that doing so turns `foldr c n $ reverse xs` into `foldl (flip c) n xs`. {{{#!hs {-# INLINE reverse #-} reverse :: [a] -> [a] reverse xs = build $ \c n -> foldl (\a x -> x `c` a) n xs }}} This simplifies to {{{#!hs Rec { poly_go_r2uL poly_go_r2uL = \ @ a_a2nn ds_a2xO eta_Xh -> case ds_a2xO of _ { [] -> eta_Xh; : y_a2xT ys_a2xU -> poly_go_r2uL ys_a2xU (: y_a2xT eta_Xh) } end Rec } reverse reverse = \ @ a_a2nn eta_B1 -> poly_go_r2uL eta_B1 ([]) }}} which looks about the same as the current version in GHC.List. Behold the beauty when it is applied to an unfold (with a fusion-friendly version of `unfoldr`): {{{#!hs testReverseUnfoldr f q0 = reverse (unfoldr f q0) }}} simplifies to {{{#!hs testReverseUnfoldr testReverseUnfoldr = \ @ a_a2w3 @ b_a2w4 f_a2mn q0_a2mo -> letrec { go_a1QX go_a1QX = \ b1_a1Hy eta_B1 -> case f_a2mn b1_a1Hy of _ { Nothing -> eta_B1; Just ds_d2d8 -> case ds_d2d8 of _ { (a1_a1Hz, new_b_a1HA) -> go_a1QX new_b_a1HA (: a1_a1Hz eta_B1) } }; } in go_a1QX q0_a2mo ([]) }}} This looks exactly like a hand-written `unfoldl`! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9434> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17