- ghc-devs - Haskell.org

Re: [Haskell-cafe] GHC 8.2.2 for WSL Ubuntu 16.04
by Herbert Valerio Riedel 13 Feb '18

13 Feb '18

Hello *, Even though WSL may eventually address this issue for good, I've setup a new WSL-optimised flavour of my PPA for Ubuntu 16.04 LTS https://launchpad.net/~hvr/+archive/ubuntu/ghc over at https://launchpad.net/~hvr/+archive/ubuntu/ghc-wsl I don't have experience myself with Ubuntu on WSL, but it should be simply a matter of using sudo add-apt-repository ppa:hvr/ghc-wsl sudo apt-get update and then sudo apt-get install ghc-8.2.2-prof cabal-install-head Then simply add `/opt/ghc/bin` to your `$PATH` (see instructions at https://launchpad.net/~hvr/+archive/ubuntu/ghc ) There are also builds of GHC 8.0.2 and GHC 8.4.1-alpha (may still be building as of writing) in this new ghc-for-wsl PPA. I'd appreciate if somebody could test whether these GHC binaries work as intended on the non-insider Windows 10 builds and let me know. Cheers, Herbert On Tue, Feb 13, 2018 at 12:21 PM, Yitzchak Gale <gale(a)sefer.org> wrote: > I wrote: >>> I have made available a build of GHC 8.2.2 with the config option: >>> --disable-large-address-space >>> [2] https://github.com/Microsoft/WSL/issues/1671 > > Shao Cheng wrote: >> Thank you! A simpler fix for WSL ghc users is upgrading to fast ring of >> insider builds, the mmap overhead is much lower and ghc startup lag is >> barely noticable. > > Thanks, that's good news. I can't use an insider build - I need to be on > standard Windows in order to support our customers. The latest reports > in the GitHub issue seemed to indicate that the slowness is still quite > significant even on insider builds. I'm glad to hear you say that this is no > longer true. I am looking forward to regular GHC binary tarballs working > normally on regular WSL sometime in the near future. > > Yitz > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

1 0

StgLint worth maintaining?
by Ömer Sinan Ağacan 10 Feb '18

10 Feb '18

Hi, I've been looking into some StgLint-related tickets: - #13994: Found a StgLint problem and fixed, there's another problem waiting to be fixed. Both related with the fact that after unarisation we lose even more typing information and type checks needs to be relaxed. - #14116: StgLint failed to look through newtypes, and because coercions are removed at that point it failed to type check. Solution was to relax type checks. - #5345: Because `unsafeCoerce# is operationally no-op, and we don't have coercions in STG, StgLint can't type check at all. The commit message notes: > Fundamentally STG Lint is impossible, because unsafeCoerce# > can randomise all the types. > This patch does a bit of fiddle faddling in StgLint which > makes it a bit better, but it's a losing battle. - #14117: Related with StgLint not keeping up with recent changes (join points), because it's not enabled by default in tests/validate. - #14118: Related with the fact that pre- and post-unarise we have different invariants in STG. Solution was to add a "unarise" parameter and do different checks based on that. - #14120: Again type checking errors. Commit for #14116 also fixes this. The commits compares `typePrimRep`s of types instead of comparing actual types (even this is not enough, see #13994). All this of course took time to debug. In addition, the new `StgCSE` pass makes transformations that trigger case alternative checks (and probably some other checks) because scrutinee and result won't have same types after the transformation described in `Note [Case 2: CSEing case binders]`. There's also this comment in StgLint.hs WARNING: ~~~~~~~~ This module has suffered bit-rot; it is likely to yield lint errors for Stg code that is currently perfectly acceptable for code generation. Solution: don't use it! (KSW 2000-05). It seems like it hasn't been used since 2000. All this suggests that - Checks related to types are impossible in StgLint. (see e.g. commit messages in #5345, #1420, transformations done by unariser and StgCSE) - It's not enabled since 2000, which I think means that it's not needed. This makes me question whether it's worth maintaining. Maybe we should just remove it. If we still want to keep we should decide on what it's supposed to do. Only invariants I can think of are: - After unarise there should be no unboxed tuple and sum binders. unarise is a simple pass and does same thing to all binders, there are no tricky cases so I'm not sure if we need to check this. - Variables should be defined before use. I again don't know if this should be checked, could this be useful for StgCSE? So I think we should do one of these: 1. Remove StgLint. 2. Rewrite it to only check these two and nothing else, enable it in validate (and in other build flavours that enable CoreLint). What do you think? If you think we should keep StgLint, can you think of any other checks? If we could reach a consensus I'm hoping to update StgLint (or remove it). Thanks, Ömer

2 2

RE: about GHC API: Looking up names
by Simon Peyton Jones 09 Feb '18

09 Feb '18

Ranjit Have you read Note [The equality types story] in compiler/prelude/TysPrim? As you’ll see (~) is actually a class; the equality predicate is (~#). There doesn’t seems to be a named-function predicate that checks for it explicitly, but if you grep for eqTyCon you’ll see lots of tests for it. I’m sure these tests could be tideied up into a smaller collection of predicates. Simon From: rjhala(a)eng.ucsd.edu [mailto:rjhala@eng.ucsd.edu] On Behalf Of Ranjit Jhala Sent: 09 February 2018 04:41 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: about GHC API: Looking up names Dear Simon, still working on the above, but hit an odd problem on the way. How can I "test for" (i.e. write a function of type `Type -> Bool`) that returns `True` for values (i.e. `Type`s) that print out as: typ ~ GHC.Types.Int<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2FGHC.Types.I…> or with, which some more detail, looks like (~ (TYPE LiftedRep) typ GHC.Types.Int<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2FGHC.Types.I…>) I would have thought that `Type.isEqPred` or `Type.isNomEqPred` described here https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/ghc-8.2.1/src/…<https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloads.ha…> would work, but apparently not? Any clues? Thanks! - Ranjit. On Thu, Feb 1, 2018 at 8:25 AM, Ranjit Jhala <jhala(a)cs.ucsd.edu<mailto:jhala@cs.ucsd.edu>> wrote: Will do! Best, Ranjit. On Thu, Feb 1, 2018 at 5:20 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: I’m glad you are un-glued, but it smells wrong to me and your solution seems like a workaround for a bug, not the Right Path. Could you make a ticket with a repro case? Thanks! Simon From: rjhala(a)eng.ucsd.edu<mailto:rjhala@eng.ucsd.edu> [mailto:rjhala@eng.ucsd.edu<mailto:rjhala@eng.ucsd.edu>] On Behalf Of Ranjit Jhala Sent: 31 January 2018 19:14 To: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Subject: Re: about GHC API: Looking up names Dear Simon, No worries, I was able to figure it out, or at least work around it. > It’s very mysterious that declaring it in an > instance decl would make any difference. It looks like that is exactly what is happening, but perhaps by design? (I saw there was something called an `ImplicitTyThing` that are not in the top-level scope, so I figured that perhaps these instance declarations were "implicit" and hence not available?) Nevertheless, I was able to work around the issue by using `tcGetFamInstEnvs` to get the `FamInstEnv` and from that, making my own lookup environment (comprising the TyCon and DataCon for the family instances.) This works for my purposes, but if the above is a possible bug, I can try to make a small test case? Thanks! - Ranjit. On Wed, Jan 31, 2018 at 1:47 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Hi Ranjit That does sound odd. You should ask on ghc-devs too… though you may already have done that. hscTcRnLookupName doesn’t do anything fancy: it just looks up the Name in the type environment. It’s very mysterious that declaring it in an instance decl would make any difference. I suppose you could somehow have gotten hold of the wrong Name. If I was debugging it, I’d start spitting out traces showing the type environment it is looking up in, to see what is there and what is not. If you make a small standalone test case (e.g. a tiny client of the GHC API that demonstrates the problem) that could enable others to reproduce and help you. Or, I guess, we could do a Skype chat with you trying things locally. I wish I could help more Simon From: rjhala(a)eng.ucsd.edu<mailto:rjhala@eng.ucsd.edu> [mailto:rjhala@eng.ucsd.edu<mailto:rjhala@eng.ucsd.edu>] On Behalf Of Ranjit Jhala Sent: 26 January 2018 02:12 To: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Subject: Q: about GHC API: Looking up names Dear Simon, I have a question about the GHC API I wonder you can help with? Suppose `Library.hs` is has the constructors defined in the simple top-level style: ``` data EntityField typ where BlobXVal :: EntityField Int BlobYVal :: EntityField Int ``` Then when analyzing `Client.hs` (that imports `Library`), the lookup function `hscTcRcLookupName` WORKS just fine to give me the `TyThing` corresponding to the name “BlobXVal”. However, if instead, Library.hs defines the constructors within an instance: ``` instance PersistEntity Blob where data EntityField Blob typ where BlobXVal :: EntityField Blob Int BlobYVal :: EntityField Blob Int ``` then, when analyzing Client.hs, the `hscTcRcLookupName` function FAILS to resolve the name. Clearly there is some difference in how `hscTcRcLookupName` works in these two cases. Does you know what it is? Thanks in advance!

1 0

Can't typeset docs
by Simon Peyton Jones 08 Feb '18

08 Feb '18

When I have BUILD_SPHINX_HTML = YES BUILD_SPHINX_PDF = YES I get this error in my build. Any ideas? I think Sphinx is up to date. Thanks Simon sh validate --fast --no-clean using THREADS=33 make: Entering directory '/5playpen/simonpj/HEAD-3/utils/checkUniques' ./check-uniques.py ../.. make: Leaving directory '/5playpen/simonpj/HEAD-3/utils/checkUniques' ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for 'phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final all /usr/bin/sphinx-build -b html -d docs/users_guide/.doctrees-html -D latex_paper_size=letter docs/users_guide docs/users_guide/build-html/users_guide /usr/bin/sphinx-build -b latex -d docs/users_guide/.doctrees-pdf -D latex_paper_size=letter docs/users_guide docs/users_guide/build-pdf/users_guide /usr/bin/sphinx-build -b man -d docs/users_guide/.doctrees-man docs/users_guide docs/users_guide/build-man Running Sphinx v1.3.6 making output directory... Running Sphinx v1.3.6 Exception occurred: making output directory... Exception occurred: Running Sphinx v1.3.6 making output directory... Exception occurred: File "conf.py", line 13, in <module> from ghc_config import extlinks, version ImportError: No module named ghc_config File "conf.py", line 13, in <module> from ghc_config import extlinks, version ImportError: No module named ghc_config File "conf.py", line 13, in <module> from ghc_config import extlinks, version ImportError: No module named ghc_config The full traceback has been saved in /tmp/sphinx-err-d_zVKs.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks! The full traceback has been saved in /tmp/sphinx-err-hbXcSK.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks! The full traceback has been saved in /tmp/sphinx-err-lmyy8H.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks! docs/users_guide/ghc.mk:28: recipe for target 'docs/users_guide/build-man/ghc.1' failed make[1]: *** [docs/users_guide/build-man/ghc.1] Error 1 make[1]: *** Waiting for unfinished jobs.... docs/users_guide/ghc.mk:16: recipe for target 'docs/users_guide/users_guide.pdf' failed make[1]: *** [docs/users_guide/users_guide.pdf] Error 1 docs/users_guide/ghc.mk:16: recipe for target 'docs/users_guide/build-html/users_guide/index.html' failed make[1]: *** [docs/users_guide/build-html/users_guide/index.html] Error 1 Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 simonpj@cam-05-unx:~/5builds/HEAD-3$

2 3

Windows build broken -- help!
by Simon Peyton Jones 08 Feb '18

08 Feb '18

Aargh. Windows build is broken again. Log below. Help! Simon "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-DWINVER=0x06000100 -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgPrimFloat.c -o rts/dist/build/StgPrimFloat.o rts\Schedule.c:274:14: error: error: unknown conversion type character 'l' in format [-Werror=format=] barf("sched_state: %" FMT_Word, sched_state); ^~~~~~~~~~~~~~~~ | 274 | barf("sched_state: %" FMT_Word, sched_state); | ^ In file included from C:/code/HEAD-1/inplace/mingw/x86_64-w64-mingw32/include/stdio.h:1036:0, from includes/rts/Flags.h:16, from includes/Rts.h:191, from rts\Schedule.c:11:0: error: C:/code/HEAD-1/inplace/mingw/x86_64-w64-mingw32/include/_mingw_print_pop.h:86:18: note: format string is defined here #define PRIu64 "llu" ^ rts\Schedule.c:274:14: error: error: too many arguments for format [-Werror=format-extra-args] barf("sched_state: %" FMT_Word, sched_state); ^~~~~~~~~~~~~~~~ | 274 | barf("sched_state: %" FMT_Word, sched_state); | ^ cc1.exe: all warnings being treated as errors `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-DWINVER=0x06000100 -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/Profiling.c -o rts/dist/build/Profiling.o make[1]: *** [rts/ghc.mk:295: rts/dist/build/Schedule.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:127: all] Error 2 /c/code/HEAD-1$

3 4

package01e failure
by Simon Peyton Jones 07 Feb '18

07 Feb '18

I'm getting this test failure, presumably because of a version bump in containers. I think this is a clean build from scratch. Could someone have forgotten to update a test file? Simon =====> package01e(normal) 1 of 1 [0, 0, 0] cd "./package01e.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -c package01e.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -hide-all-packages -XNoImplicitPrelude -package "containers (Data.Map as Map, Data.Set)" Actual stderr output differs from expected: diff -uw "./package01e.run/package01e.stderr.normalised" "./package01e.run/package01e.comp.stderr.normalised" --- ./package01e.run/package01e.stderr.normalised 2018-02-07 09:52:44.562487065 +0000 +++ ./package01e.run/package01e.comp.stderr.normalised 2018-02-07 09:52:44.562487065 +0000 @@ -2,9 +2,11 @@ package01e.hs:2:1: Could not find module 'Data.Map' It is a member of the hidden package 'containers-0.5.11.0'. + It is a member of the hidden package 'containers-0.5.10.2'. Use -v to see a list of the files searched for. package01e.hs:3:1: Could not find module 'Data.IntMap' It is a member of the hidden package 'containers-0.5.11.0'. + It is a member of the hidden package 'containers-0.5.10.2'. Use -v to see a list of the files searched for. *** unexpected failure for package01e(normal)

2 1

Strict unlifted types
by David Feuer 07 Feb '18

07 Feb '18

Sometimes there's an awkward expressive tension between saying that a type is *unboxed* and saying that it is *strict* in a field. For example, I can write data SMaybe a = SNothing | SJust !a or I can write type Maybe# a = (# (# #) | a #) but there doesn't seem to be a way to simultaneously get both unboxed and strict. I'm wondering if it might make sense to add a type to serve the purpose Strict# :: Type -> TYPE 'UnliftedRep mkStrict# :: a -> Strict# a -- force the argument getStrict# :: Strict# a -> a -- do nothing, but know the result is in WHNF Then one could write, for example, type SMaybe# a = (# (# #) | Strict# a #) at which point SMaybe is *precisely* isomorphic to the alternative representation data SMaybe' a = SMaybe' (SMaybe# a) David

2 1

[ANNOUNCE] GHC 8.4.1-alpha3 available
by Ben Gamari 06 Feb '18

06 Feb '18

The GHC development team is pleased to announce the third and likely last alpha release leading up to GHC 8.4.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-alpha3 Due to user demand we now offer a binary distribution for 64-bit Fedora 27, which links against ncurses6. This is in contrast to the Debian 8 distribution, which links against ncurses5. Users of newer distributions (Fedora 27, Debian Sid) should use this new Fedora 27 distribution. Also due to user demand we have reintroduced compatibility with GCC 4.4, which earlier alphas had dropped due to #14244. Note that this release is still affected by #14675, wherein the compiler will segmentation fault when built with some Ubuntu toolchains. We are actively working to identify the cause and hope that this will be resolved before the final release. === Notes on release scheduling === The 8.4.1 release marks the first release where GHC will be adhering to its new, higher-cadence release schedule [1]. Under this new scheme, major releases will be made in 6-month intervals with interstitial minor releases as necessary. In order to minimize the likelihood of schedule slippage and to ensure adequate testing, each major release will be preceded by a number of regular alpha releases. We will begin issuing these releases roughly three months before the final date of the major release and will issue roughly one every two weeks during this period. This high release cadence will allow us to quickly get fixes into users' hands and more quickly identify potential issues. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule

1 0

The BlockArguments extension has been added to Cabal
by Akio Takano 06 Feb '18

06 Feb '18

Dear GHC devs, The new `BlockArguments` extension has been added to the Cabal library. I'm sending out this notification because the Note [Adding a language extension] in compiler/main/DynFlags.hs asks me to do so. Regards, Takano Akio

3 2

RE: [commit: ghc] master: Hoopl.Collections: change right folds to strict left folds (2974b2b)
by Simon Peyton Jones 05 Feb '18

05 Feb '18

Hi Michael Thanks for pushing forward with Hoopl and other back-end things. Did this patch elicit any performance gains? Or what brought it to your attention? Do you have further plans for Hoopl and GHC's back end? Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 03 February 2018 00:56 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Hoopl.Collections: change right folds | to strict left folds (2974b2b) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha | skell.org%2Ftrac%2Fghc%2Fchangeset%2F2974b2b873b4bad007c619c6e32706123 | a612428%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C19a7af179b224ee | 8b74708d56aa0fa00%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C6365321 | 61979971135&sdata=muRQGh3GHuEirDVMUgTb0JKbBUkvqceymKFQTt9eAY0%3D&reser | ved=0 | | >--------------------------------------------------------------- | | commit 2974b2b873b4bad007c619c6e32706123a612428 | Author: Michal Terepeta <michal.terepeta(a)gmail.com> | Date: Thu Feb 1 00:30:22 2018 -0500 | | Hoopl.Collections: change right folds to strict left folds | | It seems that most uses of these folds should be strict left folds | (I could only find a single place that benefits from a right | fold). | So this removes the existing `setFold`/`mapFold`/`mapFoldWihKey` | replaces them with: | - `setFoldl`/`mapFoldl`/`mapFoldlWithKey` (strict left folds) | - `setFoldr`/`mapFoldr` (for the less common case where a right | fold | actually makes sense, e.g., `CmmProcPoint`) | | Signed-off-by: Michal Terepeta <michal.terepeta(a)gmail.com> | | Test Plan: ./validate | | Reviewers: bgamari, simonmar | | Reviewed By: bgamari | | Subscribers: rwbarton, thomie, carter, kavon | | Differential Revision: https://phabricator.haskell.org/D4356 | | | >--------------------------------------------------------------- | | 2974b2b873b4bad007c619c6e32706123a612428 | compiler/cmm/CmmCommonBlockElim.hs | 4 ++-- | compiler/cmm/CmmContFlowOpt.hs | 6 +++--- | compiler/cmm/CmmProcPoint.hs | 20 ++++++++++---------- | compiler/cmm/CmmUtils.hs | 6 +++--- | compiler/cmm/Hoopl/Collections.hs | 16 ++++++++++------ | compiler/cmm/Hoopl/Dataflow.hs | 8 ++++---- | compiler/cmm/Hoopl/Graph.hs | 6 +++--- | compiler/cmm/Hoopl/Label.hs | 9 ++++++--- | compiler/nativeGen/RegAlloc/Graph/Spill.hs | 9 ++++----- | 9 files changed, 45 insertions(+), 39 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 | 2974b2b873b4bad007c619c6e32706123a612428 | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C19a7af179b224ee8b7470 | 8d56aa0fa00%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C6365321619799 | 71135&sdata=hSeyqtbepopL%2FkSme3DPLOQQKf9WCLWsdVMh86tbx4o%3D&reserved= | 0

2 1