August 2014 - ghc-devs

Wired-in data-constructors with UNPACKed fields
by Herbert Valerio Riedel 18 Aug '14

18 Aug '14

Hello *, I'm a bit stuck with the wired-in type aspect of integer-gmp2 and was hoping someone with more experience in this area could provide direction on how to properly register the data definition data Integer = SI# Int# | Jp# {-# UNPACK #-} !BigNat | Jn# {-# UNPACK #-} !BigNat data BigNat = BN# ByteArray# with compiler/prelude/TysWiredIn.lhs Right now I'm getting the Lint-failure Unfolding of sqrInteger <no location info>: Warning: In the expression: $wsqrBigNat dt Argument value doesn't match argument type: Fun type: ByteArray# -> BigNat Arg type: BigNat Arg: dt where sqrBigNat :: BigNat -> BigNat which seems to be caused by the UNPACK property not being handled correctly. The full error message can be found at http://git.haskell.org/ghc.git/commitdiff/13cb42bc8b6b26d3893d4ddcc22eeab36… and the other half of the integer-gmp2 patch can be found at http://git.haskell.org/ghc.git/commitdiff/b5ed2f277e551dcaade5837568e4cbb7d… or alternatively https://phabricator.haskell.org/D82 Thanks in advance, hvr

2 1

Broken Data.Data instances
by p.k.f.holzenspies＠utwente.nl 16 Aug '14

16 Aug '14

Dear GHC-ers, Is there a reason for explicitly broken Data.Data instances? Case in point: > instance Data Var where > -- don't traverse? > toConstr _ = abstractConstr "Var" > gunfold _ _ = error "gunfold" > dataTypeOf _ = mkNoRepType "Var" I understand (vaguely) arguments about abstract data types, but this also excludes convenient queries that can, e.g. extract all types from a CoreExpr. I had hoped to do stuff like this: > collect :: (Typeable b, Data a, MonadPlus m) => a -> m b > collect = everything mplus $ mkQ mzero return > > allTypes :: CoreExpr -> [Type] > allTypes = collect Especially when still exploring (parts of) the GHC API, being able to extract things in this fashion is very helpful. SYB's "everything" being broken by these instances, not so much. Would a patch "fixing" these instances be acceptable? Regards, Philip

6 29

Help with fusion rules and such
by David Feuer 15 Aug '14

15 Aug '14

I've worked out the basics of how to make more functions from GHC.Base, GHC.List, and Data.List participate in foldr/build fusion, but I could really use some help figuring out how to write the RULES to accompany them. I have too little experience with GHC's simplification process to manage this on my own, it seems. One complication I recognize already: REVERSE reverse xs = build $ \c n -> foldl (\a x -> x `c` a) n xs works as well as we can probably expect for fusion (it fuses nicely with map and a modified unfoldr), but when it doesn't fuse, it ends up duplicating its "worker" at the top level, potentially multiple times. I tried to write a rule to rewrite that to a simpler version, but that's complicated by the fact that foldl is INLINEd unconditionally. I'm thinking maybe the "right" thing is to allow all this duplication to happen, and then clean it up at the end ( see https://ghc.haskell.org/trac/ghc/ticket/9441 ), but that will not happen soon if it does at all.

1 0

ARM64 Task Force
by Luke Iannini 14 Aug '14

14 Aug '14

Howdy all, Would anyone like to team up on getting ARM64 support into GHC? Cheers Luke

4 11

making ./validate run tests on all CPUs by default
by Sergei Trofimovich 14 Aug '14

14 Aug '14

Good evening all! Currently when being ran './validate' script (without any parameters): - builds ghc using 2 parallel jobs - runs testsuite using 2 parallel jobs I propose to change the default value to amount of available CPUs: - build ghc using N+1 parallel jobs - run testsuite using N+1 parallel jobs Pros: - first-time users will get faster ./validate - seasoned users will need less tweaking for buildbots Cons: - for imbalanced boxes (32 cores, 8GB RAM) it might be quite painful to drag box out of swap What do you think about it? Actual patch: https://phabricator.haskell.org/D146 Thanks! -- Sergei

2 2

Grumpy harbormaster
by Ben Gamari 13 Aug '14

13 Aug '14

I submitted two unrelated differentials today, D152 and D150. Somehow the Harbormaster builds of both have failed in the same peculiar way, silently dying apparently after right after finishing the initial ghc-cabal build. It's entirely possible I'm missing something silly here, but neither of the patches touch anything near Cabal or the build system so I'm a bit perplexed. What to do from here? Cheers, - Ben

1 0

CPP usage in GHC.
by Karel Gardas 13 Aug '14

13 Aug '14

Folks, in my attempt to lower number of failing tests on Solaris I've found several tests which fail on just difference in file name report. My ghc reports warning/error in /tmp/ghc<something>/<some different thing> while expected is clear T<something>.hs. See http://haskell.inf.elte.hu/builders/solaris-x86-head/125/21.html and search for T7145b as an example of this behavior. The reason why this happen is that Solaris GNU C 4.x does not emit line markers in preprocessed file when it's preprocessed with -x assembler-with-cpp. The reason behind this is documented in this thread[1] on GCC mailing list. Simply speaking Sun's assembler in the past chokes on some linemarkers generated. This was apparently case of as on older Solaris then 10 version and perhaps this will be fixed in future major GCC release as Solaris 9 is not supported anymore. Anyway, we still do have a case with GNU C compilers provided by Solaris 10 and Solaris 11. FYI: Solaris' 10 GNU C 3.4.x is OK, Solaris 11's GNU C 4.5.2 is broken and with this all more modern 4.x releases so probably also all 4.x release provided by Solaris 11.1/11.2. So far I've solved the issue of those failing tests by passing --with-hs-cpp=/usr/sfw/bin/gcc -- so configured this way GHC will use old not-buggy GNU C 3.4.x on my Solaris 11 builder as CPP and otherwise it'll use /usr/bin/gcc (GNU C 4.5.2) and everything will pass fine hopefully. Anyway, the thread[1] also contains a question which also rings in my head and that is: why we use -x assembler-with-cpp at all? Isn't simple -E enough. Or isn't simple usage of system provided CPP enough /usr/lib/cpp on Solaris)? Or what will happen if we for example change -x assembler-with-cpp to -x c or -x c-header or something like that? Please note that the testcase is OK with -x c/c-header even using this "buggy" GNU C 4.5.2 since the compiler/cpp is really buggy just for the case of -x assembler-with-cpp. Thanks! Karel [1]: https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html

2 9

diff'ing in Diffusion
by Richard Eisenberg 12 Aug '14

12 Aug '14

Hi all, I wanted to see a side-by-side diff of the GHC code between 7.8.2 and 7.8.3. So, I went to Phab's Diffusion application. I can access the different commits I wish to compare, but I can't seem to find a "Compare" or "Diff" button. Any hints? Thanks! Richard

1 0

Re: Overlapping and incoherent and intentionally omitted instances
by Iavor Diatchki 11 Aug '14

11 Aug '14

Hello, Such a pragma sounds useful, and is very much like the "fails" instance from the "Instance chains" paper. You may also be interested in ticket #9334 (https://ghc.haskell.org/trac/ghc/ticket/9334) which proposes an alternative to overlapping instances, and I just updated it to point to #7775. -Iavor On Sun, Aug 10, 2014 at 7:19 AM, Henning Thielemann < schlepptop(a)henning-thielemann.de> wrote: > Am 29.07.2014 um 12:02 schrieb Johan Tibell: > > P.S. For e.g. INLINABLE we require that you mention the function name >> next to the pragma (which means that you can e.g. put the pragma after >> the declaration). What's the rationale to not require >> >> {-# OVERLAPPING Show [Char] #-} >> >> here? Perhaps it's too annoying to have to repeat the types? >> > > Once I proposed a pragma for documenting intentionally unimplemented > instances. In this case there is no instance you can write a pragma in > front of. Your OVERLAPPING syntax would be conform with the one of > NOINSTANCE: > > https://ghc.haskell.org/trac/ghc/ticket/7775 > > Maybe NOINSTANCE can be reconsidered in the course of the introduction of > the OVERLAP pragma? > >

1 0

Re: Perf regression: ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) (f686682)
by Sergei Trofimovich 11 Aug '14

11 Aug '14

On Wed, 6 Aug 2014 22:15:34 +0300 Sergei Trofimovich <slyfox(a)gentoo.org> wrote: > On Wed, 06 Aug 2014 09:30:45 +0200 > Joachim Breitner <mail(a)joachim-breitner.de> wrote: > > > Hi, > > > > the attached commit seems to have regressed the scs nofib benchmark by > > ~3%: > > http://ghcspeed-nomeata.rhcloud.com/timeline/?ben=nofib/time/scs&env=1#/?ex… > > That's a test of compiled binary performance, not the compiler, right? > > > The graph unfortunately is in the wrong order, as the tool gets confused > > by timezones and by commits with identical CommitDate, e.g. due to > > rebasing. This needs to be fixed, I manually verified that the commit > > below is the first that shows the above-noise-level-increase of runtime. > > > > (Other benchmarks seem to be unaffected.) > > > > Is this regression expected and intended or unexpected? Is it fixable? > > Or is is this simply inexplicable? > > The graph looks mysterious (18 ms bump). Bencmark does not use haskell threads at all. > > I'll try to reproduce degradation locally and will investigate. I think I know what happens. According to perf the benchmark spends 34%+ of time in garbage collection ('perf record -- $args'/'perf report'): 27,91% test test [.] evacuate 9,29% test test [.] s9Lz_info 7,46% test test [.] scavenge_block And the whole benchmark runs a tiny bit more than 300ms. It is exactly in line with major GC timer (0.3s). If we run $ time ./test inverter 345 10n 4u 1>/dev/null multiple times there is heavy instability in there (with my patch reverted): real 0m0.319s real 0m0.305s real 0m0.307s real 0m0.373s real 0m0.381s which is +/- 80ms drift! Let's try to kick major GC earlier instead of running right at runtime shutdown time: $ time ./test inverter 345 10n 4u +RTS -I0.1 1>/dev/null real 0m0.304s real 0m0.308s real 0m0.302s real 0m0.304s real 0m0.308s real 0m0.306s real 0m0.305s real 0m0.312s which is way more stable behaviour. Thus my theory is that my changed stepped from "90% of time 1 GC run per run" to "90% of time 2 GC runs per run" -- Sergei

3 3