- ghc-devs - Haskell.org

Fwd: [commit: ghc] master: Use https links in user-facing startup and error messages (a1c0b70)
by Sylvain Henry 15 Dec '18

15 Dec '18

Hi Ben, I've just noticed that when you commit a diff from phab (as below), you are assigned both as committer and *author* (see also here https://git.haskell.org/ghc.git/commitdiff/a1c0b70638949a73bbd404c11797f2ed…) Reviewers and subscribers to the phab diff are indicated in the commit message but not the author (here Ingo Blechschmidt "iblech"). I'm worried that if the Phabricator instance goes down we won't be able to retrieve commit authors. And also that they are not credited appropriately (cf git shortlog -sne). (By the way, I've also noticed that .mailmap contents isn't up to date: `git shortlog -se | cut -f2 | cut -d'<' -f1 | uniq -d` isn't empty. Maybe you could add a check in a script somewhere to ensure that it stays empty when you push a commit?). Regards, Sylvain -------- Forwarded Message -------- Subject: [commit: ghc] master: Use https links in user-facing startup and error messages (a1c0b70) Date: Sat, 15 Dec 2018 00:49:47 +0000 (UTC) From: git(a)git.haskell.org Reply-To: ghc-devs(a)haskell.org To: ghc-commits(a)haskell.org Repository : ssh://git@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/a1c0b70638949a73bbd404c11797f2edf… > --------------------------------------------------------------- commit a1c0b70638949a73bbd404c11797f2edf28f5965 Author: Ben Gamari <ben(a)smart-cactus.org> Date: Fri Dec 14 11:10:56 2018 -0500 Use https links in user-facing startup and error messages I consider myself lucky that in my circle of friends, `http` urls (as opposed to `https` urls) are frowned upon in that we generally apologize in the rase cases that we share an `http` url. This pull request changes `http` links into their `https` analogues in the following places: * In the GHCI startup message (and parts of the User's Guide, where there are verbatim transcripts of GHCi sessions). * In a couple of error messages, asking the user to report a bug. (I also took the liberty to change a single space before the reportabug url into two spaces, harmonizing this occurence with the others.) I'm not trying to start a war. I just had a moment to spare and felt like preparing this diff. Merge or don't merge as you wish! Reviewers: bgamari, erikd, simonmar Subscribers: goldfire, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5450 > --------------------------------------------------------------- a1c0b70638949a73bbd404c11797f2edf28f5965 compiler/typecheck/TcTyClsDecls.hs | 2 +- compiler/utils/Panic.hs | 2 +- docs/users_guide/ghci.rst | 4 ++-- ghc/GHCi/UI.hs | 2 +- rts/RtsMessages.c | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/compiler/typecheck/TcTyClsDecls.hs b/compiler/typecheck/TcTyClsDecls.hs index cc9779a..71899a1 100644 --- a/compiler/typecheck/TcTyClsDecls.hs +++ b/compiler/typecheck/TcTyClsDecls.hs @@ -3609,7 +3609,7 @@ checkValidRoles tc report_error doc = addErrTc $ vcat [text "Internal error in role inference:", doc, - text "Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug"] + text "Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug"] {- ************************************************************************ diff --git a/compiler/utils/Panic.hs b/compiler/utils/Panic.hs index 03f095b..4f0f3b1 100644 --- a/compiler/utils/Panic.hs +++ b/compiler/utils/Panic.hs @@ -168,7 +168,7 @@ showGhcException exception showString "panic! (the 'impossible' happened)\n" . showString (" (GHC version " ++ cProjectVersion ++ " for " ++ TargetPlatform_NAME ++ "):\n\t") . s . showString "\n\n" - . showString "Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\n" + . showString "Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug\n" throwGhcException :: GhcException -> a diff --git a/docs/users_guide/ghci.rst b/docs/users_guide/ghci.rst index 49a96ca..f468e80 100644 --- a/docs/users_guide/ghci.rst +++ b/docs/users_guide/ghci.rst @@ -37,7 +37,7 @@ command ``ghci``: .. code-block:: none $ ghci - GHCi, version 8.y.z: http://www.haskell.org/ghc/ :? for help + GHCi, version 8.y.z: https://www.haskell.org/ghc/ :? for help Prelude> There may be a short pause while GHCi loads the prelude and standard @@ -2052,7 +2052,7 @@ by using the :ghc-flag:`-package ⟨pkg⟩` flag: .. code-block:: none $ ghci -package readline - GHCi, version 8.y.z: http://www.haskell.org/ghc/ :? for help + GHCi, version 8.y.z: https://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading package readline-1.0 ... linking ... done. Prelude> diff --git a/ghc/GHCi/UI.hs b/ghc/GHCi/UI.hs index ae8ba02..13275f8 100644 --- a/ghc/GHCi/UI.hs +++ b/ghc/GHCi/UI.hs @@ -162,7 +162,7 @@ defaultGhciSettings = ghciWelcomeMsg :: String ghciWelcomeMsg = "GHCi, version " ++ cProjectVersion ++ - ": http://www.haskell.org/ghc/ :? for help" + ": https://www.haskell.org/ghc/ :? for help" ghciCommands :: [Command] ghciCommands = map mkCmd [ diff --git a/rts/RtsMessages.c b/rts/RtsMessages.c index 053805e..a90962e 100644 --- a/rts/RtsMessages.c +++ b/rts/RtsMessages.c @@ -172,7 +172,7 @@ rtsFatalInternalErrorFn(const char *s, va_list ap) #endif fprintf(stderr, "\n"); fprintf(stderr, " (GHC version %s for %s)\n", ProjectVersion, xstr(HostPlatform_TYPE)); - fprintf(stderr, " Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\n"); + fprintf(stderr, " Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug\n"); fflush(stderr); } #if defined(mingw32_HOST_OS) _______________________________________________ ghc-commits mailing list ghc-commits(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits

4 5

Re: Better perf
by Sebastian Graf 14 Dec '18

14 Dec '18

Hey, when going through Simon-nofib-notes, I stumbled over this thread from March 2017, when I hadn't yet subscribed to this list: https://mail.haskell.org/pipermail/ghc-devs/2017-March/013887.html. Joachim and Simon were trying to pin-point seemingly random regressions and improvements of ~5% to `binary-trees`. It's hard to say in retrospect, but I suspect this is the same effect I experienced in #15333 and I'm about to fix in #15999, e.g. that small changes to allocations lead to big, uncorrelated jumps in runtime performance due to GC. Just wanted to record this here for posterity. Cheers Sebastian Hi, > > Am Dienstag, den 07.03.2017, 22:55 +0000 schrieb Simon Peyton Jones via > ghc-devs: > >* > But: binary-trees runtime increases by 5%. > *> >* David: might you look to see if there is any obvious reason for this > *>* regression? We could just accept it, but it's always good to know > *>* why, and to document it. > * > Turns out that my commit > Add rule mapFB c (λx.x) = c > fixed that regression:https://perf.haskell.org/ghc/#revision/2fa44217c1d9722227297eefb… > > Maybe there is just a performance cliff there, and these jumps don’t > really mean anything. > > Greetings, > Joachim > >

1 0

Post-spec optimisation, wen and where
by Gabor Greif 13 Dec '18

13 Dec '18

Hi devs, I am wondering where the optimisation (e.g. simplified) of specialised dictionaries is taking place. In my case -ddump-spec shows unoptimised, but -ddump-simpl-iterations shows already optimised dictionaries (float-out already happened). I searched yesterday, but to no avail. Thanks, Gabor

2 2

Re: are ghc commits only getting make fast test'd on OSX?
by Carter Schonwald 11 Dec '18

11 Dec '18

yeah, this turned out to be the dwarf issue i think, On Fri, Dec 7, 2018 at 10:05 PM Ben Gamari <bgamari(a)gmail.com> wrote: > Sorry for the latency, I'm currently working through a few weeks of > email backlog. > > > Carter Schonwald <carter.schonwald(a)gmail.com> writes: > > > thats the only explanation of why i see soooo many test suite failues of > a > > GHC RELEASE when i do make test ... > > > It's hard to comment without knowing more about what specific failures > you are seeing. > > > why do we not have a full ./validate run on each tier one platform as > part > > of some official release check list? > > > We do. All of the Tier 1 platforms have go through full validation. You > can see this yourself by looking at .circleci/config.yml. > > > DO WE HAVE a checklist for releases? if not, we should, this shouldn't be > > happening > > Yes, we do. It is here [1]. > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/wiki/MakingReleases >

1 0

Understanding bind in template haskell
by Yotam Ohad 10 Dec '18

10 Dec '18

Hi, In the function DsMeta.repE there is a format being repeated: For example in: repE e@(ExplicitTuple _ es boxed) | not (all tupArgPresent es) = notHandled "Tuple sections" (ppr e) | isBoxed boxed = do { xs <- repLEs [e | (dL->L _ (Present _ e)) <- es] ; repTup xs } | otherwise = do { xs <- repLEs [e | (dL->L _ (Present _ e)) <- es] ; repUnboxedTup xs } There is `(dL->L _ (Present _ e)) <- es`. I don't understand how this type checks correctly. If I'll try to do data Foo a = Foo a runQ [| Foo b <- Foo 1 |] in ghciI get an error. What is the difference? Yotam

2 1

Re: nofib output difference
by Andreas Klebinger 08 Dec '18

08 Dec '18

I fear that one is my fault. This should fix it: https://phabricator.haskell.org/D5426 I did not want to add a large binary file to the repo so instead compress generated the out file during boot. Which used to work well on my box. However make boot also creates the dependency files that guarantee the proper build order. Turns out sometimes we end up trying to build the compress executable before building the dependency file, so the build fails. I've just gave in to storing the output file in the repo now.

1 0

[ANNOUNCE] GHC 8.6.3 is now available
by Ben Gamari 08 Dec '18

08 Dec '18

Hello everyone, The GHC team is very happy to announce the availability of GHC 8.6.3, a bugfix release in the GHC 8.6 series. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.6.3 The 8.6 release fixes several regressions present in 8.6.2 including: - A code generation bug resulting in segmentations faults in some programs (#15892) - Darwin binary distributions are now correctly built against an in-tree GMP (#15404) - Three bugs leading to linker failures on Windows (#15105, #15894, #15934) - A bug leading to programs with deep stacks crashing when run with retainer profiling enabled (#14758) - A bug resulting in potential heap corruption during stable name allocation (#15906) - Plugins are now loaded during GHCi sessions (#15633) As a few of these issues are rather serious users are strongly encouraged to upgrade. See Trac [1] for a full list of issues resolved in this release. Note that this release ships with one significant but long-standing bug (#14251): Calls to functions taking both Float# and Double# may result in incorrect code generation when compiled using the LLVM code generator. This is not a new issue, it has existed as long as the LLVM code generator has existed; however, changes in code generation in 8.6 made it more likely that user code using only lifted types will trigger it. Happy compiling! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.6.3&col=id…

1 0

nofib output difference
by Joachim Breitner 07 Dec '18

07 Dec '18

Hi, currently, perf.haskell.org has stopped because recent commits fail to build with: expected stdout not matched by reality --- fft2.stdout7 2018-11-28 12:00:24.126015465 -0500 +++ /tmp/runtest6392.1 2018-11-28 12:59:59.329423367 -0500 @@ -1,3 +1,3 @@ -result1 = 2.59635799135966e-12 -result2 = 2.59635799135966e-12 -result3 = 4.8279900966008427e-8 +result1 = 2.649891777856828e-12 +result2 = 2.649891777856828e-12 +result3 = 4.830900479646516e-8 make[2]: *** [../../mk/target.mk:102: runtests] Error 1 do others observe this as well? This is worrying, because there has been no change to nofib since it last worked. Can we add a check of the functional correctness of the nofib programs to the CI somehow? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 4

framework failure
by Simon Peyton Jones 07 Dec '18

07 Dec '18

I'm getting this Framework failures: . ./perf/should_run/all.T [] (name 'stats_num_field' is not defined) I think it comes from this: commit fb669f51b3f2cae79511ac3d1c43939d951b1f69 Author: Tobias Decking <Tobias.Decking(a)gmail.com> Date: Thu Dec 6 15:32:18 2018 -0500 Add fusion rules for the zipWith functions in base (#15263) Simon

2 1

Cmm Memory Model (Understanding #15449)
by Travis Whitaker 07 Dec '18

07 Dec '18

Hello GHC Devs, I'm trying to get my head around ticket #15449 ( https://ghc.haskell.org/trac/ghc/ticket/15449) This gist of things is that GHC generates incorrect aarch64 code that causes memory corruption in multithreaded programs run on out-of-order machines. User trommler discovered that similar issues are present on PowerPC, and indeed ARMv7 and PowerPC support the same types of load/store reorderings. The LLVM code emitted by GHC may be incorrect with respect to LLVM's memory model, but this isn't a problem on architectures with minimal reordering like x86. I had initially thought that GHC simply wasn't emitting the appropriate LLVM fences; there's an elephant-gun-approach here ( https://github.com/TravisWhitaker/ghc/commits/ghc843-wip/T15449) that guards each atomic operation with a full barrier. I still believe that GHC is omitting necessary LLVM fences, but this change is insufficient to fix the behavior of the test case (which is simply GHC itself compiling a test package with '-jN', N > 1). It seems there's a long and foggy history of the Cmm memory model. Edward Yang discusses this a bit in his post here ( http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primiti…) and issues similar to #15449 have plagued GHC in the past, like #12469 ( https://ghc.haskell.org/trac/ghc/ticket/12469) Worryingly, GHC only has MO_WriteBarrier, whereas PowerPC and ARMv7 really need read, write, and full memory barriers. On ARM an instruction memory barrier might be required as well, but I don't know enough about STG/Cmm to say for sure, and it'd likely be LLVM's responsibility to emit that anyway. I'm hoping that someone with more tribal knowledge than I might be able to give me some pointers with regards to the following areas: - Does STG itself have anything like a memory model? My intuition says 'definitely not', but given that STG expressions may contain Cmm operations (via StgCmmPrim), there may be STG-to-STG transformations that need to care about the target machine's memory model. - With respect to Cmm, what reorderings does GHC perform? What are the relevant parts of the compiler to begin studying? - Are the LLVM atomics that GHC emits correct with respect to the LLVM memory model? As it stands now LLVM fences are only emitted for MO_WriteBarrier. Without fences accompanying the atomics, it seems the LLVM compiler could float dependent loads/stores past atomic operations. - Why is MO_WriteBarrier the only provided memory barrier? My hunch is that it's because this is the only sort of barrier required on x86, which only allows loads to be reordered with older stores, but perhaps I'm missing something? Is it plausible that Cmm simply needs additional barrier primitives to target these weaker memory models? Conversely, is there some property of Cmm that let's us get away without read barriers at all? Naturally, if I've got any of this wrong or are otherwise barking up the wrong tree, please let me know. Thanks for all your efforts! Travis Whitaker

4 3