March 2014 - ghc-devs

Optimized Cmm containing useless blocks
by Johan Tibell 10 Mar '14

10 Mar '14

While looking at some generated Cmm I saw things like this c1Cm: goto c1Cq; c1Cq: i.e. useless basic blocks that haven't been optimized away. Is this to be expected? -- Johan

5 7

Building GHC for performance testing
by Johan Tibell 08 Mar '14

08 Mar '14

Hi, I'd like to set up a performance build bot for GHC, but before I can do that I need a script that reliably builds GHC and runs nofib. Do we have such a script? Here's a strawman proposal for one: cabal install happy alex git clone git://git.haskell.org/ghc.git cd ghc ./sync-all --nofib get perl boot ./configure make cd nofib make clean make boot make -k mode=slow Questions: * Does this look sensible? * Is there a way to only build and run a subset of the benchmarks? * Are there any tweaks to mk/build.mk we can do to make the build faster without compromising the results? * Is there a way to do this in a cheap throwaway VM like travis-ci does? Could such a VM already provide GHC and the required libs to make the whole thing hermetic?

6 9

libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error: HsIntegerGmp.h: No such file or directory
by Mateusz Kowalczyk 08 Mar '14

08 Mar '14

Hi, I'm trying to build HEAD but I'm getting libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error: HsIntegerGmp.h: No such file or directory #include "HsIntegerGmp.h" ^ compilation terminated. make[1]: *** [libraries/integer-gmp/dist-install/build/.depend-v-dyn.c_asm] Error 1 make: *** [all] Error 2 This in on 32-bit Gentoo Linux, using 7.6.3 to build. I've been able to build fine before. My last few versions are … drwxr-xr-x 5 shana shana 4096 Feb 19 04:45 ghc-20140218 drwxr-xr-x 5 shana shana 4096 Feb 22 22:04 ghc-20140220 drwxr-xr-x 5 shana shana 4096 Feb 25 08:44 ghc-20140225 which means that the problem must have been introduced some time after that point. Does anyone have any ideas? -- Mateusz K.

2 4

RE: new Windows build problem
by Simon Peyton Jones 07 Mar '14

07 Mar '14

Actually, the two problems seem to be the same. A fresh build from scratch yields libraries/random/ghc.mk:5: recipe for target 'libraries/random/dist-install/build/System/Random.o' failed make[1]: *** [libraries/random/dist-install/build/System/Random.o] Segmentation fault Then sniping the command line that tried to build Random.o yields "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name random-1.0.1.1 -hide-all-packages -i -ilibraries/random/. -ilibraries/random/dist-install/build -ilibraries/random/dist-install/build/autogen -Ilibraries/random/dist-install/build -Ilibraries/random/dist-install/build/autogen -Ilibraries/random/. -optP-include -optPlibraries/random/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package time-1.4.2 -O2 -XHaskell98 -XCPP -O2 -O -dcore-lint -fno-warn-amp -fno-warn-deprecated-flags -dcore-lint -no-user-package-db -rtsopts -odir libraries/random/dist-install/build -hidir libraries/random/dist-install/build -stubdir libraries/random/dist-install/build -c libraries/random/./System/Random.hs -o libraries/random/dist-install/build/System/Random.o bash: [6536: 1 (255)] tcsetattr: Inappropriate ioctl for device io So this ioctl thing seems to be reported as a seg fault by the make system. Running the same command from a 'cmd' window does give a seg-fault pop-up window. Alas. Running with -dshow-passes shows that it happens during code generation, *** CorePrep: Result size of CorePrep = {terms: 1,214, types: 912, coercions: 52} *** Core Linted result of CorePrep: *** Stg2Stg: *** CodeOutput: *** New CodeGen: *** CPSZ: *** CPSZ: I am totally stuck. Simon From: Simon Peyton Jones Sent: 06 March 2014 22:11 To: ghc-devs(a)haskell.org Subject: new Windows build problem Sigh. Totally new problem with building GHC (HEAD) on Windows.. "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name haskell98-2.0.0.3 -hide-all-packages -i -ilibraries/haskell98/. -ilibraries/haskell98/dist-install/build -ilibraries/haskell98/dist-install/build/autogen -Ilibraries/haskell98/dist-install/build -Ilibraries/haskell98/dist-install/build/autogen -Ilibraries/haskell98/. -optP-include -optPlibraries/haskell98/dist-install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.0.0 -package directory-1.2.0.2 -package old-locale-1.0.0.6 -package old-time-1.1.0.2 -package process-1.2.0.0 -package time-1.4.2 -Wall -XHaskell98 -O2 -O -dcore-lint -fno-warn-amp -fno-warn-deprecated-flags -dcore-lint -no-user-package-db -rtsopts -odir libraries/haskell98/dist-install/build -hidir libraries/haskell98/dist-install/build -stubdir libraries/haskell98/dist-install/build -c libraries/haskell98/./Directory.hs -o libraries/haskell98/dist-install/build/Directory.o bash: [6536: 1 (255)] tcsetattr: Inappropriate ioctl for device HEAD $ What on earth is this ioctl stuff? The above is repeatable; same command line, same result. But I'm also getting random seg-faults when building libraries with the stage2 compiler libraries/random/ghc.mk:5: recipe for target 'libraries/random/dist-install/build/System/Random.o' failed make[1]: *** [libraries/random/dist-install/build/System/Random.o] Segmentation fault This is NOT repeatable. Saying 'make' again gets further. Any ideas? Simon

2 2

Re: [commit: ghc] master: Make -XDeriveFunctor more generous about non-last arguments (Trac #8678) (cdac487)
by Gabor Greif 07 Mar '14

07 Mar '14

Thanks for fixing this, Simon! I can add tests if you haven't already... Cheers, Gabor On 3/7/14, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : > http://ghc.haskell.org/trac/ghc/changeset/cdac487bcd9928d77738f6e79ead7b9bb… > >>--------------------------------------------------------------- > > commit cdac487bcd9928d77738f6e79ead7b9bb4bc00fd > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Fri Mar 7 16:45:55 2014 +0000 > > Make -XDeriveFunctor more generous about non-last arguments (Trac > #8678) > > When deriving Functor, Foldable, Traversable, we need only look at the > way that the last type argument is treated. It's fine for there to > be existentials etc, provided they don't affect the last type argument. > > See Note [Check that the type variable is truly universal] in TcDeriv. > > >>--------------------------------------------------------------- > > cdac487bcd9928d77738f6e79ead7b9bb4bc00fd > compiler/typecheck/TcDeriv.lhs | 88 > +++++++++++++++----- > compiler/typecheck/TcGenDeriv.lhs | 8 +- > docs/users_guide/glasgow_exts.xml | 7 ++ > testsuite/tests/deriving/should_compile/T8678.hs | 12 +++ > testsuite/tests/deriving/should_compile/all.T | 1 + > testsuite/tests/deriving/should_fail/T3101.stderr | 2 +- > testsuite/tests/generics/GenCannotDoRep0_0.stderr | 3 +- > testsuite/tests/generics/GenCannotDoRep1_0.stderr | 3 +- > .../tests/typecheck/should_fail/tcfail086.stderr | 2 +- > 9 files changed, 96 insertions(+), 30 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder > --ignore-space-at-eol --cc cdac487bcd9928d77738f6e79ead7b9bb4bc00fd > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0

Emitting calls to functions defined in PrimOps.cmm from the code gen
by Johan Tibell 07 Mar '14

07 Mar '14

Hi, I'm trying to make allocation of arrays of small, statically-known size inline. For large or unknown size I just want to call the existing stg_newArrayzh function. In code: doNewArrayOp :: DynFlags -> CmmFormal -> CmmExpr -> FCode () doNewArrayOp dflags res_r (CmmLit (CmmInt n _)) | n <= inlineAllocLimit = do -- Do everything inline. doNewArrayOp dflags res_r n = do emitCallTo "stg_newArrayzh" res_r n -- HERE The question is: how do I emit a call to stg_newArrayzh, which is defined in PrimOps.cmm? -- Johan

2 3

ANNOUNCE: GHC 7.8.1 Release Candidate 2
by Austin Seipp 07 Mar '14

07 Mar '14

We are pleased to announce the second release candidate for GHC 7.8.1: http://www.haskell.org/ghc/dist/7.8.1-rc2/ http://www.haskell.org/ghc/docs/7.8.1-rc2/html/ This includes the source tarball and binary distributions for Windows, Linux, OS X, FreeBSD, and Solaris, on x86 and x86_64, and more. There are now two binary builds for Linux users: one for glibc 2.12 and GMP 4, primarily intended for RHEL users, and one built for glibc 2.13 and GMP 5 - intended for Debian and more recent machines. In addition, there is also an iOS cross compiler build (both in the native ARM configuration and i386 simulator configurations), separate Solaris 10 and Solaris 11 builds - the latter supporting dynamic linking - and a new Linux/PPC64 build using glibc 2.18/GMP 5. There is a signed copy of the SHA256 hashes available (attached) using my GPG key (keyid 0x3B58D86F). We're also now offering .tar.xz files, which roughly cut the size of the binary distributions in half compared to bzip2. We've closed approximately 45 tickets that people filed for RC1 in this release. Thank you for all the reports! We plan to make the final 7.8.1 release soon, and hope RC2 will be the last RC. So *please* test as much as possible; bugs are much cheaper if we find them before the release! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

7 12

Where's the implementation of newArray#
by Johan Tibell 07 Mar '14

07 Mar '14

Is the below code it (from rts/PrimOps.cmm)? Does it being in PrimOps.cmm mean that it's always out-of-line? stg_newArrayzh ( W_ n /* words */, gcptr init ) { W_ words, size; gcptr p, arr; again: MAYBE_GC(again); // the mark area contains one byte for each 2^MUT_ARR_PTRS_CARD_BITS words // in the array, making sure we round up, and then rounding up to a whole // number of words. size = n + mutArrPtrsCardWords(n); words = BYTES_TO_WDS(SIZEOF_StgMutArrPtrs) + size; ("ptr" arr) = ccall allocate(MyCapability() "ptr",words); TICK_ALLOC_PRIM(SIZEOF_StgMutArrPtrs, WDS(n), 0); SET_HDR(arr, stg_MUT_ARR_PTRS_DIRTY_info, CCCS); StgMutArrPtrs_ptrs(arr) = n; StgMutArrPtrs_size(arr) = size; // Initialise all elements of the the array with the value in R2 p = arr + SIZEOF_StgMutArrPtrs; for: if (p < arr + WDS(words)) { W_[p] = init; p = p + WDS(1); goto for; } // Initialise the mark bits with 0 for2: if (p < arr + WDS(size)) { W_[p] = 0; p = p + WDS(1); goto for2; } return (arr); }

2 1

new Windows build problem
by Simon Peyton Jones 06 Mar '14

06 Mar '14

Sigh. Totally new problem with building GHC (HEAD) on Windows.. "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name haskell98-2.0.0.3 -hide-all-packages -i -ilibraries/haskell98/. -ilibraries/haskell98/dist-install/build -ilibraries/haskell98/dist-install/build/autogen -Ilibraries/haskell98/dist-install/build -Ilibraries/haskell98/dist-install/build/autogen -Ilibraries/haskell98/. -optP-include -optPlibraries/haskell98/dist-install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.0.0 -package directory-1.2.0.2 -package old-locale-1.0.0.6 -package old-time-1.1.0.2 -package process-1.2.0.0 -package time-1.4.2 -Wall -XHaskell98 -O2 -O -dcore-lint -fno-warn-amp -fno-warn-deprecated-flags -dcore-lint -no-user-package-db -rtsopts -odir libraries/haskell98/dist-install/build -hidir libraries/haskell98/dist-install/build -stubdir libraries/haskell98/dist-install/build -c libraries/haskell98/./Directory.hs -o libraries/haskell98/dist-install/build/Directory.o bash: [6536: 1 (255)] tcsetattr: Inappropriate ioctl for device HEAD $ What on earth is this ioctl stuff? The above is repeatable; same command line, same result. But I'm also getting random seg-faults when building libraries with the stage2 compiler libraries/random/ghc.mk:5: recipe for target 'libraries/random/dist-install/build/System/Random.o' failed make[1]: *** [libraries/random/dist-install/build/System/Random.o] Segmentation fault This is NOT repeatable. Saying 'make' again gets further. Any ideas? Simon

1 0

[PATCH] time library fix for PowerPC
by Gabor Greif 06 Mar '14

06 Mar '14

Please consider this as a pull request. <https://github.com/ggreif/packages-time/commit/83f08b8896b950707a910fed4e30…> It fixes an ugly code size blowup that trips the PowerPC assembler (NCG mode). Cheers, Gabor

2 1