- ghc-devs - Haskell.org

Re: [commit: ghc] master: Fix more 32 bit performance fallout. (c5088e2)
by Simon Marlow 24 Jan '14

24 Jan '14

On 22/01/14 23:32, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/c5088e299a66109346057afc151c33e47… > >> --------------------------------------------------------------- > > commit c5088e299a66109346057afc151c33e47b850b92 > Author: Austin Seipp <austin(a)well-typed.com> > Date: Wed Jan 22 17:30:54 2014 -0600 > > Fix more 32 bit performance fallout. > > Some of these are actually worse than I thought upon inspection, but > after a little digging I haven't found exactly what has caused them. > Some were certainly bitrotted, but others seem updated more recently, so > something has slipped. > > I'll be filing a ticket about these. Please do! These look very bad indeed. Cheers, Simon

1 1

Re: A modest proposal (re the Platform)
by Jens Petersen 24 Jan '14

24 Jan '14

On 20 January 2014 17:29, Andres Löh <andres.loeh(a)gmail.com> wrote: > (2) Simply because GHC 7.8 is itself so long delayed and so full of > new features, I think it's realistic to assume that quite a few > library glitches will appear even after it's released. Also, GHC bugs > may be found only after formal release (despite all the hammering, the > use of GHC pre release isn't quite comparable with the amount of > testing it gets afterwards; IMHO, there might very well be need for a > GHC 7.8.2). I'm all for trying to get an HP based on GHC 7.8 out as > possible, but how soon would that actually happen, realistically? > I know I already said "+1" but this is also a very valid standpoint. I guess the question is how long does HP want to wait for a stable ghc-7.8 release? There were already a number of important library updates planned for the HP release with ghc-7.6.3 - doing things more incrementally is also good I believe. Also as Andres mentioned in view of Mavericks. I know it is difficult but if ghc and haskell-platform could align their schedules better then things might be easier to plan in the future. Jens

4 5

feedback on adding CPP program / flags to ghc settings file patch please :) (it works now!)
by Carter Schonwald 23 Jan '14

23 Jan '14

Hey all, the patch for augmenting the ghc settings file to help decouple CPP from the C Compiler choice now works, on both the configure/autconf and ghc builds and uses it correctly fronts! It also results in removing the cRAWCPP variable from Config.hs, which I think is a good thing! (removes a hack / potential source of cruft). I'd love some feedback/ suggestions for this patch please. I'd also like to thank Peter Trommler for helping me debug / fix up my incorrect m4/autoconf component of the patch. the point of this patch is to make it very easy to provide a GHC that by default uses a different program for "Haskell CPP" than for compiling C code (which can only be done currently via a wrapper script hack thats a bit fragile, or via passing -pgmP everywhere! ) *https://ghc.haskell.org/trac/ghc/ticket/8683#comment:11 <https://ghc.haskell.org/trac/ghc/ticket/8683#comment:11>* thanks -Carter

1 0

32-bit Linux perf numbers
by Mateusz Kowalczyk 23 Jan '14

23 Jan '14

Hi, I just ran validate on 32-bit Linux with the latest HEAD. Here's the end of the log: > Unexpected results from: > TEST="T1969 haddock.Cabal haddock.base" > > OVERALL SUMMARY for test run started at Thu Jan 23 13:35:12 2014 GMT > 0:18:40 spent to go through > 3881 total tests, which gave rise to > 15164 test cases, of which > 11619 were skipped > > 28 had missing libraries > 3456 expected passes > 58 expected failures > > 3 caused framework failures > 0 unexpected passes > 3 unexpected failures > > Unexpected failures: > perf/compiler T1969 [stat not good enough] (normal) > perf/haddock haddock.Cabal [stat not good enough] (normal) > perf/haddock haddock.base [stat not good enough] (normal) I think that the Haddock numbers were adjusted recently (and no further changes have been made to Haddock since) but it seems that it was not enough. T1969 also seems to need inspection: should I be filing a bug for that? You can see the full log at http://fuuzetsu.co.uk/misc/validate23012014 Perhaps there should be a separate thread about this but what's happening with the nightly builds that would catch these? The builds have been stopped for months now and it doesn't seem like they'll ever resume at this rate. I can offer a 32-bit Linux box to run a validate build daily if finding the machines to build on is a problem. Thanks -- Mateusz K.

1 0

m4 / autconf help? (WIP patch for improving the CPP sitch)
by Carter Schonwald 22 Jan '14

22 Jan '14

Hey all, I"ve a WIP patch https://ghc.haskell.org/trac/ghc/ticket/8683 for making it easy to separately specify the CPP program command and associated flags in the ghc settings file. The haskell code part, for handling the dynflags / parsing the settings file etc tests out fine, i'm a bit stumped on how to get autoconf /m4 to work correctly for instantiating the desired values into the settings.intemplate though! (which happens at configure time) any help / wisdom? thanks! -Carter

1 0

Re: [commit: ghc] master: Add Windows to NoSharedLibsPlatformList (4af1e76)
by kyra 21 Jan '14

21 Jan '14

Does this mean we have no 64-bit windows support for 7.8 (only dynamic-linked compiler works on 64-bit windows)? On 1/13/2014 10:28, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/4af1e76c701a7698ebd9b5ca3fb1394dd… > >> --------------------------------------------------------------- > commit 4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d > Author: Austin Seipp <austin(a)well-typed.com> > Date: Mon Jan 13 00:21:18 2014 -0600 > > Add Windows to NoSharedLibsPlatformList > > We're punting on full -dynamic and -dynamic-too support for Windows > right now, since it's still unstable. Also, ensure "Support dynamic-too" > in `ghc --info` is set to "NO" for Cabal. > > See issues #7134, #8228, and #5987 > > Signed-off-by: Austin Seipp <austin(a)well-typed.com> > > >> --------------------------------------------------------------- > 4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d > compiler/main/DynFlags.hs | 4 +++- > mk/config.mk.in | 19 ++++--------------- > 2 files changed, 7 insertions(+), 16 deletions(-) > > diff --git a/compiler/main/DynFlags.hs b/compiler/main/DynFlags.hs > index 06d1ed9..734e7e9 100644 > --- a/compiler/main/DynFlags.hs > +++ b/compiler/main/DynFlags.hs > @@ -3563,7 +3563,7 @@ compilerInfo dflags > ("Support SMP", cGhcWithSMP), > ("Tables next to code", cGhcEnableTablesNextToCode), > ("RTS ways", cGhcRTSWays), > - ("Support dynamic-too", "YES"), > + ("Support dynamic-too", if isWindows then "NO" else "YES"), > ("Support parallel --make", "YES"), > ("Dynamic by default", if dYNAMIC_BY_DEFAULT dflags > then "YES" else "NO"), > @@ -3574,6 +3574,8 @@ compilerInfo dflags > ("LibDir", topDir dflags), > ("Global Package DB", systemPackageConfig dflags) > ] > + where > + isWindows = platformOS (targetPlatform dflags) == OSMinGW32 > > #include "../includes/dist-derivedconstants/header/GHCConstantsHaskellWrappers.hs" > > diff --git a/mk/config.mk.in b/mk/config.mk.in > index f61ecc0..59d48c4 100644 > --- a/mk/config.mk.in > +++ b/mk/config.mk.in > @@ -94,22 +94,11 @@ else > TargetElf = YES > endif > > -# Currently, on Windows, we artificially limit the unfolding creation > -# threshold to minimize the number of exported symbols on Windows > -# platforms in the stage2 DLL. This avoids a hard limit of 2^16 > -# exported symbols in the windows dynamic linker. > -# > -# This is a pitifully low threshold (the default is 750,) but it > -# reduced the symbol count by about ~7,000, bringing us back under the > -# limit (for now.) > -# > -# See #5987 > -ifeq "$(TargetOS_CPP)" "mingw32" > -GhcStage2HcOpts += -funfolding-creation-threshold=100 > -endif > - > # Some platforms don't support shared libraries > -NoSharedLibsPlatformList = arm-unknown-linux powerpc-unknown-linux > +NoSharedLibsPlatformList = arm-unknown-linux \ > + powerpc-unknown-linux \ > + x86_64-unknown-mingw32 \ > + i386-unknown-mingw32 > > ifeq "$(SOLARIS_BROKEN_SHLD)" "YES" > NoSharedLibsPlatformList += i386-unknown-solaris2 > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

3 7

RC Status
by Austin Seipp 20 Jan '14

20 Jan '14

Hello all, I apologize for the lack of updates recently. I'm well aware people are a bit ready to move on, so the good news is we should be able to do so shortly. Simon and I talked last week, and for the RC to go ahead, we've decided to punt a few tickets for the moment. The biggest hurdle is dynamic support on Windows, which we've decided to punt. I have put together a page detailing the current status with some more detail about what's going on: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 I spent a lot of time testing my (just merged) branch on several machines. The highlights for interested parties: * OS X looks pretty good across the board, minus a `./validate` bug I need to track down on Mavericks. 10.8 still needs to be tested (this will hopefully happen soon.) Otherwise it seems to be fine. * With the dynamic stuff punted, Windows looks pretty good right now too. There is some minor testsuite fallout I need to investigate. One of Herbert's patches broke the 64bit windows build, and I'm bisecting it. Then I'll test a win64 bootstrap. * Linux, as usual, seems just fine, and I just need to finish the i386 bootstrap. * I need to update some performance numbers. There is one final bug to fix, #7602, which is a performance regression for OS X, but I'm investigating the `./validate` bug on Mavericks first. Once these look green across the board, I speculate I'll begin to make the RC. I expect this to happen ASAP (within the week.) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

6 10

Re: [commit: ghc] master: Re-work the naming story for the GHCi prompt (Trac #8649) (73c08ab)
by Simon Marlow 20 Jan '14

20 Jan '14

On 10/01/14 08:52, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/73c08ab10e4077e18e459a1325996bff1… > >> --------------------------------------------------------------- > > commit 73c08ab10e4077e18e459a1325996bff110360c3 > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Thu Jan 9 17:58:18 2014 +0000 > > Re-work the naming story for the GHCi prompt (Trac #8649) Thanks for going to the trouble of cleaning this up. I was never happy with how this all worked. The prefix colon in the name (":Interactive") was supposed to avoid the possibility of clashing with a user-defined module, rather like the ":Main" pseudo-module. Could that be a problem with "Ghci1" and so on? What about the "interactive" package? Perhaps these ought to be renamed to something that can't be user-defined? Cheers, Simon

2 1

Re: Pattern synonyms for 7.8?
by Dr. ÉRDI Gergő 20 Jan '14

20 Jan '14

Hi, Wow, so, I thought there would be some back-and-forth, then a decision, then I would go and walk the last mile and then formally submit the patch for review - and now I see that in <2 days all that has passed... Of course I'll make validate pass, I just didn't even know about it. Likewise, I needed the carrot of 7.8 inclusion dangling before me to start writing the user docs. One problem, though, is that I'll be on holiday from tomorrow, so I'll only have time to look into this tonight before next weekend. I'll try my best to fix up validate tonight, and I'll write the docs (which I hope will mostly be an editing job on the wiki) next week. How does that sound? Thanks, Gergo On Jan 8, 2014 3:41 AM, "Austin Seipp" <aseipp(a)pobox.com> wrote: > Hi Gergo, > > Thanks for rebasing your changes. Unfortunately, they do not compile > cleanly with ./validate, which we really need to have working for all > incoming patches. > > In particular, ./validate enables -Werror and a slew of warnings that > you won't normally see during development, which greatly aids in > keeping the code clean. One, for example, is that some of your commits > introduce tabs - we ban tabs and validate errors on them! > > Another: the problem is that in > > https://github.com/gergoerdi/ghc/commit/afefa7ac948b1d7801d622824fbdd75ade2… > , > you added a Monoid instance for UniqSet - but this doesn't work > correctly. The problem is that UniqSet is just an alias for UniqFM > (type UniqSet a = UniqFM a), so the instance is technically seen as an > orphan. Orphan instances cause -Werror failures with ./validate > (unless you disable them for that module, but here we really > shouldn't.) > > The fix is to write the Monoid instance for UniqFM directly in > UniqFM.hs instead. > > Likewise, here's a real bug that -Werror found in your patch in the > renamer (by building with ./validate): > > compiler/rename/RnBinds.lhs:744:1: Warning: > Pattern match(es) are non-exhaustive > In an equation for `renameSig': > Patterns not matched: _ (PatSynSig _ _ _ _ _) > > Indeed, renameSig in RnBinds doesn't check the PatSynSig case! The > missing instance looks straightforward to implement, but this could > have been a nasty bug waiting. > > If you could please take the time to clean up the ./validate failures, > I'd really appreciate it. I imagine it'll take very little time, and > it will make merging much easier for me. An easy way to do it is just > to check out your pattern-synonyms branches, then say: > > $ CPUS=X sh ./validate > > where 'X' is the number of cores, similar to 'make -jX' > > If it fails, you can make a change, and keep going with: > > $ CPUS=X sh ./validate --no-clean > > and rinse and repeat until it's done. > > Note the --no-clean is required, since `./validate` will immediately > run `make distclean` by default if you do not specify it. > > On Tue, Jan 7, 2014 at 5:50 AM, Dr. ERDI Gergo <gergo(a)erdi.hu> wrote: > > On Mon, 6 Jan 2014, Carter Schonwald wrote: > > > >> as long as we clearly communicate that there may be refinements / > breaking > >> changes > >> subsequently, i'm all for it, unless merging it in slows down 7.8 > hitting > >> RC . (its > >> taken long enough for RC to happen... don't want to drag it out further) > > > > > > If that helps, I've updated the version at > https://github.com/gergoerdi/ghc > > (and the two sister repos https://github.com/gergoerdi/ghc-testsuite and > > https://github.com/gergoerdi/ghc-haddock) to be based on top of master > as of > > today. > > > > Bye, > > Gergo > > > > -- > > > > .--= ULLA! =-----------------. > > \ http://gergo.erdi.hu \ > > `---= gergo(a)erdi.hu =-------' > > Elvis is dead and I don't feel so good either. > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > -- > Regards, > Austin - PGP: 4096R/0x91384671 >

8 18

unexpected failures expected?
by Mark Lentczner 20 Jan '14

20 Jan '14

Hiho - I just built GHC HEAD on Mac OS X... and make test yields 4 unexpected failures. Is this something I should, er, expect? I'm just trying to calibrate myself for building GHC from source as part of Mac Haskell Platform packaging, and wondering if this (pre-final release) is something to expect, or something I should chase down: OVERALL SUMMARY for test run started at Sun Jan 19 21:02:36 2014 PST 0:33:45 spent to go through 3866 total tests, which gave rise to 16062 test cases, of which 12536 were skipped 26 had missing libraries 3458 expected passes 38 expected failures 0 caused framework failures 0 unexpected passes 4 unexpected failures Unexpected failures: cabal/cabal04 cabal04 [bad exit code] (normal) concurrent/should_run T5611 [bad stderr] (normal) perf/compiler T4801 [stat not good enough] (normal) th TH_spliceE5_prof [bad exit code] (normal) - Mark

2 1