- ghc-devs - Haskell.org

Running GHC Tests for Cross-Compiler?
by Stephen Paul Weber 20 Jun '13

20 Jun '13

Anyone know the best way to build the GHC test suite so that it can be run on another device (so that I can run them for my cross-compiler)? -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

2 1

Literate Markdown
by Trevor Elliott 20 Jun '13

20 Jun '13

Hi All, I've implemented support for literate markdown in a branch [1]. After doing a search on the bug tracker to see if anyone had already worked on this I came across bug #4836 [2], which details some unexpected interactions between the markdown format, unlit and CPP. Specifically, unlit attempts to keep CPP in the comment sections of a literate file, which clashes with the way that headings are defined in markdown. The approach that I took is that when GHC is processing markdown files, it passes the -r and -# flags to unlit, causing it to remove CPP in the comment parts of the file. I've added support for .markdown and .md as source file extensions supported by GHC to be able to detect when this is necessary. CPP can still be used within code blocks, giving a path forward for the case where the file was generated by something that wishes to leave #line markers. I've documented the changes on the wiki at [3]. Does this approach sound reasonable? If so, should I attach a patch to #4836, or create a new ticket? Thanks! --trevor [1] https://github.com/elliottt/ghc/tree/literate-markdown [2] http://hackage.haskell.org/trac/ghc/ticket/4836 [3] http://hackage.haskell.org/trac/ghc/wiki/LiterateMarkdown

1 0

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

20 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 19 Jun '13

19 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 19 Jun '13

19 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 19 Jun '13

19 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