Re: [GHC] #7120: Markdown literate programming proposal
#7120: Markdown literate programming proposal -+-- Reporter: holzensp |Owner: Type: feature request | Status: closed Priority: normal|Component: Compiler Version: 7.5 | Resolution: invalid Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Testcase:|Blockedby: Blocking:| Related: #4836 -+-- Changes (by holzensp): * status: new = closed * resolution: = invalid -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7120#comment:4 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] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons --+- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: lowest | Milestone: 7.6.1 Component: Compiler |Version: 6.8.2 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by simonmar): C/C++ compilers use abstract interpretation to do this, e.g. [http://en.wikipedia.org/wiki/Sparse_conditional_constant_propagation]. This could be expressed very nicely as a Hoopl optimisation, which would deal nicely with loops too. However, at the Hoopl level we would only be able to optimise within a single function or closure, whereas doing this at the Core level has far greater reach. I don't have any specific comments about this particular implementation - there's a lot of code and I haven't fully reviewed it. I still think the best way forward is for this to be a plugin; I think all the infrastructure is in place to make this work. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:26 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] #6156: Optimiser bug on linux-powerpc
#6156: Optimiser bug on linux-powerpc
--+-
Reporter: erikd| Owner: igloo
Type: bug | Status: new
Priority: normal | Milestone: 7.6.1
Component: Compiler |Version: 7.4.1
Resolution: | Keywords:
Os: Linux| Architecture: powerpc
Failure: Incorrect result at runtime | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Comment(by erikd):
Thanks @simonmar, thats a good tip. Using the FFI:
{{{
import Foreign.C.Types
import Numeric
foreign import ccall c_printInt64 printInt64 :: CLLong - IO ()
main :: IO ()
main = do
printInt64 input
putStrLn (showHex input )
input :: CLLong
input = 0x1a2a3a4a5a6a7a8a
}}}
and compiled without optimisation I get:
{{{
1a2a3a4a5a6a7a8a
1a2a3a4a5a6a7a8a
}}}
and with optimisation I get:
{{{
7a8a
1a2a3a4a5a6a7a8a
}}}
which is weird in that the FFI version is incorrect, but only when
optimisation is off.
Modifying this example as:
{{{
import Foreign.C.Types
import Numeric
foreign import ccall c_printInt64 printInt64 :: CLLong - IO ()
main :: IO ()
main = do
printInt64 (succ input)
putStrLn (showHex (succ input) )
input :: CLLong
input = 0x1a2a3a4a5a6a7a8a
}}}
and then both the FFI and the pure Haskell version are incorrect with
optimisation.
This suggests that its actually a problem with the way 64 bit values are
passed to functions.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6156#comment:38
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] #6156: Optimiser bug on linux-powerpc
#6156: Optimiser bug on linux-powerpc
--+-
Reporter: erikd| Owner: igloo
Type: bug | Status: new
Priority: normal | Milestone: 7.6.1
Component: Compiler |Version: 7.4.1
Resolution: | Keywords:
Os: Linux| Architecture: powerpc
Failure: Incorrect result at runtime | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Comment(by simonmar):
Replying to [comment:38 erikd]:
foreign import ccall c_printInt64 printInt64 :: CLLong - IO ()
Add unsafe here to make the generated code simpler.
main :: IO ()
main = do
printInt64 input
putStrLn (showHex input )
suggest getting rid of the `putStrLn`, again to make things simpler.
and compiled without optimisation I get:
{{{
1a2a3a4a5a6a7a8a
1a2a3a4a5a6a7a8a
}}}
and with optimisation I get:
{{{
7a8a
1a2a3a4a5a6a7a8a
}}}
which is weird in that the FFI version is incorrect, but only when
optimisation is off.
Did you mean to say ''on'' here?
This suggests that its actually a problem with the way 64 bit values are
passed to functions.
Yes, probably.
So now you have a very simple example that generates incorrect code and
doesn't call any library functions, the bug must be somewhere in the
generated code for this module. Compile it with -S and eyeball the
assembly code.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6156#comment:39
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] #7177: Flag -rtsopts not obeyed in hs_init()
#7177: Flag -rtsopts not obeyed in hs_init() ---+ Reporter: augustss | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Runtime System|Version: 7.4.2 Resolution: invalid | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * status: new = closed * difficulty: = Unknown * resolution: = invalid Comment: This is documented in the User Guide: [http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html #using-own-main], you need to call `hs_init_ghc()` to use a different `RtsConfig`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7177#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] #6057: hGetBufNonBlocking blocks the underlying handle on Windows
#6057: hGetBufNonBlocking blocks the underlying handle on Windows --+- Reporter: cetinsert| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base |Version: 7.0.4 Resolution: invalid | Keywords: Os: Windows | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by simonmar): Replying to [comment:7 cetinsert]: Now I came to learn that one should not have any assumptions on how handles should behave as they seem to very platform specific in funny ways. Could you give more details? Handles are supposed to be a platform- independent API. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6057#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] #6156: Optimiser bug on linux-powerpc
#6156: Optimiser bug on linux-powerpc
--+-
Reporter: erikd| Owner: igloo
Type: bug | Status: new
Priority: normal | Milestone: 7.6.1
Component: Compiler |Version: 7.4.1
Resolution: | Keywords:
Os: Linux| Architecture: powerpc
Failure: Incorrect result at runtime | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Comment(by erikd):
Replying to [comment:39 simonmar]:
which is weird in that the FFI version is incorrect, but only when
optimisation is off.
Did you mean to say ''on'' here?
Yes.
Simplifying the haskell code (adding unsafe as suggested):
{{{
import Foreign.C.Types
import Numeric
foreign import ccall unsafe c_printInt64 printInt64 :: CLLong - IO ()
main :: IO ()
main = printInt64 input
input :: CLLong
input = 0x1a2a3a4a5a6a7a8a
}}}
compiles to the following ASM:
{{{
Main.main1_info:
_c1ni:
lis 31, 0; r31 = 0
ori 31, 31, 31370; r31 |= 0x7a8a
lis 30, 0; r30 = 0
ori 31, 31, 0; r30 |= 0
mr 3, 30; r3 = r30
mr 4, 31; r4 = r31
bl c_printInt64
lis 14, GHC.Tuple.()_closure+1@ha
addi14, 14, GHC.Tuple.()_closure+1@l
lwz 31, 0(22)
mtctr 31
bctr
}}}
Obviously the generated code is wrong. Looking at the PPC code generator
now.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6156#comment:40
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] #7171: erroneous overlapping instances reported with FunDeps
#7171: erroneous overlapping instances reported with FunDeps -+-- Reporter: jwlato | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) |Version: 7.6.1-rc1 Resolution: fixed | Keywords: type classes, fundeps Os: Unknown/Multiple| Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: typecheck/should_compile/T7171 | Blockedby: Blocking: |Related: -+-- Comment(by simonpj): That is very strange. The patches I ''thought'' were important have been merged. I'll build 7.6 and try wit that. It's great to have your small test case, thank you. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7171#comment:4 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] #7171: erroneous overlapping instances reported with FunDeps
#7171: erroneous overlapping instances reported with FunDeps -+-- Reporter: jwlato | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler (Type checker) |Version: 7.6.1-rc1 Resolution: | Keywords: type classes, fundeps Os: Unknown/Multiple| Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: typecheck/should_compile/T7171 | Blockedby: Blocking: |Related: -+-- Changes (by simonpj): * priority: normal = highest * status: closed = new * resolution: fixed = * milestone: = 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7171#comment:5 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] #7178: Panic in coVarsOfTcCo
#7178: Panic in coVarsOfTcCo
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: highest | Milestone: 7.6.1
Component: Compiler | Version: 7.4.2
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Ganesh says: I'm getting the panic below when building darcs 2.8 with GHC
7.6. It'll take some effort to cut it down or give repro instructions for
an uncut-down version (I needed to hack a lot of underlying packages to be
able to even get as far as doing this build), so could someone confirm
that it's worth it before I do so? I can't spot anything already reporting
this in trac.
{{{
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.6.0.20120810 for i386-unknown-mingw32):
coVarsOfTcCo:Bind
cobox{v a6Czs} [lid]
= cobox{v a6CTr} [lid] `cast`
(main:Darcs.Test.Patch.WithState.WithState{tc r1LL8}
model{tv tC} [tv]
..blah blah..
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7178
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] #7178: Panic in coVarsOfTcCo
#7178: Panic in coVarsOfTcCo -+-- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.6.1 Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * owner: = simonpj Comment: I know what this is. Patch coming. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7178#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] #7176: Failure to let kind variable remain uninstantiated when not needed
#7176: Failure to let kind variable remain uninstantiated when not needed
---+
Reporter: goldfire| Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler| Version: 7.6.1-rc1
Keywords: PolyKinds TypeFamilies | Os: Unknown/Multiple
Architecture: Unknown/Multiple| Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Changes (by simonpj):
* difficulty: = Unknown
Comment:
Aha. I have fixed this on the 7.6 branch thus:
{{{
commit 5133bb97a47340a9008615e412fcf62f7762bea8
Author: Simon Peyton Jones simo...@microsoft.com
Date: Wed Aug 22 18:01:57 2012 +0100
Allocate a fresh META unique in newMetaKindVar
Fixes Trac #7176 on the branch. HEAD has a better fix
(the big patch to untouchable handling)
compiler/typecheck/TcMType.lhs |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
}}}
Separate fix for HEAD coming
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7176#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] #7171: erroneous overlapping instances reported with FunDeps
#7171: erroneous overlapping instances reported with FunDeps
-+--
Reporter: jwlato | Owner:
Type: bug | Status: new
Priority: highest | Milestone: 7.6.1
Component: Compiler (Type checker) |Version: 7.6.1-rc1
Resolution: | Keywords: type classes,
fundeps
Os: Unknown/Multiple| Architecture:
Unknown/Multiple
Failure: GHC rejects valid program | Difficulty: Unknown
Testcase: typecheck/should_compile/T7171 | Blockedby:
Blocking: |Related:
-+--
Changes (by simonpj):
* milestone: 7.8.1 = 7.6.1
Comment:
I think this is fixed by this HEAD patch, which I have now merged into
7.6:
{{{
commit 702f0db0dd4e85de445e5edb5e6294057ebe6792
Author: Simon Peyton Jones simo...@microsoft.com
Date: Wed Aug 22 18:03:12 2012 +0100
Numerous small changes to the constraint solver
The main thing is that we now keep unsolved Derived constraints in
the
wc_flats of a WantedConstraints, rather than discarding them each
time.
This actually fixes a poential (admittedly obscure) bug, when we
currently
discard a superclass constraint, and may never re-generate it, and
may
thereby miss a functional dependency.
Instead, reportErrors filters out Derived constraints that we
don't want
to report.
The other changes are all small refactorings following our walk-
through.
MERGED from commit 9c0a6bbb0194f65cd62e48936c0c00fc4888eef3 on HEAD
compiler/typecheck/TcErrors.lhs | 53 +-
compiler/typecheck/TcHsSyn.lhs| 50 --
compiler/typecheck/TcInteract.lhs | 192
+
compiler/typecheck/TcRnTypes.lhs | 42
compiler/typecheck/TcSMonad.lhs | 137 +-
compiler/typecheck/TcSimplify.lhs | 86 +
6 files changed, 228 insertions(+), 332 deletions(-)
}}}
Can you try now with the 7.6 branch when the next snapshot appears?
I'll add your example as a regression test (for HEAD).
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7171#comment:6
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] #7150: unjustified overlapping instances error
#7150: unjustified overlapping instances error +--- Reporter: maeder | Owner: Type: bug| Status: closed Priority: highest| Milestone: 7.6.1 Component: Compiler |Version: 7.6.1-rc1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Changes (by simonpj): * status: merge = closed * resolution: worksforme = fixed Comment: I think I've fixed this: see #7171. Can you try now with the 7.6 branch when the next branch snapshot appears? And reopen if still broken. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7150#comment:26 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] #7167: Make it a warning (not error) to hide an import that isn't exported
#7167: Make it a warning (not error) to hide an import that isn't exported -+-- Reporter: simonpj | Owner: pcapriotti Type: bug | Status: new Priority: highest | Milestone: 7.6.1 Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by conrad): * cc: conrad@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7167#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] #7179: Non-unique variable bindings in the Core
#7179: Non-unique variable bindings in the Core --+- Reporter: stephen70edwards | Owner: Type: bug | Status: new Priority: normal| Component: External Core Version: 7.4.1 | Keywords: CoreSyn Unique Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Testcase: Blockedby:| Blocking: Related:| --+- In the process of using GHC as a library, I found that the new variables bound in a core Case may not be unique, which I did not expect (what part of unique don't you understand?). They're in mutually exclusive branches and don't seem to adversely affect the generated code (perhaps another unique pass runs). It's visible in the external core output, although I discovered the problem while using core data structures. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7179 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
