- ghc-devs - Haskell.org

Adding Doxygen (or other documentation tool) comments to GHC patches?
by Howard B. Golden 25 Apr '14

25 Apr '14

Hi, I am working on a patch for GHC Trac ticket #9021. I wonder whether it would be welcome or unwelcome to include Doxygen (or other documentation tool) comments in the patch? If another tool is preferred, please recommend it. Thanks. Howard B. Golden Northridge, CA

3 2

make 2 FAST=YES
by Simon Peyton Jones 25 Apr '14

25 Apr '14

When I say "make 2 FAST=YES" in compiler/, the make system is supposed to recompile the stage-2 compiler, but ignoring the fact that the stage-1 compiler has changed. It used to do that. But now it doesn't. It recompiles every module in GHC, and every module in the base libraries on which GHC depends. The recompilation checker then spots that nothing has changed, but it still takes several unnecessary minutes. Would it be possible to restore the old behaviour? It saves quite a lot of time when rebuilding stage2 after a minor change. Thanks! Simon

1 0

Patches fixing a few test failures
by Daniel Fischer 24 Apr '14

24 Apr '14

I've prepared two patches fixing some test failures. The first passes '-ignore-dot-ghci' to all tests, not only the ghci way, which deals with forgetting to pass the flag when the test is invoked with '-- interactive' from a makefile, as was the case with T8333. The second removes the now-obsolete pragma setting '-fno-warn-amp' from spec001. I didn't notice the trailing whitespace that was also removed in time, sorry, but I hope the clutter from that is not too bad. Kindly revise the patches, please.

1 0

More validate failures
by Daniel Fischer 24 Apr '14

24 Apr '14

Running the full testsuite (sh validate --testsuite-only --slow), I get a lot of unexpected failures (45 on this run). typecheck/should_run/tcrun045 fails due to Compile failed (status 256) errors were: [1 of 1] Compiling Main ( tcrun045.hs, tcrun045.o ) tcrun045.hs:24:1: Illegal implict parameter ‘?imp::Int’ In the context: (?imp::Int) While checking the super-classes of class ‘D’ In the class declaration for ‘D’ and 6.12, 7.0, 7.2 and 7.8 refuse the file with the same error, only 7.4 and 7.6 accept it. Is that a regression or are 7.4 and 7.6 wrong and it shouldn't have compiled? Then I get a lot of optllvm failures, like =====> GMapAssoc(optllvm) 891 of 3955 [0, 8, 0] cd ./indexed-types/should_run && '/home/dafis/GHC/virgo/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -ignore-dot-ghci -fno-ghci-history -o GMapAssoc GMapAssoc.hs -O -fllvm -package containers >GMapAssoc.comp.stderr 2>&1 cd ./indexed-types/should_run && ./GMapAssoc </dev/null >GMapAssoc.run.stdout 2>GMapAssoc.run.stderr /bin/sh: Zeile 1: 21331 Speicherzugriffsfehler ./GMapAssoc < /dev/null > GMapAssoc.run.stdout 2> GMapAssoc.run.stderr Wrong exit code (expected 0 , actual 139 ) Stdout: Stderr: *** unexpected failure for GMapAssoc(optllvm) or =====> qq007(optllvm) 1161 of 3955 [0, 10, 0] cd ./quasiquotation/qq007 && $MAKE -s --no-print-directory TH_QQ cd ./quasiquotation/qq007 && '/home/dafis/GHC/virgo/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -ignore-dot-ghci -fno-ghci-history --make Test -O -fllvm -v0 >qq007.comp.stderr 2>&1 /bin/sh: Zeile 1: 25528 Speicherzugriffsfehler '/home/dafis/GHC/virgo/bindisttest/install dir/bin/ghc' -fforce-recomp - dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -ignore- dot-ghci -fno-ghci-history --make Test -O -fllvm -v0 > qq007.comp.stderr 2>&1 Compile failed (status 35584) errors were: *** unexpected failure for qq007(optllvm) which I don't know what to make of, other optllvm tests work fine. Has anybody an idea what might cause those? T6145 fails to compile with a type error and a missing argument to the `MG` constructor. Apparently the API changed but the test was not updated. T8639_api has unexpected stdout, the type is printed as `Bool` instead of the expected `GHC.Types.Bool`, I guess one should update the expected output, but maybe the type should be printed qualified? =====> T4891(normal) 1610 of 3955 [0, 14, 0] cd ./ghc-api/T4891 && $MAKE -s --no-print-directory T4891 </dev/null >T4891.run.stdout 2>T4891.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: T4891.hs:23:19: Module ‘PrelNames’ does not export ‘iNTERACTIVE’ gmake[2]: *** [T4891] Fehler 1 *** unexpected failure for T4891(normal) T3064 and T6048 allocate slightly more than they are allowed to (about 1% resp. 0.15% too much). Generally, I have the impression that whoever decides the 64-bit Linux allocation numbers has a system where the figures aresystematically lower than on mine, maybe the expected numbers should be given a bit higher. joao-circular fails the optllvm way with unexpected stdout: Actual stdout output differs from expected: --- ./programs/joao-circular/joao-circular.stdout 2014-04-24 11:18:07.363987627 +0200 +++ ./programs/joao-circular/joao-circular.run.stdout 2014-04-24 14:27:38.927486429 +0200 @@ -68,13 +68,6 @@ PUSHa "recfact" 2 PUSHa "x" 2 LOAD -PUSHa "x" 1 -PUSHa "x" 2 -LOAD -PUSHi 1 -SUB -STORE -CALL "recfact" MUL STORE C_Ident_1 "end_if_1": @@ -83,4 +76,4 @@ Detected Semantic Errors: [C_E_Name_AD_1 (C_Ident_1 "a")] -[] +[C_E_T_NC_1 C_Errortype_1 C_Inttype_1,C_E_T_while_1,C_E_T_BOP_1,C_E_T_NC_1 C_Errortype_1 C_Errortype_1,C_E_T_BOP_1,C_E_T_NC_1 C_Errortype_1 C_Errortype_1,C_E_T_BOP_1,C_E_T_if_t_e_1,C_E_T_BOP_1,C_E_T_NC_1 C_Errortype_1 C_Inttype_1,C_E_T_NC_1 C_Errortype_1 C_Errortype_1,C_E_T_BOP_1] *** unexpected failure for joao-circular(optllvm) which I have no idea how to interpret. T7919 (optllvm) fails to compile. The ghci way, although it passed, uses a lot of memory (~ 2.5 G), temporarily froze my box, and got my browser OOM- killed. The other ways also use a lot of memory (~1.1 G - 1.7 G). While it looks as though it is to be expected that the test uses a fair bit of memory, perhaps it should not use quite as much. If somebody more knowledgeable looks at it that might be good. simplCore/should_compile/spec001 fails due to unexpected stdout, the `-fno- warn-amp` flag is deprecated, the pragma should be removed probably. arr016 (optllvm) failed with what looks serious: =====> arr016(optllvm) 3092 of 3955 [0, 32, 0] cd ./array/should_run && '/home/dafis/GHC/virgo/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -ignore-dot-ghci -fno-ghci-history -o arr016 arr016.hs -O -fllvm >arr016.comp.stderr 2>&1 cd ./array/should_run && ./arr016 </dev/null >arr016.run.stdout 2>arr016.run.stderr /bin/sh: Zeile 1: 23929 Abgebrochen ./arr016 < /dev/null > arr016.run.stdout 2> arr016.run.stderr Wrong exit code (expected 0 , actual 134 ) Stdout: Stderr: arr016: internal error: MUT_ARR_PTRS_DIRTY object entered! (GHC version 7.9.20140424 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for arr016(optllvm) T7653(ghci) managed to get my browser OOM-killed again (yes, I was naive enough to restart it), using ~2.7 G of memory. And the test timed out - also when running only T7653 without the browser to compete for the memory. The threaded1 way uses even more memory (~2.9 G), other ways much, but not that much. posix002(threaded2) failed with +posix002: failed to create OS thread: Resource temporarily unavailable *** unexpected failure for posix002(threaded2) but that isn't replicable running the test alone.

2 1

Help with cast error
by Conal Elliott 24 Apr '14

24 Apr '14

I'd appreciate help with a cast-related Core Lint error I'm getting with a GHC plugin I'm working on: Argument value doesn't match argument type: Fun type: Enc (Vec ('S 'Z) Bool) ~ (Bool, ()) => EP (Enc (Vec ('S 'Z) Bool)) -> EP (Bool, ()) Arg type: ~R# (Enc (Vec ('S 'Z) Bool)) (Bool, ()) Arg: CO Sub (TFCo:R:EncVec[0] <'Z>_N <Bool>_N) ; (Sub TFCo:R:EncBool[0], Sub (TFCo:R:EncVec0[0] <Bool>_N))_R (I omitted the module prefixes for brevity.) Do I have a role wrong here, or maybe something more fundamental? I can easily supply more info if it'd help. Thanks, -- Conal

2 2

RE: Cloning ghc-7.8
by Simon Peyton Jones 24 Apr '14

24 Apr '14

OK. So are you saying that you can't reliably change to a different branch in an existing tree, but rather must freshly clone from the source each time you want to check out a different branch? That seems a bit extreme. I thought switching branches is precisely what git is good at. Still I'll blow away my tree and try what you say. Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 24 April 2014 11:30 | To: Simon Peyton Jones | Cc: Austin Seipp | Subject: Re: Cloning ghc-7.8 | | On 2014-04-24 at 12:14:16 +0200, Simon Peyton Jones wrote: | > I tried the sequence below and got this: | | maybe try this sequence that was suggested by Austin on #ghc a couple | of | days ago: | | <thoughtpolice> (sync-all has a little difficulty with the submodules | here, and you'll end up needing to always clean anyway due to interface | changes, etc) | <thoughtpolice> 'git clone -b ghc-7.8 git://git.haskell.org && cd ghc | && ./sync-all get -b ghc-7.8' should do it |

3 2

Cloning ghc-7.8
by Simon Peyton Jones 24 Apr '14

24 Apr '14

How would I get a GHC 7.8 branch repo? Something like git clone http://git.haskell.org/ghc.git ghc-7.8-branch cd ghc-7.8-branch ./sync-all get git checkout ghc-7.8 git submodule update Is that enough? What about the non-submodule libraries? Do I need to do any more pull/get stuff? This would be another great entry on the workflow page. Thanks Simon

1 1

Porting GHC
by Simon Peyton Jones 24 Apr '14

24 Apr '14

Colin I saw your porting-ghc blog post<http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2014-04-15-porting…> (via the Haskell Weekly News) today. What a great post! Porting GHC to new architectures is way beyond the slender resources of GHC HQ, so depends utterly on volunteers. And you see to be a particularly skilled and knowledgeable one. Thank you! Simon PS: where you have offered patches to the main sources (e.g the function-prototype thing), did you elaborately comment the "technically wrong" prototype? I have this fear that in three year's time someone is going to say "oh, we could do better with that prototype" and re-introduce the bug! Aha. I've just checked #8965, and there's no comment at all. I'll add the commit message as a comment. Other ghc-devs, nb! Adding the ticket number to the comment is also fantastically helpful, because it often points to examples and discussion that are too long to include in the code.

1 0

checking clean reporting a lot of non-deleted files.
by Karel Gardas 23 Apr '14

23 Apr '14

Hello Herbert, I hope you are the right person to ask, but it looks like after folding base/template-haskell/ghc-prim/integer-gmp/ etc. libraries to ghc tree the build's checking clean step reports a lot of non-deleted files. This makes our builder logs quite huge: http://haskell.inf.elte.hu/builders/solaris-x86-head/36/14.html the situation just few days ago was quite different: http://haskell.inf.elte.hu/builders/solaris-x86-head/33/14.html Do you think this is caused by your change? If not, do you have an idea what's going wrong here? Thanks! Karel

2 1

Re: [commit: ghc] master: Be less untruthful about the prototypes of external functions (5a31f23)
by Simon Marlow 23 Apr '14

23 Apr '14

Could we have a comment with the ticket number next to the prototype please? Otherwise some well-meaning developer will "fix" it again in the future :-) Cheers, Simon On 22/04/2014 05:40, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/5a31f231eebfb8140f9b519b166094d9d… > >> --------------------------------------------------------------- > > commit 5a31f231eebfb8140f9b519b166094d9d4fc2d79 > Author: Colin Watson <cjwatson(a)debian.org> > Date: Sat Apr 12 01:55:07 2014 +0100 > > Be less untruthful about the prototypes of external functions > > GHC's generated C code uses dummy prototypes for foreign imports. At the > moment these all claim to be (void), i.e. functions of zero arguments. On > most platforms this doesn't matter very much: calls to these functions put > the parameters in the usual places anyway, and (with the exception of > varargs) things just work. > > However, the ELFv2 ABI on ppc64 optimises stack allocation > (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01149.html) a call to a > function that has a prototype, is not varargs, and receives all parameters > in registers rather than on the stack does not require the caller to > allocate an argument save area. The incorrect prototypes cause GCC to > believe that all functions declared this way can be called without an > argument save area, but if the callee has sufficiently many arguments then > it will expect that area to be present, and will thus corrupt the caller's > stack. This happens in particular with calls to runInteractiveProcess in > libraries/process/cbits/runProcess.c. > > The simplest fix appears to be to declare these external functions with an > unspecified argument list rather than a void argument list. This is no > worse for platforms that don't care either way, and allows a successful > bootstrap of GHC 7.8 on little-endian Linux ppc64 (which uses the ELFv2 > ABI). > > Fixes #8965 > > Signed-off-by: Colin Watson <cjwatson(a)debian.org> > Signed-off-by: Austin Seipp <austin(a)well-typed.com> > > >> --------------------------------------------------------------- > > 5a31f231eebfb8140f9b519b166094d9d4fc2d79 > includes/Stg.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/includes/Stg.h b/includes/Stg.h > index be966aa..1707c9b 100644 > --- a/includes/Stg.h > +++ b/includes/Stg.h > @@ -213,7 +213,7 @@ typedef StgFunPtr F_; > #define II_(X) static StgWordArray (X) GNU_ATTRIBUTE(aligned (8)) > #define IF_(f) static StgFunPtr GNUC3_ATTRIBUTE(used) f(void) > #define FN_(f) StgFunPtr f(void) > -#define EF_(f) extern StgFunPtr f(void) > +#define EF_(f) extern StgFunPtr f() > > /* ----------------------------------------------------------------------------- > Tail calls > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0