Re: [GHC] #5774: main = forever (putStrLn = getLine) continuously saturates a CPU when compiled
#5774: main = forever (putStrLn = getLine) continuously saturates a CPU when compiled --+- Reporter: lpsmith | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.4.1-rc1 Resolution: duplicate| Keywords: Os: Linux| Architecture: x86_64 (amd64) Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by simonpj): Ian, are you sure it's a dup? The symptoms look very different. Have you checked that it's ok in 7.4? Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5774#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] #5774: main = forever (putStrLn = getLine) continuously saturates a CPU when compiled
#5774: main = forever (putStrLn = getLine) continuously saturates a CPU when compiled --+- Reporter: lpsmith | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.4.1-rc1 Resolution: duplicate| Keywords: Os: Linux| Architecture: x86_64 (amd64) Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by simonpj): Ignore me. I was looking at #5373 or something -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5774#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] #5767: Integer inefficiencies
#5767: Integer inefficiencies
--+-
Reporter: rl | Owner: igloo
Type: bug | Status: new
Priority: highest | Milestone: 7.4.1
Component: Compiler |Version: 7.5
Resolution: | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Comment(by simonpj):
Note: the call to `smallInteger` arises from the `fromIntegral` method of
`Integral Int` (in `base:GHC.Real`):
{{{
instance Integral Int where
toInteger (I# i) = smallInteger i
}}}
So, yes we need a `integerToInt (smallInteger n)` RULE.
Ditto `int64ToInteger` and `wordToInteger`.
Also we'd like a RULE for `(smallInteger (I# n)`, which should generate an
`Integer` literal. This isn't easy right now for tiresome reasons. !ToDo
for 7.6. The most plausible route for doing it is to take `mkIntegerLit`
out of `Integer` literals, and keep it somewhere global instead.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5767#comment:7
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] #5716: Failure when using promoted data family instances
#5716: Failure when using promoted data family instances -+-- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal| Milestone: 7.4.2 Component: Compiler | Version: 7.3 Keywords: PolyKinds | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by dreixel): * keywords: = PolyKinds -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5716#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] #5717: ScopedTypeVariables and PolyKinds
#5717: ScopedTypeVariables and PolyKinds -+-- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal| Milestone: 7.6.1 Component: Compiler | Version: 7.3 Keywords: PolyKinds | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by dreixel): * keywords: = PolyKinds -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5717#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] #5770: Non-sensical error message when compiling with PolyKinds and a type family
#5770: Non-sensical error message when compiling with PolyKinds and a type family +--- Reporter: goldfire | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.4.1 Component: Compiler (Type checker) | Version: 7.4.1-rc1 Keywords: PolyKinds| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC rejects valid program Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: #5717| +--- Changes (by dreixel): * related: = #5717 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5770#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] #5769: Incorrect error message when compiling with PolyKinds and a type family
#5769: Incorrect error message when compiling with PolyKinds and a type family +--- Reporter: goldfire | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.4.1 Component: Compiler (Type checker) | Version: 7.4.1-rc1 Keywords: PolyKinds| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC rejects valid program Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: #5717| +--- Changes (by dreixel): * related: = #5717 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5769#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] #5717: ScopedTypeVariables and PolyKinds
#5717: ScopedTypeVariables and PolyKinds +--- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.1 Component: Compiler | Version: 7.3 Keywords: PolyKinds| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: #5768, #5769, #5770 | +--- Changes (by dreixel): * related: = #5768, #5769, #5770 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5717#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] #5779: SPECIALISE pragma generates wrong activations
#5779: SPECIALISE pragma generates wrong activations
--+-
Reporter: rl | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler |Version: 7.5
Resolution: invalid | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Changes (by simonpj):
* status: new = closed
* difficulty: = Unknown
* resolution: = invalid
Comment:
On the contrary it's vital that specialisations don't kick in too early.
Imagine that `foo` had a rule
{{{
RULE foo/bar forall x. foo (bar x) = x
}}}
You put a NOINLINE pragma on `foo` to make sure it isn't inlined too
early, to make sure that the RULE gets to fire. But you'd be annoyed if
the SPECIALISE pragma rewrite `foo` to `foo_spec`, and thereby stopped the
RULE firing!
Happily you can add a phase to the SPECIALISE pragma, thus:
{{{
{-# SPECIALISE [1] foo :: Int - Int #-}
}}}
which should let you do as you want. This behaviour, and the override
mechanism, are documented:
http://www.haskell.org/ghc/dist/current/docs/html/users_guide/pragmas.html
#specialize-pragma. If the documenation is unclear (all too possible)
could you suggest better wording? Thanks.
Simon
Yell if that doesn't do the job
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5779#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] #5779: SPECIALISE pragma generates wrong activations
#5779: SPECIALISE pragma generates wrong activations
--+-
Reporter: rl | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler |Version: 7.5
Resolution: invalid | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Comment(by rl):
In fact, what guarantees does GHC give about specialisation vs. inlining?
If I have:
{{{
{-# INLINE [1] f #-}
f = e
{-# SPECIALISE f :: ... #-}
}}}
both the `INLINE` rule and the `SPECIALISE` rule are now only active in
phase 1. Does GHC guarantee to try the `SPECIALISE` rule before inlining?
I suspect not (I vaguely remember you saying that you no longer guarantee
that rule matching happens before inlining at some point).
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5779#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] #5779: SPECIALISE pragma generates wrong activations
#5779: SPECIALISE pragma generates wrong activations --+- Reporter: rl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.5 Resolution: invalid | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by simonpj): * Yes, we really need a way to say ALWAYS. And we don't have that at the moment; you'd have to say [100] or something. (Which means phase 100 and later.) I'm not sure that's it's worth the pain of adding an ALWAYS case too. * There is no guarantee about SPECIALISE vs INLINE. After all, if you are going to inline something that is ''even better'' than specialising it. Generally you want specialisation to kick in only if inlining doesn't. So in the case you give, I'd just nuke the SPECIALISE pragma. Unless you specifically want to SPECIALISE first, in which case give a phase. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5779#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
[GHC] #5780: -faggressive-primops change caused a failure in perf/compiler/parsing001
#5780: -faggressive-primops change caused a failure in perf/compiler/parsing001 -+-- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.2.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- The commit 601c983dd0bada6b49bdadd8f172fd4eacac4b0c apparently caused a regression in perf/compiler/parsing001, so I'm reverting it pending investigation. The patch should have made no changes to performance, because the new functionality was only enabled by a new flag. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5780 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] #5780: -faggressive-primops change caused a failure in perf/compiler/parsing001
#5780: -faggressive-primops change caused a failure in perf/compiler/parsing001
-+--
Reporter: simonmar | Owner:
Type: bug | Status: new
Priority: high | Milestone: 7.6.1
Component: Compiler | Version: 7.2.2
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by marlowsd@…):
commit 395ef284545bb5e7a57c180cc1f2a1b66fa30f37
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Mon Jan 16 12:41:56 2012 +
Revert Add -faggressive-primops plus refactoring in CoreUtils
(#5780)
This reverts commit 601c983dd0bada6b49bdadd8f172fd4eacac4b0c.
compiler/coreSyn/CoreArity.lhs|4 +-
compiler/coreSyn/CoreUtils.lhs| 237
compiler/main/StaticFlagParser.hs |1 -
compiler/main/StaticFlags.hs |6 -
compiler/prelude/PrimOp.lhs | 59 ++---
compiler/simplCore/FloatIn.lhs| 10 +--
compiler/simplCore/OccurAnal.lhs |4 +-
compiler/simplCore/SimplUtils.lhs | 10 +-
compiler/simplCore/Simplify.lhs | 20 ++--
9 files changed, 137 insertions(+), 214 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5780#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] #5773: main = forever (putStrLn = getLine) continuously saturates a CPU when compiled
#5773: main = forever (putStrLn = getLine) continuously saturates a CPU when
compiled
---+
Reporter: lpsmith | Owner: simonmar
Type: bug | Status: new
Priority: highest | Milestone: 7.4.1
Component: Compiler| Version: 7.4.1-rc1
Keywords: | Os: Linux
Architecture: x86_64 (amd64) | Failure: Runtime performance bug
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Comment(by marlowsd@…):
commit fac8ecbbafde17dd92439c41747223c43e9d2b80
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Mon Jan 16 09:49:24 2012 +
Fix bug causing polling instead of blocking in the non-threaded RTS
(#5773)
This was a regression introduced accidentally in
6b1098511aaabd2c9503ee7be6da1944466f9cb4. We were previously passing
a large time value to select() to simulate blocking, and this broke
due to a change from unsigned to signed arithmetic. I've refactored
it to be less fragile now - we just pass NULL as the timeval parameter
to select(), which is the correct way to do blocking.
rts/posix/Select.c | 35 +--
1 files changed, 17 insertions(+), 18 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5773#comment:7
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] #5773: main = forever (putStrLn = getLine) continuously saturates a CPU when compiled
#5773: main = forever (putStrLn = getLine) continuously saturates a CPU when compiled ---+ Reporter: lpsmith | Owner: simonmar Type: bug | Status: merge Priority: highest | Milestone: 7.4.1 Component: Compiler| Version: 7.4.1-rc1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by simonmar): * status: new = merge Comment: Thanks for the report - a good one to find before the release. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5773#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] #5779: SPECIALISE pragma generates wrong activations
#5779: SPECIALISE pragma generates wrong activations --+- Reporter: rl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.5 Resolution: invalid | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by rl): But if there is no guarantee about `SPECIALISE` vs `INLINE`, then how does it make sense that the `SPECIALISE` rule activates in the same phase as the `INLINE` rule by default? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5779#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
Re: [GHC] #5779: SPECIALISE pragma generates wrong activations
#5779: SPECIALISE pragma generates wrong activations
--+-
Reporter: rl | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler |Version: 7.5
Resolution: invalid | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Comment(by simonpj):
Because the common case is that you have
{{{
f x = e
{-# SPECIALISE f :: Int - Int #-}
}}}
Then you are saying if f doesn't inline by itself, use the specialised
version. That's a perfectly reasonable thing to say.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5779#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] #5745: import-hidden symbol is still re-exported
#5745: import-hidden symbol is still re-exported ---+ Reporter: j.waldmann| Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Compiler |Version: 7.2.1 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by simonmar): Simon: do you know if we have a test for this? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5745#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] #5741: openFile should fail if null bytes are in the argument
#5741: openFile should fail if null bytes are in the argument -+-- Reporter: Veinor| Owner: Type: feature request | Status: new Priority: high | Milestone: 7.6.1 Component: libraries/base| Version: 7.2.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonmar): Arguably truncation on `NUL` is part of the filesystem semantics of the underlying OS, just like `/` being the directory separator. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5741#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] #5779: SPECIALISE pragma generates wrong activations
#5779: SPECIALISE pragma generates wrong activations --+- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler |Version: 7.5 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Changes (by simonpj): * status: closed = new * resolution: invalid = Comment: PS I agree that we should warn if the SPECIALISE rule gets a NEVER activation. Reopening for that reason. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5779#comment:7 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] #5778: GHCi won't load compiled object files outside of a package
#5778: GHCi won't load compiled object files outside of a package ---+ Reporter: lpsmith | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi| Version: 7.4.1-rc1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by simonmar): * difficulty: = Unknown Comment: I can't reproduce this. Are you sure that `ghc` is referring to GHC 7.4.20120111? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5778#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] #5779: SPECIALISE pragma generates wrong activations
#5779: SPECIALISE pragma generates wrong activations --+- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler |Version: 7.5 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by rl): Ah, I see, your point is that it doesn't matter whether we inline or specialise whereas I assume it's always better to specialise than to inline (mostly because of compilation speed and intermediate code size). I still disagree with the current default behaviour but I now see the logic behind it. Thanks for the explanation! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5779#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] #5771: Confusing printout with PolyKinds
#5771: Confusing printout with PolyKinds -+-- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal| Milestone: 7.6.1 Component: Compiler | Version: 7.4.1-rc1 Keywords: PolyKinds | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Other Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonpj): Thanks for reporting bugs with !PolyKinds. Very helpful. We are not advertising !PolyKinds as a ''working'' part of the 7.4 release, but I do appreciate bug reports, because they tell us what to fix. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5771#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] #5778: GHCi won't load compiled object files outside of a package
#5778: GHCi won't load compiled object files outside of a package ---+ Reporter: lpsmith | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: GHCi |Version: 7.4.1-rc1 Resolution: invalid | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * status: new = closed * resolution: = invalid Comment: This is a feature, not a bug! GHC has to recompile the source file, just in case the different language extensions have any effect. See #437. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5778#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] #5778: GHCi won't load compiled object files outside of a package
#5778: GHCi won't load compiled object files outside of a package ---+ Reporter: lpsmith | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: GHCi |Version: 7.4.1-rc1 Resolution: invalid | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by lpsmith): Well, I disagree that all of the language flags need to be included here; for example, ViewPatterns. Are there any programs that compile without the ViewPatterns flag that behave any differently with it enabled? This is a step forward in terms of usability when it comes to the compiler, but it seems a step backwards when it comes to ghci. Especially the OverloadedStrings issue. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5778#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] #5778: GHCi won't load compiled object files outside of a package
#5778: GHCi won't load compiled object files outside of a package ---+ Reporter: lpsmith | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: GHCi |Version: 7.4.1-rc1 Resolution: invalid | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by simonmar): Admittedly we didn't do a full audit of the flags to see where we could be more relaxed, but apart from the fact that it would be time-consuming and error prone to do that, the current implementation can't handle the requirement that *adding* ViewPatterns is (probably) safe but *removing* it is not. That's because we just take a hash of the flags and store that in the interface file. I understand the problem - having some extensions on in GHCi by default is quite handy, but you don't want that to cause recompilation of files that you've already compiled. I think the right fix for that would be to separate the flags that are in use at the GHCi prompt from those that are used when loading source files: see #3217. I'm going to bump the priority of that ticket, now that dealing with it is more pressing. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5778#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
Re: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions
#3217: Make GHCi have separate flags for interactive Haskell expressions -+-- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 6.10.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * priority: low = high -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3217#comment:25 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] #3217: Make GHCi have separate flags for interactive Haskell expressions
#3217: Make GHCi have separate flags for interactive Haskell expressions -+-- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.4.1 Component: Compiler | Version: 6.10.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonmar): see #5778 - dealing with this is now a higher priority. Due to the fixes in #437, people who turn on extensions by default in their `.ghci` file will now see all their compiled modules get recompiled by GHCi because the flags have changed. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3217#comment:24 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] #3217: Make GHCi have separate flags for interactive Haskell expressions
#3217: Make GHCi have separate flags for interactive Haskell expressions -+-- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.4.2 Component: Compiler | Version: 6.10.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * milestone: 7.4.1 = 7.4.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3217#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] #5778: GHCi won't load compiled object files outside of a package
#5778: GHCi won't load compiled object files outside of a package
---+
Reporter: lpsmith | Owner:
Type: bug | Status: closed
Priority: normal| Milestone:
Component: GHCi |Version: 7.4.1-rc1
Resolution: invalid | Keywords:
Os: Linux | Architecture: x86_64 (amd64)
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Comment(by lpsmith):
Ok, that sounds like a good solution. It doesn' make sense to me at the
moment why the {{{:a ~/ghc/env.hs}}} causes recompilation, but I note that
I can move the imports into the ghci.conf to get around that, and that I
really don't use the older versions of ghc (6.10?) that was intended for
much anymore.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5778#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
[GHC] #5781: Add Data.List.at :: [a] - Int - Maybe a
#5781: Add Data.List.at :: [a] - Int - Maybe a --+- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal| Component: libraries/base Version: 7.5 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Testcase: Blockedby:| Blocking: Related:| --+- Don't know how this can _not_ exist. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5781 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] #5782: llvm --enable-tbaa forces LLVM to be 2.9 or above
#5782: llvm --enable-tbaa forces LLVM to be 2.9 or above ---+ Reporter: pmonday| Owner: dterei Type: bug| Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.5| Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: GHC rejects valid program | Testcase: Blockedby: | Blocking: Related: | ---+ I compiled the latest master against LLVM 2.8. The compile worked initially, but when using the ghc-stage2 compiler against new code with the fllvm option, all programs fail to compile with: opt: Unknown command line argument '--enable-tbaa=true'. Try: 'opt -help' This is the result of the following flags being added to: ghc/compiler/main/DriverPipeline.hs tbaa | dopt Opt_LlvmTBAA dflags = --enable-tbaa=true | otherwise= --enable-tbaa=false --enable-tbaa is available on opt version 2.9 and above only. It would be helpful if the ./configure script verified that the opt (and possibly llc) versions were 2.9 or above. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5782 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] #5783: Data.Text.isPrefixOf fails to terminate
#5783: Data.Text.isPrefixOf fails to terminate
-+--
Reporter: reinerp | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.4.1-rc1| Keywords:
Os: MacOS X | Architecture: x86_64 (amd64)
Failure: Incorrect result at runtime | Testcase:
Blockedby: | Blocking:
Related: |
-+--
The function {{{Data.Text.isPrefixOf}}} fails to terminate with GHC
7.4-rc1, although it terminates with GHC-7.2. Reproduction instructions:
{{{
$ cd ghc-7.4.0.20111219
$ sudo make install
$ cabal -V
cabal-install version 0.10.2
using version 1.10.1.0 of the Cabal library
$ cabal install text-0.11.1.12
$ cd /tmp
$ cat Test.hs
import Data.Text
main = print (pack A `isPrefixOf` pack AB)
$ runghc Test.hs
program hangs on 100% CPU use, without producing any output
}}}
Unfortunately, it appears to be rather difficult to create a reduced test
case; the problem disappears when I make any attempt to minimize it.
I have verified this on Mac OS X 10.7.2 and 64-bit Ubuntu 10.10.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5783
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] #5782: llvm --enable-tbaa forces LLVM to be 2.9 or above
#5782: llvm --enable-tbaa forces LLVM to be 2.9 or above ---+ Reporter: pmonday| Owner: dterei Type: bug| Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.5| Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: GHC rejects valid program | Testcase: Blockedby: | Blocking: Related: | ---+ Comment(by dterei): Yes this is a known issue. I'm experimenting with some features in the backend that require 2.9 but will get around to making this a runtime detected feature sometime soon. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5782#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
[GHC] #5784: Forked thread running infinite loop blocks other threads from running
#5784: Forked thread running infinite loop blocks other threads from running
-+--
Reporter: joeyadams| Owner:
Type: bug | Status: new
Priority: normal | Component: Runtime System
Version: 7.2.2| Keywords:
Os: Linux| Architecture: x86_64 (amd64)
Failure: Incorrect result at runtime | Testcase:
Blockedby: | Blocking:
Related: |
-+--
When I compile the following under GHC 7.2.2 with -O1 or -O2, it spins in
the forked thread's infinite loop. The forked thread does not yield
control to the main thread:
{{{
import Control.Concurrent
import Control.Monad
main :: IO ()
main = do
tid - forkIO $ forever $ return ()
putStrLn $ Forked ++ show tid
}}}
This happens up even if I compile with -threaded -rtsopts, use +RTS -N2,
and use forkOS instead of forkIO.
The problem goes away if I disable optimization. It also goes away if I
stick a yield :: IO () call in the loop.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5784
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] #5785: Test failures on i386 with LLVM backend
#5785: Test failures on i386 with LLVM backend
-+--
Reporter: dterei | Owner: dterei
Type: bug | Status: new
Priority: normal | Component: Compiler (LLVM)
Version: 7.4.1-rc1| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Incorrect result at runtime | Testcase:
Blockedby: | Blocking:
Related: |
-+--
Currently we get the following testsuite results on i386:
{{{
OVERALL SUMMARY for test run started at Fri Jan 13 22:25:17 UTC 2012
3195 total tests, which gave rise to
15839 test cases, of which
0 caused framework failures
3431 were skipped
12083 expected passes
182 had missing libraries
132 expected failures
1 unexpected passes
10 unexpected failures
Unexpected passes:
module/mod175 mod175 (normal)
Unexpected failures:
codeGen/should_runcgrun071 [bad stdout] (optllvm)
dph/diophantine dph-diophantine-copy-opt [bad exit code]
(normal,threaded1,threaded2)
driver/recomp006 recomp006 [bad stderr] (normal)
ffi/should_runffi018 [bad stdout] (optllvm)
ghc-api/apirecomp001 apirecomp001 [bad stderr] (normal)
ghci/scripts Defer02 [bad stdout] (ghci)
lib/should_runenum02 [bad stdout] (optllvm)
numeric/should_runarith011 [bad stdout] (optllvm)
}}}
Need to fix these
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5785
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] #5757: zero unexpected failures on all tier 1 platforms
#5757: zero unexpected failures on all tier 1 platforms -+-- Reporter: simonmar | Owner: Type: task | Status: new Priority: highest | Milestone: 7.4.1 Component: Test Suite| Version: 7.2.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related: 5785 | -+-- Changes (by dterei): * related: = 5785 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5757#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
[GHC] #5786: Dynanmic way fails when GHC built with LLVM backend
#5786: Dynanmic way fails when GHC built with LLVM backend --+- Reporter: dterei| Owner: dterei Type: bug | Status: new Priority: normal| Component: Compiler (LLVM) Version: 7.4.1-rc1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Testcase: Blockedby:| Blocking: Related: 5757 | --+- If I build GHC with the LLVM backend then the 'Dyn' testsuite way fails completely (tested on x64). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5786 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] #5757: zero unexpected failures on all tier 1 platforms
#5757: zero unexpected failures on all tier 1 platforms -+-- Reporter: simonmar | Owner: Type: task | Status: new Priority: highest | Milestone: 7.4.1 Component: Test Suite| Version: 7.2.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related: #5785, #5757 | -+-- Changes (by dterei): * related: 5785 5757 = #5785, #5757 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5757#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] #5785: Test failures on i386 with LLVM backend
#5785: Test failures on i386 with LLVM backend -+-- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.4.1-rc1| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Testcase: Blockedby: | Blocking: Related: #5757| -+-- Changes (by dterei): * related: = #5757 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5785#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
[GHC] #5787: Add instances to ZipList
#5787: Add instances to ZipList --+- Reporter: pumpkin | Owner: Type: feature request | Status: new Priority: normal| Component: libraries/base Version: 7.2.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Testcase: Blockedby:| Blocking: Related:| --+- There was a reasonably uncontroversial vote on the libraries list to add common derived instances (Eq, Ord, Show, Read) to ZipList, which currently only has Functor and Applicative. I have made the change on my local ghc build and it seems to build, but I can't get validate to pass. I'm not sure if it's my own fault, but considering I only made a one-line change, it seems odd. I'll attach a patch once I make sure it wasn't my fault. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5787 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
