- ghc-devs - Haskell.org

Segfault when using integer-simple
by Stephen Paul Weber 17 Jun '13

17 Jun '13

This may not be integer-simple, but that's my immediate suspicion. The following two programs crash with SIGSEGV and core dump when run on my BB10 device after being cross-compiled with my GHC-to-QNXNTO-ARM cross-compiling GHC: > module Main (main) where > > import Data.Bits > import Data.ByteString > import qualified Data.ByteString.Char8 as C8 > > os2ip :: ByteString -> Integer > os2ip = foldl' (\a b -> (256 * a) .|. (fromIntegral b)) 0 > > main :: IO () > main = do > print $ os2ip x > where > x = C8.pack "\NUL\STX\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\NUL\ETX\SOH\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255" --- > module Main (main) where > > main :: IO () > main = print 169821641172389640937095636777672117931888945045504182713271897430274187839083732143233634367563316254925040331580602942790529924419031237257992694047545188803054325440702792009735658578224936744314329623399862853427161588994478038000957583036049445212750560294647972107700330648403394932373528288706138101730866129542001812796094504052779945357555018210304989340497464935845180607042646690920787035715174921382511732745931975718868480005317353569848454618331425749699355019762926384123909468814180690222898222556785716853422930906736084397064171894642825018414586574929919999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 --- So, it seems to be a problem with forcing very large integers. I'm not sure if this is my integer-simple build, integer-simple in general, or something strange in the way I built GHC. Can one of the people working on Android and/or Raspberry Pi ports try this code out and let me know if it works for you? I'll try to do a native (non-cross-compile) build of GHC with integer-simple as well, to test this on. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

3 5

shared libraries for profiling
by Kazu Yamamoto 17 Jun '13

17 Jun '13

Hi, I seems to me that shared libraries for profiling are not installed. For example, let's see the base library: % cd lib/ghc-7.7.20130616/base-4.7.0.0 % ls -1 libHSbase* libHSbase-4.7.0.0.a libHSbase-4.7.0.0-ghc7.7.20130616.so* libHSbase-4.7.0.0_p.a A static library for profiling is installed, but there is not a corresponding dynamic library. I'm suffering from this because I cannot take profiling for my program with GHC head. Is this a bug? --Kazu

1 0

CPP macro to determine GHCi presence?
by Stephen Paul Weber 15 Jun '13

15 Jun '13

Trying to cross-build the vector package I get: > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 7.7.20130123 for arm-unknown-nto-qnx): > Cant do annotations without GHCi > {Data/Vector/Fusion/Stream/Monadic.hs:104:19-33} > base:GHC.Exts.ForceSpecConstr{d r2Qv} This is because the source uses a feature that cannot be supported in cross-compilation. The problematic line, however, can easily be removed. It would be very useful to have a CPP macro defined by GHC that can be used to enable/disable these sorts of features. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

1 0

spam on the wiki?
by Nicolas Frisby 14 Jun '13

14 Jun '13

I've yet to fully comprehend the build system, but I'm pretty sure these links are not related. http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking?action=diff&versi…

3 6

exprType and existentials
by Andrew Farmer 13 Jun '13

13 Jun '13

Calling `exprType` on: case enumFromStepN Int $fNumInt (I# 1) (I# 1) x of wild Stream s1 ostep t ds1 -> Left s1 ((Int, (Int, Int)), s1) t gives: Either s1 ((Int, (Int, Int)), s1) Which is problematic, as the type variable 's1' is unbound outside of the alternative RHS! Unfolding the scrutinee and case-reducing gives: Left (Int, Int) ((Int, (Int, Int)), (Int, Int)) ((,) Int Int (I# 1) (case x of n1 I# ipv ? n1)) Calling `exprType` now gives: Either (Int, Int) ((Int, (Int, Int)), (Int, Int)) That is, `s1` was `(Int, Int)` in this case. Is it expected that `exprType` behaves this way? Or should I file a ticket? I realize the type of the scrutinee (in this case Stream Int) gives no indication as to the existential type... and I'm not sure how you would get it without making exprType do some kind of evaluation, but it would be nice if exprType at least failed if it doesn't have enough information... Andrew

2 1

Linking to changeset on wiki
by Geoffrey Mainland 13 Jun '13

13 Jun '13

What is the magical incantation for linking to a changeset in a bug report/on the trac wiki? i can't for the life of me figure it out. Thanks, Geoff

2 1

Build broken: urgent
by Simon Peyton-Jones 12 Jun '13

12 Jun '13

Ian This getRegister bug is killing my Windows builds too; indeed every 32-bit build is broken, and that is stalling a lot of people, now including me. Could you perhaps revert the patch (around 6 June) that caused this, until it's sorted out? Thanks Simon "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 7.7.20130611 for i386-unknown-mingw32): getRegister(x86) I64[Sp] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug bash-3.1$

3 6

RE: builders
by Simon Peyton-Jones 12 Jun '13

12 Jun '13

Breakage on 32-bit Linux looks like this: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.7.20130610 for i386-unknown-linux): getRegister(x86) I64[Sp] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 Breakage on 64-bit Linux started about 6 June, and looks like this: ../../libraries/array/tests T2120 [exit code non-0] (profasm,profthreaded) ../../libraries/array/tests array001 [exit code non-0] (profasm,profthreaded) ../../libraries/array/tests largeArray [exit code non-0] (profasm,profthreaded) ../../libraries/base/tests CPUTime001 [exit code non-0] (profasm,profthreaded) plus a million more From: Simon Peyton-Jones Sent: 11 June 2013 12:04 To: Ian Lynagh (ian(a)well-typed.com) Cc: ghc-devs(a)haskell.org Subject: builders Ian Something we didn't discuss yesterday: * 32-bit Linux build is broken (see nightly-build email that Geoff generates here at MSR) * are other buildbots working? * we are getting no snapshot builds * there are many test failures (with plain "make" in testsuite/) even on 64-bit Linux. Can you investigate? Thanks Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

2 1

Validate failures
by Simon Peyton-Jones 11 Jun '13

11 Jun '13

Validation failures with "make" on 64-bit Linux are these. No prof or profasm tests were run; not sure why. But they are failing in droves Unexpected passes: driver T5313 (ghci,dyn) perf/should_run T149 (normal) Unexpected failures: ../../libraries/base/tests echo001 [bad exit code] (ghci) ../../libraries/base/tests/IO hClose002 [bad exit code] (ghci,threaded1,threaded2) ../../libraries/base/tests/IO hSetBuffering002 [bad exit code] (ghci) ../../libraries/base/tests/IO hSetBuffering004 [bad stdout or stderr] (ghci) ../../libraries/process/tests process007 [bad stderr] (threaded1,threaded2) ../../libraries/process/tests process007 [bad stdout or stderr] (ghci) ../../libraries/unix/tests/libposix posix002 [bad stderr] (threaded2) annotations/should_run annrun01 [bad exit code] (threaded2,optllvm) ffi/should_run T7170 [bad stdout or stderr] (ghci) ghc-api/apirecomp001 apirecomp001 [bad exit code] (normal) perf/space_leaks space_leak_001 [stat too good] (hpc,optasm,dyn,optllvm) programs/andy_cherry andy_cherry [bad exit code] (hpc,ghci) programs/jl_defaults jl_defaults [bad exit code] (ghci) programs/jq_readsPrec jq_readsPrec [bad exit code] (ghci) programs/jules_xref jules_xref [bad exit code] (ghci) programs/jules_xref2 jules_xref2 [bad exit code] (ghci) programs/launchbury launchbury [bad exit code] (ghci) programs/lex lex [bad exit code] (ghci) programs/rittri rittri [bad exit code] (ghci) quasiquotation/qq007 qq007 [exit code non-0] (normal,hpc,optasm,optllvm) quasiquotation/qq008 qq008 [exit code non-0] (normal,hpc,optasm,optllvm) Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

2 1

builders
by Simon Peyton-Jones 11 Jun '13

11 Jun '13

Ian Something we didn't discuss yesterday: * 32-bit Linux build is broken (see nightly-build email that Geoff generates here at MSR) * are other buildbots working? * we are getting no snapshot builds * there are many test failures (with plain "make" in testsuite/) even on 64-bit Linux. Can you investigate? Thanks Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

1 0