Simon Peyton Jones via ghc-devs <[email protected]> writes: > I’m getting this on HEAD on my Linux box (64 bit) > > cd "./perf/T10858.run" && "/5playpen/simonpj/HEAD-2/inplace/test > spaces/ghc-stage2" -c T10858.hs -dcore-lint -dcmm-lint -no-user-package-db > -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups > -dno-debug-output -O +RTS -V0 -tT10858.comp.stats --machine-readable -RTS > > bytes allocated value is too low: > > (If this is because you have improved GHC, please > > update the test so that GHC doesn't regress again) > > Expected T10858(normal) bytes allocated: 241655120 +/-8% > > Lower bound T10858(normal) bytes allocated: 222322710 > > Upper bound T10858(normal) bytes allocated: 260987530 > > Actual T10858(normal) bytes allocated: 221938928 > > Deviation T10858(normal) bytes allocated: -8.2 % > > Does anyone else? It’s good – but why isn’t Harbormaster complaining? > A very good question. It looks like the result is straddling the edge of acceptable so it's conceivable that Harbormaster is (for some reason) just below the failing threshold. We've seen this sort of small non-determinism in allocations in the past, although I don't have a compelling explanation for why.
Cheers, - Ben
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
