[GHC] #7295: bad code for Double literals
#7295: bad code for Double literals
--+-
Reporter: jwlato| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
For this program
{{{
module Foo where
foo :: [Double] - [Double]
foo = map f
where f x = x*(-0.5)
}}}
GHC generates the following core:
{{{
Foo.foo5 :: GHC.Integer.Type.Integer
[GblId,
Str=DmdType,
Unf=Unf{Src=vanilla, TopLvl=True, Arity=0, Value=True,
ConLike=True, WorkFree=True, Expandable=True,
Guidance=IF_ARGS [] 100 0}]
Foo.foo5 = __integer 1
Foo.foo4 :: GHC.Integer.Type.Integer
[GblId,
Str=DmdType,
Unf=Unf{Src=vanilla, TopLvl=True, Arity=0, Value=True,
ConLike=True, WorkFree=True, Expandable=True,
Guidance=IF_ARGS [] 100 0}]
Foo.foo4 = __integer 2
Foo.foo3 :: GHC.Types.Double
[GblId,
Str=DmdType,
Unf=Unf{Src=vanilla, TopLvl=True, Arity=0, Value=False,
ConLike=False, WorkFree=False, Expandable=False,
Guidance=IF_ARGS [] 51 20}]
Foo.foo3 =
case GHC.Float.$w$cfromRational Foo.foo5 Foo.foo4
of _ { GHC.Types.D# x_agI -
GHC.Types.D# (GHC.Prim.negateDouble# x_agI)
}
Foo.foo1 :: GHC.Types.Double - GHC.Types.Double
[GblId,
Arity=1,
Str=DmdType U(L)m,
Unf=Unf{Src=InlineStable, TopLvl=True, Arity=1, Value=True,
ConLike=True, WorkFree=True, Expandable=True,
Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=False)
Tmpl= \ (eta_B1 [Occ=Once] :: GHC.Types.Double) -
GHC.Float.timesDouble eta_B1 Foo.foo3}]
Foo.foo1 =
\ (eta_B1 :: GHC.Types.Double) -
GHC.Float.timesDouble eta_B1 Foo.foo3
Foo.foo :: [GHC.Types.Double] - [GHC.Types.Double]
[GblId,
Arity=1,
Str=DmdType,
Unf=Unf{Src=vanilla, TopLvl=True, Arity=0, Value=True,
ConLike=True, WorkFree=True, Expandable=True,
Guidance=IF_ARGS [] 20 60}]
Foo.foo =
GHC.Base.map @ GHC.Types.Double @ GHC.Types.Double Foo.foo1
}}}
which looks pretty bad to me.
This may be related to #5731, especially as 'foo2 = map (* (-0.5))'
results in much better code.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7295
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] #7292: Optimization works for Word but not Word32 or Word64
#7292: Optimization works for Word but not Word32 or Word64 -+-- Reporter: zuserm| Owner: igloo Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * owner: = igloo * difficulty: = Unknown * priority: normal = high * milestone: = 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7292#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
[GHC] #7296: ghc-7 assumes incoherent instances without requiring language `IncoherentInstances`
#7296: ghc-7 assumes incoherent instances without requiring language
`IncoherentInstances`
-+--
Reporter: maeder | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.6.1| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: GHC accepts invalid program | Testcase:
Blockedby: | Blocking:
Related: |
-+--
the attached examples works with ghc-7 and returns
{{{
*Main a
[Spec1 Spec2]
*Main b
[]
}}}
(One may wish that b also returned [Spec1 Spec2])
ghc-6 complains with
{{{
Splittable.hs:16:36:
Overlapping instances for Test a Spec2
arising from a use of `test' at Splittable.hs:16:36-43
Matching instances:
instance [overlap ok] Test a Spec2
-- Defined at Splittable.hs:20:13-24
instance [overlap ok] Test Bool Spec2
-- Defined at Splittable.hs:25:13-27
(The choice depends on the instantiation of `a'
To pick the first instance above, use -XIncoherentInstances
when compiling the other instance declarations)
In the second argument of `($)', namely `test a b'
In the expression: map Spec1 $ test a b
In the definition of `test':
test a (Spec1 b) = map Spec1 $ test a b
Failed, modules loaded: none.
}}}
After adding `IncoherentInstances` the file also goes through ghc-6 with
the same results.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7296
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] #7296: ghc-7 assumes incoherent instances without requiring language `IncoherentInstances`
#7296: ghc-7 assumes incoherent instances without requiring language `IncoherentInstances` -+-- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Testcase: Blockedby: | Blocking: Related: | -+-- Comment(by maeder): I meant, one may wish that a and b returned equal results, namely that a returned [] by using the more special instance of Spec2 in the instance definition of Spec1. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7296#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] #7295: bad code for Double literals
#7295: bad code for Double literals
-+--
Reporter: jwlato| Owner: igloo
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by simonpj):
* owner: = igloo
* difficulty: = Unknown
Comment:
Good point. Here's what is happening.
* In `map (* (-0.5)) xs :: [Double]`, the typechecker and/or desugarer
can see a totally mono-typed use of the literal `0.5` at `Double` and so
genreates exactly that literal.
* But in your main example, you define a polymorphic function `f`, whose
type is
{{{
f :: Fractional a = a - a
}}}
Sure, `f` has only one call site but the typechecker/desugarer don't know
that, so they generate `fromRational d (negate d (1 % 2))`, where `d` is
the fractional dictionary.
So, good as the typechecker/desugarer short-cut is for literals, your
example points out that we should do better constant folding for literals
that start life overloaded, but become specialised. This will also happen
when we have a top-level overloaded function that gets specialised.
My solution. In `GHC.Float` we see
{{{
instance Fractional Float where
fromRational = blah blah blah
}}}
Instead we want
{{{
instance Fractioal Float where
{-# INLINE fromRational #-}
fromRational (a :% b) = rationalToFloat a b
rationalToFloat :: Integer - Integer - Float
{-# NOINLINE [1] rationalToFloat
rationalToFloat = blah blah blah -- As before
}}}
AND we want a constant-folding rule in `PrelRules` for `rationalToFloat`
that spots two `Integer`-literal arguments and produces the right float;
just like `TcHsSyn.shortCutLit` does.
Same for `fromRational` at `Double`.
We already have similar mechanisms for `fromInteger`, so I think that's
all right.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7295#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] #7295: bad code for Double literals
#7295: bad code for Double literals -+-- Reporter: jwlato| Owner: igloo Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * priority: normal = high * milestone: = 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7295#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
Re: [GHC] #7296: ghc-7 assumes incoherent instances without requiring language `IncoherentInstances`
#7296: ghc-7 assumes incoherent instances without requiring language
`IncoherentInstances`
-+--
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: GHC accepts invalid program
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by simonpj):
* difficulty: = Unknown
Comment:
You are right, and this is tricky. The real error is that in the recursive
call to `test` on line 16 of `Splittable.hs`, rather than rejecting the
code (which is arguably right) GHC picks the `Test a Spec2` instance on
line 20.
But that's actually deliberate. Here the note from `TcInstDcls`:
{{{
Note [Subtle interaction of recursion and overlap]
~~
Consider this
class C a where { op1,op2 :: a - a }
instance C a = C [a] where
op1 x = op2 x ++ op2 x
op2 x = ...
instance C [Int] where
...
When type-checking the C [a] instance, we need a C [a] dictionary (for
the call of op2). If we look up in the instance environment, we find
an overlap. And in *general* the right thing is to complain (see Note
[Overlapping instances] in InstEnv). But in *this* case it's wrong to
complain, because we just want to delegate to the op2 of this same
instance.
Why is this justified? Because we generate a (C [a]) constraint in
a context in which 'a' cannot be instantiated to anything that matches
other overlapping instances, or else we would not be excecuting this
version of op1 in the first place.
It might even be a bit disguised:
nullFail :: C [a] = [a] - [a]
nullFail x = op2 x ++ op2 x
instance C a = C [a] where
op1 x = nullFail x
Precisely this is used in package 'regex-base', module Context.hs.
See the overlapping instances for RegexContext, and the fact that they
call 'nullFail' just like the example above. The DoCon package also
does the same thing; it shows up in module Fraction.hs
Conclusion: when typechecking the methods in a C [a] instance, we want to
treat the 'a' as an *existential* type variable, in the sense described
by Note [Binding when looking up instances]. That is why
isOverlappableTyVar
responds True to an InstSkol, which is the kind of skolem we use in
tcInstDecl2.
}}}
But your example points out that my reasoning is flawed. I'm not sure
exactly what to do, and I'm too swamped to think about it right now. I
hope it's not a show stopper for you.
You can work around thus:
{{{
instance Test a Spec2 = Test a Spec1 where
test a (MkSpec1 b) = map MkSpec1 $ test a b
}}}
which defers the choice to later, which is what we want. Then you get
`[]` for both tests. Sadly you need `FlexibleContexts` and
`UndecidableInstances` to persuade GHC to accept this instance.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7296#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
Re: [GHC] #7296: ghc-7 assumes incoherent instances without requiring language `IncoherentInstances`
#7296: ghc-7 assumes incoherent instances without requiring language `IncoherentInstances` -+-- Reporter: maeder| Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC accepts invalid program Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by maeder): Thanks for this analysis, it is no show stopper for us. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7296#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
Re: [GHC] #6018: Injective type families
#6018: Injective type families +--- Reporter: lunaris | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: TypeFamilies, Injective | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | +--- Changes (by nfrisby): * cc: nfrisby (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6018#comment:8 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] #7050: stage 1 compiler crashes when the quickest build flavour is chosen
#7050: stage 1 compiler crashes when the quickest build flavour is chosen
---+
Reporter: ilya| Owner:
Type: bug | Status: merge
Priority: normal | Milestone:
Component: Compiler| Version: 7.5
Keywords: | Os: MacOS X
Architecture: x86_64 (amd64) | Failure: Building GHC failed
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Changes (by simonpj):
* status: new = merge
Comment:
OK, the commit that broke this was
{{{
commit 792449f555bb4dfa8e718079f6d42dc9babe938a
Author: Simon Peyton Jones simo...@microsoft.com
Date: Sat Jun 11 14:26:34 2011 +0100
Ignore UNPACK pragmas with OmitInterfacePragmas is on (fixes Trac
#5252)
The point here is that if a data type chooses a representation that
unpacks an argument field, the representation of the argument field
must be visible to clients. And it may not be if OmitInterfacePragmas
is on.
compiler/typecheck/TcTyClsDecls.lhs | 44
+--
1 file changed, 22 insertions(+), 22 deletions(-)
}}}
However, it was fixed on the HEAD by
{{{
commit ba8fd081ba9b222dd5f93604d7deeaca372e4511
Author: Simon Peyton Jones simo...@microsoft.com
Date: Mon Sep 17 18:22:10 2012 +0100
Make the call to chooseBoxingStrategy lazy again
}}}
(Confusingly the latter patch attributes the introduction of the bug to
the wrong patch.)
The basic solution is to apply the fix on the branch too. It may not
apply cleanly because there are some intermediate patches on HEAD, but I
think it should be obvious what to do. The important thing is that in
`tcConArg` we should see
{{{
; let strict_mark = chooseBoxingStrategy dflags arg_ty
(getBangStrictness bty)
}}}
or something like that, NOT `strict_mark - chooseBoxingStrategy...`.
Ian, can you fix this up please? I'll add a test for HEAD.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7050#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
Re: [GHC] #7293: Wrong location reported for inaccessible code with GADTs
#7293: Wrong location reported for inaccessible code with GADTs
--+-
Reporter: goldfire | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.6.1 | Keywords: GADTs
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
Comment(by simonpj@…):
commit 629d1f48b513be3cc662ea79376737dbcdb6b18f
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Thu Oct 4 17:54:38 2012 +0100
Improve erorr location for Given errors
Note [Inaccessible code].
Fixes Trac #7293.
compiler/typecheck/TcErrors.lhs | 91
+++---
compiler/typecheck/TcRnTypes.lhs |5 ++-
2 files changed, 59 insertions(+), 37 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7293#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] #7204: Use a class to control FFI marshalling
#7204: Use a class to control FFI marshalling
-+--
Reporter: simonpj | Owner:
Type: feature request | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.4.2
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by simonpj):
You're right. And arguably `newtype deriving` should work with at
suitably-simple AT. Given
{{{
class C a where
type F a :: kind
newtype T a b c = MkT reptype deriving( C )
}}}
we should generate an instance looking like
{{{
instance C reptype = C (T a b c) where
F (T a b c) = F reptype
}}}
That's another new extension to the (already complex) `newtype deriving`,
but people will surely be asking for it before long!
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7204#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] #7297: LLVM incorrectly hoisting loads
#7297: LLVM incorrectly hoisting loads -+-- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Testcase: 367_letnoescape Blockedby: | Blocking: Related: | -+-- test 367_letnoescape fails under LLVM as a load of the HpLim register is hoisted out of the loop. So yielding is never done. What I am not sure about right now is the best way to fix. Loads in LLVM can be annotated in a few different ways to fix this and not sure which one is the most 'correct'. All the following work: * mark the load as volatile. (seems to give nicest code as well) * mark the load as atomic with either monotonic or seq_cst ordering. * mark the load as both volatile and atomic. This bug while only affecting a single test case seems very serious and potentially indicative of a large problem. How well are we communicating the load/store threaded semantics to LLVM? So making a bug for now as I don't know yet the best way to proceed without dedicating some time to reading LLVM docs and probably talking to the LLVM devs as the docs on the memory model are fairly confusing. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7297 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] #7297: LLVM incorrectly hoisting loads
#7297: LLVM incorrectly hoisting loads -+-- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Testcase: 367_letnoescape Blockedby: | Blocking: Related: | -+-- Description changed by dterei: Old description: test 367_letnoescape fails under LLVM as a load of the HpLim register is hoisted out of the loop. So yielding is never done. What I am not sure about right now is the best way to fix. Loads in LLVM can be annotated in a few different ways to fix this and not sure which one is the most 'correct'. All the following work: * mark the load as volatile. (seems to give nicest code as well) * mark the load as atomic with either monotonic or seq_cst ordering. * mark the load as both volatile and atomic. This bug while only affecting a single test case seems very serious and potentially indicative of a large problem. How well are we communicating the load/store threaded semantics to LLVM? So making a bug for now as I don't know yet the best way to proceed without dedicating some time to reading LLVM docs and probably talking to the LLVM devs as the docs on the memory model are fairly confusing. New description: test 367_letnoescape fails under LLVM as a load of the !HpLim register is hoisted out of the loop. So yielding is never done. What I am not sure about right now is the best way to fix. Loads in LLVM can be annotated in a few different ways to fix this and not sure which one is the most 'correct'. All the following work: * mark the load as volatile. (seems to give nicest code as well) * mark the load as atomic with either monotonic or seq_cst ordering. * mark the load as both volatile and atomic. This bug while only affecting a single test case seems very serious and potentially indicative of a large problem. How well are we communicating the load/store threaded semantics to LLVM? So making a bug for now as I don't know yet the best way to proceed without dedicating some time to reading LLVM docs and probably talking to the LLVM devs as the docs on the memory model are fairly confusing. -- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7297#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] #7297: LLVM incorrectly hoisting loads
#7297: LLVM incorrectly hoisting loads -+-- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Testcase: 367_letnoescape Blockedby: | Blocking: Related: | -+-- Description changed by dterei: Old description: test 367_letnoescape fails under LLVM as a load of the !HpLim register is hoisted out of the loop. So yielding is never done. What I am not sure about right now is the best way to fix. Loads in LLVM can be annotated in a few different ways to fix this and not sure which one is the most 'correct'. All the following work: * mark the load as volatile. (seems to give nicest code as well) * mark the load as atomic with either monotonic or seq_cst ordering. * mark the load as both volatile and atomic. This bug while only affecting a single test case seems very serious and potentially indicative of a large problem. How well are we communicating the load/store threaded semantics to LLVM? So making a bug for now as I don't know yet the best way to proceed without dedicating some time to reading LLVM docs and probably talking to the LLVM devs as the docs on the memory model are fairly confusing. New description: test 367_letnoescape fails under LLVM as a load of the !HpLim register is hoisted out of the loop. So yielding is never done. What I am not sure about right now is the best way to fix. Loads in LLVM can be annotated in a few different ways to fix this and not sure which one is the most 'correct'. All the following work: * mark the load as volatile. (seems to give nicest code as well) * mark the load as atomic with either monotonic or seq_cst ordering. * mark the load as both volatile and atomic. This bug while only affecting a single test case seems very serious and potentially indicative of a large problem. How well are we communicating the load/store threaded semantics to LLVM? So making a bug for now as I don't know yet the best way to proceed without dedicating some time to reading LLVM docs and probably talking to the LLVM devs as the docs on the memory model are fairly confusing. -- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7297#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
Re: [GHC] #7297: LLVM incorrectly hoisting loads
#7297: LLVM incorrectly hoisting loads -+-- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Testcase: 367_letnoescape Blockedby: | Blocking: Related: | -+-- Description changed by dterei: Old description: test 367_letnoescape fails under LLVM as a load of the !HpLim register is hoisted out of the loop. So yielding is never done. What I am not sure about right now is the best way to fix. Loads in LLVM can be annotated in a few different ways to fix this and not sure which one is the most 'correct'. All the following work: * mark the load as volatile. (seems to give nicest code as well) * mark the load as atomic with either monotonic or seq_cst ordering. * mark the load as both volatile and atomic. This bug while only affecting a single test case seems very serious and potentially indicative of a large problem. How well are we communicating the load/store threaded semantics to LLVM? So making a bug for now as I don't know yet the best way to proceed without dedicating some time to reading LLVM docs and probably talking to the LLVM devs as the docs on the memory model are fairly confusing. New description: test 367_letnoescape fails under LLVM as a load of the !HpLim register is hoisted out of the loop. So yielding is never done. What I am not sure about right now is the best way to fix. Loads in LLVM can be annotated in a few different ways to fix this and not sure which one is the most 'correct'. All the following work: * mark the load as volatile. (seems to give nicest code as well) * mark the load as atomic with either monotonic or seq_cst ordering. * mark the load as both volatile and atomic. This bug while only affecting a single test case seems very serious and potentially indicative of a large problem. How well are we communicating the load/store threaded semantics to LLVM? And what semantics do we need to communicate? I think we are fine other than the STG registers... So making a bug for now as I don't know yet the best way to proceed without dedicating some time to reading LLVM docs and probably talking to the LLVM devs as the docs on the memory model are fairly confusing. -- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7297#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
Re: [GHC] #7297: LLVM incorrectly hoisting loads
#7297: LLVM incorrectly hoisting loads
-+--
Reporter: dterei | Owner: dterei
Type: bug | Status: new
Priority: normal | Component: Compiler (LLVM)
Version: 7.7 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Incorrect result at runtime | Testcase: 367_letnoescape
Blockedby: | Blocking:
Related: |
-+--
Description changed by dterei:
Old description:
test 367_letnoescape fails under LLVM as a load of the !HpLim register is
hoisted out of the loop. So yielding is never done.
What I am not sure about right now is the best way to fix. Loads in LLVM
can be annotated in a few different ways to fix this and not sure which
one is the most 'correct'.
All the following work:
* mark the load as volatile. (seems to give nicest code as well)
* mark the load as atomic with either monotonic or seq_cst ordering.
* mark the load as both volatile and atomic.
This bug while only affecting a single test case seems very serious and
potentially indicative of a large problem. How well are we communicating
the load/store threaded semantics to LLVM?
And what semantics do we need to communicate? I think we are fine other
than the STG registers...
So making a bug for now as I don't know yet the best way to proceed
without dedicating some time to reading LLVM docs and probably talking to
the LLVM devs as the docs on the memory model are fairly confusing.
New description:
test 367_letnoescape fails under LLVM as a load of the !HpLim register is
hoisted out of the loop. So yielding is never done.
What I am not sure about right now is the best way to fix. Loads in LLVM
can be annotated in a few different ways to fix this and not sure which
one is the most 'correct'.
All the following work:
* mark the load as volatile. (seems to give nicest code as well)
* mark the load as atomic with either monotonic or seq_cst ordering.
* mark the load as both volatile and atomic.
This bug while only affecting a single test case seems very serious and
potentially indicative of a large problem. How well are we communicating
the load/store threaded semantics to LLVM?
And what semantics do we need to communicate? I think we are fine other
than the STG registers...
So making a bug for now as I don't know yet the best way to proceed
without dedicating some time to reading LLVM docs and probably talking to
the LLVM devs as the docs on the memory model are fairly confusing.
e.g., Code in question:
Bad version (LBB0_1 loops forever as load hoisted out):
{{{
r1Uf_info: # @r1Uf_info
# BB#0: # %c1Vy
movq144(%r13), %rax
decq%r14
.align 16, 0x90
.LBB0_1:# %tailrecurse
# =This Inner Loop Header:
Depth=1
incq%r14
testq %rax, %rax
jne .LBB0_1
# BB#2: # %c1VD
movq-8(%r13), %rax
movl$r1Uf_closure, %ebx
jmpq*%rax # TAILCALL
}}}
Code when marked with atomic (either monatonic or seq_cst) or both atomic
and volatile:
{{{
r1Uf_info: # @r1Uf_info
# BB#0: # %c1Vy
decq%r14
.align 16, 0x90
.LBB0_1:# %tailrecurse
# =This Inner Loop Header:
Depth=1
incq%r14
movq144(%r13), %rax
testq %rax, %rax
jne .LBB0_1
# BB#2: # %c1VD
movq-8(%r13), %rax
movl$r1Uf_closure, %ebx
jmpq*%rax # TAILCALL
}}}
Code when marked volatile:
{{{
r1Uf_info: # @r1Uf_info
# BB#0: # %c1Vy
decq%r14
.align 16, 0x90
.LBB0_1:# %tailrecurse
# =This Inner Loop Header:
Depth=1
incq%r14
cmpq$0, 144(%r13)
jne .LBB0_1
# BB#2: # %c1VD
movq-8(%r13), %rax
movl$r1Uf_closure, %ebx
jmpq*%rax # TAILCALL
}}}
--
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7297#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
Re: [GHC] #7162: RULES that never fire (automatically)
#7162: RULES that never fire (automatically) -+-- Reporter: andygill | Owner: Type: feature request | Status: patch Priority: normal| Milestone: Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by afarmer): * status: new = patch Comment: Here is a patch that implements this functionality (with [~] meaning never automatically fire), as well as a patch to the testsuite to verify the parser works. I've built HERMIT against head (with this patch applied) and verified that we can still use RULES that are marked to never fire (at both ends of the optimization pipeline). As an aside, all the packages required by HERMIT compiled fine, so it doesn't seem to break any existing code. I've also run the ghc validate script, with no extra unexpected errors. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7162#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
Re: [GHC] #7162: RULES that never fire (automatically)
#7162: RULES that never fire (automatically) -+-- Reporter: andygill | Owner: Type: feature request | Status: patch Priority: normal| Milestone: Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by afarmer): * version: 7.4.2 = 7.7 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7162#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] #7298: Test 2228 fails with dynamic-by-default
#7298: Test 2228 fails with dynamic-by-default
-+--
Reporter: igloo | Owner: igloo
Type: bug | Status: new
Priority: high | Milestone: 7.8.1
Component: GHCi | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
{{{
= 2228(normal) 6 of 8 [0, 0, 0]
cd . $MAKE --no-print-directory -s 2228/dev/null 2228.run.stdout
8.run.stderr
Actual stdout output differs from expected:
--- ./2228.stdout 2011-07-21 12:03:54.0 +0100
+++ ./2228.run.stdout 2012-10-05 02:07:04.0 +0100
@@ -1,2 +1,2 @@
BlockBuffering Nothing
-BlockBuffering Nothing
+NoBuffering
*** unexpected failure for 2228(normal)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7298
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] #7299: threadDelay broken in ghci, Mac OS X
#7299: threadDelay broken in ghci, Mac OS X
+---
Reporter: tmcdonell | Owner:
Type: bug | Status: new
Priority: normal | Component: GHCi
Version: 7.6.1 | Keywords:
Os: MacOS X | Architecture: Unknown/Multiple
Failure: GHCi crash | Testcase:
Blockedby: | Blocking:
Related: |
+---
`Control.Concurrent.threadDelay` fails in ghci on Mac OS X. Behaviour is
correct in compiled code. To reproduce, it is enough to just execute
`threadDelay` at the prompt.
Depending on the architecture, I get different behaviour:
* i386: 7.6.1 and 7.7.20121003: segmentation fault (11)
* x86_64: 7.6.1 and 7.7.20121003: executes without segfault, but there
is no actual delay.
This is on Mac OS X 10.7.5 and 10.8.2.
Correct behaviour for ghci-7.6.1-x86_64 on Ubuntu 12.04. Also fine on Mac
in the 7.4 series.
Example output:
{{{
Nightfall $ ghci
GHCi, version 7.6.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude Foreign.Storable.sizeOf (undefined :: Int)
4
Prelude Control.Concurrent.threadDelay (1000 * 1000)
Segmentation fault: 11
}}}
Sample program for the second case:
{{{
import Control.Concurrent
count :: Int - IO ()
count n
| n = 0 = return ()
| otherwise = do
putStrLn $ shows n -ah-ha-ha
threadDelay (1000 * 1000) -- 1 second
count (n-1)
main :: IO ()
main = count 10
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7299
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
