June 2013 - ghc-devs - Haskell.org

Integer constant folding in the presence of new primops
by Jan Stolarek 19 Jun '13

19 Jun '13

I'm finishing my patches for T6135, but I still have some work to do on integer-gmp and integer-simpl libraries. I changed the previously existing functions that compare Integers: {-# NOINLINE #-} eqInteger :: Integer -> Integer -> Bool eqInteger = ... to something like this: {-# NOINLINE eqIntegerPrim #-} eqIntegerPrim :: Integer -> Integer -> Int# eqIntegerPrim ... -- same as before, but uses new primops eqInteger :: Integer -> Integer -> Bool eqInteger a b = tagToEnum# (a `eqIntegerPrim` b) I noticed that in some cases this implementation prevents constant folding for Integers. I'm trying to figure out the proper way to fix this. I am considering two ways of doing it: - add new folding rules for eqIntegerPrim and other functions, leave the existing rules for eqInteger. This should fold: (100012 :: Integer) == 100012 to True (as it does now) - add new folding rules for eqIntegerPrim and other functions, remove the existing rules for eqInteger. This would fold (100012 :: Integer) == 100012 to tagToEnum# 1# Which approach is better? Another question related to this: how do I run validation with integer-simpl enabled? Wiki describes how to enable integer-simpl for the build, but I think that validation is always run against integer-gmp? Or am I wrong here? Janek

5 11

Windows failures
by Simon Peyton-Jones 19 Jun '13

19 Jun '13

Ian This is 'sh validate" on 64bit Windows. Rather a lot of failures. Might you look? The perf tests seem to fail because it's comparing with the *32* bit numbers, even though this is definitely a *64* bit laptop. Whether the entire build system thinks it's a 32 bit machine, or just the testsuite, I can't tell. Thanks Simon Unexpected failures: cabal/cabal01 cabal01 [bad exit code] (normal) cabal/cabal04 cabal04 [bad exit code] (normal) driver dynHelloWorld [exit code non-0] (dyn) driver/dynamicToo dynamicToo002 [bad stdout] (normal) driver/dynamicToo dynamicToo003 [bad exit code] (normal) dynlibs T4464 [bad exit code] (normal) dynlibs T5373 [bad exit code] (normal) ghc-api/T7478 T7478 [bad exit code] (normal) ghci.debugger/scripts break008 [bad exit code] (ghci) ghci.debugger/scripts dynbrk009 [bad exit code] (ghci) ghci/scripts T5975a [bad stderr] (ghci) llvm/should_compile T5486 [exit code non-0] (optllvm) llvm/should_compile T5681 [exit code non-0] (optllvm) llvm/should_compile T6158 [exit code non-0] (optllvm) llvm/should_compile T7571 [exit code non-0] (optllvm) llvm/should_compile T7575 [exit code non-0] (optllvm) perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3294 [stat not good enough] (normal) perf/compiler T4801 [stat too good] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) perf/should_run T7797 [stat too good] (normal) rts T4850 [bad stdout] (normal) rts derefnull [bad exit code] (normal) rts divbyzero [bad exit code] (normal) runghc T7859 [bad stderr] (normal) safeHaskell/check/pkg01 ImpSafeOnly01 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly02 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly03 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly04 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly05 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly06 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly07 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly08 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly09 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly10 [exit code non-0] (normal) safeHaskell/check/pkg01 safePkg01 [bad exit code] (normal)

2 2

build error on Mac
by Kazu Yamamoto 19 Jun '13

19 Jun '13

Hi, I got an build error on Mac today: make -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -o utils/dll-split/dist-install/build/tmp/dll-split -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/dll-split/. -iutils/dll-split/dist-install/build -iutils/dll-split/dist-install/build/autogen -Iutils/dll-split/dist-install/build -Iutils/dll-split/dist-install/build/autogen -optP-include -optPutils/dll-split/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.0.0 -package filepath-1.3.0.2 -XHaskell98 -no-user-package-db -rtsopts -odir utils/dll-split/dist-install/build -hidir utils/dll-split/dist-install/build -stubdir utils/dll-split/dist-install/build -optl-Wl,-headerpad_max_install_names utils/dll-split/dist-install/build/Main.dyn_o ld: unknown option: --undefined=_ghczmprim_GHCziTypes_Izh_static_info collect2: ld returned 1 exit status make[1]: *** [utils/dll-split/dist-install/build/tmp/dll-split] Error 1 make: *** [all] Error 2 --Kazu

3 7

Nightly builds
by Simon Peyton-Jones 18 Jun '13

18 Jun '13

Hi Ian What's the state of our nightly builds? * I'd rather not rely on build infrastructure here at MSR, because I am not capable of maintaining it, and Geoff is leaving in August. (Geoff is, however, willing to continue to help on infrastructure issues, after his move to Drexel; thanks Geoff.) * I believe that our nightly snapshots are still dead. Are these constructed by buildbots? * How are the buildbots doing? Is all this awaiting our shift of abott? Or is it orthogonal? Do we need help from others? If so who? Thanks Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

3 2

profiling
by Kazu Yamamoto 18 Jun '13

18 Jun '13

Hi, The following command can install acme-http with profiling if GHC 7.6.3 is used: % cabal install -p --ghc-options="-prof -fprof-auto" --enable-executable-profiling -j10 acme-http But if GHC head is used, the following error occurs: % cabal install -p --ghc-options="-prof -fprof-auto" --enable-executable-profiling -j10 acme-http In function `sofa_closure': (.data+0xe8): undefined reference to `CCCS' /ghc-head/lib/ghc-7.7.20130616/Cabal-1.17.0/libHSCabal-1.17.0_p.a(Setup__1680.p_o):(.data+0x88): more undefined references to `CCCS' follow Is this a bug? I'm using Linux 3 and Cabal version is: % cabal --version cabal-install version 1.16.0.2 using version 1.16.0 of the Cabal library --Kazu

2 2

Keeping GHC's history intact
by Iavor Diatchki 18 Jun '13

18 Jun '13

Hello, I'd noticed that occasionally my branch of GHC would fail to check-out due to missing references to the Cabal repo. For a while this was puzzling me, because as far as I know we don't do rebasing of published changes, but as I was reading another thread I found the problem. Ian explains the current workflow for collaborating with Cabal: * Initially ghc's Cabal repo is at the same commit as upstream * We make a local commit 123 in Cabal to fix some bug * Cabal upstream makes a commit 456 to fix the same bug differently * We jump to commit 456, in such a way that we don't end up merging with our 123 commit every time we pull from Cabal in the future The last step in this work-flow---where we jump directly from 123 to 456---loses information: the Cabal repo has no way of knowing that some previous version of GHC still depends on 123. As a result, commit 123 can get GC-ed, which breaks GHC's history (i.e., we can't go back to GHC as it was back when it depended on 123). I'd like to propose the following workflow for repos where GHC developers need to make temporary changes that are not intended to be merged into upstream. 1. Create a new branch 'ghc-tmp-changes' in the foreign repo (e.g., Cabal). This branch is where we'll make the temporary changes, and its history will keep track of all previous temporary changes we made, so that our history stays intact. 2. The GHC sub-module will point to: 2.1 some upstream commit, if we don't currently use any temporary changes; 2.2 some commit on the `ghc-tmp-changes` branch, if we are depending on some temporary fix. 3. To start a new set of temporary changes (i.e., our sub-module is currently pointing to upstream commit `111`) 3.1 Merge `111` into `ghc-tmp-changes` by using strategy `theirs`. This makes sure that `ghc-tmp-changes` is up to date. If this is not the first temporary change to make, then we can skip this step. 3.2 Make the change and commit it on branch `ghc-tmp-changes`, resulting in commit `222`. 3.3 Update the sub-module to point to `222`. 4. When our temporary changes are no longer needed (i.e., they got fixed in upstream in some other way), then we simply point the sub-module to the relevant upstream commit. I hope this helps, -Iavor

1 0

cabal uses dynamic-linking for lifted-base
by Kazu Yamamoto 18 Jun '13

18 Jun '13

Hi, When I try to install libfted-base, cabal uses dynamic-linking while it uses static-linking for other libraries. So, I got the following error: % cabal install lifted-base /usr/bin/ld: cannot find -lHSmonad-control-0.3.2.1-ghc7.7.20130616 /usr/bin/ld: cannot find -lHStransformers-base-0.4.1-ghc7.7.20130616 /usr/bin/ld: cannot find -lHSbase-unicode-symbols-0.2.2.4-ghc7.7.20130616 If I explicitly enable/disable dynamic-linking, lifted-base can be installed. That is, the following two commands are valid: % cabal install lifted-base --enable-shared % cabal install lifted-base --disable-shared Why dynamic-linking is used for lifted-base (only)? --Kazu

1 0

How to build statically linking GHC?
by Stephen Paul Weber 17 Jun '13

17 Jun '13

What's the correct way, on GHC head, to get it to build libraries in the way GHC does now (so that they are statically linked into binaries) instead of the new-but-super-annoying dynamic linking? Do I just DYNAMIC_BY_DEFAULT=NO in my build.mk? -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

3 3

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