Re: STG code

On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote: > Sorry, I should have been more precise. The language definition does not > say anything about the pragmas and GHC ignores them by default. However, > GHC has a flag which tells it to assign a meaning to certain pragmas. > With this flag

Re: STG code

Tim Chevalier wrote: On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote: If it can't or doesn't want to maintain it, it throws it away. The info is optional: if it's there, it has to be correct but it doesn't have to be there. [snip] Just like in Haskell, they don't have a semantics -

Re: STG code

On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote: > > If it can't or doesn't want to maintain it, it throws it away. The info > is optional: if it's there, it has to be correct but it doesn't have to > be there. [snip] > > Just like in Haskell, they don't have a semantics - they are essen

Re: STG code

Tim Chevalier wrote: On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote: Tim Chevalier wrote: > > 2) Perhaps even more seriously, GHC keeps a great deal of analysis > information attached to variables, and it doesn't really make sense to > export much of it into External Core files --

Re: STG code

On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote: > Tim Chevalier wrote: > > > > 2) Perhaps even more seriously, GHC keeps a great deal of analysis > > information attached to variables, and it doesn't really make sense to > > export much of it into External Core files -- external tools

Re: STG code

Tim Chevalier wrote: 2) Perhaps even more seriously, GHC keeps a great deal of analysis information attached to variables, and it doesn't really make sense to export much of it into External Core files -- external tools presumably mostly can't or don't want to make usage of strictness informatio

Re: patch applied (ghc): Make some more modules use LazyUniqFM instead of UniqFM

Ian, This is a bad patch (maybe in conjunction with "Rewrite fixTvSubstEnv so it iteratively applies its substition"). The patch goes through validate, but it breaks builds using the "devel1" scheme defined in build.mk.sample. This might be due to the different optimisation settings, bu

Re: STG code

On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote: > Tim Chevalier wrote: > > > > Working on the documentation and external tools (with help from Andrew > > Tolmach) is my priority right now, as I need it for my own work. Thus > > *generating* External Core (and parsing it back in with a

[nightly] 20-Feb-2008 build of STABLE on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com)

Build description = STABLE on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com) Build location= /playpen/simonmar/nightly/STABLE Build config file = /home/simonmar/nightly/site/msrc/conf-STABLE-cam-02-unx Nightly build started on cam-02-unx at Wed Feb 20 18:10:01 GMT 2008. checki

Re: STG code

Tim Chevalier wrote: Working on the documentation and external tools (with help from Andrew Tolmach) is my priority right now, as I need it for my own work. Thus *generating* External Core (and parsing it back in with an external tool) should be possible for mere mortals again soon. That's gre

Re: Test concio001 failures on PPC Mac OS X

Hello, I am unable to make the new test concio002 fail on the PPC Mac where I was able to make concio001 fail. So that seems to have fixed the problem. Best regards Thorkil On Monday 18 February 2008 11:23, Simon Marlow wrote: > [EMAIL PROTECTED] wrote: > > Hello, > > > > The test case concio00

patch applied (ghc): Rewrite fixTvSubstEnv so it iteratively applies its substition

Wed Feb 20 07:37:52 PST 2008 Ian Lynagh <[EMAIL PROTECTED]> * Rewrite fixTvSubstEnv so it iteratively applies its substition This fixes a stack overflow when using strict UniqFMs. It might be possible to rewrite it more efficiently, or to avoid needing it in the first place. M ./compi

patch applied (ghc): Typo

Tue Feb 19 12:41:17 PST 2008 Ian Lynagh <[EMAIL PROTECTED]> * Typo M ./compiler/simplCore/OccurAnal.lhs -1 +1 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

patch applied (ghc): Make some more modules use LazyUniqFM instead of UniqFM

Wed Feb 6 17:57:14 PST 2008 Ian Lynagh <[EMAIL PROTECTED]> UNDO: Make some more modules use LazyUniqFM instead of UniqFM If these modules use UniqFM then we get a stack overflow when compiling modules that use fundeps. I haven't tracked down the actual cause. M ./compiler/basicTypes/Ne

patch applied (testsuite): Add 'dyn' as WAY (different from 'normal' only by -dynamic)

Wed Feb 20 05:53:04 PST 2008 Clemens Fruhwirth <[EMAIL PROTECTED]> * Add 'dyn' as WAY (different from 'normal' only by -dynamic) M ./config/ghc -3 +5 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

Daily report for head

Build results: x86-64 Linux head: fail (exception build.mk) x86 Windows head: lost x86 Windows head fast: lost pass pass kahl G5 Gentoo Linux head: pass tnaur PPC OSX head 2: pass x86-64 Linux head unreg: lost New unexpected test failures: CPUTime001 1 x86 Window

Daily report for stable

Build results: gabor stable: pass kahl G5 Gentoo Linux stable:pass mnemosyne x86-64 Gentoo stable: pass tnaur PPC OSX stable 2: fail (failed stage2) tnaur x86 Linux stable: fail (failed stage1) x86 Windows stable: lost x86 Windows stable fast: