Re: [GHC] #5625: Code using seq has wrong strictness when unoptimised (too lazy)
#5625: Code using seq has wrong strictness when unoptimised (too lazy)
---+
Reporter: michal.palka|Owner: simonpj
Type: bug | Status: new
Priority: high|Milestone: 7.4.1
Component: Compiler| Version: 7.3
Keywords: seq strictness strict lazy | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple| Blocking:
Architecture: Unknown/Multiple| Failure: Incorrect result at
runtime
---+
Comment(by simonpj@…):
commit a522c3b25eea1fe40edae7052335acce75e8a1c3
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Fri Nov 11 20:08:42 2011 +
Tighten up the definition of arityType a bit further,
to make Trac #5625 work. The main change is that
we eta-expand (case x of p - \y. blah) only if the
case-expression is in the context of a \x. That is still
technically unsound, but it makes a big difference to
performance; and the change narrows the unsound cases
a lot.
compiler/coreSyn/CoreArity.lhs | 140
+++-
1 files changed, 80 insertions(+), 60 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5625#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #5625: Code using seq has wrong strictness when unoptimised (too lazy)
#5625: Code using seq has wrong strictness when unoptimised (too lazy)
-+--
Reporter: michal.palka | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.3 |Keywords: seq strictness strict lazy
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: Incorrect result at runtime
-+--
The code code should crash with Prelude.undefined. When compiled with `-O`
it behaves correctly, however with no optimisation (`-O0`) it prints `[0]`
instead. Reading the Core suggests that the expression gets translated
into `print (id [0])` when compiled with `-O0`. It was tested with GHC
7.3.20111022.
{{{
main = do
let a = \x - seq undefined (+1)
print $ (a `seq` a [] `seq` id) [0]
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5625
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5625: Code using seq has wrong strictness when unoptimised (too lazy)
#5625: Code using seq has wrong strictness when unoptimised (too lazy)
-+--
Reporter: michal.palka | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.3 |Keywords: seq strictness strict lazy
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: Incorrect result at runtime
-+--
Comment(by michal.palka):
It seems that it's possible to simplify it further if `a` is exported.
Thanks to Nick Smallbone for suggesting this one.
{{{
module Main (a, main) where
a = \x - seq undefined (+1)
main = do
print $ (a [] `seq` id) [0]
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5625#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5625: Code using seq has wrong strictness when unoptimised (too lazy)
#5625: Code using seq has wrong strictness when unoptimised (too lazy) ---+ Reporter: michal.palka|Owner: simonpj Type: bug | Status: new Priority: high|Milestone: 7.4.1 Component: Compiler| Version: 7.3 Keywords: seq strictness strict lazy | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple| Blocking: Architecture: Unknown/Multiple| Failure: Incorrect result at runtime ---+ Changes (by igloo): * owner: = simonpj * priority: normal = high * milestone: = 7.4.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5625#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
