- ghc-devs - Haskell.org

Cabal-1.18.1.3 and cabal-install-1.18.0.3 releases made
by Johan Tibell 04 Mar '14

04 Mar '14

Hi, I've just made a release of Cabal/cabal-install, for the benefit of GHC 7.8. People have in the past expressed a desire for having prebuilt binaries of cabal-install. I'm happy to upload such binaries if people send them to me. Please specify for which arch/OS the binary is built. -- Johan

1 0

git.haskell.org misbehaving?
by Simon Peyton Jones 04 Mar '14

04 Mar '14

I'm getting fatal: read error: Connection reset by peer when I try git pull from git://git.haskell.org/ghc.git Works ok if I try http://git.haskell.org/ghc.git This happens from both Windows and Linux. Anyone know what is going on? Simon

2 2

Re: What does the DWARF information generated by your GHC branch look like?
by Johan Tibell 03 Mar '14

03 Mar '14

On Fri, Feb 28, 2014 at 3:15 PM, Peter Wortmann <scpmw(a)leeds.ac.uk> wrote: > Johan Tibell wrote:> Lets try to get our name standardized and pushed into > GDB. It's > > hopefully as simple as sending an email to the GDB devs. > > Strictly speaking standardization is the job of the DWARF format > committee, which seem to currently be in the process of specifying > DWARF5[1]. Not quite sure we have a strong enough case, but if we wanted > our own language ID these would probably be the right people to ask. > I just emailed the DWARF discussion mailing list to sort this out. -- Johan

5 10

Runtime error using LLVM bitcode execution
by Benzinger, Ralph 03 Mar '14

03 Mar '14

Hello, My apologies in advance if this mailing list is not the appropriate address for posting my problem with the GHC runtime, but it seemed like the best option on the GHC home page. I'm trying to execute standalone Haskell functions exported via FFI and compiled as LLVM bitcode. Unfortunately, all my efforts yield the following runtime error: lu003107:~/hs-bitcode> ./bce_so hsallinone.bc hs_init complete hs_add_root complete hsallinone: internal error: stg_ap_p_ret (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug 0 bce_so 0x0000000000d6b310 1 bce_so 0x0000000000d6b53b 2 bce_so 0x0000000000d6ba1c 3 libpthread.so.0 0x00007f7683298800 4 libc.so.6 0x00007f7682592b35 gsignal + 53 5 libc.so.6 0x00007f7682594111 abort + 385 6 libHSrts-ghc7.6.3.so 0x00007f7683f6ca21 rtsFatalInternalErrorFn + 177 7 libHSrts-ghc7.6.3.so 0x00007f7683f6cce1 barf + 145 8 libHSrts-ghc7.6.3.so 0x00007f7683f8a24a stg_ap_p_info + 130 Stack dump: 0. Program arguments: ./bce_so hsallinone.bc Aborted This is what I do: I have a function hfun.hs that exports a function foreign export ccall hfun :: CInt -> CInt and a wrapper cmain.c that calls this function: #include <HsFFI.h> #include "hfun_stub.h" extern void __stginit_HFun(void); #include <stdio.h> int main(int argc, char *argv[]) { hs_init(&argc, &argv); printf("hs_init complete\n"); hs_add_root(__stginit_HFun); printf("hs_add_root complete\n"); int i = hfun(42); printf("hfun(42) = %d\n", i); hs_exit(); return 0; } To generate a callable bitcode file I use these commands: $ ghc -S -keep-llvm-files -keep-tmp-files hfun.hs $ llvm-as hfun.ll $ cp /tmp/... hfun_stub.c $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include hfun_stub.c $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include cmain.c $ llvm-link cmain.bc hfun_stub.bc hfun.bc -o hsallinone.bc My main program "bce_so" loads the linked bitcode and feeds it to the LLVM execution engine. All required Haskell runtime libraries are linked dynamically against bce_so. Could you kindly provide some insight on whether this runtime error is due to a bug with GHC (unlikely) or rather some negligence in my setup? Or does the issue highlight some principal limitation in my (admittedly somewhat naive) approach of using LLVM -- threading support, maybe? Note that compiling hfun.hs/cmain.c into a .so and executing everything natively using ldload() works flawlessly. Regards Ralph -- Pflichtangaben/Mandatory Disclosure Statements: http://www.sap.com/company/legal/impressum.epx Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank. This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

4 7

RE: [commit: packages/base] ghc-7.8: Workaround failed constant-folding for zeroBits (591142f)
by Simon Peyton Jones 01 Mar '14

01 Mar '14

Herbert would you like to open a ticket, saying what's wrong and how to reproduce it? Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 01 March 2014 13:53 | To: ghc-commits(a)haskell.org | Subject: [commit: packages/base] ghc-7.8: Workaround failed constant- | folding for zeroBits (591142f) | | Repository : ssh://git@git.haskell.org/base | | On branch : ghc-7.8 | Link : | http://ghc.haskell.org/trac/ghc/changeset/591142f8aead4c28bdaa5656d79e6 | dc38273e685/base | | >--------------------------------------------------------------- | | commit 591142f8aead4c28bdaa5656d79e6dc38273e685 | Author: Herbert Valerio Riedel <hvr(a)gnu.org> | Date: Sat Mar 1 14:45:48 2014 +0100 | | Workaround failed constant-folding for zeroBits | | For some reason GHC fails to constant fold `zeroBits :: Int` and | `zeroBits :: Integer`; `ghc -show-iface` shows | | $fBitsInt_$czeroBits :: GHC.Types.Int | {- Strictness: m, | Unfolding: (GHC.Types.I# (GHC.Prim.andI# 1 (GHC.Prim.notI# | 1))) -} | | Otoh, constant-folding works as expected, reducing `zeroBits` to 0 | constant | for the other integer-types (= {Word,Int}{8,16,32,64}` and `Word`). | So this | quickfix is actually just treating the symptom rather than the | cause. | | Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> | (cherry picked from commit | 2dbfcd70e53845d9119389cecc88411b47b70644) | | | >--------------------------------------------------------------- | | 591142f8aead4c28bdaa5656d79e6dc38273e685 | Data/Bits.hs | 3 +++ | 1 file changed, 3 insertions(+) | | diff --git a/Data/Bits.hs b/Data/Bits.hs | index e771624..28cd024 100644 | --- a/Data/Bits.hs | +++ b/Data/Bits.hs | @@ -363,6 +363,8 @@ instance Bits Int where | {-# INLINE bit #-} | {-# INLINE testBit #-} | | + zeroBits = 0 | + | bit = bitDefault | | testBit = testBitDefault | @@ -437,6 +439,7 @@ instance Bits Integer where | | otherwise = shiftRInteger x (negateInt# i#) | testBit x (I# i) = testBitInteger x i | | + zeroBits = 0 | bit = bitDefault | popCount = popCountDefault | | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

Ready for Cabal release now?
by Johan Tibell 01 Mar '14

01 Mar '14

Hi, I know we're waiting until the last minute before the Cabal release that need to go into 7.8. Should I make that release now? -- Johan

3 7

Cabal-1.18.1.3 and cabal-install-1.18.0.3 RCs
by Johan Tibell 01 Mar '14

01 Mar '14

Hi all, I've uploaded release candidates for Cabal-1.18.1.3 (to be shipped with GHC 7.8) and cabal-install-1.18.0.3. You can install the RCs like so: cabal install http://johantibell.com/files/Cabal-1.18.1.3-rc.tar.gz http://johantibell.com/files/cabal-install-1.18.0.3-rc.tar.gz It's especially important that Cabal-1.18.1.3 gets some testing on OS X using GHC 7.8, as there's a change in how linking is done (see https://github.com/haskell/cabal/issues/1660) These RCs correspond to commit d310d87c2c445f52987169a2ce4da03c14070918 on the 1.18 branch in the cabal repo [1]. Note that both Cabal and cabal-install are released from the same repo. If you want to check which commits are new since last release run: git log Cabal-v1.18.1.2.. -- Cabal/ git log cabal-install-v1.18.0.2 -- cabal-install/ -- Johan 1. https://github.com/haskell/cabal

1 0

Re: first version of RC2 has problems with lack of dynamic libraries at least on the Mac
by George Colpitts 28 Feb '14

28 Feb '14

corrected subject line On Thu, Feb 27, 2014 at 7:47 PM, George Colpitts <george.colpitts(a)gmail.com>wrote: > Hi > > After installing the first version of RC2 I ran into the following problem > > cabal install vector > Resolving dependencies... > Configuring vector-0.10.9.1... > ... > [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( > Data/Vector/Fusion/Stream/Monadic.hs, > dist/build/Data/Vector/Fusion/Stream/Monadic.o ) > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Loading package primitive-0.5.2.1 ... <command line>: can't load .so/.DLL > for: libHSprimitive-0.5.2.1.dylib (dlopen(libHSprimitive-0.5.2.1.dylib, 9): > image not found) > > There seems to be a general problem that the install did not produce any > dynamic libraries at least on the Mac: > > ls /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/*/lib > /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/cpphs-1.18.2/lib: > HScpphs-1.18.2.o Language Text libHScpphs-1.18.2.a libHScpphs-1.18.2_p.a > > > /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hashable-1.2.1.0/lib: > Data HShashable-1.2.1.0.o libHShashable-1.2.1.0.a > libHShashable-1.2.1.0_p.a > > > /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hscolour-1.20.3/lib: > HShscolour-1.20.3.o Language libHShscolour-1.20.3.a > libHShscolour-1.20.3_p.a > > > /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/primitive-0.5.2.1/lib: > Control HSprimitive-0.5.2.1.o libHSprimitive-0.5.2.1.a > Data include libHSprimitive-0.5.2.1_p.a > > /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/syb-0.4.1/lib: > Data Generics HSsyb-0.4.1.o libHSsyb-0.4.1.a libHSsyb-0.4.1_p.a > > /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/text-1.1.0.0/lib: > Data HStext-1.1.0.0.o libHStext-1.1.0.0.a libHStext-1.1.0.0_p.a > > > /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/unordered-containers-0.2.3.3/lib: > Data libHSunordered-containers-0.2.3.3.a > HSunordered-containers-0.2.3.3.o libHSunordered-containers-0.2.3.3_p.a >

3 9

Clean build ASSERT failure
by Simon Peyton Jones 28 Feb '14

28 Feb '14

I'm seeing this assertion failure when using the stage1 compiler (built with -DDEBUG) to compile the stage2 compiler. Is anyone else seeing this? Simon ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 7.9.20140227 for i386-unknown-mingw32): ASSERT failed! file compiler\basicTypes\Demand.lhs line 445 3 [U] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug compiler/ghc.mk:642: recipe for target 'compiler/stage2/build/ParserCore.o' failed

2 1

What does the DWARF information generated by your GHC branch look like?
by Johan Tibell 28 Feb '14

28 Feb '14

Hi! (I've CCed ghc-devs on this email, as I think the question is of general interest.) I enjoyed reading your paper [1] and I have some questions. * What does the generated DWARF information look like? For example, will you fill in the .debug_line section so that standard tools like "perf report" and gprof can be used on Haskell code? Code pointers would be appreciated. * Does your GHC allow DWARF information to be generated without actually using any of the RTS (e.g. eventlog) machinery? This would be very useful if you want to use "report record/report" only, in order to achieve minimal overhead when that matters. Another way to ask the same question, do you have a ghc -g flag that has no implication for the runtime settings? * Do you generate DW_TAG_subprogram sections in the .debug_info section so that other tools can figure out the name of Haskell functions? Cheers, Johan 1. "Causality of Optimized Haskell: What is burning our cycles?" http://eprints.whiterose.ac.uk/76448/

2 1