- ghc-devs - Haskell.org

valid substitutions for holes
by Richard Eisenberg 07 Nov '17

07 Nov '17

Hi all, GHC HEAD currently suggests valid in-scope single-identifier substitutions for typed holes (underscores in terms). Some unrelated work somehow changed the output, and I'm wondering if this is a change for the better or for the worse. The test case is this: > f :: Int -> Int -> Int > f x y = _ x y With my patch, GHC now suggests `pure` and `return` as replacements for _ (along with the other top contenders of (-), asTypeOf, and const). (You can also increase the number of suggestions, which will then include (+) and (*) among others.) It's true that `pure` and `return` fit the bill, noting that ((->) Int) is an Applicative. But I doubt these suggestions will help the user. I'm not keen to make fixing this "valid suggestions" feature (which I do really like) a dependency of finishing my patch, but I also don't want the change to output to go unnoticed. So, I'm asking: when I merge my patch, should I post a bug asking for perhaps a priority ordering of suggestions? Thanks, Richard

2 1

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2
by Sven Panne 06 Nov '17

06 Nov '17

2017-11-05 15:37 GMT+01:00 <jpaugh(a)gmx.com>: > A better approach might be to develop a "machine-readable" output format > which then is kept stable, and can be enabled with a flag. Git has a > similar solution. > Without doubt, this is definitely the better approach, but this is hardly what can be achieved for 8.2.2. Adding some flag to get the old behavior back when wanted *is* achievable. > It would be a shame to avoid changes which make the user experience better > simply because other projects cannot sync their development cycle, > Don't get me wrong: I'm all for improving user experience, but making ad hoc changes without enough thought or even a chance to get the old behavior back is probably not the right way to proceed. All SW lives in some kind of ecosystem, so it should behave well in that. And for Emacs users, the user experience has been made much worse. > especially if those projects are not universally used or required. > This is highly a matter of personal taste: No project is "universally used", so this is tautological statement. The question is: Is a minor cosmetic change really worth breaking things in one of the major IDEs? Cheers, S.

3 3

GHC build broken
by Simon Peyton Jones 06 Nov '17

06 Nov '17

Ben: I'm getting this from a clean build on Linux. Any ideas? I'm up to date on master git branch -v data-kind-syntax 4174458178 Add IfacePromotionInfo * master 436b3ef01e Clean up comments about match algorithm a bit. tc-untouchables b737a45391 More simplifications to the constraint solver type-nats 87d2a63b8d [behind 1491] Fix uses of (<=?) as a function to reduce properly. wip/pattern-synonyms e54d396752 [ahead 6, behind 4569] Comments and tracing only wip/spj-T13397 43540c8c6b Improve code generation for conditionals wip/spj-early-inline 8515fcfa91 Mark non-recursive join lambdas as one-shot simonpj@cam-05-unx:~/code/HEAD/compiler$ Simon libraries/ghc-prim/cbits/atomic.c:311:54: error: error: '__ATOMIC_SEQ_CST' undeclared (first use in this function) | 311 | __atomic_store_n((StgWord16 *) x, (StgWord16) val, __ATOMIC_SEQ_CST); | ^ libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicwrite32': make[1]: *** [libraries/ghc-prim/dist-install/build/cbits/atomic.o] Error 1 make[1]: *** Waiting for unfinished jobs.... libraries/ghc-prim/cbits/atomic.c:318:54: error: error: '__ATOMIC_SEQ_CST' undeclared (first use in this function) | 318 | __atomic_store_n((StgWord32 *) x, (StgWord32) val, __ATOMIC_SEQ_CST); | ^ libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicwrite64': libraries/ghc-prim/cbits/atomic.c:325:54: error: error: '__ATOMIC_SEQ_CST' undeclared (first use in this function) | 325 | __atomic_store_n((StgWord64 *) x, (StgWord64) val, __ATOMIC_SEQ_CST); | ^ libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicread64': libraries/ghc-prim/cbits/atomic.c:294:1: error: error: control reaches end of non-void function [-Werror=return-type] | 294 | } | ^ libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicread32': libraries/ghc-prim/cbits/atomic.c:287:1: error: error: control reaches end of non-void function [-Werror=return-type] | 287 | } | ^ libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicread16': libraries/ghc-prim/cbits/atomic.c:280:1: error: error: control reaches end of non-void function [-Werror=return-type] | 280 | } | ^ libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicread8': libraries/ghc-prim/cbits/atomic.c:273:1: error: error: control reaches end of non-void function [-Werror=return-type] | 273 | } | ^ cc1: all warnings being treated as errors `gcc' failed in phase `C Compiler'. (Exit code: 1) make[1]: *** [libraries/ghc-prim/dist-install/build/cbits/atomic.dyn_o] Error 1 <<ghc: 14960944 bytes, 10 GCs, 194012/240680 avg/max bytes residency (2 samples), 54M in use, 0.000 INIT (0.000 elapsed), 0.024 MUT (0.187 elapsed), 0.012 GC (0.033 elapsed) :ghc>> make: *** [all] Error 2 simonpj@cam-05-unx:~/5builds/HEAD$ dirs ~/5builds/HEAD ~/5builds/HEAD/testsuite/tests/typecheck/should_fail simonpj@cam-05-unx:~/5builds/HEAD$

2 2

[ANNOUNCE] GHC 8.2.2 release candidate 2
by Ben Gamari 05 Nov '17

05 Nov '17

Hello everyone, The GHC team is very pleased to announce the second candidate of the 8.2.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.2-rc2/ This is the second and hopefully last of two release candidates leading up the final 8.2.2 release. This release fixes approximately fifty bugs present in 8.2.1. These most notably include, * A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) * A correctness issue resulting in undefined behavior in some programs using STM (#14171) * A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) * clearBit of Natural no longer bottoms (#13203) * A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) * ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) * GHC again supports production of position-independent executables (#13702) * Better error messages around kind mismatches (#11198, #12373, #13530, #13610) See [1] for the full list. As always, please report any issues you encounter. Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.2.2&col=id…

4 3

Re: [ANNOUNCE] GHC 8.2.2 release candidate 2
by Ben Gamari 04 Nov '17

04 Nov '17

Peter Trommler <Peter.Trommler(a)th-nuernberg.de> writes: > Hi Ben, > > Building and packaging RC2 on openSUSE works on all openSUSE platforms. > I noticed, however, that versions of Cabal and process were downgraded > from the respective versions in ghc 8.2.1: > > Cabal 2.0.0.2 -> 2.0.0.0 > process 1.6.1.0 -> 1.6.0.0 > Thanks for pointing this out, Peter. It seems that my source distribution script cleans submodules, but doesn't actually run `git submodule update`, hence the issue. Quite unfortunate and yet another argument for building these artifacts via CI. I suppose at this point we have two options: 1. invalidate the release, cut an -rc3 and try again, or 2. make the issue known but continue testing under the assumption that the submodule issues won't interact with any of the other changes and eventually and move directly to 8.2.2 final Unfortunately at the moment I'm rather deep in debugging a codegen bug, so I don't have the bandwidth to handle either of these at the moment. Cheers, - Ben > Peter >> On 31. Oct 2017, at 19:15, Ben Gamari <ben(a)well-typed.com> wrote: >> >> >> Hello everyone, >> >> The GHC team is very pleased to announce the second candidate of the >> 8.2.2 release of the Glasgow Haskell Compiler. Source and binary >> distributions are available at >> >> https://downloads.haskell.org/~ghc/8.2.2-rc2/ >> >> [...] >> As always, please report any issues you encounter. >> >> Happy testing, >> >> - Ben

1 0

Re: [commit: ghc] master: llvmGen: Pass vector arguments in vector registers by default (15f788f)
by Gabor Greif 03 Nov '17

03 Nov '17

IIRC there are no more static flags around. So adding ":type: dynamic" each time seems redundant. Could this be automated somehow? Or should we remove ":type:" altogether? Cheers, Gabor On 11/3/17, 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/15f788f5e5096641245a4f060600a6db9… > >>--------------------------------------------------------------- > > commit 15f788f5e5096641245a4f060600a6db9cbc2c4e > Author: Ben Gamari <bgamari.foss(a)gmail.com> > Date: Thu Nov 2 17:28:40 2017 -0400 > > llvmGen: Pass vector arguments in vector registers by default > > Earlier this year Edward Kmett requested [1] that we enable passing of > vector values in vector registers by default. The GHC calling convention > changes have been in LLVM for a number of years now so let's just flip > the switch. > > [1] https://mail.haskell.org/pipermail/ghc-devs/2017-March/013905.html > > Reviewers: austin > > Subscribers: rwbarton, thomie > > Differential Revision: https://phabricator.haskell.org/D4142 > > >>--------------------------------------------------------------- > > 15f788f5e5096641245a4f060600a6db9cbc2c4e > compiler/main/DynFlags.hs | 5 +++-- > docs/users_guide/using-optimisation.rst | 12 ++++++++++++ > 2 files changed, 15 insertions(+), 2 deletions(-) > > diff --git a/compiler/main/DynFlags.hs b/compiler/main/DynFlags.hs > index a421284..825497e 100644 > --- a/compiler/main/DynFlags.hs > +++ b/compiler/main/DynFlags.hs > @@ -3757,7 +3757,7 @@ fFlagsDeps = [ > flagSpec "kill-one-shot" Opt_KillOneShot, > flagSpec "late-dmd-anal" Opt_LateDmdAnal, > flagSpec "liberate-case" Opt_LiberateCase, > - flagHiddenSpec "llvm-pass-vectors-in-regs" > Opt_LlvmPassVectorsInRegisters, > + flagSpec "llvm-pass-vectors-in-regs" > Opt_LlvmPassVectorsInRegisters, > flagHiddenSpec "llvm-tbaa" Opt_LlvmTBAA, > flagHiddenSpec "llvm-fill-undef-with-garbage" > Opt_LlvmFillUndefWithGarbage, > flagSpec "loopification" Opt_Loopification, > @@ -4051,7 +4051,8 @@ defaultFlags settings > Opt_RPath, > Opt_SharedImplib, > Opt_SimplPreInlining, > - Opt_VersionMacros > + Opt_VersionMacros, > + Opt_LlvmPassVectorsInRegisters > ] > > ++ [f | (ns,f) <- optLevelFlags, 0 `elem` ns] > diff --git a/docs/users_guide/using-optimisation.rst > b/docs/users_guide/using-optimisation.rst > index 4714de7..fc958e0 100644 > --- a/docs/users_guide/using-optimisation.rst > +++ b/docs/users_guide/using-optimisation.rst > @@ -493,6 +493,18 @@ by saying ``-fno-wombat``. > self-recursive saturated tail calls into local jumps rather than > function calls. > > +.. ghc-flag:: -fllvm-pass-vectors-in-regs > + :shortdesc: Pass vector value in vector registers for function calls > + :type: dynamic > + :reverse: -fno-llvm-pass-vectors-in-regs > + :category: > + > + :default: on > + > + Instructs GHC to use the platform's native vector registers to pass > vector > + arguments during function calls. As with all vector support, this > requires > + :ghc-flag:`-fllvm`. > + > .. ghc-flag:: -fmax-inline-alloc-size=⟨n⟩ > :shortdesc: *default: 128.* Set the maximum size of inline array > allocations > to ⟨n⟩ bytes (default: 128). > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits >

2 1

Re: [ANNOUNCE] GHC 8.2.2 release candidate 2
by Ryan Scott 03 Nov '17

03 Nov '17

I built all of Stackage with this RC the other night and didn't observe any regressions. Hooray! (Thanks to Doug Wilson for helping me get set up with his https://github.com/duog/build-stackage repo.) Ryan S.

2 1

Bringing some observable sharing to GHCi
by David Feuer 02 Nov '17

02 Nov '17

The :sprint, :print, and :force commands in GHCi fall into infinite loops when confronted by cyclical data. This bit me hard in https://phabricator.haskell.org/D4085 because that produces cyclical TypeReps, which is trouble for (e.g.) the test break011 which tries to :force a SomeException (which wraps an Exception dictionary, which has a Typeable constraint). I could try coming up with a fix myself, but I'm rather curious whether some of the work you (or others) have already done on observing GHC data graphs could be yanked into GHCi itself for this purpose. We want 1. To be able to display cyclical data in some sensible way. > x = "hi" : x > x `seq` () > :print x should print some useful representation of x. 2. To be able to force cyclical data without looping. > x = "hi" : x > :force x should print a useful representation of x.

4 3

When does GHC produce unlifted `let` bindings?
by Sebastian Graf 02 Nov '17

02 Nov '17

Hi folks, I was debugging a Core-to-Core transform for TEST=spec-inline <https://github.com/ghc/ghc/blob/fe04f3783b662c52c4a0ff36b2d62a7a575998a5/te…> and was wondering (yet again) why GHC produces unlifted `let` bindings in Core like it seems supposed to be doing <https://github.com/ghc/ghc/blob/fe04f3783b662c52c4a0ff36b2d62a7a575998a5/te…> . - Why doesn't this use `case` instead? - Is there a semantic difference? - Can `case` be used with unlifted types? - And if not, why can `let`? Unlifted `let` seems much close to `case` than to `let`. Some GHC passes seem to agree. <https://github.com/ghc/ghc/search?l=Haskell&q=%22strict+let%22&type=&utf8=%…> Cheers, Sebastian

3 4

RE: Building the docs, again
by Andrey Mokhov 01 Nov '17

01 Nov '17

> Maybe Hadrian will help here? Hadrian can build documentation in various formats but the current implementation is very coarse-grain: we either build all possible docs or no docs at all. It would be relatively easy to add more fine-grain documentation targets and modes. If someone could design/describe the requirements in a ticket that would be great. Cheers, Andrey From: Simon Peyton Jones [mailto:simonpj@microsoft.com] Sent: 01 November 2017 08:28 To: Iavor Diatchki <iavor.diatchki(a)gmail.com>; ghc-devs(a)haskell.org; Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Subject: RE: Building the docs, again It is quite confusing that we can be setting the same variable to different values in different places. It would also be quite helpful if we modified the Makefile to say `documentation build target is disabled` or some such, rather then going ahead and building the whole of GHC, only at the end to inform me that it doesn't know what is `html`. Maybe Hadrian will help here? Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Iavor Diatchki Sent: 31 October 2017 21:49 To: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: Re: Building the docs, again Hello, never mind, I figured it out---apparently the build targets were disabled for the `quick` flavor, which I was using. It is quite confusing that we can be setting the same variable to different values in different places. It would also be quite helpful if we modified the Makefile to say `documentation build target is disabled` or some such, rather then going ahead and building the whole of GHC, only at the end to inform me that it doesn't know what is `html`. -Iavor On Tue, Oct 31, 2017 at 2:26 PM Iavor Diatchki <iavor.diatchki(a)gmail.com<mailto:iavor.diatchki@gmail.com>> wrote: Hello, sometime ago, I asked if it is possible to build just the GHC docs, without building the compiler. I was told to just run `make html`. This does not appear to work, the command seems to just start building GHC. What am I doing wrong? Here is the output I see, running the command from the root of the GHC tree. > make html V=0 ===--- building phase 0 make --no-print-directory -f ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data…> 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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data…> phase=1 phase_1_builds HC [stage 0] compiler/stage1/build/BufWrite.o HC [stage 0] compiler/stage1/build/Pretty.o compilation IS NOT required HC [stage 0] compiler/stage1/build/PprColour.o compilation IS NOT required HC [stage 0] compiler/stage1/build/Outputable.o compilation IS NOT required HC [stage 0] compiler/stage1/build/Json.o compilation IS NOT required HC [stage 0] compiler/stage1/build/SrcLoc.o compilation IS NOT required HC [stage 0] compiler/stage1/build/BasicTypes.o compilation IS NOT required HC [stage 0] compiler/stage1/build/Unique.o HC [stage 0] compiler/stage1/build/Packages.o-boot compilation IS NOT required HC [stage 0] compiler/stage1/build/FiniteMap.o compilation IS NOT required HC [stage 0] compiler/stage1/build/Name.o-boot (then I interrupted it). Also, in `mk/config.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fconfig.mk&d…>` I see this: BUILD_SPHINX_HTML = YES -Iavor

3 2