March 2014 - ghc-devs

Standalone Deriving, GND and roles in 7.8.1-rc2
by Sergei Trofimovich 06 Mar '14

06 Mar '14

Hello! Trying to build random packages with fresh ghc-7.8.1-rc2 I've come up with a strange bit: https://github.com/trofi/Idris-dev/commit/9f93122ba1aa075c2fa1555fea68a6c40… Is it an intended behaviour that deriving instance Parsing IdrisInnerParser capable of doing more, than newtype IdrisInnerParser a = IdrisInnerParser { runInnerParser :: Parser a } deriving (Parsing) ? Thanks! -- Sergei

3 4

Strange file
by Simon Peyton Jones 06 Mar '14

06 Mar '14

What is this file? nofib/real/HMMS/lib/haskell/Builtin.hi It's a mystery! Can we delete it? Simon

2 1

GHC 7.8 RC2: ARM cross compiler (LLVM Error)
by Luke Clifton 05 Mar '14

05 Mar '14

Hi, I successfully compiled a native GHC 7.8 RC2 from the source distribution. I now want to create an GHC cross compiler targeting ARM. So I do a ./configure --target=arm-linux-gnueabi --with-gcc=arm-linux-gnueabi-gcc (I don't know why I have to explicitly supply the GCC, documentation seems to suggest that it would pick that up based on target, which it seems to do for ld.) I then make a copy of the mk/build.mk.sample and place it at mk/build.mk and uncomment the BuildFlavour = quick-cross line. At this point I run make and it goes along happily until... "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -package-name haskeline-0.7.1.2 -hide-all-packages -i -ilibraries/haskeline/. -ilibraries/haskeline/dist-install/build -ilibraries/haskeline/dist-install/build/autogen -Ilibraries/haskeline/dist-install/build -Ilibraries/haskeline/dist-install/build/autogen -Ilibraries/haskeline/includes -optP-DUSE_GHC_ENCODINGS -optP-DTERMINFO -optP-include -optPlibraries/haskeline/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package bytestring-0.10.4.0 -package containers-0.5.4.0 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package terminfo-0.4.0.0 -package transformers-0.3.0.0 -package unix-2.7.0.1 -Wall -XHaskell98 -XForeignFunctionInterface -XRank2Types -XFlexibleInstances -XTypeSynonymInstances -XFlexibleContexts -XExistentialQuantification -XScopedTypeVariables -XGeneralizedNewtypeDeriving -XMultiParamTypeClasses -XOverlappingInstances -XUndecidableInstances -XCPP -XDeriveDataTypeable -XPatternGuards -O -fllvm -no-user-package-db -rtsopts -odir libraries/haskeline/dist-install/build -hidir libraries/haskeline/dist-install/build -stubdir libraries/haskeline/dist-install/build -c libraries/haskeline/./System/Console/Haskeline/Command/History.hs -o libraries/haskeline/dist-install/build/System/Console/Haskeline/Command/History.o LLVM ERROR: .Lbase_GHCziChar_chr2_info$alias: Target doesn't support aliases to declarations libraries/haskeline/ghc.mk:4: recipe for target 'libraries/haskeline/dist-install/build/System/Console/Haskeline/Command/History.o' failed make[1]: *** [libraries/haskeline/dist-install/build/System/Console/Haskeline/Command/History.o] Error 1 Makefile:64: recipe for target 'all' failed make: *** [all] Error 2 Here is my setup. - The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228 - arm-linux-gnueabi-gcc (GCC) 4.7.3 - LLVM 3.4 Is this me being silly, or is it a real problem? If it is a real problem then I can file a ticket. If there is anything I can do to help try and get GHC cross compiling for ARM I would gladly do what I can. Regards, Luke

1 0

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