Porting GHC
Colin I saw your porting-ghc blog posthttp://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2014-04-15-porting-ghc-a-tale-of-two-architectures.html (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. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RFC: template-haskell Data.Map vs. Prelude.lookup use
Hello *, In order to address https://github.com/haskell/cabal/issues/1811 I've prepared a commit for review at https://git.haskell.org/ghc.git/commitdiff/refs/heads/wip/drop-containers-dep-from-th However, I'm wondering if we really need Data.Map, or if would be equally ok to simply use O(n) Prelude.lookup-style dictionary Does anyone here happen to have an estimate for how large the dictionary in https://git.haskell.org/ghc.git/blob/HEAD:/libraries/template-haskell/Language/Haskell/TH/PprLib.hs#l120 (which is the only use of Data.Map in TH) typically gets? Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Strange checkout message
Herbert or others, What does this mean (in a clean tree) git checkout wip/orf Checking out files: 100% (159/159), done. Mutils/haddock Branch wip/orf set up to track remote branch wip/orf from origin. Switched to a new branch 'wip/orf' simonpj@cam-05-unx:~/code/HEAD-3$ What's all this about haddock being modified? I've just checked out a branch, which is supposed to make everything line up, isn't it? Do you need to say git submodule update as well? Could this be documented in the (upcoming?) workflows page? Thanks Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Help with cast error
(a ~ b) is a boxed, nominal equality.
(a ~R# b) is an unboxed, representational equality
So it is rightly rejected.
For the boxed/unboxed thing, the paper “practical aspects…” gives more detail.
http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/
I think you already know about the nominal/representational distinction.
Simon
From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org]
On Behalf Of Conal Elliott
Sent: 24 April 2014 01:29
To: glasgow-haskell-us...@haskell.org; ghc-devs@haskell.org; Richard Eisenberg;
Simon Peyton Jones
Subject: Help with cast error
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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Cloning ghc-7.8
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Status updates
| having GHC HQ monitor breakage in (a subset) of hackage for HEAD would | be great! I can imagine a daily (or weekly, depending on resources) | build of all of hackage or stackage using HEAD, and when there is a | breakage, then git bisect on our soon bisectable repo and a tool that | would allow the common git hacker to easily built and test the one | breaking package will let us know about problems quickly and with | little friction. | | (The sole purpose of this message is to convey motivation :-)) Please remember that ghc hq = Austin and me. And I have another job. Relying on GHC for anything means that you may wait a long time. So we increasingly rely on the army of GHC volunteers to do the heavy lifting. I'm increasingly encouraging Austin to see his role as supporting, encouraging, helping, coordinating, removing road-blocks from, keeping well-informed, and thanking volunteers, rather than doing the work himself. So Yay for motivation, but it's the ghc-devs community that you are addressing, not ghc hq. And THANK YOU ghc-devs. We love you. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Strange checkout message
I believe you need to run `git submodule update`. The orf branch was likely set to use a different commit from the haddock repo than your current repo. Git doesn't automatically assume that you want to switch your submodule to use the same commit as the orf branch was using, hence you now have a change in your checkout relative to the orf branch (i.e. you changed to using a different commit from the haddock repo.) On Thu, Apr 24, 2014 at 9:50 AM, Simon Peyton Jones simo...@microsoft.comwrote: Herbert or others, What does this mean (in a clean tree) git checkout wip/orf Checking out files: 100% (159/159), done. *Mutils/haddock* Branch wip/orf set up to track remote branch wip/orf from origin. Switched to a new branch 'wip/orf' simonpj@cam-05-unx:~/code/HEAD-3$ What’s all this about haddock being modified? I’ve just checked out a branch, which is supposed to make everything line up, isn’t it? Do you need to say “git submodule update” as well? Could this be documented in the (upcoming?) workflows page? Thanks Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status updates
Hi, Am Donnerstag, den 24.04.2014, 08:29 + schrieb Simon Peyton Jones: Please remember that ghc hq = Austin and me. sorry, I meant and should have said, more generally, GHC developers. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status updates
On Thu, Apr 24, 2014 at 3:29 PM, Simon Peyton Jones simo...@microsoft.comwrote: So we increasingly rely on the army of GHC volunteers to do the heavy lifting. I'm increasingly encouraging Austin to see his role as supporting, encouraging, helping, coordinating, removing road-blocks from, keeping well-informed, and thanking volunteers, rather than doing the work himself. To that end, I have one or two book recommendations for Austin if he would like them (ping me off-list). Organizing volunteers isn't easy but specialists have worked hard on this problem and shared their results. -- Kim-Ee ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Cloning ghc-7.8
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:hvrie...@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 | ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Cloning ghc-7.8
On 2014-04-24 at 12:38:40 +0200, Simon Peyton Jones wrote: 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. In all fairness, you made it sound (e.g. Subject-line) as if you wanted to know how to *clone* a GHC 7.8 branch rather than switching to the ghc-7.8 branch... :-) That said, however: Yes, switching between the 'ghc-7.8' branch and 'master' is currently problematic, because 'ghc-7.8' has a different mix of submodules and loose subrepos than 'master', and the issue being that Git isn't aware of that, so Git gets confused here and there, as it doesn't have all information it needs. This will get better however, once everything is put under Git's control. Then switching between 'ghc-7.10' and GHC HEAD should work much smoother than now between 'ghc-7.8' and GHC HEAD Hope this makes some sense... ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Cloning ghc-7.8
On Thu, Apr 24, 2014 at 12:38 PM, Simon Peyton Jones simo...@microsoft.comwrote: That seems a bit extreme. I thought switching branches is precisely what git is good at. It was made not so great in the past (i.e. 7.8) by us having the homegrown sync-all pull system instead of submodules. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RFC: template-haskell Data.Map vs. Prelude.lookup use
That map seems to store the set of variables during printing TH, for the purposes of disambiguating identifiers with the same name but different uniques. If blatting out a whole lot of program text, I could imagine the Map getting somewhat sizeable. But, it seems to only need the lookup and insert operations... is there a simpler data structure that has only these operations efficiently? Richard On Apr 24, 2014, at 3:43 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: Hello *, In order to address https://github.com/haskell/cabal/issues/1811 I've prepared a commit for review at https://git.haskell.org/ghc.git/commitdiff/refs/heads/wip/drop-containers-dep-from-th However, I'm wondering if we really need Data.Map, or if would be equally ok to simply use O(n) Prelude.lookup-style dictionary Does anyone here happen to have an estimate for how large the dictionary in https://git.haskell.org/ghc.git/blob/HEAD:/libraries/template-haskell/Language/Haskell/TH/PprLib.hs#l120 (which is the only use of Data.Map in TH) typically gets? Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
More validate failures
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 21 cd ./indexed-types/should_run ./GMapAssoc/dev/null GMapAssoc.run.stdout 2GMapAssoc.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 21 /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 21 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 2T4891.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
Re: Help with cast error
Thanks for the summary and paper pointer! I'll study up. -- Conal
On Thu, Apr 24, 2014 at 12:58 AM, Simon Peyton Jones
simo...@microsoft.comwrote:
(a ~ b) is a *boxed*, *nominal* equality.
(a ~R# b) is an *unboxed, representational* equality
So it is rightly rejected.
For the boxed/unboxed thing, the paper “practical aspects…” gives more
detail.
http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/
I think you already know about the nominal/representational distinction.
Simon
*From:* Glasgow-haskell-users [mailto:
glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Conal Elliott
*Sent:* 24 April 2014 01:29
*To:* glasgow-haskell-us...@haskell.org; ghc-devs@haskell.org; Richard
Eisenberg; Simon Peyton Jones
*Subject:* Help with cast error
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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Adding Doxygen (or other documentation tool) comments to GHC patches?
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
optllvm failures
I have done a bit of testing with regards to my optllvm failures in the testsuite. Some tests compile but segfault when they are run, others fail to compile, both with HEAD and 7.8.2, but those I tested all work with 7.6.3, although 7.6 gives the warning: You are using a new version of LLVM that hasn't been tested yet! We will try though... I suspect that the LLVM backend thinks I have a different version than I actually have, or maybe the LLVM tools think I have a different CPU than I have: dafis@schwartz:~/JNthPrime llc --version LLVM (http://llvm.org/): LLVM version 3.2svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: corei7-avx Registered Targets: arm- ARM ppc32 - PowerPC 32 ppc64 - PowerPC 64 thumb - Thumb x86- 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 dafis@schwartz:~/JNthPrime opt --version LLVM (http://llvm.org/): LLVM version 3.2svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: corei7-avx But my CPU is a Core i5, not i7. Can somebody confirm or deny that that may be the cause? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: optllvm failures
What OS? Is this on a vm? I7-avx is the instruction family. I5 will be ok. Certain vms break handling avx register saves. On Thursday, April 24, 2014, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: I have done a bit of testing with regards to my optllvm failures in the testsuite. Some tests compile but segfault when they are run, others fail to compile, both with HEAD and 7.8.2, but those I tested all work with 7.6.3, although 7.6 gives the warning: You are using a new version of LLVM that hasn't been tested yet! We will try though... I suspect that the LLVM backend thinks I have a different version than I actually have, or maybe the LLVM tools think I have a different CPU than I have: dafis@schwartz:~/JNthPrime llc --version LLVM (http://llvm.org/): LLVM version 3.2svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: corei7-avx Registered Targets: arm- ARM ppc32 - PowerPC 32 ppc64 - PowerPC 64 thumb - Thumb x86- 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 dafis@schwartz:~/JNthPrime opt --version LLVM (http://llvm.org/): LLVM version 3.2svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: corei7-avx But my CPU is a Core i5, not i7. Can somebody confirm or deny that that may be the cause? ___ ghc-devs mailing list ghc-devs@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: More validate failures
The fact GHC 7.4 and GHC 7.6 accepted tcrun045 was a bug that we didn't catch (implicit parameters in superclass constraints should have been rejected). I don't have a reference off hand for this, but I do know Simon discussed it and this was the conclusion. As for the others, it's entirely possible that the LLVM version you are running is buggy and produces incorrect code. It wouldn't be the first time this has happened. Can you try with any other version of LLVM, perhaps? On Thu, Apr 24, 2014 at 10:54 AM, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: 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 21 cd ./indexed-types/should_run ./GMapAssoc/dev/null GMapAssoc.run.stdout 2GMapAssoc.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 21 /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 21 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 2T4891.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
Re: optllvm failures
On Thursday 24 April 2014, 14:49:18, Carter Schonwald wrote: What OS? Is this on a vm? Oops, sorry. openSuSE 12.3 (64 bit), nothing virtual. I7-avx is the instruction family. I5 will be ok. Okay, then it's probably that what openSuSE calls 3.2 is not what GHC thinks 3.2 is. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: optllvm failures
GHC 7.6 did not support LLVM 3.2 - it was only tested with up-to LLVM 3.1. The odd version number for LLVM 3.2 was a known problem with their tarball, they forgot to remove the 'svn' suffix. This shouldn't be a problem for GHC, it should correctly parse the right thing anyway. Can you try another LLVM version? LLVM 3.2 has been known to be particularly problematic - I believe me and David looked into this a while back, and we couldn't get even get the compiler to bootstrap with it at one point, let alone figure out what the hell was going on (I'll see if I can find the ticket related to this). LLVM 3.3 or LLVM 3.4 should work just fine, and you can put them on the front of your $PATH before running the testsuite to check this. On Thu, Apr 24, 2014 at 1:57 PM, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: On Thursday 24 April 2014, 14:49:18, Carter Schonwald wrote: What OS? Is this on a vm? Oops, sorry. openSuSE 12.3 (64 bit), nothing virtual. I7-avx is the instruction family. I5 will be ok. Okay, then it's probably that what openSuSE calls 3.2 is not what GHC thinks 3.2 is. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: optllvm failures
Look at the output of ghc --info It will tell you what opt /LLC ghc will invoke by default. ghc 7.8 should work with llvm 3.3/3.4 On Thursday, April 24, 2014, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: On Thursday 24 April 2014, 14:49:18, Carter Schonwald wrote: What OS? Is this on a vm? Oops, sorry. openSuSE 12.3 (64 bit), nothing virtual. I7-avx is the instruction family. I5 will be ok. Okay, then it's probably that what openSuSE calls 3.2 is not what GHC thinks 3.2 is. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: optllvm failures
On Thursday 24 April 2014, 14:04:13, Austin Seipp wrote: Can you try another LLVM version? LLVM 3.2 has been known to be particularly problematic - I believe me and David looked into this a while back, and we couldn't get even get the compiler to bootstrap with it at one point, let alone figure out what the hell was going on (I'll see if I can find the ticket related to this). LLVM 3.3 or LLVM 3.4 should work just fine, and you can put them on the front of your $PATH before running the testsuite to check this. Okay, I got myself a 3.4, and it seems to work. I'll re-run the testsuite and see what failures remain. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Patches fixing a few test failures
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.From f4ccb957acdf1108aa60d0d2cf8074cc05a9901f Mon Sep 17 00:00:00 2001
From: Daniel Fischer daniel.is.fisc...@googlemail.com
Date: Fri, 25 Apr 2014 00:07:43 +0200
Subject: [PATCH 1/2] Pass '-ignore-dot-ghci' to all tests, as suggested by SPJ
in http://www.haskell.org/pipermail/ghc-devs/2014-April/004726.html
The flag was set for the ghci way, but T8333 passed '--interactive' without
'-ignore-dot-ghci' on the command line in the makefile, making the test
fail if the .ghci file produces output (as mine does), or if it loads
modules which aren't present in a validate build.
Passing it always doesn't hurt, and prevents forgetting it in
'--interactive' invocations.
---
testsuite/config/ghc | 4 ++--
testsuite/mk/test.mk | 14 +++---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/testsuite/config/ghc b/testsuite/config/ghc
index 947f558..73f5db0 100644
--- a/testsuite/config/ghc
+++ b/testsuite/config/ghc
@@ -92,7 +92,7 @@ config.way_flags = lambda name : {
'prof' : ['-prof', '-static', '-auto-all', '-fasm'],
'profasm' : ['-O', '-prof', '-static', '-auto-all'],
'profthreaded' : ['-O', '-prof', '-static', '-auto-all', '-threaded'],
-'ghci' : ['--interactive', '-v0', '-ignore-dot-ghci', '+RTS', '-I0.1', '-RTS'],
+'ghci' : ['--interactive', '-v0', '+RTS', '-I0.1', '-RTS'],
'extcore' : ['-fext-core'],
'optextcore' : ['-O', '-fext-core'],
'threaded1': ['-threaded', '-debug'],
@@ -116,7 +116,7 @@ config.way_flags = lambda name : {
'dynllvm' : ['-O', '-dynamic', '-fllvm']
}
-config.way_rts_flags = {
+config.way_rts_flags = {
'normal' : [],
'g1' : ['-G1'],
'optasm' : [],
diff --git a/testsuite/mk/test.mk b/testsuite/mk/test.mk
index 0cc3f21..46c3c5c 100644
--- a/testsuite/mk/test.mk
+++ b/testsuite/mk/test.mk
@@ -25,9 +25,9 @@ COMPILER = ghc
CONFIGDIR= $(TOP)/config
CONFIG = $(CONFIGDIR)/$(COMPILER)
-# TEST_HC_OPTS is passed to every invocation of TEST_HC
+# TEST_HC_OPTS is passed to every invocation of TEST_HC
# in nested Makefiles
-TEST_HC_OPTS = -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-$(GhcPackageDbFlag) -rtsopts $(EXTRA_HC_OPTS)
+TEST_HC_OPTS = -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-$(GhcPackageDbFlag) -rtsopts -ignore-dot-ghci $(EXTRA_HC_OPTS)
RUNTEST_OPTS =
@@ -207,23 +207,23 @@ RUNTEST_OPTS += \
ifeq $(list_broken) YES
set_list_broken = -e config.list_broken=True
else
-set_list_broken =
+set_list_broken =
endif
ifeq $(fast) YES
setfast = -e config.fast=1
else
-setfast =
+setfast =
endif
ifeq $(accept) YES
setaccept = -e config.accept=1
else
-setaccept =
+setaccept =
endif
-TESTS =
-TEST =
+TESTS =
+TEST =
WAY =
.PHONY: all boot test verbose accept fast
--
1.8.1.4
From 6d348ed020abeef384e8c64f6c526b802df198fb Mon Sep 17 00:00:00 2001
From: Daniel Fischer daniel.is.fisc...@googlemail.com
Date: Fri, 25 Apr 2014 00:17:51 +0200
Subject: [PATCH 2/2] Remove pragma setting '-fno-warn-amp'.
The flag is deprecated, and the deprecation warning makes the test fail.
Without the flag, the test passes, as it should, HEAD is AMP-compliant,
as far as I know.
---
testsuite/tests/simplCore/should_compile/spec001.hs | 1 -
1 file changed, 1 deletion(-)
diff --git a/testsuite/tests/simplCore/should_compile/spec001.hs b/testsuite/tests/simplCore/should_compile/spec001.hs
index f4b4dd0..5a6fb03 100644
--- a/testsuite/tests/simplCore/should_compile/spec001.hs
+++ b/testsuite/tests/simplCore/should_compile/spec001.hs
@@ -1,6 +1,5 @@
{-# LANGUAGE CPP, UnboxedTuples, MagicHash, StandaloneDeriving, DeriveDataTypeable #-}
{-# OPTIONS_GHC -O #-}
-{-# OPTIONS_GHC -fno-warn-amp #-}
-- In GHC 6.4, compiling this module gave a Core Lint failure following the
-- specialier, because a function was floated out that had a RULE that
--
1.8.1.4
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Adding Doxygen (or other documentation tool) comments to GHC patches?
hey howard, somehow your emails keep on going to my spam folder! https://ghc.haskell.org/trac/ghc/ticket/9021 right? Im not sure if theres any docs convention for the C code in ghc, perhaps simon marlow or austin can chime in? On Thu, Apr 24, 2014 at 12:45 PM, Howard B. Golden howard_b_gol...@yahoo.com (mailto:howard_b_gol...@yahoo.com) wrote: 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 ___ ghc-devs mailing list ghc-devs@haskell.org (mailto:ghc-devs@haskell.org) http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
