January 2013 - ghc-devs

RE: [commit: ghc] master: Tidy up cross-compiling (109a1e5)
by Simon Peyton-Jones 17 Jan '13

17 Jan '13

Would it be worth transferring that comment into the building guide (a cross-compiling page perhaps). The distinction is subtle and the information is useful There is http://hackage.haskell.org/trac/ghc/wiki/CrossCompilation but I'm not sure it has this info Simon | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of Simon Marlow | Sent: 17 January 2013 12:57 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Tidy up cross-compiling (109a1e5) | | Repository : ssh://darcs.haskell.org//srv/darcs/ghc | | On branch : master | | http://hackage.haskell.org/trac/ghc/changeset/109a1e53287f50103e8a5b5922 | 75940b6e3dbb53 | | >--------------------------------------------------------------- | | commit 109a1e53287f50103e8a5b592275940b6e3dbb53 | Author: Simon Marlow <marlowsd(a)gmail.com> | Date: Thu Jan 17 11:52:15 2013 +0000 | | Tidy up cross-compiling | | We have two cases: | 1. building a cross-compiler | 2. compiling GHC to run on a foreign platform | | These two are done with almost the same setup: (1) is the stage 1 | compiler, and (2) is the stage 2 compiler, when CrossCompiling=YES. | | The only difference between (1) and (2) is that you if you set up | the | build for (1), then it stops before stage 2 and you can 'make | install' | to install stage 1. | | Unfortunately, (2) didn't work, and the build system code needed | some | tidying up. | | Change to the way the build is set up: | | Before | ------ | | To build a cross-compiler: | ./configure --target=<..> | | To compile a foreign GHC: | ./configure --host=<..> --target=<..> | | Now | --- | | To build a cross-compiler: | ./configure --target=<..> | And set "Stage1Only=YES" in mk/build.mk | | To compile a foreign GHC: | ./configure --target=<..> | | aclocal.m4 | 28 ++++++++---- | compiler/ghc.mk | 99 ++++++++++++++++++++---------------- | ------ | configure.ac | 35 ++++----------- | ghc.mk | 10 ++-- | ghc/ghc.mk | 2 +- | libraries/primitive | 1 - | libraries/vector | 1 - | mk/config.mk.in | 27 +++++++----- | rules/build-package-data.mk | 7 +++- | settings.in | 1 + | utils/ghc-pkg/ghc.mk | 4 +- | 11 files changed, 107 insertions(+), 108 deletions(-) | | | Diff suppressed because of size. To see it, use: | | git show 109a1e53287f50103e8a5b592275940b6e3dbb53 | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

LLVM failures
by Simon Peyton-Jones 17 Jan '13

17 Jan '13

I'm getting testsuite failures like this on Windows <no location info>: Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM Fair enough, but shouldn't 'configure' find out if I have LLVM. And if I don't, shouldn't the tests be disabled? Do we have instructions for installing LLVM on Windows? Simon

4 10

New demand analysis
by Johan Tibell 17 Jan '13

17 Jan '13

Hi, I'm curious about the new demand analyser. Is there a wiki page/paper describing what it's trying to achieve? Cheers, Johan

2 2

Testsuite produces false failures?
by Jan Stolarek 17 Jan '13

17 Jan '13

Today I verified my patch and I got seven failures of the test suite, six of which were caused by changes in the fundeps (according to Simon's mail it should be fixed by now). So one was obviously caused by my patch. After validation has completed I run this one test again using "make TEST=name_of_test" and it passed without problems. After submiting my patch I rebased my branch with changes onto latest HEAD (which has changed while I was running previous validation) and I got 207 test failures. For example one of them is "2566" from driver directory. So I run "make TEST=2566" and get this: cd ./driver && $MAKE -s --no-print-directory 2566 </dev/null >2566.run.stdout 2>2566.run.stderr OVERALL SUMMARY for test run started at śro, 16 sty 2013, 19:11:02 CET 3576 total tests, which gave rise to 14254 test cases, of which 0 caused framework failures 14253 were skipped 1 expected passes 0 had missing libraries 0 expected failures 0 unexpected passes 0 unexpected failures Also, running the command being tested manually on the stage 2 binary gives correct result: [killy@xerxes : /dane/uczelnia/projekty/ghc-validate/inplace/bin] ./ghc-stage2 -c foo2566.bar Warning: the following files would be used as linker inputs, but linking is not being done: foo2566.bar ghc-stage2: no input files Usage: For basic information, try the `--help' option. Can someone give me a hint what is going on? Janek

1 0

Build error when doing full build
by Jan Stolarek 17 Jan '13

17 Jan '13

I'm trying to build GHC from commit def97b82b3c5f2787e6eea5ddb52d69b8e86fc82 (it's from Monday). This is for validation so I'm making a full build to run the test suite. When doing 'make -j2' I got en error like this: ------------------------------------------------------------------------ Build haddock.ps Build haddock.pdf This is pdfTeX, Version 3.1415926-1.40.11 (TeX Live 2010) This is pdfTeX, Version 3.1415926-1.40.11 (TeX Live 2010) restricted \write18 enabled. restricted \write18 enabled. entering extended mode entering extended mode processing index /tmp/tmpi1K_Jj/haddock_tmp.idx... makeindex: Not writing to /tmp/tmpi1K_Jj/haddock_tmp.ind (openout_any = p). Can't create output index file /tmp/tmpi1K_Jj/haddock_tmp.ind. Usage: makeindex [-ilqrcgLT] [-s sty] [-o ind] [-t log] [-p num] [idx0 idx1 ...] could not make index /tmp/tmpi1K_Jj/haddock_tmp.ind Error: latex compilation failed make[1]: *** [utils/haddock/doc/haddock.ps] Błąd 1 make[1]: *** Oczekiwanie na niezakończone zadania.... processing index /tmp/tmpGEJ104/haddock_tmp.idx... makeindex: Not writing to /tmp/tmpGEJ104/haddock_tmp.ind (openout_any = p). Can't create output index file /tmp/tmpGEJ104/haddock_tmp.ind. Usage: makeindex [-ilqrcgLT] [-s sty] [-o ind] [-t log] [-p num] [idx0 idx1 ...] could not make index /tmp/tmpGEJ104/haddock_tmp.ind Error: pdflatex compilation failed make[1]: *** [utils/haddock/doc/haddock.pdf] Błąd 1 make: *** [all] Błąd 2 ------------------------------------------------------------------------ I tried to continue by typing 'make' and the build did resume, but at some point I ended up with the same problem (or a very similar one): ------------------------------------------------------------------------ XSLT stylesheets DocBook - LaTeX 2e (0.2.7) =================================================== Pixel unit not handled (replaced by pt) Pixel unit not handled (replaced by pt) Found eps for 'prof_scc' Missing character Λ Build users_guide.ps This is pdfTeX, Version 3.1415926-1.40.11 (TeX Live 2010) restricted \write18 enabled. entering extended mode processing index /tmp/tmp_1vN_S/users_guide_tmp.idx... makeindex: Not writing to /tmp/tmp_1vN_S/users_guide_tmp.ind (openout_any = p). Can't create output index file /tmp/tmp_1vN_S/users_guide_tmp.ind. Usage: makeindex [-ilqrcgLT] [-s sty] [-o ind] [-t log] [-p num] [idx0 idx1 ...] could not make index /tmp/tmp_1vN_S/users_guide_tmp.ind Error: latex compilation failed make[1]: *** [docs/users_guide/users_guide.ps] Błąd 1 make: *** [all] Błąd 2 ------------------------------------------------------------------------ Now when I type 'make' I just end up with this error. This happens when compiling stage 2, but only with full build. Quick build goes fine. Is there anything I'm missing on my system? Janek

2 3

RE: Cardinality
by Simon Peyton-Jones 17 Jan '13

17 Jan '13

I don't know how to account for that. Make sure you are compiling everything with -dcore-lint. I guess you are on a Mac? I'm using 64-bit Linux. Is it definitely ok with the old demand analyser? Note for others: this is nofib/imaginary/integrate. Simon From: ilyas239(a)gmail.com [mailto:ilyas239@gmail.com] On Behalf Of Ilya Sergey Sent: 16 January 2013 17:25 To: Simon Peyton-Jones Subject: Re: Cardinality I run nofib and at some point I get the following output: ==nofib== integrate: time to run integrate follows... ../../runstdtest/runstdtest ./integrate -o1 integrate.stdout -o1 integrate.stdout -ghc-timing +RTS -K20m -H100m -RTS 50000; ../../runstdtest/runstdtest ./integrate -o1 integrate.stdout -o1 integrate.stdout -ghc-timing +RTS -K20m -H100m -RTS 50000; ../../runstdtest/runstdtest ./integrate -o1 integrate.stdout -o1 integrate.stdout -ghc-timing +RTS -K20m -H100m -RTS 50000; ../../runstdtest/runstdtest ./integrate -o1 integrate.stdout -o1 integrate.stdout -ghc-timing +RTS -K20m -H100m -RTS 50000; ../../runstdtest/runstdtest ./integrate -o1 integrate.stdout -o1 integrate.stdout -ghc-timing +RTS -K20m -H100m -RTS 50000; /bin/sh: line 1: 33635 Bus error: 10 ././integrate +RTS -s/var/folders/c1/pbj77lbx6fnc3qkj984xp44h0000gn/T//stats33626 -RTS +RTS -K20m -H100m -RTS 50000 < /dev/null > /var/folders/c1/pbj77lbx6fnc3qkj984xp44h0000gn/T//runtest33626.1.raw 2> /var/folders/c1/pbj77lbx6fnc3qkj984xp44h0000gn/T//runtest33626.2.raw 3> /var/folders/c1/pbj77lbx6fnc3qkj984xp44h0000gn/T//runtest33626.3.raw real 0m0.922s user 0m0.004s sys 0m0.009s ././integrate +RTS -K20m -H100m -RTS 50000 < /dev/null **** expected exit status 0 not seen ; got 138 /bin/sh: line 1: 33651 Bus error: 10 If I remove integrate from the nofib Makefile, the rest of the benchmarks works just fine. Ilya On Wed, Jan 16, 2013 at 9:19 PM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: no, I don't. That's odd. How does it manifest for you? S From: ilyas239(a)gmail.com<mailto:ilyas239@gmail.com> [mailto:ilyas239@gmail.com<mailto:ilyas239@gmail.com>] On Behalf Of Ilya Sergey Sent: 16 January 2013 17:13 To: Simon Peyton-Jones Subject: Re: Cardinality Thank you. I ran nofib myself too, and it seems to be fine, except that issue with imaginary/integrate. Did you have that error when running nofib as well? Ilya On Wed, Jan 16, 2013 at 5:39 PM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: fixed thanks. I'm doing another nofib run now. S From: ilyas239(a)gmail.com<mailto:ilyas239@gmail.com> [mailto:ilyas239@gmail.com<mailto:ilyas239@gmail.com>] On Behalf Of Ilya Sergey Sent: 16 January 2013 12:38 To: Simon Peyton-Jones Subject: Re: Cardinality Hi Simon. I tried to build from the `new-demand-to-merge` branch recently, and I got the following Lint error when building libraries/base/GHC/Event/Array.hs by a stage-1 compiler: *** Core Lint errors : in result of Common sub-expression *** <no location info>: Warning: In a case alternative: (GHC.ForeignPtr.ForeignPtr fo_s3mr :: GHC.Prim.Addr#, ds1_s3mq :: GHC.ForeignPtr.ForeignPtrContents) Occurrence of a dead Id wild_s3ms Any ideas, how it could be fixed, so I could integrate your changes into the cardinality branch and run the experiments? Kind regards, Ilya On Tue, Jan 8, 2013 at 11:22 PM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: ok. busy working on it now. From: ilyas239(a)gmail.com<mailto:ilyas239@gmail.com> [mailto:ilyas239@gmail.com<mailto:ilyas239@gmail.com>] On Behalf Of Ilya Sergey Sent: 07 January 2013 11:53 To: Simon Peyton-Jones Subject: Re: Cardinality Great, thank you. Please, let me know when it's in the stable state, so I could implement the optimisation making use of single-used thunks (and it would not interfere with your changes). Kind regards, Ilya On Fri, Jan 4, 2013 at 3:11 PM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: I've been working on the code. Will commit shortly. Integrate seems ok, happily. SImon From: ilyas239(a)gmail.com<mailto:ilyas239@gmail.com> [mailto:ilyas239@gmail.com<mailto:ilyas239@gmail.com>] On Behalf Of Ilya Sergey Sent: 23 December 2012 16:57 To: Simon Peyton-Jones Subject: Re: Cardinality Hi Simon. >From what I can observe, after the trivial merge the new-demand compiled 'integrate' fails (exit code 138), whereas the trunk-compiled one does not. The last time I merged before was November 8, and everything was fine, just as I left it in September. So far, the only difference I can see in the W/W code is that the new-demand compiler makes more aggressive split for the arguments of `integrate1D` (see ww-new.log in the attachment), which seems to be correct to me, as these arguments are used strictly. The compiler from the trunk, however, keeps these arguments boxed, which surprises me (ww-trunk.log). I'm not entirely sure, but it might affect the unpacking strategy on later stages of the simplifier. It would be helpful to know what else I can do to debug this inconsistency. Thanks. Best regards, Ilya On Sun, Dec 23, 2012 at 8:10 PM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: However, now we have a problem: for one test from nofib, namely imaginary/integrate, the optimizer changes the semantics, so the program fails. Can you be more specific? How does the semantics change? How do you know it is changed? Is this a recent change? Simon From: ilyas239(a)gmail.com<mailto:ilyas239@gmail.com> [mailto:ilyas239@gmail.com<mailto:ilyas239@gmail.com>] On Behalf Of Ilya Sergey Sent: 22 December 2012 19:04 To: Simon Peyton-Jones Subject: Re: Cardinality Dear Simon. Today I spent some time merging 'master' into the 'new-demand-to-merge' branch. It went fine, and I managed to compile it and run the nofib, and results *almost* didn't change: the new strictness analyzer still does better in most of the cases than the old one. However, now we have a problem: for one test from nofib, namely imaginary/integrate, the optimizer changes the semantics, so the program fails. It is quite strange, as from the perspective of the demand analyser the results are similar. As I haven't changed anything in the analysis or the worker/wrapper split, I tend to think it might be the refactoring of the unpacking strategy that clashed with the current logic of W/W. Shall I merge the 'master' into 'new-demand' branch ignoring this issue, or should I keep things as they are, so you could take a look on it and merge it yourself? Kind regards, Ilya On Sat, Dec 22, 2012 at 2:30 AM, Ilya Sergey <ilya.sergey(a)gmail.com<mailto:ilya.sergey@gmail.com>> wrote: Dear Simon. Thank you for the example. I will definitely compile something like this and check the memory consumption. I also have to implement the changes suggested by you and Dimitrios for single-used thunks. The cardinality branch was up-to date with the trunk (and the new demand branch) by mid-November. Yesterday I tried to update it, but by some mysterious reasons I could not compile the current trunk (getting seg-fault). I suspect it might be because of some outdated cabal packages. So once I get the trunk compiled, I will bring both new demand and cardinality branch up to date. I'm still in Saint Petersburg, and will be here until mid-January, waiting for my Spanish visa. Next week I have a deadline for our SCP invited paper, and then for a few weeks I will be focusing exclusively on the cardinality and demand work. Merry Christmas and happy holidays to you and your family! With best regards, Ilya On Fri, Dec 21, 2012 at 9:51 PM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Ilya I've found an example where cardinality will really help: CPS code. For example, deriving( Read ) generates code (in HEAD, soon) like this expectP x (\v1 -> expectP y (\v2 -> expectP z (\v3 -> ...))) Then the full-laziness (float-out) pass tries to float out lets from those lambdas, because it thinks they may be called many times. But actually they are only called once ... they are continuations ... and the cardinality analysis will discover that I think. I hope to get to this in the new year. What is the state of the cardinality branch? I hope you are enjoying Madrid Simon

1 0

Failing test
by Simon Peyton-Jones 16 Jan '13

16 Jan '13

Iavor Are these four failures the result of your changes? Should we fix the tests? Should the error message say "The instance decl is inconsistent with the fundeps"? And maybe be more precise about which fundep. I'm a bit confused. Simon =====> Gentle(normal) 1182 of 3527 [0, 3, 0] cd ./indexed-types/should_compile && 'C:/code/HEAD/bindisttest/install dir/bin/ghc.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c Gentle.hs >Gentle.comp.stderr 2>&1 Compile failed (status 256) errors were: Gentle.hs:13:10: Illegal instance declaration for `Concrete a b' Multiple uses of this instance may be inconsistent with the functional dependencies of the class. In the instance declaration for `Concrete a b' *** unexpected failure for Gentle(normal) =====> T6068(ghci) 1852 of 3527 [0, 14, 0] cd ./polykinds && HC='C:/code/HEAD/bindisttest/install dir/bin/ghc.exe' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' 'C:/code/HEAD/bindisttest/install dir/bin/ghc.exe' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history <T6068.script >T6068.run.stdout 2>T6068.run.stderr Actual stderr output differs from expected: --- /dev/null 2013-01-14 17:04:32 +0000 +++ ./polykinds/T6068.run.stderr 2013-01-14 17:04:32 +0000 @@ -0,0 +1,9 @@ + +T6068.hs:23:10: + Illegal instance declaration for `HasSingleton + (Maybe ak) (Maybe a) mp' + Multiple uses of this instance may be inconsistent + with the functional dependencies of the class. + In the instance declaration for `HasSingleton (Maybe a) mp' + =====> tc235(normal) 2812 of 3527 [0, 16, 0] cd ./typecheck/should_compile && 'C:/code/HEAD/bindisttest/install dir/bin/ghc.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c tc235.hs -fno-warn-incomplete-patterns >tc235.comp.stderr 2>&1 Compile failed (status 256) errors were: tc235.hs:24:10: Illegal instance declaration for `Gr g ep m' Multiple uses of this instance may be inconsistent with the functional dependencies of the class. In the instance declaration for `Gr g ep m' =====> T5684(normal) 3185 of 3527 [0, 17, 0] cd ./typecheck/should_fail && 'C:/code/HEAD/bindisttest/install dir/bin/ghc.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T5684.hs >T5684.comp.stderr 2>&1 Actual stderr output differs from expected: --- ./typecheck/should_fail/T5684.stderr 2013-01-14 13:42:13 +0000 +++ ./typecheck/should_fail/T5684.comp.stderr 2013-01-14 17:27:00 +0000 @@ -1,64 +1,6 @@ -T5684.hs:25:12: - No instance for (A b6) arising from a use of `op' - In the expression: op True undefined - In the expression: - [op False False, op 'c' undefined, op True undefined] - In an equation for `flop1': - flop1 = [op False False, op 'c' undefined, op True undefined] - -T5684.hs:30:12: - No instance for (A b5) arising from a use of `op' - In the expression: op True undefined - In the expression: - [op False False, op True undefined, op 'c' undefined] - In an equation for `flop2': - flop2 = [op False False, op True undefined, op 'c' undefined] - -T5684.hs:36:12: - No instance for (A b4) arising from a use of `op' - In the expression: op True undefined - In the expression: - [op 'c' undefined, op True undefined, op False False] - In an equation for `flop3': - flop3 = [op 'c' undefined, op True undefined, op False False] - -T5684.hs:42:12: - No instance for (A b3) arising from a use of `op' - In the expression: op True undefined - In the expression: - [op 'c' undefined, op False False, op True undefined] - In an equation for `flop4': - flop4 = [op 'c' undefined, op False False, op True undefined] - -T5684.hs:46:12: - No instance for (A b2) arising from a use of `op' - In the expression: op True undefined - In the expression: - [op True undefined, op 'c' undefined, op False False] - In an equation for `flop5': - flop5 = [op True undefined, op 'c' undefined, op False False] - -T5684.hs:52:12: - No instance for (A b0) arising from a use of `op' - In the expression: op True undefined - In the expression: - [op True undefined, op False False, op 'c' undefined] - In an equation for `flop6': - flop6 = [op True undefined, op False False, op 'c' undefined] - -T5684.hs:53:12: - No instance for (A Bool) arising from a use of `op' - In the expression: op False False - In the expression: - [op True undefined, op False False, op 'c' undefined] - In an equation for `flop6': - flop6 = [op True undefined, op False False, op 'c' undefined] - -T5684.hs:54:12: - No instance for (B Char b1) arising from a use of `op' - In the expression: op 'c' undefined - In the expression: - [op True undefined, op False False, op 'c' undefined] - In an equation for `flop6': - flop6 = [op True undefined, op False False, op 'c' undefined] +T5684.hs:10:10: + Illegal instance declaration for `B Bool b' + Multiple uses of this instance may be inconsistent + with the functional dependencies of the class. + In the instance declaration for `B Bool b' *** unexpected failure for T5684(normal)

2 2

RE: [commit: ghc] master: Use a version of the coverage condition even with UndecidableInstances. (fe61599)
by Simon Peyton-Jones 15 Jan '13

15 Jan '13

OK. I see that * oclose is never used * Note [Important subtlety in oclose] is out of date; it relates to when oclose was used with the global tyvars. This relates to change (1) of yours, behaving uniformly when the fixed tyvars are empty. So I nuked oclose altogether (hurrah), and renamed oclose1 to oclose. I'm happy with (2) using equalities. I'll commit these simplifications shortly. Simon | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of Iavor Diatchki | Sent: 14 January 2013 00:30 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Use a version of the coverage condition | even with UndecidableInstances. (fe61599) | | Repository : ssh://darcs.haskell.org//srv/darcs/ghc | | On branch : master | | http://hackage.haskell.org/trac/ghc/changeset/fe61599ffebb27924c4beef47b | 6237542644f3f4 | | >--------------------------------------------------------------- | | commit fe61599ffebb27924c4beef47b6237542644f3f4 | Author: Iavor S. Diatchki <iavor.diatchki(a)gmail.com> | Date: Sun Jan 13 16:29:10 2013 -0800 | | Use a version of the coverage condition even with | UndecidableInstances. | | This fixes bug #1241 and #2247. When UndecidableInstances are on, | we use the "Liberal Coverage Condition", which is what GHC used to | do in | the past. This is the gist of the check: | | class C a b | a -> b | instance theta => C t1 t2 | | we check that `fvs t2` is a subset of `fd-closure(theta,fvs t1)`. | | This is strictly more general than the coverage condition, while | it still guarantees consistency with the FDs of the class. This | check is completely orthogonal to termination (it by no means | guarantees | it). | | I am not sure of the role of the "coverage condition" in | termination--- | the comments suggest that it is important. This is why, for the | moment, | we only use this check when UndecidableInstances are on. | | >--------------------------------------------------------------- | | compiler/typecheck/TcValidity.lhs | 8 ++++- | compiler/types/FunDeps.lhs | 65 | ++++++++++++++++++++++++++++++++++++- | 2 files changed, 71 insertions(+), 2 deletions(-) | | diff --git a/compiler/typecheck/TcValidity.lhs | b/compiler/typecheck/TcValidity.lhs | index 80e7aa0..44d7d4c 100644 | --- a/compiler/typecheck/TcValidity.lhs | +++ b/compiler/typecheck/TcValidity.lhs | @@ -827,7 +827,9 @@ checkValidInstance ctxt hs_type ty | -- in the constraint than in the head | ; undecidable_ok <- xoptM Opt_UndecidableInstances | ; if undecidable_ok | - then checkAmbiguity ctxt ty | + then do checkAmbiguity ctxt ty | + checkTc (checkInstLiberalCoverage clas theta | inst_tys) | + (instTypeErr clas inst_tys liberal_msg) | else do { checkInstTermination inst_tys theta | ; checkTc (checkInstCoverage clas inst_tys) | (instTypeErr clas inst_tys msg) } @@ -837,6 | +839,10 @@ checkValidInstance ctxt hs_type ty | msg = parens (vcat [ptext (sLit "the Coverage Condition fails for | one of the functional dependencies;"), | undecidableMsg]) | | + liberal_msg = vcat | + [ ptext $ sLit "Multiple uses of this instance may be | inconsistent" | + , ptext $ sLit "with the functional dependencies of the class." | + ] | -- The location of the "head" of the instance | head_loc = case hs_type of | L _ (HsForAllTy _ _ _ (L loc _)) -> loc diff --git | a/compiler/types/FunDeps.lhs b/compiler/types/FunDeps.lhs index | 09d0be0..6bca407 100644 | --- a/compiler/types/FunDeps.lhs | +++ b/compiler/types/FunDeps.lhs | @@ -19,7 +19,7 @@ module FunDeps ( | FDEq (..), | Equation(..), pprEquation, | oclose, improveFromInstEnv, improveFromAnother, | - checkInstCoverage, checkFunDeps, | + checkInstCoverage, checkInstLiberalCoverage, checkFunDeps, | pprFundeps | ) where | | @@ -145,6 +145,52 @@ oclose preds fixed_tvs | ClassPred cls tys -> [(cls, tys)] | TuplePred ts -> concatMap classesOfPredTy ts | _ -> [] | + | +-- An alternative implementation of `oclose`. Differences: | +-- 1. The empty set of variables is allowed to determine stuff, | +-- 2. We also use equality predicates as FDs. | +-- | +-- I (Iavor) believe that this is the correct implementation of oclose. | +-- For 1: the above argument about `t` being monomorphic seems | incorrect. | +-- The correct behavior is to quantify over `t`, even though we know | that | +-- it may be instantiated to at most one type. The point is that we | might | +-- only find out what that type is later, at the class site to the | function. | +-- In genral, we should be quantifying all variables that are not | mentioned | +-- in the environment + the variables that are determined by them. | +-- For 2: This is just a nicity, but it makes things a bit more | general: | +-- if we have an assumption `t1 ~ t2`, then we use the fact that if | we know | +-- `t1` we also know `t2` and the other way. | + | +oclose1 :: [PredType] -> TyVarSet -> TyVarSet | +oclose1 preds fixed_tvs | + | null tv_fds = fixed_tvs -- Fast escape hatch for common case. | + | otherwise = loop fixed_tvs | + where | + loop fixed_tvs | + | new_fixed_tvs `subVarSet` fixed_tvs = fixed_tvs | + | otherwise = loop new_fixed_tvs | + where new_fixed_tvs = foldl extend fixed_tvs tv_fds | + | + extend fixed_tvs (ls,rs) | + | ls `subVarSet` fixed_tvs = fixed_tvs `unionVarSet` rs | + | otherwise = fixed_tvs | + | + tv_fds :: [(TyVarSet,TyVarSet)] | + tv_fds = [ (tyVarsOfTypes xs, tyVarsOfTypes ys) | + | (xs, ys) <- concatMap deterimned preds | + ] | + | + deterimned :: PredType -> [([Type],[Type])] | + deterimned pred | + = case classifyPredType pred of | + ClassPred cls tys -> | + do let (cls_tvs, cls_fds) = classTvsFds cls | + fd <- cls_fds | + return (instFD fd cls_tvs tys) | + EqPred t1 t2 -> [([t1],[t2]), ([t2],[t1])] | + TuplePred ts -> concatMap deterimned ts | + _ -> [] | + | \end{code} | | | @@ -471,6 +517,23 @@ checkInstCoverage clas inst_taus | fundep_ok fd = tyVarsOfTypes rs `subVarSet` tyVarsOfTypes ls | where | (ls,rs) = instFD fd tyvars inst_taus | + | +checkInstLiberalCoverage :: Class -> [PredType] -> [Type] -> Bool | +-- Check that the Liberal Coverage Condition is obeyed in an instance | +decl | +-- For example, if we have: | +-- class C a b | a -> b | +-- instance theta => C t1 t2 | +-- Then we require fv(t2) `subset` oclose(fv(t1), theta) | +-- This ensures the self-consistency of the instance, but | +-- it does not guarantee termination. | +-- See Note [Coverage Condition] below | + | +checkInstLiberalCoverage clas theta inst_taus | + = all fundep_ok fds | + where | + (tyvars, fds) = classTvsFds clas | + fundep_ok fd = tyVarsOfTypes rs `subVarSet` oclose1 theta | (tyVarsOfTypes ls) | + where (ls,rs) = instFD fd tyvars inst_taus | \end{code} | | Note [Coverage condition] | | | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

Is there unused code in GHC source?
by Jan Stolarek 15 Jan '13

15 Jan '13

Dear devs, I'm trying to dig into GHC code and one thing is wondering me. Does the source contain old fragments of code that are not used anymore? Well, for such a big project the answer will probably be 'yes', but I'm wondering what the scale of this might be. I thought that such leftovers could be a bit misleading and I want to know if I should stay alert :) Janek

2 2

Understand disassemble for segfault on android
by Nathan Hüsken 14 Jan '13

14 Jan '13

Hey, I am still investigating the segfaults of the exectuable produced by ghc to arm-linux-androideabi cross compiler. I need help. Can someone tell me if my conclusions are correct? The crash happens here: Dump of assembler code for function stg_returnToStackTop: 0x003f059c <+0>: push {r4, lr} 0x003f05a0 <+4>: sub sp, sp, #16 0x003f05a4 <+8>: ldr r1, [r0, #140] ; 0x8c => 0x003f05a8 <+12>: ldr r12, [r1, #12] 0x003f05ac <+16>: ldr r1, [r12, #12] 0x003f05b0 <+20>: mov r2, #0 Since it is in the begining of stg_returnToStackTop, it has to be LOAD_THREAD_STATE(); I believe the code for this is produced by loadThreadState: loadThreadState dflags tso stack = do catAGraphs [ -- tso = CurrentTSO; mkAssign (CmmLocal tso) stgCurrentTSO, -- stack = tso->stackobj; mkAssign (CmmLocal stack) (CmmLoad (cmmOffset dflags (CmmReg (CmmLocal tso)) (tso_stackobj dflags)) (bWord dflags)), (...) So I believe the instruction are mapped like this: ldr r1, [r0, #140] <-> tso = CurrentTSO ldr r12, [r1, #12] <-> stack = tso->stackobj If that is true, the loaded tso pointer ([r0, #140]) must be wrong. When I look at the backtrace at the moment of crash: #0 0x003f0588 in stg_returnToStackTop () #1 0x003c2e74 in schedule (initialCapability=0x3f057c, task=0x52f350) at rts/Schedule.c:463 #2 0x003c2e74 in schedule (initialCapability=0x52f340, task=0x400a42f0) at rts/Schedule.c:463 #3 0x003c4cb0 in scheduleWaitThread (tso=0x401033c0, ret=0x0, pcap=0xbe843b6c) at rts/Schedule.c:2351 There is a "tso" value passed to scheduleWaitThread (tso=0x401033c0). Should be this is the same address, form where the tso is loaded in the instruction: ldr r1, [r0, #140] <-> tso = CurrentTSO ? If so, the value in r0 is way of. info register r0 0x3f057c 4130172 r1 0xe24dd010 -498216944 Are my conclusions so far correct, and I have to find out why r0 is having the wrong value? Thanks! Nathan

1 1