- ghc-devs - Haskell.org

Re: Build failure under Fedora 21
by Roman Cheplyaka 25 Jan '15

25 Jan '15

On 12/01/15 04:00, Dominick Samperi wrote: > Hi Roman. > > As I said in my comments I tried the binary distribution provided for > CentOS65 Linux but ran into problems. I also tried the distribution provided > for Debian Linux; this installed, but there were problems. > > Fedora is the most "cutting edge" distro, and there is no ghc binary > provided for it. I was able to build from source under Fedora 20 about a year > ago. % lsb_release -d Description: Fedora release 21 (Twenty One) % ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 There's no reason the binary ghc release shouldn't work for you (specifically, the deb7 one). What problems did you run into? (There's also no reason you shouldn't be able to build from source; but if all you want is just a working ghc installation, installing the bindist is much easier and faster.) Roman

5 8

SPARC NCG, how to debug load isn issue.
by Karel Gardas 24 Jan '15

24 Jan '15

Folks, from time to time I'm attempting to resurrect SPARC NCG. It looks like it's off by default since 7.4? release and I feel it's kind of pity. I've been able to hack it on 7.6.x and make it functional. I failed on 7.8 and later. Double float load was broken there. Now, I'm attempting on fairly recent GHC HEAD as of Jan 17 and I do have problem with illegal isn generated into the binary. This is caused by LD II64 ... Instr to be translated to SPARC ldd <addr>,g1 where g1 reg is not even, but odd and this fails as spec. says: " The load doubleword integer instructions (LDD, LDDA) move a doubleword from memory into an r register pair. The more significant word at the effective memory address is moved into the even r register. The less significant word (at the effective memory address + 4) is moved into the following odd r register. (Note that a load doubleword with rd = 0 modifies only r[1].) The least significant bit of the rd field is unused and should be set to zero by software. An attempt to execute a load doubleword instruction that refers to a mis-aligned (odd) destination register number may cause an illegal_instruction trap. " I've found out that the problematic source code is HeapStackCheck.cmm and the problematic piece is: if (Capability_context_switch(MyCapability()) != 0 :: CInt || Capability_interrupt(MyCapability()) != 0 :: CInt || (StgTSO_alloc_limit(CurrentTSO) `lt` (0::I64) && (TO_W_(StgTSO_flags(CurrentTSO)) & TSO_ALLOC_LIMIT) != 0)) { ret = ThreadYielding; goto sched; This "(0::I64)" causes it. So that's the problem description. Now I'm attempting to debug it a little bit to find out where the LD II64 Instr is generated and I'm not able to find single place which would looks familiar with asm I get here: .Lcq: ld [%i1+812],%g1 ldd [%g1+64],%g1 cmp %g1,0 bge .Lcs nop b .Lcr nop more importantly when I look into sparc's version on mkLoadInstr, I don't see any way how it may generate LD II64: sparc_mkLoadInstr dflags reg _ slot = let platform = targetPlatform dflags off = spillSlotToOffset dflags slot off_w = 1 + (off `div` 4) sz = case targetClassOfReg platform reg of RcInteger -> II32 RcFloat -> FF32 RcDouble -> FF64 _ -> panic "sparc_mkLoadInstr" in LD sz (fpRel (- off_w)) reg In whole SPARC NCG I've found the only place which clearly uses LD II64 and this is in Gen32.hs for loading literal float into reg: getRegister (CmmLit (CmmFloat d W64)) = do lbl <- getNewLabelNat tmp <- getNewRegNat II32 let code dst = toOL [ LDATA ReadOnlyData $ Statics lbl [CmmStaticLit (CmmFloat d W64)], SETHI (HI (ImmCLbl lbl)) tmp, LD II64 (AddrRegImm tmp (LO (ImmCLbl lbl))) dst] return (Any FF64 code) It's interesting but also iselExpr64 which should be probably here for manipulating 64bit data on 32bit platform, so even this is using pairs of LD II32 Instrs instead of single LD II64.... So I'm kind of out of idea where the LD II64 gets in the flow and is later translated into ldd with problematic reg. Do you have any idea how to debug this issue? Or do you have any idea where to read more about general structure of NCG, I've already seen https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/NCG -- but this is kind of dated... Thanks for any idea how to proceed! Karel

1 0

Strange failures in directory/
by Simon Peyton Jones 23 Jan '15

23 Jan '15

I'm getting these validate failures from "sh validate -fast": Unexpected failures: ../../libraries/directory/tests getHomeDirectory001 [exit code non-0] (normal) .. and about 20 more similar complaints ... The failure report is this: Compile failed (status 256) errors were: [1 of 1] Compiling Main ( getHomeDirectory001.hs, getHomeDirectory001.o ) *** unexpected failure for getHomeDirectory001(normal) BUT if I "cd libraries/directory/tests", and say "make TEST=getDirContents001", I get no failures. Here is a clue. If I "cd testsuite/tests" and say "make TEST=getDirContents001", I get this: =====> getHomeDirectory001(normal) 4288 of 4405 [0, 0, 13] cd ../../libraries/directory/tests && '/5playpen/simonpj/HEAD-2/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history -o getHomeDirectory001 getHomeDirectory001.hs >getHomeDirectory001.comp.stderr 2>&1 cd ../../libraries/directory/tests && ./getHomeDirectory001 </dev/null >getHomeDirectory001.run.stdout 2>getHomeDirectory001.run.stderr =====> getHomeDirectory001(normal) 4301 of 4405 [0, 0, 13] cd ../../libraries/directory/tests && '/5playpen/simonpj/HEAD-2/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history -o getHomeDirectory001 getHomeDirectory001.hs >getHomeDirectory001.comp.stderr 2>&1 cd ../../libraries/directory/tests && ./getHomeDirectory001 </dev/null >getHomeDirectory001.run.stdout 2>getHomeDirectory001.run.stderr Note that it gets compiled TWICE. This is likely to cause problems when multi-threading. Anyone have any ideas? Simon

2 1

Re: Proposal for removing transformers dependency
by Johannes Waldmann 23 Jan '15

23 Jan '15

> ... a proposal for removing transformers dependency from ghc library. +1 - J.W. (I subscribed to this list just to send this one message ...)

1 0

GHC HEAD failure [was: Re: [commit: ghc] master: Update Haddock submodule (34d68d8)]
by Karel Gardas 23 Jan '15

23 Jan '15

Hello, last night build on i386-freebsd, i386/amd64-solaris and smartos-x86 failed with problem on configuring haddock: "inplace/bin/ghc-cabal" check utils/haddock 'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit and not just imposing longer compile times on your users. "inplace/bin/ghc-cabal" configure utils/haddock dist "" --with-ghc="/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/inplace/bin/ghc-stage1" --with-ghc-pkg="/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/inplace/bin/ghc-pkg" --flag in-ghc-tree --disable-library-for-ghci --disable-library-vanilla --disable-library-profiling --disable-shared --configure-option=CFLAGS=" -U__i686 -fno-stack-protector " --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -U__i686 -fno-stack-protector " --configure-option=--with-gmp-includes="/usr/include/gmp" --configure-option=--with-gmp-libraries="/usr/lib" --with-gcc="/usr/bin/gcc" --with-ld="/usr/bin/ld" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/xpg4/bin/ar" --with-alex="/buildbot//bin/alex" --with-happy="/buildbot//bin/happy" Configuring haddock-2.16.0... ghc-cabal: At least the following dependencies are missing: ghc >=7.9 && <7.11 gmake[1]: *** [utils/haddock/dist/package-data.mk] Error 1 gmake: *** [all] Error 2 At least i386-solaris is using ghc 7.8.2 as a bootsrap ghc and amd64-solaris is using ghc 7.10.0.20141222 as a bootstrap ghc. This is IIRC 7.10 rc1. I've thought the general policy is to keep GHC buildable by two last release generation in the past and if this policy still applies then haddock is probably a culprit here. Perhaps it was done by the commit below which is the reason I address you directly Mateusz. If not, and the failure is caused by something else, then please excuse me for this email. Thanks! Karel On 01/23/15 01:12 AM, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/34d68d8e83676c5010e9bc5d4619f2487… > >> --------------------------------------------------------------- > > commit 34d68d8e83676c5010e9bc5d4619f24879f222af > Author: Mateusz Kowalczyk<fuuzetsu(a)fuuzetsu.co.uk> > Date: Fri Jan 23 00:14:00 2015 +0000 > > Update Haddock submodule > > >> --------------------------------------------------------------- > > 34d68d8e83676c5010e9bc5d4619f24879f222af > utils/haddock | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/utils/haddock b/utils/haddock > index d61bbc7..bf77580 160000 > --- a/utils/haddock > +++ b/utils/haddock > @@ -1 +1 @@ > -Subproject commit d61bbc75890e4eb0ad508b9c2a27b91f691213e6 > +Subproject commit bf77580eb40fa960b701296ac828372d127a43dd > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0

Proposal for removing transformers dependency
by Alexander V Vershilov 22 Jan '15

22 Jan '15

Hello. I'm coming with a proposal for removing transformers dependency from ghc library. The reason for this proposal that it's not possible to build consistent environment where a modern libraries (that depend on a newer transformers or mtl-2.2) and libraries that use ghc API are used together. And often people are tend to use version that is bundled with ghc, even if newer are available. As transformers usage are quite limited in ghc, and it's really relevant in ghc-bin, it's possible to duplicate the code, and provide required fixes in ghc-bin.cabal. As a result ghc uses it's own MonadIO, MonadControl and Strict State, and ghc-bin.cabal (ghc/*) uses ones from transformers. I have prepared a proof of concept [1], however it doesn't look very clean and it's quite possible that will require some generalization, for example introduction of the ghc-transformers-instances package that will have all required instances. Should I continue doing this? Are there any things to consider and fix? [1] https://github.com/qnikst/ghc/compare/wip/remove-tf -- Alexander

8 15

RE: [commit: ghc] master: 32-bit performance wibbles (387f1d1)
by Simon Peyton Jones 22 Jan '15

22 Jan '15

BOTHER! I have no idea how my commit, which was meant to change two all.T files, also ended up adding libraries/haskell98. I'll revert and re-commit. I also inadvertently did 'git pull' rather than 'git pull --rebase' so there's a merge node too. But I don't know how to undo that, and probably no harm done. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 22 January 2015 09:41 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: 32-bit performance wibbles (387f1d1) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/387f1d1ec334788c3e891e9304d4 | 27bc804998f4/ghc | | >--------------------------------------------------------------- | | commit 387f1d1ec334788c3e891e9304d427bc804998f4 | Author: Simon Peyton Jones <simonpj(a)microsoft.com> | Date: Tue Jan 20 17:31:13 2015 +0000 | | 32-bit performance wibbles | | Less for GHC, more for Haddock | | | >--------------------------------------------------------------- | | 387f1d1ec334788c3e891e9304d427bc804998f4 | libraries/{integer-simple => haskell98}/.gitignore | 0 | libraries/haskell98/Array.hs | 15 + | libraries/haskell98/Bits.hs | 8 + | libraries/haskell98/CError.hs | 8 + | libraries/haskell98/CForeign.hs | 7 + | libraries/haskell98/CPUTime.hs | 9 + | libraries/haskell98/CString.hs | 7 + | libraries/haskell98/CTypes.hs | 7 + | libraries/haskell98/Char.hs | 18 + | libraries/haskell98/Complex.hs | 11 + | libraries/haskell98/Directory.hs | 46 +++ | libraries/haskell98/ForeignPtr.hs | 7 + | libraries/haskell98/IO.hs | 74 ++++ | libraries/haskell98/Int.hs | 7 + | libraries/haskell98/Ix.hs | 10 + | libraries/haskell98/LICENSE | 28 ++ | libraries/haskell98/List.hs | 34 ++ | libraries/haskell98/Locale.hs | 17 + | libraries/haskell98/MarshalAlloc.hs | 7 + | libraries/haskell98/MarshalArray.hs | 7 + | libraries/haskell98/MarshalError.hs | 22 ++ | libraries/haskell98/MarshalUtils.hs | 7 + | libraries/haskell98/Maybe.hs | 16 + | libraries/haskell98/Monad.hs | 19 + | libraries/haskell98/Numeric.hs | 48 +++ | libraries/haskell98/Prelude.hs | 196 ++++++++++ | libraries/haskell98/Ptr.hs | 7 + | libraries/haskell98/Random.hs | 407 | +++++++++++++++++++++ | libraries/haskell98/Ratio.hs | 10 + | libraries/{integer-gmp => haskell98}/Setup.hs | 0 | libraries/haskell98/StablePtr.hs | 7 + | libraries/haskell98/Storable.hs | 7 + | libraries/haskell98/System.hs | 15 + | libraries/haskell98/Time.hs | 22 ++ | libraries/haskell98/Word.hs | 7 + | libraries/haskell98/changelog.md | 15 + | libraries/haskell98/haskell98.cabal | 86 +++++ | libraries/haskell98/prologue.txt | 9 + | testsuite/tests/perf/compiler/all.T | 7 +- | testsuite/tests/perf/haddock/all.T | 13 +- | 40 files changed, 1240 insertions(+), 7 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 | 387f1d1ec334788c3e891e9304d427bc804998f4 | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

RE: Request for assistance from Haskell-oriented startup: GHCi performance
by Simon Peyton Jones 20 Jan '15

20 Jan '15

Konrad That does sound frustrating. I think your first port of call should be Manuel Chakravarty, the author of accelerate. The example you give in your stackoverflow post<http://stackoverflow.com/questions/27541609/difference-in-performance-of-co…> can only be some weird systems thing. After all, you are executing precisely the same code (namely compiled Accelerate code); it’s just that in one case it’s dynamically linked and excecuted from GHCi and in the other it’s linked and executed by the shell. I have no clue what could cause that. I wonder if you are using a GPU and whether that might somehow behave differently. Could it be the difference between static linking and dynamic linking (which could plausibly account for some startup delay)? Is it a fixed overhead (eg takes 100ms extra) or does it run a factor of two slower (increase the size of your test case to see)? I’d be happy to have a Skype call with you, but I am rather unlikely to know anything helpful because it doesn’t sound like a core Haskell issue at all. You are executing the very same machine instructions! The overheads of the GHC API to compile and run the expression “main” are pretty small. I’m copying ghc-devs in case anyone else has any ideas. Simon From: Konrad Gądek [mailto:kgadek@gmail.com] Sent: 14 January 2015 13:59 To: Simon Peyton Jones Cc: Piotr Młodawski; kgadek(a)flowbox.io Subject: Request for assistance from Haskell-oriented startup: GHCi performance Dear Mr Jones, My name is Konrad Gądek and I'm one of the programmers at Flowbox ( http://flowbox.io ), a startup that is to bring a fresh view on image composition in movie industry. We proudly use Haskell in nearly all of our development. I believe you may remember our CEO, Wojciech Daniło, from discussions like in this thread: https://phabricator.haskell.org/D69 . What can be interesting for you is that to achieve our goals as a company, we started developing a new programming language - Luna. Long story short, we believe that Luna could be as beneficial for the Haskell community as Elixir is for Erlang. However, we found some major performance problems with the code that are as critical for us as they are cryptic. We have found difficulties in pinpointing the actual issue, not to mention solving it. We're getting a bit desperate about that, nobody so far has been able to help us, and so we would like to ask you for help. We would be really really grateful if you could take a look, maybe your fresh ideas could shed some light on the issue. Details are attached below. Is there any chance we could arrange eg. a Skype call so we could further discuss the matter? Thank you in advance! Background Currently Luna is trans-compiled to Haskell and then compiled to bytecode by GHC. Furthermore, we use ghci to evaluate expressions (the flow graph) interactively. We use accelerate library to perform high-performance computations with the help of graphic cards. The problem Executing some of the functions from libraries compiled with -O2 (especially from accelerate) is much slower than calling it from compiled executable (see http://stackoverflow.com/questions/27541609/difference-in-performance-of-co… and https://github.com/AccelerateHS/accelerate/issues/227) Maybe there is some other way to interactively evaluate Haskell code, which is more lightweight/more customizable ie. would not require all ghc-api features which are probably slowing down the whole process? Is it possible to just use ghc linker and make function calls simpler and more time efficient? Details We feed ghci with statements (using ghc-api) and declarations (using runStmt and runDecls). We can also change imports and language extensions before each call. The overall process is as follows: * on init: · * set ghcpath to one with our custom installation of ghc with preinstalled graphic libraries * set imports to our libraries * enable/disable appropriate language extensions * for each run: · * generate haskell code (including datatype declarations, using lenses and TemplateHaskell) and load it to ghci using runDecls * for each expression: o * run statements that use freshly generated code * bind (lazy) results to variables * evaluate values from bound variables, and get it from GhcMonad to runtime of our interpreter (see http://hackage.haskell.org/package/hint–0.4.2.1/docs/Language-Haskell-Inter…<http://hackage.haskell.org/package/hint%E2%80%930.4.2.1/docs/Language-Haske…>) This behaviour was observed when using GHC 7.8.3 (with D69 patch) on Fedora 20 (x86-64), Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz Tried so far 1. Specializing nearly everything in accelerate library, specializing calls to accelearate methods (no speedup). 2. Load precompiled, optimised code to ghci (no speedup). 3. Truth to be told, we have no idea what to try next. -- Konrad Gądek typechecker team-leader in Flowbox

2 1

Re: [commit: ghc] master: comments only (9894f6a)
by Gabor Greif 20 Jan '15

20 Jan '15

Hi Simon, JFTR, you seem to be after the trailing zeros in the code you commented. If the bitmap is *really* that sparse then it might be profitable to rewrite it in terms of __builtin_ctz (when present). Some CPUs even have instructions for this. http://hardwarebug.org/2010/01/14/beware-the-builtins/ Possibly one could even switch to checking *leading* zeros by reformulating the algorithm and eliminate a few more instructions. http://www.hackersdelight.org/ might be another source for inspiration. Cheers, Gabor On 1/20/15, 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/9894f6a5b4883ea87fd5f280a2eb4a8ab… > >>--------------------------------------------------------------- > > commit 9894f6a5b4883ea87fd5f280a2eb4a8abfbd2a6b > Author: Simon Marlow <marlowsd(a)gmail.com> > Date: Wed Jan 14 08:45:07 2015 +0000 > > comments only > > >>--------------------------------------------------------------- > > 9894f6a5b4883ea87fd5f280a2eb4a8abfbd2a6b > rts/sm/Scav.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/rts/sm/Scav.c b/rts/sm/Scav.c > index 2ecb23b..781840c 100644 > --- a/rts/sm/Scav.c > +++ b/rts/sm/Scav.c > @@ -285,6 +285,8 @@ scavenge_large_srt_bitmap( StgLargeSRT *large_srt ) > > for (i = 0; i < size / BITS_IN(W_); i++) { > bitmap = large_srt->l.bitmap[i]; > + // skip zero words: bitmaps can be very sparse, and this helps > + // performance a lot in some cases. > if (bitmap != 0) { > for (j = 0; j < BITS_IN(W_); j++) { > if ((bitmap & 1) != 0) { > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

3 3

Playing with the profiler
by Luís Gabriel 20 Jan '15

20 Jan '15

Hi there, I'm doing some experiments with the GHC time profiler and I need to add a new field to the Cost Centre structures. I managed to add the field in the *CCS.h* header as well as in *codeGen/StgCmmProf.hs* but for some reason the program is crashing during garbage collection. As I have no experience with the GHC internals, I'm having trouble to find the problem. It would be very nice if someone could give me some clue to find this bug. The patch on GHC as well as the test sample and stack traces can be found here: https://gist.github.com/luisgabriel/39d51cf4d661c7e62e22 Thanks, Luís Gabriel

2 2