May 2013 - ghc-devs - Haskell.org

FW: Missing snapshots
by Simon Peyton-Jones 18 May '13

18 May '13

Fwding to ghc-devs, a better target for this email. Simon -----Original Message----- From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Mateusz Kowalczyk Sent: 12 May 2013 13:11 To: glasgow-haskell-users(a)haskell.org Subject: Missing snapshots -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, On the GHC download page [1], there are no available snapshots. Both HEAD and STABLE branch dist directories are empty. Any idea what the deal is? [1] - http://www.haskell.org/ghc/download - -- Mateusz K. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRj4bJAAoJEM1mucMq2pqXahAQAKS+IbI7BReGmuNWaPvkova5 eg+4yKcgC3wMeeOBocSYC7B+8x6p0XZaz8gY2BaOOfInDWeuCdHtXAtd3VCQf/5B ZLTPxZztFwW9TNn28YnW9OmB09H3fmsFT3eMRYWJ7sEkVuuetWmsbYHKlUfXCs1o f3fzK9N6iauvCMpbrYQyh1CIObltmh9xIuLl3pAQ5rFOlGqPrW8p3bMxyk1KF0gA 973yBgsWV0rlPx2/xysXXlxhZIpK5LLzJVzCKMBEqCE+8Uii/jtLFyps2ZCYOiI/ q4634JzTj13LR+wlxIRRQUqySTklGvBoWU0n5ZIhlB8AvMxoc7UCn7LfYMYDnwBb C9Y9PMLoPS3XCVqrN2pQ8UCnqaTgzGRYAvbDjQGb51ta+DgppYnz7pKw+fWnV2X+ +OEjyEe10CQ0hsLyQ1mRUi/dI2b0RyypRP/q0PZiQ8qYurwel3W8+nsbt9NvkEdo ZzNKmF+lRJGQEuj4cILkdepHX9DOhjBgIRma6Y6BcaurAnJtDKFrP9a5OAV7g1CB T2tAJiEuYUHtIrAMaRqcRsCXwi/+1jJTv/bmeoAiniXh15l56L8dIQLt1Og05Dsq haZqiLxOKzCib7k9AZJgE0wd8B1mFXv0E31cYCyMworGJU89aWkaKG+Bjlf2xWOS mqVoJArrZCv7tkYoLdN2 =rENI -----END PGP SIGNATURE----- _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

4 4

Windows validate failing
by Simon Peyton-Jones 18 May '13

18 May '13

My Windows build has started failing like this when I try "sh validate" Any ideas? Simon /usr/bin/install -c -m 755 -d "c:/code/HEAD/bindistprep/ghc-7.7.20130516/doc/html/libraries" for i in libraries/dist-haddock/*; do \ /usr/bin/install -c -m 644 $i "c:/code/HEAD/bindistprep/ghc-7.7.20130516/doc/html/libraries/"; \ done /usr/bin/install -c -m 644 libraries/prologue.txt "c:/code/HEAD/bindistprep/ghc-7.7.20130516/doc/html/libraries/" /usr/bin/install -c -m 755 libraries/gen_contents_index "c:/code/HEAD/bindistprep/ghc-7.7.20130516/doc/html/libraries/" cd bindistprep && "/usr/bin/tar" cf - ghc-7.7.20130516 | bzip2 -c > ../bindistprep/ghc-7.7.20130516-i386-unknown-mingw32.tar.bz2 make -r --no-print-directory -f ghc.mk windows-installer make[1]: *** No rule to make target `windows-installer'. Stop. make: *** [binary-dist-prep] Error 2 bash-3.1$

2 1

Re: New branch implementing typed/untyped Template Haskell
by Geoffrey Mainland 17 May '13

17 May '13

No special magic. Just make sure you get the th-new branches of ghc, libraries/template-haskell, and testsuite. If you hit any snags let me know---happy to help you get running. Geoff On 05/17/2013 07:12 PM, Jacques Carette wrote: > Fantastic! I will definitely be trying it out early next week. > > Are there any special instructions regarding how to compile this > branch? I will work on adding test cases, which would be translations > of larger metaocaml programs. > > Jacques > > On 13-05-16 11:21 AM, Geoffrey Mainland wrote: >> I have pushed a new branch, th-new, that partially implements the >> proposal outlined in Simon PJ's "New directions for Template Haskell" >> post at: >> >> http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal >> >> The main missing features are top-level pattern splices and local >> declaration splices. >> >> Typed expression quotations and typed expression splices *are* >> implemented. Syntax is as in Simon's original proposal: [|| ||] for >> typed expression brackets and $$(...) for typed expression splices. One >> can now write: >> >> power :: Int -> TExp (Int -> Int) >> power n = [|| \x -> $$(go n [|| x ||]) ||] >> where >> go :: Int -> TExp Int -> TExp Int >> go 0 x = [|| 1 ||] >> go n x = [|| $$x * $$(go (n-1) x) ||] >> >> In fact, one can even write: >> >> power :: Num a => Int -> TExp (a -> a) >> power n = [|| \x -> $$(go n [|| x ||]) ||] >> where >> go :: Num a => Int -> TExp a -> TExp a >> go 0 x = [|| 1 ||] >> go n x = [|| $$x * $$(go (n-1) x) ||] >> >> Writing the following >> >> f :: TExp Char -> TExp Integer >> f x = [|| $$x * 3 ||] >> >> gives the error >> >> Main.hs:28:7: >> Couldn't match type ‛Char’ with ‛Integer’ >> Expected type: TExp Integer >> Actual type: TExp Char >> In the Template Haskell quotation [|| $$x * 3 ||] >> In the expression: [|| $$x * 3 ||] >> In an equation for ‛f’: f x = [|| $$x * 3 ||] >> >> The th-new branch of ghc has accompanying branches for template-haskell >> and testsuite, both named th-new. These are mirrors of my local branch, >> and I reserve the right to rebase them :). That said, please do try it >> out! >> >> Geoff

1 0

Registering GHC for Coverity SCAN
by Austin Seipp 16 May '13

16 May '13

Hello all, On IRC today, Nicolas Trangez brought up the idea of registering GHC for Coverity's SCAN project. SCAN is essentially a free service run by Coverity, which runs their Static Analyzer on open source projects ('open source' being defined by OSI) and gives the results back to developers. Coverity is widely regarded as having the absolute best tool in the business for C codebases as it stands. The idea is to try and rattle bugs out of the runtime system if possible. I think this is a good idea, but it needs some public discussion. Namely, Coverity requires an official Point of Contact within the project (maintainer/author/governing body) to register the project in their name. We are left up to determine who this is and verify it. Bug reports which are found are not also made public, as they could be potentially serious security vulnerabilities.* So, if done, this is a rather piece-by-piece project which requires a bit of commitment, because it will require the registree to not only assess the bugs, but sensibly move them into the issue tracker or fix it themselves. It's also a question of whether it's worth it. Personally, I think it has the chance to uncover some real bugs. But the RTS is highly unusual C code (by some standards) and it will probably require tuning and patience to get tangible results. Bugs will also need to be assessed by someone. False positives happen etc. This is the double edged sword of static analysis.** Anyone who does it should be very aware of this. So, what do you all think? I'd particularly like input from Simon M here since he's the primary author of the RTS, of course. :) And anyone who does this will undoubtedly have to be in contact with him to some degree, for all the aforementioned reasons. If nobody else would step up for this, I would be interested in contacting them if it seems worth it and giving it a shot. * I think the chance of this in our case is very very low of course. The cases we really care about for a safety perspective are type-safety violations at the Haskell level, obviously. Nonetheless this requires an individual who is committed to sifting through reports and assessing them in a detailed way. ** Coverity at one point found out the hard way that more analysis is not necessarily better, and people don't respond well to the results sometimes. Or they're too complicated to explain. The following is a great read: http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-late… -- Regards, Austin - PGP: 4096R/0x91384671

4 3

New branch implementing typed/untyped Template Haskell
by Geoffrey Mainland 16 May '13

16 May '13

I have pushed a new branch, th-new, that partially implements the proposal outlined in Simon PJ's "New directions for Template Haskell" post at: http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal The main missing features are top-level pattern splices and local declaration splices. Typed expression quotations and typed expression splices *are* implemented. Syntax is as in Simon's original proposal: [|| ||] for typed expression brackets and $$(...) for typed expression splices. One can now write: power :: Int -> TExp (Int -> Int) power n = [|| \x -> $$(go n [|| x ||]) ||] where go :: Int -> TExp Int -> TExp Int go 0 x = [|| 1 ||] go n x = [|| $$x * $$(go (n-1) x) ||] In fact, one can even write: power :: Num a => Int -> TExp (a -> a) power n = [|| \x -> $$(go n [|| x ||]) ||] where go :: Num a => Int -> TExp a -> TExp a go 0 x = [|| 1 ||] go n x = [|| $$x * $$(go (n-1) x) ||] Writing the following f :: TExp Char -> TExp Integer f x = [|| $$x * 3 ||] gives the error Main.hs:28:7: Couldn't match type ‛Char’ with ‛Integer’ Expected type: TExp Integer Actual type: TExp Char In the Template Haskell quotation [|| $$x * 3 ||] In the expression: [|| $$x * 3 ||] In an equation for ‛f’: f x = [|| $$x * 3 ||] The th-new branch of ghc has accompanying branches for template-haskell and testsuite, both named th-new. These are mirrors of my local branch, and I reserve the right to rebase them :). That said, please do try it out! Geoff

3 3

Re: PolyKinds, Control.Category and GHC 7.6.1
by Austin Seipp 16 May '13

16 May '13

I presume people are still interested in this. I actually just ran into Category's non poly-kinded-ness the other day (while attempting to make a Category instance for promoted pairs) and found this email in my history. Can we schedule this for 7.8.1? There's -plenty- of time, and the addendum to Control.Category that Edward posted originally is pretty much all that is needed. If that sounds OK, I can post a patch for review or commit it directly to base. On Tue, Aug 14, 2012 at 6:14 AM, Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: > | FWIW PolyKinds in 7.4 is rough, and I had experiences where enabling it > | led to compile failures in downstream modules, so this wouldn't > | necessarily have been painless. Hopefully with 7.6 it will be. > > PolyKinds is not an advertised feature of 7.4, so you should absolutely not rely on it working in 7.4. But it IS an advertised feature for 7.6 and should work flawlessly. (If not, yell.) > > Simon > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Regards, Austin - PGP: 4096R/0x91384671

2 2

RE: Windows failures
by Simon Peyton-Jones 15 May '13

15 May '13

Yes, the test simply doesn't run at all on Windows. I've committed the patch for you. Thanks! Simon From: Andreas Voellmy [mailto:andreas.voellmy@gmail.com] Sent: 15 May 2013 14:07 To: Simon Peyton-Jones Subject: Re: Windows failures Hi Simon, I added 7773 recently. I should have noticed that it wouldn't work on Windows. I don't have a Windows machine, so can you try this fix for me? In libraries/base/tests/all.T, change the line for T7773 (line 125 for me) to this: test('T7773', when(opsys('mingw32'), skip), compile_and_run, ['']) Does that eliminate the 7773 failure for you. If so, I'll commit the patch. I just want to double-check, because I am just getting my feet wet with the test system. -Andi On Wed, May 15, 2013 at 7:21 AM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: On Windows I'm getting these failures. Details below. Simon Unexpected failures: ../../libraries/base/tests T7773 [exit code non-0] (normal) ../../libraries/random/tests rangeTest [bad exit code] (normal) cabal/cabal01 cabal01 [bad stdout] (normal) ghc-api/T7478 T7478 [bad exit code] (normal) ghci.debugger/scripts dynbrk009 [bad exit code] (ghci) ghci/scripts T5975a [bad stderr] (ghci) rts T4850 [bad stdout] (normal) =====> T7773(normal) 3517 of 3614 [2, 18, 0] cd ../../libraries/base/tests && 'C:/code/HEAD/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o T7773 T7773.hs >T7773.comp.stderr 2>&1 Compile failed (status 256) errors were: T7773.hs:2:8: Could not find module System.Posix.IO<http://System.Posix.IO> Use -v to see a list of the files searched for. *** unexpected failure for T7773(normal) =====> rangeTest(normal) 3386 of 3589 [2, 25, 0] cd ../../libraries/random/tests && 'C:/code/HEAD/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o rangeTest rangeTest.hs >rangeTest.comp.stderr 2>&1 cd ../../libraries/random/tests && ./rangeTest </dev/null >rangeTest.run.stdout 2>rangeTest.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Int: Passed Integer: Passed Int8: Passed Int16: Passed Int32: Passed Int64: Passed Word: Passed Word8: Passed Word16: Passed Word32: Passed Word64: Passed Double: Passed Float: Passed CChar: Passed CSChar: Passed CUChar: Passed CShort: Passed CUShort: Passed CInt: Passed CUInt: Passed CLong: Passed CULong: Passed CPtrdiff: Passed CSize: Passed CWchar: Passed CSigAtomic: Passed CLLong: Passed CULLong: Passed CIntPtr: Passed CUIntPtr: Passed CIntMax: Passed CUIntMax: Passed Int R: Passed Integer R: Passed Int8 R: Passed Int8 Rsmall: Passed Int8 Rmini: Passed Int8 Rtrivial: Passed Int16 R: Passed Int32 R: Passed Int64 R: Passed Word R: Passed Word8 R: Passed Word16 R: Passed Word32 R: Passed Word64 R: Passed Double R: Passed Float R: Passed CChar R: Passed CSChar R: Passed CUChar R: Passed CShort R: Passed CUShort R: Passed CInt R: Passed CUInt R: Passed CLong R: Passed CULong R: Passed CPtrdiff R: Passed CSize R: Passed CWchar R: Stderr: rangeTest.exe: broke lower bound: 100 =====> cabal01(normal) 81 of 3614 [0, 0, 0] cd ./cabal/cabal01 && $MAKE -s --no-print-directory cabal01 VANILLA=--enable-library-vanilla PROF=--disable-library-profiling DYN=--disable-shared CLEANUP=1 </dev/null >cabal01.run.stdout 2>cabal01.run.stderr Actual stdout output differs from expected: --- ./cabal/cabal01/cabal01.stdout-mingw32 2012-06-22 00:08:51 +0100 +++ ./cabal/cabal01/cabal01.run.stdout 2013-05-15 07:18:31 +0100 @@ -1,9 +1,9 @@ install1: bin -test-1.0 +i386-windows-ghc-7.7.20130514 install2: bin -test-1.0 +i386-windows-ghc-7.7.20130514 dist: build package.conf.inplace *** unexpected failure for cabal01(normal) =====> T7478(normal) 6 of 6 [0, 0, 0] cd ./T7478 && $MAKE -s --no-print-directory T7478 </dev/null >T7478.run.stdout 2>T7478.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: ----- 0 ------ (0,"[1 of 2] Compiling B ( B.hs, B.o )") (0,"[2 of 2] Compiling Main ( A.hs, A.o )") ----- 1 ------ (1,"[2 of 2] Compiling Main ( A.hs, A.o )") ----- 2 ------ (2,"[1 of 1] Compiling Main ( C.hs, C.o )") (2,"Linking A.exe ...") Stderr: T7478.exe: T7478.exe: phase `Linker' failed (exitcode = 1) make[1]: *** [T7478] Error 1 *** unexpected failure for T7478(normal) =====> dynbrk009(ghci) 67 of 76 [0, 0, 0] cd ./scripts && HC='C:/code/HEAD/inplace/bin/ghc-stage2.exe' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' 'C:/code/HEAD/inplace/bin/ghc-stage2.exe' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -ignore-dot-ghci <dynbrk009.script >dynbrk009.run.stdout 2>dynbrk009.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stopped at dynbrk009.hs:8:22 _result :: Int = _ Stopped at dynbrk009.hs:8:27-36 _result :: Int = _ Stopped at dynbrk009.hs:8:31-35 Stopped at dynbrk009.hs:6:1-9 Stopped at dynbrk009.hs:6:9 Segmentation fault/access violation in generated code =====> T5975a(ghci) 84 of 100 [0, 0, 0] cd . && touch f b r1.hs cd . && HC='C:/code/HEAD/inplace/bin/ghc-stage2.exe' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' 'C:/code/HEAD/inplace/bin/ghc-stage2.exe' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history <T5975a.script >T5975a.run.stdout 2>T5975a.run.stderr Actual stderr output differs from expected: --- /dev/null 2013-05-15 09:05:22 +0100 +++ ./T5975a.run.stderr 2013-05-15 09:05:21 +0100 @@ -0,0 +1,2 @@ + +<no location info>: can't find file: f b r1.hs *** unexpected failure for T5975a(ghci) =====> T4850(normal) 2232 of 3614 [2, 11, 0] cd ./rts && $MAKE -s --no-print-directory T4850 </dev/null >T4850.run.stdout 2>T4850.run.stderr Actual stdout output differs from expected: --- ./rts/T4850.stdout 2013-02-12 13:55:56 +0000 +++ ./rts/T4850.run.stdout 2013-05-15 08:14:04 +0100 @@ -1 +1 @@ -5 +4 _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-devs

1 0

RE: [commit: ghc] master: SpecConstr: seed specialisation of top-level bindings, as with letrecs. (8a58851)
by Simon Peyton-Jones 15 May '13

15 May '13

Cool! Did you comment the change with a Note [Seed specialisation of top-level bindings] inside SpecContr itself? (You could use more or less the text below.) Simon | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of Amos Robinson | Sent: 15 May 2013 13:47 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: SpecConstr: seed specialisation of top- | level bindings, as with letrecs. (8a58851) | | Repository : http://darcs.haskell.org/ghc.git/ | | On branch : master | | https://github.com/ghc/ghc/commit/8a58851150af11020140256bbd7c6d5359e020 | ee | | >--------------------------------------------------------------- | | commit 8a58851150af11020140256bbd7c6d5359e020ee | Author: Amos Robinson <amos.robinson(a)gmail.com> | Date: Wed May 15 22:15:56 2013 +1000 | | SpecConstr: seed specialisation of top-level bindings, as with | letrecs. | | When specialising a top-level recursive group, if none of the | binders | are exported then we can start specialising based on the later calls | to | the functions. | This is instead of creating specialisations based on the RHS of the | bindings. | The main benefit of this is that only specialisations that will | actually | be used are created. This saves quite a bit of memory when compiling | stream-fusion and ForceSpecConstr sort of code. | | Nofib has an average allocation and runtime of -0.7%, maximum 2%. | There are a few with significant decreases in allocation (10 - 20%) | but, interestingly, those ones seem to have similar runtimes. | One of these does have a significantly reduced total elapsed time | though: -38%. | | On average the nofib compilation times are the same, but they do | vary | with s.d. of -4 to 4%. | I think this is acceptable because of the fairly major code blowup | fixes | this has for fusion-style code. | (In one example, a SpecConstr was previously producing 122,000 term | size, | now only produces 28,000 with the same object code) | | compiler/specialise/SpecConstr.lhs | 142 +++++++++++++++++++++++++++++- | ------- | 1 file changed, 113 insertions(+), 29 deletions(-) | | | Diff suppressed because of size. To see it, use: | | git show 8a58851150af11020140256bbd7c6d5359e020ee | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

Windows failures
by Simon Peyton-Jones 15 May '13

15 May '13

On Windows I'm getting these failures. Details below. Simon Unexpected failures: ../../libraries/base/tests T7773 [exit code non-0] (normal) ../../libraries/random/tests rangeTest [bad exit code] (normal) cabal/cabal01 cabal01 [bad stdout] (normal) ghc-api/T7478 T7478 [bad exit code] (normal) ghci.debugger/scripts dynbrk009 [bad exit code] (ghci) ghci/scripts T5975a [bad stderr] (ghci) rts T4850 [bad stdout] (normal) =====> T7773(normal) 3517 of 3614 [2, 18, 0] cd ../../libraries/base/tests && 'C:/code/HEAD/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o T7773 T7773.hs >T7773.comp.stderr 2>&1 Compile failed (status 256) errors were: T7773.hs:2:8: Could not find module System.Posix.IO Use -v to see a list of the files searched for. *** unexpected failure for T7773(normal) =====> rangeTest(normal) 3386 of 3589 [2, 25, 0] cd ../../libraries/random/tests && 'C:/code/HEAD/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o rangeTest rangeTest.hs >rangeTest.comp.stderr 2>&1 cd ../../libraries/random/tests && ./rangeTest </dev/null >rangeTest.run.stdout 2>rangeTest.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Int: Passed Integer: Passed Int8: Passed Int16: Passed Int32: Passed Int64: Passed Word: Passed Word8: Passed Word16: Passed Word32: Passed Word64: Passed Double: Passed Float: Passed CChar: Passed CSChar: Passed CUChar: Passed CShort: Passed CUShort: Passed CInt: Passed CUInt: Passed CLong: Passed CULong: Passed CPtrdiff: Passed CSize: Passed CWchar: Passed CSigAtomic: Passed CLLong: Passed CULLong: Passed CIntPtr: Passed CUIntPtr: Passed CIntMax: Passed CUIntMax: Passed Int R: Passed Integer R: Passed Int8 R: Passed Int8 Rsmall: Passed Int8 Rmini: Passed Int8 Rtrivial: Passed Int16 R: Passed Int32 R: Passed Int64 R: Passed Word R: Passed Word8 R: Passed Word16 R: Passed Word32 R: Passed Word64 R: Passed Double R: Passed Float R: Passed CChar R: Passed CSChar R: Passed CUChar R: Passed CShort R: Passed CUShort R: Passed CInt R: Passed CUInt R: Passed CLong R: Passed CULong R: Passed CPtrdiff R: Passed CSize R: Passed CWchar R: Stderr: rangeTest.exe: broke lower bound: 100 =====> cabal01(normal) 81 of 3614 [0, 0, 0] cd ./cabal/cabal01 && $MAKE -s --no-print-directory cabal01 VANILLA=--enable-library-vanilla PROF=--disable-library-profiling DYN=--disable-shared CLEANUP=1 </dev/null >cabal01.run.stdout 2>cabal01.run.stderr Actual stdout output differs from expected: --- ./cabal/cabal01/cabal01.stdout-mingw32 2012-06-22 00:08:51 +0100 +++ ./cabal/cabal01/cabal01.run.stdout 2013-05-15 07:18:31 +0100 @@ -1,9 +1,9 @@ install1: bin -test-1.0 +i386-windows-ghc-7.7.20130514 install2: bin -test-1.0 +i386-windows-ghc-7.7.20130514 dist: build package.conf.inplace *** unexpected failure for cabal01(normal) =====> T7478(normal) 6 of 6 [0, 0, 0] cd ./T7478 && $MAKE -s --no-print-directory T7478 </dev/null >T7478.run.stdout 2>T7478.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: ----- 0 ------ (0,"[1 of 2] Compiling B ( B.hs, B.o )") (0,"[2 of 2] Compiling Main ( A.hs, A.o )") ----- 1 ------ (1,"[2 of 2] Compiling Main ( A.hs, A.o )") ----- 2 ------ (2,"[1 of 1] Compiling Main ( C.hs, C.o )") (2,"Linking A.exe ...") Stderr: T7478.exe: T7478.exe: phase `Linker' failed (exitcode = 1) make[1]: *** [T7478] Error 1 *** unexpected failure for T7478(normal) =====> dynbrk009(ghci) 67 of 76 [0, 0, 0] cd ./scripts && HC='C:/code/HEAD/inplace/bin/ghc-stage2.exe' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' 'C:/code/HEAD/inplace/bin/ghc-stage2.exe' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -ignore-dot-ghci <dynbrk009.script >dynbrk009.run.stdout 2>dynbrk009.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stopped at dynbrk009.hs:8:22 _result :: Int = _ Stopped at dynbrk009.hs:8:27-36 _result :: Int = _ Stopped at dynbrk009.hs:8:31-35 Stopped at dynbrk009.hs:6:1-9 Stopped at dynbrk009.hs:6:9 Segmentation fault/access violation in generated code =====> T5975a(ghci) 84 of 100 [0, 0, 0] cd . && touch f b r1.hs cd . && HC='C:/code/HEAD/inplace/bin/ghc-stage2.exe' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' 'C:/code/HEAD/inplace/bin/ghc-stage2.exe' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history <T5975a.script >T5975a.run.stdout 2>T5975a.run.stderr Actual stderr output differs from expected: --- /dev/null 2013-05-15 09:05:22 +0100 +++ ./T5975a.run.stderr 2013-05-15 09:05:21 +0100 @@ -0,0 +1,2 @@ + +<no location info>: can't find file: f b r1.hs *** unexpected failure for T5975a(ghci) =====> T4850(normal) 2232 of 3614 [2, 11, 0] cd ./rts && $MAKE -s --no-print-directory T4850 </dev/null >T4850.run.stdout 2>T4850.run.stderr Actual stdout output differs from expected: --- ./rts/T4850.stdout 2013-02-12 13:55:56 +0000 +++ ./rts/T4850.run.stdout 2013-05-15 08:14:04 +0100 @@ -1 +1 @@ -5 +4

1 0

Need help with debugging "Impossible case alternative"
by Jan Stolarek 14 May '13

14 May '13

I'm working on modifying comparison primops so that they return Int# instead of Bool. I've been stuck with one bug for about two weeks now and I just reached a point where I don't have any more ideas what to do. I would appreciate any hints or ideas. So far I changed the primops to return Int# and created a module GHC.PrimWrappers that contains wrappers around the new primops: (>#) :: Int# -> Int# -> Bool (>#) a b = tagToEnum# (a >$# b) -- (>$#) :: Int# -> Int# -> Int# I also made changes to base, integer-gmp, primitive and ghc-prim libraries The problem is that many compiled programs produce "Impossible case alternative" message when they are run. This is generated by missingAlt function, which is called by rebuildCase function on line 1785 in simplCore/Simplify.lhs. I modified the message displayed by missingAlt to get information about the scrutinee, binder and case alternatives: missingAlt env scrut@(LitAlt _) case_bndr alts cont = WARN( True, ptext (sLit "missing LitAlt: ") <+> ppr case_bndr ) return (env, mkImpossibleExpr_REMOVE_ME (contResultType cont) (showSDoc unsafeGlobalDynFlags $ ptext (sLit "missing LitAlt : ") <+> ppr scrut <+> ppr case_bndr <+> ppr alts)) Here's an example error message: Impossible case alternative: missing LitAlt : 1 wild [(GHC.Types.False, [], GHC.Types.False), (GHC.Types.True, [], x)] If I understand correctly this means that the case tries to scrutinize integer 1 against True and False, which obviously fails (surprisingly, compiling with -dcore-lint and -dcmm-lint doesn't detect any problems). My theory is that this integer is supposed to be a tag of a Bool data type (in the example message this would be True) and the call to tagToEnum# somehow got eliminated or floated out of the case scrutinee. Is that a reasonable theory? Is there a transform that could perform such floating of tagToEnum# and if so how to prevent it? I am unable to create a minimal code example that would cause this problem. I noticed that the problem happens on every attempt to print a floating point number (this causes tens of tests in the testsuite to fail). I extracted all the code responsible for converting Double to String from the GHC.Float and GHC.Show modules so that I have a self-contained program (except the call to print). Surprisingly that extracted code does not produce the error message. I'm clueless and will really appreciate any ideas. Janek

2 5