- ghc-devs - Haskell.org

validate failure on Mac
by Richard Eisenberg 03 Oct '13

03 Oct '13

Sorry if this has been addressed recently, but I can't validate right now, due to a build failure from -Werror in C code in primitive: > "inplace/bin/ghc-stage2" -optc-Werror -optc-Wall -optc-Ilibraries/primitive/cbits -optc-O3 -optc-ftree-vectorize -optc-fomit-frame-pointer -optc-msse2 -optc-I'/Users/rae/Documents/ghc-cur/libraries/base/include' -optc-I'/Users/rae/Documents/ghc-cur/rts/dist/build' -optc-I'/Users/rae/Documents/ghc-cur/includes' -optc-I'/Users/rae/Documents/ghc-cur/includes/dist-derivedconstants/header' -static -H32m -O -Werror -Wall -H64m -O0 -package-name primitive-0.5.1.0 -hide-all-packages -i -ilibraries/primitive/. -ilibraries/primitive/dist-install/build -ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive/dist-install/build -Ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive/cbits -optP-include -optPlibraries/primitive/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package ghc-prim-0.3.1.0 -O2 -Wall -XHaskell2010 -O2 -O -dcore-lint -fno-warn-amp -fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -c libraries/primitive/cbits/primitive-memops.c -o libraries/primitive/dist-install/build/cbits/primitive-memops.o > cc1: warnings being treated as errors > libraries/primitive/cbits/primitive-memops.c: In function ‘hsprimitive_memset_Word16’: > > libraries/primitive/cbits/primitive-memops.c:44:0: > warning: dereferencing type-punned pointer will break strict-aliasing rules > libraries/primitive/cbits/primitive-memops.c: In function ‘hsprimitive_memset_Word32’: > > libraries/primitive/cbits/primitive-memops.c:45:0: > warning: dereferencing type-punned pointer will break strict-aliasing rules > libraries/primitive/cbits/primitive-memops.c: In function ‘hsprimitive_memset_Word64’: > > libraries/primitive/cbits/primitive-memops.c:46:0: > warning: dereferencing type-punned pointer will break strict-aliasing rules > libraries/primitive/cbits/primitive-memops.c: In function ‘hsprimitive_memset_Word’: > > libraries/primitive/cbits/primitive-memops.c:47:0: > warning: dereferencing type-punned pointer will break strict-aliasing rules > libraries/primitive/cbits/primitive-memops.c: In function ‘hsprimitive_memset_Ptr’: > > libraries/primitive/cbits/primitive-memops.c:48:0: > warning: dereferencing type-punned pointer will break strict-aliasing rules > libraries/primitive/cbits/primitive-memops.c: In function ‘hsprimitive_memset_Float’: > > libraries/primitive/cbits/primitive-memops.c:49:0: > warning: dereferencing type-punned pointer will break strict-aliasing rules > libraries/primitive/cbits/primitive-memops.c: In function ‘hsprimitive_memset_Double’: > > libraries/primitive/cbits/primitive-memops.c:50:0: > warning: dereferencing type-punned pointer will break strict-aliasing rules > make[1]: *** [libraries/primitive/dist-install/build/cbits/primitive-memops.o] Error 1 > make: *** [all] Error 2 I have not been playing around in this area lately (or ever), and I did a ./sync-all pull this morning. Any advice? Thanks! Richard

1 0

FW: Detabbing patch and GHC developers Wiki
by p.k.f.holzenspies＠utwente.nl 03 Oct '13

03 Oct '13

PS. Ignore my comments about git send-email. Ubuntu enjoys splitting everything up in minute sub-packages. I should have installed git-email. From: Holzenspies, P.K.F. (EWI) Sent: donderdag 3 oktober 2013 15:18 To: 'ghc-devs(a)haskell.org' Subject: Detabbing patch and GHC developers Wiki Dear GHCers, Attached is a patch to detab the current HEAD. I've followed the GHC developers Wiki instructions on validation and patch generation. However, the Wiki seems to contain an error (or, at least, does not agree with my version of git). At [1], the wiki says I can submit patches using "git send-email". My git complains that it does not know this command. If this is indeed wrong, could someone in the know update the wiki? Can I consider my patch submitted for consideration or should I send it somewhere else? Regards, Philip

1 0

Make spins with THREADS>1 on Win 7
by Edsko de Vries 02 Oct '13

02 Oct '13

Hi all, Trying to get a build going on Win 7. On both the 32-bit and the 64-bit version running 'sh validate' stalls at "inplace/bin/mkdirhier" utils/touchy/dist/build/tmp//. At this point nothing happens, other than that I seem to have 100% CPU usage; 'ps' only shows two make processes, but no further subprocesses. Not sure what's going on here. Running 'sh validate --no-clean' after killing both make processes at this point stalls at the same point; running it with THREADS=1 seems to resolve the issue. Anybody any idea what might be going on? Edsko

3 5

gcc on Windows
by Simon Peyton-Jones 02 Oct '13

02 Oct '13

Dear ghc devs My Windows build failed as below, because it couldn't find gcc. But this is the ONLY reason we need gcc! GHC and its libraries all built without gcc, perhaps because we use ghc itself to compile C files, and ghc has a C compiler in its belly (no PATH reqd). Question: would it be possible to use the same technique to compile timeout, so that we don't need to install gcc separately? This is on Windows. Thanks Simon Building timeout-1... Preprocessing executable 'timeout' for timeout-1... Setup.exe: The program gcc is required but it could not be found. Makefile:39: recipe for target 'install-inplace/bin/timeout' failed make[3]: *** [install-inplace/bin/timeout] Error 1 make[3]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/timeout' ../mk/test.mk:234: recipe for target '../timeout/install-inplace/bin/timeout.exe' failed make[2]: *** [../timeout/install-inplace/bin/timeout.exe] Error 2 make[2]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' ../mk/test.mk:253: recipe for target 'fast' failed make[1]: *** [fast] Error 2 make[1]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' Makefile:112: recipe for target 'test' failed make: *** [test] Error 2

1 0

Validate failures
by Austin Seipp 02 Oct '13

02 Oct '13

Today, validate has been failing with: $ cat testsuite_summary.txt Unexpected results from: TEST="T7873 haddock.compiler haddock.base Roles1 T2247 T3064 TH_Roles2 T7230 T7967 T7786" OVERALL SUMMARY for test run started at Tue Oct 1 23:46:30 2013 CDT 0:09:17 spent to go through 3809 total tests, which gave rise to 15066 test cases, of which 11598 were skipped 28 had missing libraries 3373 expected passes 57 expected failures 0 caused framework failures 0 unexpected passes 10 unexpected failures Unexpected failures: ghci/scripts T7873 [bad stdout] (ghci) indexed-types/should_fail T7786 [stderr mismatch] (normal) indexed-types/should_fail T7967 [stderr mismatch] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) polykinds T7230 [stderr mismatch] (normal) roles/should_compile Roles1 [stderr mismatch] (normal) th TH_Roles2 [stderr mismatch] (normal) typecheck/should_fail T2247 [stderr mismatch] (normal) A lot of these seem to be changes in pretty printing, and other error message wibbles. I double-checked this on a clean tree before I pushed my latest round of patches. Simon, I believe you pushed changes relating to this? (I'm also looking into the performance failures, but finding out which commit is a bit difficult.) -- Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 2

newSession
by Kazu Yamamoto 02 Oct '13

02 Oct '13

Hi, It seems to me that "newSession" does not exist. But it is used in comments and error messages. % grep -r newSession * compiler/main/DynFlags.hs:-- | Used by 'GHC.newSession' to partially initialize a new 'DynFlags' value compiler/main/DynFlags.hs:-- and must be fully initialized by 'GHC.newSession' first. compiler/main/StaticFlags.hs: when ready $ throwGhcExceptionIO (ProgramError "Too late for parseStaticFlags: call it before newSession") compiler/main/StaticFlags.hs: then panic "Static flags have not been initialised!\n Please call GHC.newSession or GHC.parseStaticFlags early enough." I think they should be updated. --Kazu

3 3

Windows build failures in FD.hs
by Edsko de Vries 02 Oct '13

02 Oct '13

Hi all, I'm still trying to get a Windows build (Win 7, tried both 32-bit and 64-bit, same result) -- using THREADS=1. When running 'sh validate', compilation eventually stops with "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell2010 -O2 -O -dcore-lint -fno-warn-amp -fno-warn-deprecated-flags -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/IO/FD.hs -o libraries/base/dist-install/build/GHC/IO/FD.o -dyno libraries/base/dist-install/build/GHC/IO/FD.dyn_o libraries\base\GHC\IO\FD.hs:281:23: Empty 'do' block libraries\base\GHC\IO\FD.hs:282:23: Empty 'do' block libraries\base\GHC\IO\FD.hs:283:26: Not in scope: `devptr' libraries\base\GHC\IO\FD.hs:283:33: Not in scope: `inoptr' libraries\base\GHC\IO\FD.hs:284:20: Not in scope: `devptr' libraries\base\GHC\IO\FD.hs:284:34: Not in scope: `inoptr' make[1]: *** [libraries/base/dist-install/build/GHC/IO/FD.o] Error 1 make: *** [all] Error 2 Since nobody else seems to be experiencing this, there must be something wrong with my setup? I've tried to follow http://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows best I could, but I'm not a Windows user so I might have got something wrong. Any suggestions welcome! Edsko

4 3

LLVM opt/llc command settings (under Windows) IRT #7143
by Kyle Van Berendonck 02 Oct '13

02 Oct '13

Hi, It was suggested on #ghc we get a discussion going about #7143. We think it's a good idea that `we should have a default value for lllc and opt anyways ... even in[if] the host building system doesn't have it locally`. Non-windows platforms seem to have one that's configured in aclocal.m4. I tried pulling this conditional thing out and getting it running on Windows too, but for some reason it doesn't work even if I explicitly set the values to "llc" and "opt". Regards, Kyle

1 0

New space leak?
by Simon Marlow 01 Oct '13

01 Oct '13

My validate has a few perf failures (below). Now I know that sampling heap size is inaccurate, but the evidence here is pretty strong. Also validate fell over completely in my 2GB VM when Haddock ran out of memory, I had to give it more memory to complete. Something has got worse recently - this wasn't happening a couple of weeks ago. Does anyone have any idea what might have caused this? Going back in time is difficult. Are these failures happening for other people? Let me suggest something that might help with these perf tests: running the program with +RTS -h -i0.01 will give a more accurate indication of peak residency, by running major GCs much more often. Also you get a heap profile. Cheers, Simon =====> haddock.base(normal) 2474 of 3806 [0, 1, 0] max_bytes_used value is too high: Expected max_bytes_used: 96022312 +/-10% Lower bound max_bytes_used: 86420080 Upper bound max_bytes_used: 105624544 Actual max_bytes_used: 113537216 peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 274 +/-10% Lower bound peak_megabytes_allocated: 246 Upper bound peak_megabytes_allocated: 302 Actual peak_megabytes_allocated: 323 *** unexpected failure for haddock.base(normal) =====> haddock.Cabal(normal) 2475 of 3806 [0, 2, 0] =====> haddock.compiler(normal) 2476 of 3806 [0, 2, 0] peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 1250 +/-10% Lower bound peak_megabytes_allocated: 1125 Upper bound peak_megabytes_allocated: 1375 Actual peak_megabytes_allocated: 1397 bytes allocated value is too high: Expected bytes allocated: 25990254632 +/-10% Lower bound bytes allocated: 23391229168 Upper bound bytes allocated: 28589280096 Actual bytes allocated: 28680445952 *** unexpected failure for haddock.compiler(normal) =====> T3064(normal) 2480 of 3806 [0, 3, 0] cd ./perf/compiler && '/home/smarlow/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3064.hs +RTS -V0 -tT3064.comp.stats --machine-readable -RTS >T3064.comp.stderr 2>&1 max_bytes_used value is too high: Expected max_bytes_used: 12000480 +/-20% Lower bound max_bytes_used: 9600384 Upper bound max_bytes_used: 14400576 Actual max_bytes_used: 15258696 peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 30 +/-20% Lower bound peak_megabytes_allocated: 24 Upper bound peak_megabytes_allocated: 36 Actual peak_megabytes_allocated: 37 *** unexpected failure for T3064(normal)

4 4

Is evacuate for StgMutArrPtrs and StgArrPtrs expensive to GC?
by Johan Tibell 01 Oct '13

01 Oct '13

Hi, When I benchmark Data.HashMap.insert from unordered-containers (inserting the keys [0..10000]) the runtime is dominated by GC: $ cat Test.hs module Main where import Control.DeepSeq import Control.Exception import Control.Monad import qualified Data.HashMap.Strict as HM import Data.List (foldl') main = do let ks = [0..10000] :: [Int] evaluate (rnf ks) forM_ ([0..1000] :: [Int]) $ \ x -> do evaluate $ HM.null $ foldl' (\ m k -> HM.insert k x m) HM.empty ks $ perf record -g ./Test +RTS -s 6,187,678,112 bytes allocated in the heap 3,309,887,128 bytes copied during GC 1,299,200 bytes maximum residency (1002 sample(s)) 118,816 bytes maximum slop 5 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 11089 colls, 0 par 1.31s 1.30s 0.0001s 0.0005s Gen 1 1002 colls, 0 par 0.49s 0.51s 0.0005s 0.0022s INIT time 0.00s ( 0.00s elapsed) MUT time 1.02s ( 1.03s elapsed) GC time 1.80s ( 1.80s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 2.82s ( 2.84s elapsed) %GC time 63.7% (63.5% elapsed) Alloc rate 6,042,264,963 bytes per MUT second Productivity 36.3% of total user, 36.1% of total elapsed $ perf report 41.46% Test Test [.] evacuate 15.47% Test Test [.] scavenge_block 11.04% Test Test [.] s3cN_info 8.74% Test Test [.] s3aZ_info 3.59% Test Test [.] 0x7ff5 2.83% Test Test [.] scavenge_mut_arr_ptrs 2.69% Test libc-2.15.so [.] 0x147fd9 2.51% Test Test [.] allocate 2.00% Test Test [.] s3oo_info 0.91% Test Test [.] todo_block_full 0.87% Test Test [.] hs_popcnt64 0.80% Test Test [.] s3en_info 0.62% Test Test [.] s3el_info Is GC:ing StgMutArrPtrs and StgArrPtrs, which I create a lot of, more expensive than GC:ing normal heap objects (i.e. for standard data types)? -- Johan

4 6