#7930: Nested STM Invariants are lost
-------------------------------------+-------------------------------------
Reporter: fryguybob | Owner: fryguybob
Type: bug | Status: new
Priority: normal | Milestone:
Component: Runtime System | Version: 7.6.3
Resolution: | Keywords: STM
Operating System: Unknown/Multiple | Architecture:
Type of failure: Incorrect result | Unknown/Multiple
at runtime | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by int-e):
Replying to [comment:1 fryguybob]:
I believe the analysis is excellent. I only have some minor additional
comments:
> 2. The delay does not make sense because there are other effects that
can
> intervene before the transaction is committed! Indeed, it could be
that
> it will not hit the retry later on. Or an exception could happen
due to
> the very invariant property being checked (See example below).
In fact, the effect does not even have to be external to the transaction,
as demonstrated by the following single threaded example, which completes
successfully instead of getting stuck retrying the transaction:
{{{
import Control.Concurrent.STM
main = do
atomically $ do
t <- newTVar True
alwaysSucceeds $ do
b <- readTVar t
if b then retry else return ()
writeTVar t False
putStrLn "Success"
}}}
Interestingly, there is no CHECK rule for the `retry` case in the
operational semantics (Figure 4 of [1]), which could well explain this
oversight.
> This definition attempts to reuse the `retry` mechanism to handle the
rollback of the initial run of the invariant.
The rollback is (also?) necessary to ensure [D6].
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7930#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#13037: educational purpose 2
-------------------------------------+-------------------------------------
Reporter: vanto | Owner:
Type: feature | Status: new
request |
Priority: normal | Milestone:
Component: GHCi | Version: 8.0.1
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
The goal is to have, in GHCi, the interim results provided by the function
before the end result by a command available from the prompt, like
this: for example:[[BR]]
Prelude> g op n [] = n ; g op n (h:t) = h `op` g op n t[[BR]]
Prelude> :stp[[BR]]
Prelude> g (*) 2 [1..3][[BR]]
1* (*) 2 [2,3][[BR]]
1*2 (*) 2 [3][[BR]]
1*2*3 (*) 2 [][[BR]]
1*2*3*2[[BR]]
12[[BR]]
Prelude>[[BR]]
And to quit the mode we write from the prompt a command like this[[BR]]
Prelude> :quitstp
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13037>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#11216: RebindableSyntax with pattern guards needs `fail`
-------------------------------------+-------------------------------------
Reporter: goldfire | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.11
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
If I say
{{{
{-# LANGUAGE RebindableSyntax #-}
module Bug where
foo :: (a, b) -> ()
foo x | (_,_) <- x = ()
}}}
I get
{{{
Bug.hs:6:9: error: Not in scope: ‘fail’
}}}
Yet even if I bring `fail` into scope, it's not mentioned in the Core
produced by my program. And it really shouldn't: there's not a monad in
sight!
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11216>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#229: Integer overflow in array allocation
-------------------------------------+-------------------------------------
Reporter: josefs | Owner: bgamari
Type: bug | Status: closed
Priority: high | Milestone: 8.2.1
Component: Core Libraries | Version: 7.9
Resolution: fixed | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Changes (by akio):
* cc: akio (added)
Comment:
Sorry if I'm missing something, but the overflow check looks like it may
be incorrect. For example, if `Int` is 32 bits wide, `0x58000000 * 4 ::
Int` is greater than `0x58000000`, so it passes the test, but the
multiplication is still overflowing.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/229#comment:31>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#13021: Inaccessible RHS warning is confusing for users
-------------------------------------+-------------------------------------
Reporter: mpickering | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.0.1
Keywords: | Operating System: Unknown/Multiple
PatternMatchWarnings |
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
The pattern match checker makes the distinction between redundant matches
and matches with an inaccessible right hand side.
A pattern with an inaccessible RHS, is a redundant pattern which forces
the argument so affects strictness.
I think this is confusing for users as most of the time you write programs
assuming totality but the error message doesn't make it clear why the two
warnings are different. I think that instead they should both be called
redundant but a note added to the inaccessible case explaining that
removing it could affect strictness.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13021>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#13029: Dead code in DsCCall?
-------------------------------------+-------------------------------------
Reporter: goldfire | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.0.1
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
Simon and I were poring over `DsCCall.mk_alt`, and we seem to think that
the first case (for unboxed tuples) is dead code. If it's live, it's
utterly broken because it ignores the `RuntimeRep` args to an unboxed
tuple.
This ticket is to remind us to continue investigating.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13029>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#13031: Bogus calculation of bottoming arity
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.0.1
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
In `CoreArity` we see
{{{
andArityType (ABot n1) (ABot n2) = ABot (n1 `min` n2)
}}}
If you look at the documentation for `ABot` (which is about functions that
are ''guaranteed'' to diverge) this is obviously bogus. The `min` should
be `max`!
Here's a test case:
{{{
{-# LANGUAGE MagicHash #-}
module Foo( f ) where
import GHC.Prim
f True = raise# True
f False = \p q -> raise# False
}}}
If you compile (with GHC 8.0) `-ddump-simpl` you'll see
{{{
f :: forall a p1 p2. Bool -> p2 -> p1 -> a
[GblId, Arity=1, Caf=NoCafRefs, Str=<L,U>x]
}}}
That `Str=<L,U>x` is totally bogus; it claims that `f` will always diverge
given one argument.
The fix is easy.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13031>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#13004: Timeout no longer kills processes on timeout
-------------------------------------+-------------------------------------
Reporter: Phyx- | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 8.2.1
Component: Test Suite | Version: 8.1
Keywords: | Operating System: Windows
Architecture: | Type of failure: Incorrect result
Unknown/Multiple | at runtime
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
There's a bug in timeout where processes aren't being killed on a timeout.
e.g. `~/ghc/testsuite/timeout/install-inplace/bin/timeout.exe 10 "sleep
10000s"` never ends
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13004>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
