- ghc-devs - Haskell.org

New validate failures
by Johan Tibell 14 Mar '14

14 Mar '14

Hi, Did something change in pretty-printing recently? I saw these new validate failures today: Unexpected failures: ghci.debugger/scripts break008 [bad stdout] (ghci) ghci.debugger/scripts break012 [bad stdout] (ghci) ghci.debugger/scripts break026 [bad stdout] (ghci) ghci.debugger/scripts hist001 [bad stdout] (ghci) ghci/scripts T5545 [bad stdout] (ghci) ghci/scripts ghci008 [bad stdout] (ghci) ghci/scripts ghci012 [bad stdout] (ghci) ghci/scripts ghci023 [bad stdout] (ghci) ghci/scripts ghci025 [bad stdout] (ghci) ghci/scripts ghci026 [bad stdout] (ghci) ghci/scripts ghci055 [bad stdout] (ghci) Two example stdout changes: --- ./T5545.stdout 2014-03-13 09:48:23.000000000 +0100 +++ ./T5545.run.stdout 2014-03-13 21:11:32.000000000 +0100 @@ -1,2 +1,2 @@ -($!) :: (a -> b) -> a -> b -- Defined in 'Prelude' +$! :: forall a b. (a -> b) -> a -> b -- Defined in 'Prelude' infixr 0 $! *** unexpected failure for T5545(ghci) --- ./ghci008.stdout 2014-03-13 09:48:23.000000000 +0100 +++ ./ghci008.run.stdout 2014-03-13 21:12:20.000000000 +0100 @@ -32,5 +32,5 @@ -- Defined in 'GHC.Float' instance RealFloat Float -- Defined in 'GHC.Float' instance RealFloat Double -- Defined in 'GHC.Float' -Data.List.isPrefixOf :: Eq a => [a] -> [a] -> Bool +isPrefixOf :: forall a. Eq a -> [a] -> [a] -> Bool -- Defined in 'Data.List' *** unexpected failure for ghci008(ghci)

3 2

Should we always inline newByteArray#?
by Johan Tibell 13 Mar '14

13 Mar '14

Hi all, After some refactoring of the StgCmmPrim, it's now possible to have both an inline and an out-of-line (in PrimOps.cmm) version of the same primop. Very soon (#8876) we'll have both an inline and an out-of-line version of newByteArray#. The inline version is used when the array size is statically known and commons up the allocation with the normal heap check. The reason to have both versions is that we don't want to increase code size to much (by inlining a primop which implementation is large) unless we know that there's a benefit in doing so. However, the newByteArray# implementation is one function call (to allocate) followed by three stores (to the closure header). Perhaps, that's small enough to always inline? It would save one function call for each call to newByteArray#. Anyone have any thoughts on whether always inlining would be a good idea? -- Johan

2 4

[PATCH] sync-all: Skip END actions on exceptions
by Florian Weimer 13 Mar '14

13 Mar '14

The instructions at <https://ghc.haskell.org/trac/ghc/wiki/Newcomers> were slightly outdated, and result in a rather confusing error messsage: $ ./sync-all --testsuite get Unrecognised flag: --testsuite at ./sync-all line 872. == Checking for old haddock repo == Checking for old binary repo == Checking for old mtl repo == Checking for old Cabal repo == Checking for old time from tarball ============================ ATTENTION! You have an old time package in your GHC tree! Please remove it (e.g. "rm -r libraries/time"), and then run "./sync-all get" to get the new repository. ============================ == Checking for obsolete Git repo URL $ The patch corrects the error message. I've removed the --testsuite flag from the wiki page as well.

2 1

Building GHC on Windows
by Jan Stolarek 13 Mar '14

13 Mar '14

I'm trying to build GHC on 64-bit Windows 7. I installed Cygwin, GHC and cloned the main repo but when I run configure I get this error: configure: Building in-tree ghc-pwd checking for path to top of build tree... cygwin warning: MS-DOS style path detected: C:/cygwin64/home/tewi/head Preferred POSIX equivalent is: /home/tewi/head CYGWIN environment variable option "nodosfilewarning" turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames C:/cygwin64/home/tewi/head checking for gcc... C:/cygwin64/home/tewi/head/inplace/mingw/bin/gcc.exe checking whether the C compiler works... no configure: error: in `/home/tewi/head': configure: error: C compiler cannot create executables See `config.log' for more details I have gcc installed under Cygwin, but for some reason ./configure is looking for an in-tree compiler. I tried passing --with-gcc=/usr/bin/gcc to configure but with no result. Help? Janek

3 5

Can't build HEAD on OS X
by Johan Tibell 13 Mar '14

13 Mar '14

Checking out a clean tree today (commit: ) I can no longer build HEAD. Here's what I did: git clone git://git.haskell.org/ghc.git cd ghc ./sync-all --no-dph get cp mk/build.mk.sample mk/build.mk # Uncomment devel2 in mk/build.mk ./boot && ./configure --with-gcc=/usr/local/bin/gcc-4.9 make Here's the result: gcc -E -m64 -DPROFILING -DTHREADED_RTS -DDEBUG -Irts/dist/build -m64 -fno-stack-protector -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Winline -Waggregate-return -Wpointer-arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -fno-strict-aliasing -fno-common -DDTRACE -O2 -fomit-frame-pointer -DRtsWay=\"rts_v\" -Wno-strict-prototypes -Wno-inline -finline-limit=2500 -MM -x c rts/sm/Compact.c -MF rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit clang: error: unknown argument: '-finline-limit=2500' [-Wunused-command-line-argument-hard-error-in-future] clang: note: this will be a hard error (cannot be downgraded to a warning) in the future make[1]: *** [rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm] Error 1 More context: sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.dyn_o|" -e "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.l_o|" -e "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.debug_o|" -e "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_o|" -e "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_debug_o|" -e "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_l_o|" -e "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.debug_dyn_o|" -e "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_dyn_o|" -e "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_debug_dyn_o|" -e "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.l_dyn_o|" -e "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_l_dyn_o|" -e "1s|^|rts/sm/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && true gcc -E -m64 -DPROFILING -DTHREADED_RTS -DDEBUG -Irts/dist/build -m64 -fno-stack-protector -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Winline -Waggregate-return -Wpointer-arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -fno-strict-aliasing -fno-common -DDTRACE -O2 -fomit-frame-pointer -DRtsWay=\"rts_v\" -Wno-strict-prototypes -Wno-inline -finline-limit=2500 -MM -x c rts/sm/Compact.c -MF rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit clang: error: unknown argument: '-finline-limit=2500' [-Wunused-command-line-argument-hard-error-in-future] clang: note: this will be a hard error (cannot be downgraded to a warning) in the future make[1]: *** [rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm] Error 1 make: *** [all] Error 2 -- Johan

1 1

GHC 7.8 release
by Simon Peyton Jones 13 Mar '14

13 Mar '14

Friends The status of the GHC 7.8 release is here https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8/RC2. Alas we are currently stalled on #8870, #8834: we are getting seg-faults on Windows. (For example, on my laptop, the stage2 compiler seg-faults when compiling some (but not all) files. Although few people develop GHC on Windows, many people *use* GHC on Windows, so we can't really release in this state. We need help! Austin is trying, but it's all working on his Windows build. He's trying to get more machines to see if he can reproduce the failure there. Does anyone feel able to help? Even git-bisecting to find the offending commit would be a huge help. In principle I can do that (at two hours per bisection) but I was defeated by an out-of-sync Haddock. I need to know how to remove Haddock from the build altogether. But others are far more skilled than me. On #8834 Simon M speculates that we may have the callee-saves register wrong on Win64. Does anyone feel up to looking into that? Until we find what's going on, 7.8 is stalled. Thanks! Simon

4 4

GHC Trac registration failed
by Ken Bateman 12 Mar '14

12 Mar '14

I tried to register at https://ghc.haskell.org/trac/ghc/register but I never received a verification email. I've checked my spam folder. Could somebody help me out? The account name is novadenizen, and it's attached to this gmail address. -Ken

1 0

RE: FW: [GHC] #4385: Type-level natural numbers
by Simon Peyton Jones 12 Mar '14

12 Mar '14

I think a new section on “Type-level naturals” would make more sense. That way it’s easier to find, and makes it easier to tell a coherent story Do it on HEAD; Austin can merge as reqd. Simon From: Iavor Diatchki [mailto:iavor.diatchki@gmail.com] Sent: 12 March 2014 16:26 To: Simon Peyton Jones Subject: Re: FW: [GHC] #4385: Type-level natural numbers Hello, There are some docs under `Promoted Literals`. I can add a few more paragraphs to capture the current state. Two questions: - Should I add the new stuff in the same place, or should I move everything under a new Section (e.g., `Type-Level Naturals` or something) - Is there a special branch for the release candidate, or should I only do it on the `master` branch? -Iavor On Tue, Mar 11, 2014 at 1:33 PM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Iavor? -----Original Message----- From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org<mailto:ghc-tickets-bounces@haskell.org>] On Behalf Of GHC Sent: 11 March 2014 20:12 Cc: ghc-tickets(a)haskell.org<mailto:ghc-tickets@haskell.org> Subject: Re: [GHC] #4385: Type-level natural numbers #4385: Type-level natural numbers --------------------------------------------+------------------------------ Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Lemming): Type-level natural numbers are advertised everywhere for GHC-7.8, but I cannot find documentation in http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4385#comment:66> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ ghc-tickets mailing list ghc-tickets(a)haskell.org<mailto:ghc-tickets@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-tickets

1 0

SV: GHC 7.8 release
by Niklas Larsson 12 Mar '14

12 Mar '14

I'll try to reproduce it and see if I can pin it down.. Niklas ----- Ursprungligt meddelande ----- Från: "Simon Peyton Jones" <simonpj(a)microsoft.com> Skickat: ‎2014-‎03-‎12 16:05 Till: "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> Ämne: GHC 7.8 release Friends The status of the GHC 7.8 release is here https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8/RC2. Alas we are currently stalled on #8870, #8834: we are getting seg-faults on Windows. (For example, on my laptop, the stage2 compiler seg-faults when compiling some (but not all) files. Although few people develop GHC on Windows, many people *use* GHC on Windows, so we can’t really release in this state. We need help! Austin is trying, but it’s all working on his Windows build. He’s trying to get more machines to see if he can reproduce the failure there. Does anyone feel able to help? Even git-bisecting to find the offending commit would be a huge help. In principle I can do that (at two hours per bisection) but I was defeated by an out-of-sync Haddock. I need to know how to remove Haddock from the build altogether. But others are far more skilled than me. On #8834 Simon M speculates that we may have the callee-saves register wrong on Win64. Does anyone feel up to looking into that? Until we find what’s going on, 7.8 is stalled. Thanks! Simon

1 0

RE: [commit: ghc] master: Call Arity: Resurrect fakeBoringCalls (7f919de)
by Simon Peyton Jones 12 Mar '14

12 Mar '14

Could we please have a Note to explain what is going on here? It clearly isn't obvious, or it would have been right the first time! Everyone: practically *whenever* you fix a bug, please add a Note. By definition something subtle is happening. Thanks Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 12 March 2014 12:23 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Call Arity: Resurrect fakeBoringCalls | (7f919de) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/7f919dec1579641bbcd02978a0038c8 | a3723d8b7/ghc | | >--------------------------------------------------------------- | | commit 7f919dec1579641bbcd02978a0038c8a3723d8b7 | Author: Joachim Breitner <mail(a)joachim-breitner.de> | Date: Wed Mar 12 11:15:16 2014 +0100 | | Call Arity: Resurrect fakeBoringCalls | | (Otherwise the analysis was wrong, as covered by the new test case.) | | | >--------------------------------------------------------------- | | 7f919dec1579641bbcd02978a0038c8a3723d8b7 | compiler/simplCore/CallArity.hs | 16 | ++++++++++++++-- | testsuite/tests/callarity/unittest/CallArity1.hs | 4 ++++ | testsuite/tests/callarity/unittest/CallArity1.stderr | 3 +++ | testsuite/tests/perf/compiler/all.T | 3 ++- | 4 files changed, 23 insertions(+), 3 deletions(-) | | diff --git a/compiler/simplCore/CallArity.hs | b/compiler/simplCore/CallArity.hs | index 6334d8d..db0406d 100644 | --- a/compiler/simplCore/CallArity.hs | +++ b/compiler/simplCore/CallArity.hs | @@ -348,7 +348,8 @@ callArityTopLvl exported int1 (b:bs) | exported' = filter isExportedId int2 ++ exported | int' = int1 `addInterestingBinds` b | (ae1, bs') = callArityTopLvl exported' int' bs | - (ae2, b') = callArityBind ae1 int1 b | + ae1' = fakeBoringCalls int' b ae1 | + (ae2, b') = callArityBind ae1' int1 b | | | callArityRHS :: CoreExpr -> CoreExpr | @@ -434,7 +435,8 @@ callArityAnal arity int (Let bind e) | where | int_body = int `addInterestingBinds` bind | (ae_body, e') = callArityAnal arity int_body e | - (final_ae, bind') = callArityBind ae_body int bind | + ae_body' = fakeBoringCalls int_body bind ae_body | + (final_ae, bind') = callArityBind ae_body' int bind | | -- This is a variant of callArityAnal that is additionally told whether | -- the expression is called once or multiple times, and treats thunks | appropriately. | @@ -468,6 +470,16 @@ addInterestingBinds int bind | = int `delVarSetList` bindersOf bind -- Possible shadowing | `extendVarSetList` interestingBinds bind | | +-- For every boring variable in the binder, this amends the CallArityRes | to | +-- report safe information about them (co-called with everything else, | arity 0). | +fakeBoringCalls :: VarSet -> CoreBind -> CallArityRes -> CallArityRes | +fakeBoringCalls int bind res | + = addCrossCoCalls (domRes boring) (domRes res) $ (boring `lubRes` | res) | + where | + boring = ( emptyUnVarGraph | + , mkVarEnv [ (v, 0) | v <- bindersOf bind, not (v | `elemVarSet` int)]) | + | + | -- Used for both local and top-level binds | -- First argument is the demand from the body | callArityBind :: CallArityRes -> VarSet -> CoreBind -> (CallArityRes, | CoreBind) | diff --git a/testsuite/tests/callarity/unittest/CallArity1.hs | b/testsuite/tests/callarity/unittest/CallArity1.hs | index 8a142d5..6dd6182 100644 | --- a/testsuite/tests/callarity/unittest/CallArity1.hs | +++ b/testsuite/tests/callarity/unittest/CallArity1.hs | @@ -163,6 +163,10 @@ exprs = | , (n, Var go `mkApps` [d `mkLApps` [1]]) | , (go, mkLams [x] $ mkACase (Var n) (Var go `mkApps` [Var n | `mkVarApps` [x]]) ) ]) $ | Var go `mkApps` [mkLit 0, go `mkLApps` [0,1]] | + , ("a thunk (non-function-type) co-calls with the body (d 1 would be | bad)",) $ | + mkLet d (f `mkLApps` [0]) $ | + mkLet x (d `mkLApps` [1]) $ | + Var d `mkVarApps` [x] | ] | | main = do | diff --git a/testsuite/tests/callarity/unittest/CallArity1.stderr | b/testsuite/tests/callarity/unittest/CallArity1.stderr | index d5d7d91..c331a64 100644 | --- a/testsuite/tests/callarity/unittest/CallArity1.stderr | +++ b/testsuite/tests/callarity/unittest/CallArity1.stderr | @@ -78,3 +78,6 @@ a thunk (function type), in mutual recursion, still | calls once, d part of mutual | go 1 | d 1 | n 0 | +a thunk (non-function-type) co-calls with the body (d 1 would be bad): | + x 0 | + d 0 | diff --git a/testsuite/tests/perf/compiler/all.T | b/testsuite/tests/perf/compiler/all.T | index fc0abc9..b03a48f 100644 | --- a/testsuite/tests/perf/compiler/all.T | +++ b/testsuite/tests/perf/compiler/all.T | @@ -133,7 +133,7 @@ test('T3294', | # 2012-10-08: 1373514844 (x86/Linux) | # 2013-11-13: 1478325844 (x86/Windows, 64bit machine) | # 2014-01-12: 1565185140 (x86/Linux) | - (wordsize(64), 2897630040, 5)]), | + (wordsize(64), 2705289664, 5)]), | # old: 1357587088 (amd64/Linux) | # 29/08/2012: 2961778696 (amd64/Linux) | # (^ increase due to new codegen, see #7198) | @@ -141,6 +141,7 @@ test('T3294', | # 08/06/2013: 2901451552 (amd64/Linux) (reason unknown) | # 12/12/2013: 3083825616 (amd64/Linux) (reason unknown) | # 18/02/2014: 2897630040 (amd64/Linux) (call arity | improvements) | + # 12/03/2014: 2705289664 (amd64/Linux) (more call arity | improvements) | conf_3294 | ], | compile, | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0