- ghc-devs - Haskell.org

ANN: Overlay Hackage Package Index for GHC HEAD
by Herbert Valerio Riedel 19 Sep '17

19 Sep '17

Hi GHC devs, A long-standing common problem when testing/dogfooding GHC HEAD is that at some point during the development cycle more and more packages from Hackage will run into build failures. Obviously, constantly nagging upstream maintainers to release quickfixes for unreleased GHC HEAD snapshots which will likely break again a few weeks later (as things are generally in flux until freeze comes into effect) does not scale and only introduces a latency/coordination bottleneck, and on top of it ultimately results in spamming the primary Hackage Package index with releases (which has non-negligible negative impact/costs of its own on the Hackage infrastructure, and thus ought to be minimised). OTOH, we need the ability to easily test, debug, profile, and prototype changes to GHC HEAD while things are still in motion, and case in point, if you try to e.g. build `pandoc` with GHC HEAD today, you'll currently run into a dozen or so of packages not building with GHC HEAD. To this end, I've finally found time to work on a side-project (related to matrix.hackage.haskell.org) which implements a scheme tailored to `cabal new-build`, which is inspired by how Eta copes with a very related issue (they rely on it for stable versions of the compiler); i.e., they maintain a set of patches at https://github.com/typelead/eta-hackage/tree/master/patches which fix up existing Hackage packages to work with the Eta compiler. And this gave me the idea to use a similar scheme for GHC HEAD: https://github.com/hvr/head.hackage/tree/master/patches This folder already contains several of patches (which mostly originate from Ryan, Ben and myself) to packages which I needed to patch in order to build popular Hackage packages & tools. The main difference is how those patches are applied; Eta uses a modified `cabal` which they renamed to `etlas` which is checks availability of .patch & .cabal files in the GitHub repo linked above; Whereas for GHC HEAD with `cabal new-build` a different scheme makes more sense: we simply generate an add-on Hackage repo, and use the existing `cabal` facilities (e.g. multi-repo support or the nix-style package store which makes sure that unofficially patched packages don't contaminate "normal" install-plans, etc.) to opt into the opt-in Hackage repo containing fixed up packages. I've tried to describe how to use the HEAD.hackage add-on repo in the README at https://github.com/hvr/head.hackage#how-to-use And finally, here's a practical example of how you can use it to build e.g. the `pandoc` executable with GHC HEAD (can easily be adapted to build your project of choice; please refer to http://cabal.readthedocs.io/en/latest/nix-local-build-overview.html to learn more about how to describe your project via `cabal.project` files): 0.) This assumes you have a recent cabal 2.1 snapshot built from Git 1.) create & `cd` into a new work-folder 2.) invoke `head.hackage.sh update` to update the HEAD.hackage index cache 3.) invoke `head.hackage.sh init` to create an initial `cabal.project` configuration which locally activates the HEAD.hackage overlay repo 4.) If needed, edit the cabal.project file and change where GHC HEAD can be found (the script currently assumes GHC HEAD is installed from my Ubuntu PPA), e.g. with-compiler: /home/hvr/src/ghc-dev/inplace/bin/ghc-stage2 or you can add something like `optional-packages: deps/*/*.cabal` to have cabal pick up package source-trees unpacked in the deps/ folder, or you can inject ghc-options, relax upper bounds via `allow-newer: *:base` etc (please refer to the cabal user guide) 5.) Create a `dummy.cabal` file (in future we will have `cabal new-install` or other facilities, but for now we use this workaround): --8<---------------cut here---------------start------------->8--- name: dummy version: 0 build-type: Simple cabal-version: >=2.0 library default-language: Haskell2010 -- library components you want cabal to solve & build for -- and become accessible via .ghc.environment files and/or -- `cabal new-repl` build-depends: base, lens -- executable components you want cabal to build build-tool-depends: pandoc:pandoc --8<---------------cut here---------------end--------------->8--- 6.) invoke `cabal new-build` 7.) If everything works, you'll find the `pandoc:pandoc` executable somewhere in your ~/.cabal/store/ghc-8.3.*/ folder (you can use http://hackage.haskell.org/package/cabal-plan to conveniently list the location via `cabal-plan list-bins`) 8.) As for libraries, you can either use `cabal new-repl` or you can leverage GHC's package environment files: `cabal new-build` will have generated a file like .ghc.environment.x86_64-linux-8.3.20170913 which brings into scope all transitive dependencies of `build-depends: base, lens` Now all you need to do is simply call ghc-stage2 --make MyTestProg.hs to compile a program against those libs, or start up GHCi via ghc-stage2 --interactive and you'll be thrown into that package environment. I hope you find this useful Cheers, Herbert

6 5

Spurious recompilations when using a compiler plugin
by Conal Elliott 19 Sep '17

19 Sep '17

It appears that use of GHC plugins causes client code to get needlessly recompiled. (See Trac issues 12567 <https://ghc.haskell.org/trac/ghc/ticket/12567> and 7414 <https://ghc.haskell.org/trac/ghc/ticket/7414>.) It’s becoming more of a problem for usability of the plugin <http://conal.net/papers/compiling-to-categories> I’ve been developing, and I’m wondering what can be done. Some questions: - Is there any work in progress on fixing this situation? - Are there serious obstacles to fixing it? - Do plugin writers or users have any workarounds? Other insights appreciated. – Conal

3 3

ANN: preview of alternative llvm code gen
by Moritz Angermann 19 Sep '17

19 Sep '17

Hi, as presented during the HIW at ICFP 2016, and ICFP 2017, I’ve been spending a some time on an alternative llvm backend. GHC used LLVM as an external tool, and communicates with LLVM via LLVMs Intermediate Representation. For this the LLVM backend in GHC (via `-fllvm`) writes out text files containing the textual LLVM IR, and feeds those into LLVMs the `opt` and `llc` tools to produce the final machine code. The textual IR has been changing quite a bit for each release in the past. But seems to have been quite stable from LLVM3.9 through LLVM4 and now LLVM5. However LLVM also has a binary IR called LLVM Bitcode, which is a very stable format and the one they advise to work against. Sadly, the documentation on it is mostly contained in the BitcodeReader and BitcodeWriter C++ files from the LLVM project. As Cmm hands out only labels for function without function signatures, and the LLVM backend wants to be a good consumer, we assume functions to always be pointers to int8 (i8*), as LLVM expects them to be properly typed. Of course when defining functions we do have the full function signature and also need it to pass arguments. Yet to make i8* assumption work, we create aliases for each function we define, that are of type i8*. On macOS (and iOS) where the mach-o format is used, the linker uses a feature called `subsections_via_symbols` to strip dead code. This works, by assuming that all code between two symbols belongs to the first symbol. GHCs use of Tables Next To Code, and the `prefixdata` feature that was added to llvm just for this purpose however put data in front of symbols, and the linker will strip that data if it determines the previous symbol is not used. Thus we can not strip any code on macOS or iOS produced by GHC. The NCG inserts `$dsp` suffix symbols in front of the TNTC data, and marks those as used, to work around the dead-strip issue. The current llvm backend uses the LLVMManger to strip out the `.symbols_via_subsections` directive from the generated assembly prior to handing it off to the assembler. I therefore sat out to try and see if I could fix some of the issues we ran into. This has lead to building three libraries: - data-bitcode (github.com/angerman/data-bitcode) A bitcode reader/writer. In itself Bitcode is a rather simple encoding format. It is based on sequences of bits as opposed to bytes. And encoded so called blocks (with IDs), that can give meaning to records (think: structs) that are in those blocks. It also comes with a compression mechanism, where one can define so called abbreviated records (think: packed structs). - data-bitcode-llvm (github.com/angerman/data-bitcode-llvm) A package to model LLVM modules, and lower them into the bitcode AST - data-bitcode-edsl (github.com/angerman/data-bitcode-edsl) A Haskell EDSL, that allows to construct LLVM modules. E.g. testModule :: Module testModule = mod "undef" [ def "main" ([i32, ptr =<< i8ptr] --> i32) $ \[ argc, argv ] -> mdo block "entry" $ do mem <- undef =<< (arr 10 =<< i8) memG <- global (mutable . private) "mem" mem ptr <- gep memG =<< sequence [int32 0, int32 0] memset <- fun "llvm.memset.p0i8.i32" =<< [i8ptr, i8, i32, i32, i1] --> void ccall memset =<< (ptr:) <$> sequence [ int8 0, int32 10, int32 4, int 1 0 ] ret =<< int32 0 pure () ] More examples can be found in github.com/angerman/data-bitcode-edsl/blob/master/test/EDSLSpec.hs With this in hand, I went a head and ported the existing llvm code gen to use the EDSL instead of concatenating strings. After this introduction, I’m now pleased to inform you that the `llvmng` backend now passes fast and slow validation, with the exception of the peculiar case of T6084 (ghc.haskell.org/t/6084) where the callee and caller signatures do not match up, and this causes the `llvmng` backend to topple over. Another note is in order: the llvmng backend is currently quite a bit more memory hungry and time consuming than the current llvm backend for non trivial modules. We do get dead-strippable binaries through (for `main = putStrLn “hello world”`): 1.2M Main8.2-llvm 972k MainHEAD-llvmng The relevant code can be found in github.com/zw3rk/ghc/tree/llvm-ng Cheers, Moritz Validation Results Below: fast validation: Unexpected results from: TEST="MultiLayerModules T12707 T13379 T13701 T13719 T6084 T9630" SUMMARY for test run started at Tue Sep 19 12:53:34 2017 +08 0:08:06 spent to go through 6077 total tests, which gave rise to 23781 test cases, of which 16423 were skipped 17 had missing libraries 2392 expected passes 32 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 1 unexpected failures 6 unexpected stat failures Unexpected failures: codeGen/should_run/T6084.run T6084 [exit code non-0] (llvmng) Unexpected stat failures: perf/compiler/T13379.run T13379 [stat not good enough] (llvmng) perf/compiler/T9630.run T9630 [stat not good enough] (llvmng) perf/compiler/T12707.run T12707 [stat not good enough] (llvmng) perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good enough] (llvmng) perf/compiler/T13719.run T13719 [stat not good enough] (llvmng) perf/compiler/T13701.run T13701 [stat not good enough] (llvmng) slow validation: Unexpected results from: TEST="MultiLayerModules T12707 T13379 T13701 T13719 T6084 T9630" SUMMARY for test run started at Tue Sep 19 13:14:18 2017 +08 0:28:57 spent to go through 6077 total tests, which gave rise to 23908 test cases, of which 16302 were skipped 69 had missing libraries 6223 expected passes 72 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 3 unexpected failures 12 unexpected stat failures Unexpected failures: codeGen/should_run/T6084.run T6084 [exit code non-0] (llvmng) codeGen/should_run/T6084.run T6084 [exit code non-0] (llvmng) codeGen/should_run/T6084.run T6084 [exit code non-0] (llvmng) Unexpected stat failures: perf/compiler/T13379.run T13379 [stat not good enough] (llvmng) perf/compiler/T13379.run T13379 [stat not good enough] (llvmng) perf/compiler/T9630.run T9630 [stat not good enough] (llvmng) perf/compiler/T12707.run T12707 [stat not good enough] (llvmng) perf/compiler/T9630.run T9630 [stat not good enough] (llvmng) perf/compiler/T12707.run T12707 [stat not good enough] (llvmng) perf/compiler/T13719.run T13719 [stat not good enough] (llvmng) perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good enough] (llvmng) perf/compiler/T13701.run T13701 [stat not good enough] (llvmng) perf/compiler/T13719.run T13719 [stat not good enough] (llvmng) perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good enough] (llvmng) perf/compiler/T13701.run T13701 [stat not good enough] (llvmng)

1 0

A type checker plugin for row types
by Nicolas Frisby 18 Sep '17

18 Sep '17

Hi all. I've been spending my free time for the last couple months on a type checker plugin for row types. The free time waxes and wanes; sending an email like this one was my primary goal for the past couple weeks. At the very least, I hoped this project would let me finally get some hands on experience with OutsideIn. And I definitely have. But I've also made more progress than I anticipated, and I think the plugin is starting to have legs! I haven't uploaded the code yet to github -- it's not quite ready to share. But I did do a write up on the dev wiki. https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain I would really appreciate and questions, comments, and --- boy, oh boy --- answers. I hope to upload within a week or so, and I'll update that wiki page and reply to this email when I do. Thanks very much. -Nick P.S. -- I've CC'd and BCC'd people who I anticipate would be specifically interested in this (e.g. plugins, row types, etc). Please feel free to forward to others that come to mind; I know some inboxes abjectly can't afford default list traffic. P.P.S. -- One hold up for the upload is: which license? I intend to release under BSD3, mainly to match GHC since one ideal scenario would involve being packaged with/integrated into GHC. But my brief recent research suggests that the Apache license might be more conducive to eventual widespread adoption. If you'd be willing to advise or even just refer me to other write ups, please feel free to email me directly or to start a separate thread on a more appropriate distribution list (CC'ing me, please). Thanks again.

8 16

-0 rational?
by Moritz Angermann 18 Sep '17

18 Sep '17

Hi *, I just ran into the following case: > fromRat (-0 :: Rational) :: Double 0.0 > -0 :: Rational 0 % 1 How do I encode negative zero as a rational? The question come up as `CmmFloat` is defined as `CmmFloat Rational Width` in compiler/cmm/CmmExpr.hs. And my code generator thus turned (Int, Rational) into a floating point expression, and when trying to turn it into a `double` value, I ended up getting bad negative zeros. This makes me believe I can’t actually encode `-0` as a Rational, and such `CmmFloat` will never contain `-0`? Cheers, Moritz

2 1

Feedback request regarding HSOC project (bringing sanity to the GHC performance test-suite)
by Jared Weakly 15 Sep '17

15 Sep '17

Hey y'all, A quick ToC before I dive right in: * What my HSOC project is on * My progress so far * Feedback welcome * What I have left to do * Theoretical potential improvements ----------- My HSOC project was on bringing sanity to the GHC performance test-suite. My blog post on this is here: https://jaredweakly.com/blog/haskell-summer-of-code/ The Trac ticket that corresponds to this is here: https://ghc.haskell.org/trac/ghc/ticket/12758 The Phabricator ticket for this patch: https://phabricator.haskell.org/D3758 The tl;dr of my HSOC project is that GHC's performance tests currently require the programmer to add in expected numbers manually, updated them, handhold the testsuite, etc. This is a bit absurd and my project's overall aim is to reduce the effort required of the programmer to as close to zero as possible while simultaneously increasing the potential ability of the testsuite to catch regressions as much as possible. ------------ My progress so far: - I have a few comparison tools in perf_notes.py. These allow people to compare performance numbers of tests across commits - I have all the performance numbers generated by running the tests automatically stored in git notes and referenced by both the comparison tool and the testsuite - I have refactored the testsuite to use my new code that pulls expected numbers automatically from git notes (trivially passing if the note does not yet exist for that test), then it compares that expected number with the number that was gotten from running the testsuite on the latest commit. The comparison passes if it's within a certain deviation (20% by default, but can be customized by the programmer). - I have refactored all of the all.T files to use the new comparison functions for the performance tests and ensured that this doesn't break any existing tests. ------------ Anyone who wants to checkout the wip/perf-testsuite and try this out is more than welcome. Feedback on anything is welcome; comments are appreciated; discussion is welcome, etc. ------------- What I have left to do is: 1. Finish writing up the documentation 2. Update the wiki in all the relevant places concerning additions/modifications to the testsuite and test driver 3. Make sure everyone is happy with the change (and make small changes as necessary) -------------- Possible features and improvements I am thinking about adding in: * As a stopgap to full integration with performance tracking tools (such as Gipedia), optionally emitting a test warning with the test summary if there is any regression detected whatsoever (even if the number falls within the allowed deviation) * Some tests, such as T7702, have a somewhat nonsensical regression percentage. Ideally the testsuite could handle those better. I could potentially build in multiple ways to determine a regression (percentage, 'above a certain value', 'taking longer than X amount of time', as potential examples) * Currently some tests require installing some Haskell packages; they are skipped if the packages are not installed. I could try to build in a way to automatically attempt to install all necessary Haskell packages if someone attempts to run a test that requires them. (Perhaps using a command such as 'make test exhaustive') * The performance metric 'peak_megabytes' is sometimes not accurate enough; I could see if adding something like `RTS -h -i0.01` automatically to tests that use 'peak_megabytes' would resolve that. Currently it is a manual debugging step. Any thoughts? Comments? Questions? Regards, Jared Weakly

4 6

Overapproximation of loopbreakers due to unfoldings
by Matthew Pickering 15 Sep '17

15 Sep '17

I have been puzzling over the example presented by Harendra in #14211 for the last two days. Ultimately it led me to discover that if a self-recursive definition is marked with an INLINE pragma then it will always be marked as a loopbreaker. This is undesirable in this case as the simplifier ends up with in the first pass.. bindWith = ... bindWith ... => bindWith = bindWith_abc |> co bindWith_abc = ... bindWith ... So we can then inline `bindWith` into the RHS of `bindWith_abc` and create a single self-recursive function rather than a mutually recursive block. Marking `bindWith` as `INLINE` means that both `bindWith` and `bindWith_abc` are marked as loopbreakers. Mutual recursive blocks are bad as they completely stop the static argument transformation from working. My question is, why is it necessary to mark "bindWith" as a loopbreaker in the current module? Are there any tickets or notes which discuss this problem? Matt

2 1

Phab: conditional approval
by Richard Eisenberg 14 Sep '17

14 Sep '17

Hi devs, When reviewing a diff on Phab, I can "accept" or "request changes". Sometimes, though, I want to do both: I suggest very minor (e.g., typo) changes, but then when these changes are made, I accept. I'm leery of making the suggestions and saying "accept", because then someone working quickly may merge without noticing the typos. Does Phab have such an option? Thanks, Richard

4 5

Perf improvement
by Simon Peyton Jones 14 Sep '17

14 Sep '17

I'm seeing this in validate 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 T5837(normal) bytes allocated: 56782344 +/-7% Lower bound T5837(normal) bytes allocated: 52807579 Upper bound T5837(normal) bytes allocated: 60757109 Actual T5837(normal) bytes allocated: 52424864 Deviation T5837(normal) bytes allocated: -7.7 % *** unexpected stat test failure for T5837(normal) Does anyone else? Simon

2 3

./validate --slow results
by Bartosz Nitka 14 Sep '17

14 Sep '17

Hi all, I happened to run ./validate --slow on my linux machine and I thought it would be useful to share the results. Results: Unexpected results from: TEST="EtaExpandLevPoly PatternSplice StrictPats T10508_api T11627b T12809 T12870a T12870b T12870c T12870d T12870e T12870f T12870g T12870h T12903 T12962 T13366 T13543 T13688 T13780c T13822 T13949 T14137 T2552 T2783 T3001-2 T4114c T4114d T4188 T4334 T5129 T5363 T5559 T5611 T680 T7411 T7837 T7944 T8025 T8089 T8542 TH_spliceE5_prof_ext UnsafeReenter compact_gc compact_share dsrun014 dynamic-paper haddock.Cabal hpc_fork prof-doc-fib prof-doc-last profinline001 read029 return_mem_to_os rn041 scc001 scc002 scc003 scc005 space_leak_001 tc165 tryReadMVar2" SUMMARY for test run started at Thu Sep 14 04:57:20 2017 PDT 0:12:27 spent to go through 6091 total tests, which gave rise to 24105 test cases, of which 4531 were skipped 143 had missing libraries 19120 expected passes 203 expected failures 0 caused framework failures 0 caused framework warnings 6 unexpected passes 97 unexpected failures 5 unexpected stat failures Unexpected passes: /tmp/ghctest-e17wqi8b/test spaces/./dependent/should_compile/dynamic-paper.run dynamic-paper [unexpected] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./indexed-types/should_compile/T7837.run T7837 [unexpected] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./parser/should_compile/read029.run read029 [unexpected] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./rename/should_compile/rn041.run rn041 [unexpected] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./simplCore/should_fail/T7411.run T7411 [unexpected] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_compile/tc165.run tc165 [unexpected] (optasm) Unexpected failures: /tmp/ghctest-e17wqi8b/test spaces/./codeGen/should_run/T5129.run T5129 [bad exit code] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./codeGen/should_run/T5129.run T5129 [bad exit code] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./codeGen/should_run/T5129.run T5129 [bad exit code] (threaded2) /tmp/ghctest-e17wqi8b/test spaces/./codeGen/should_run/T5129.run T5129 [bad exit code] (dyn) /tmp/ghctest-e17wqi8b/test spaces/./concurrent/should_run/T5611.run T5611 [bad stdout] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./concurrent/should_run/tryReadMVar2.run tryReadMVar2 [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (threaded2) /tmp/ghctest-e17wqi8b/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (dyn) /tmp/ghctest-e17wqi8b/test spaces/./dependent/should_fail/T13780c.run T13780c [stderr mismatch] (normal) /tmp/ghctest-e17wqi8b/test spaces/./dependent/should_compile/dynamic-paper.run dynamic-paper [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./driver/T4114d.run T4114d [bad exit code] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./driver/T4114c.run T4114c [bad exit code] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./ghc-api/T10508_api.run T10508_api [bad exit code] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./numeric/should_compile/T8542.run T8542 [stderr mismatch] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./ghc-api/T10508_api.run T10508_api [bad exit code] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/./partial-sigs/should_compile/PatternSplice.run PatternSplice [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./patsyn/should_run/T13688.run T13688 [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./patsyn/should_run/T13688.run T13688 [exit code non-0] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T3001-2.run T3001-2 [exit code non-0] (prof_hb) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/scc003.run scc003 [bad profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T11627b.run T11627b [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T12962.run T12962 [bad profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/scc003.run scc003 [bad profile] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T12962.run T12962 [bad profile] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/scc003.run scc003 [bad profile] (prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T12962.run T12962 [bad profile] (prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/scc001.run scc001 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/scc005.run scc005 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/profinline001.run profinline001 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T5559.run T5559 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T11627b.run T11627b [bad heap profile] (prof_hc_hb) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/scc003.run scc003 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T680.run T680 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/scc002.run scc002 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T12962.run T12962 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/prof-doc-fib.run prof-doc-fib [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T11627b.run T11627b [bad heap profile] (prof_hb) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T2552.run T2552 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/prof-doc-last.run prof-doc-last [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T11627b.run T11627b [bad heap profile] (prof_hd) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T5363.run T5363 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T11627b.run T11627b [bad heap profile] (prof_hy) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T11627b.run T11627b [bad heap profile] (prof_hr) /tmp/ghctest-e17wqi8b/test spaces/./rts/T2783.run T2783 [bad exit code] (threaded1) /tmp/ghctest-e17wqi8b/test spaces/./rts/return_mem_to_os.run return_mem_to_os [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./rts/T12903.run T12903 [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870a.run T12870a [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870f.run T12870f [bad stdout] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870b.run T12870b [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870c.run T12870c [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870e.run T12870e [bad stdout] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870d.run T12870d [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870b.run T12870b [bad exit code] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870f.run T12870f [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870c.run T12870c [bad exit code] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870e.run T12870e [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870g.run T12870g [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870h.run T12870h [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870h.run T12870h [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870f.run T12870f [bad stdout] (threaded2) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870e.run T12870e [bad stdout] (threaded2) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870f.run T12870f [bad stdout] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870e.run T12870e [bad stdout] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/./simplCore/should_compile/T7944.run T7944 [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./simplCore/should_compile/T13543.run T13543 [stderr mismatch] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./simplCore/should_compile/T13543.run T13543 [stderr mismatch] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./simplCore/should_compile/T13543.run T13543 [stderr mismatch] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./simplCore/should_compile/T14137.run T14137 [stderr mismatch] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./th/TH_spliceE5_prof_ext.run TH_spliceE5_prof_ext [bad exit code] (normal) /tmp/ghctest-e17wqi8b/test spaces/./th/T4188.run T4188 [exit code non-0] (normal) /tmp/ghctest-e17wqi8b/test spaces/./th/T4188.run T4188 [exit code non-0] (ext-interp) /tmp/ghctest-e17wqi8b/test spaces/./th/T13366.run T13366 [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./th/should_compile/T8025/T8025.run T8025 [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./th/should_compile/T13949/T13949.run T13949 [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_compile/T13822.run T13822 [exit code non-0] (normal) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_compile/T13822.run T13822 [exit code non-0] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_compile/T13822.run T13822 [exit code non-0] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_compile/T13822.run T13822 [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_run/T12809.run T12809 [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_run/StrictPats.run StrictPats [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [exit code non-0] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/base/tests/T8089.run T8089 [bad exit code] (ghci) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/base/tests/T8089.run T8089 [bad exit code] (threaded1) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/base/tests/T8089.run T8089 [bad exit code] (threaded2) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/base/tests/T8089.run T8089 [bad exit code] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/hpc/tests/fork/hpc_fork.run hpc_fork [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/ghc-compact/tests/compact_share.run compact_share [bad stdout] (profasm) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/ghc-compact/tests/compact_share.run compact_share [bad stdout] (ghci) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/ghc-compact/tests/compact_gc.run compact_gc [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/ghc-compact/tests/compact_share.run compact_share [bad stdout] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/./ffi/should_fail/UnsafeReenter.run UnsafeReenter [bad exit code] (threaded1) /tmp/ghctest-e17wqi8b/test spaces/./ffi/should_fail/UnsafeReenter.run UnsafeReenter [bad exit code] (threaded2) /tmp/ghctest-e17wqi8b/test spaces/./ffi/should_fail/UnsafeReenter.run UnsafeReenter [bad exit code] (profthreaded) Unexpected stat failures: /tmp/ghctest-e17wqi8b/test spaces/./perf/haddock/haddock.Cabal.run haddock.Cabal [stat not good enough] (normal) /tmp/ghctest-e17wqi8b/test spaces/./perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./perf/space_leaks/T4334.run T4334 [stat not good enough] (threaded2) /tmp/ghctest-e17wqi8b/test spaces/./perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (dyn) >From my point of view, with this amount of failures it's difficult to tell if a new change introduces problems. Shall we mark them as broken and open tickets for follow ups? Cheers, Bartosz

3 2