- ghc-tickets - Haskell.org

Re: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations
by GHC 09 Oct '14

09 Oct '14

#7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime | Version: 7.6.1 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Feuerbach): Another report of this bug: https://github.com/haskell- fswatch/hfsnotify/issues/51 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7325#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1257: Bytecode generator can't handle unboxed tuples
by GHC 09 Oct '14

09 Oct '14

#1257: Bytecode generator can't handle unboxed tuples -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.4.1 Component: GHCi | Version: 6.6 Resolution: wontfix | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: dsrun014 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): The problem is at the boundary between compiled code and interpreted code. We have a few special-purpose stack frames that do the impedence matching between the two worlds, one for each return convention. The problem with unboxed tuples is that there aren't a fixed number of return conventions, so we can't cover all the cases with a few stack frames. I haven't thought about this for a long term, but perhaps there's a way to make a generic stack frame that takes some kind of descriptor to describe the convention. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1257#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9649: symbols should/might be type level lists of chars
by GHC 08 Oct '14

08 Oct '14

#9649: symbols should/might be type level lists of chars -------------------------------------+------------------------------------- Reporter: ibotty | Owner: ibotty Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I thought I had seen that feature request in trac but did not find it. Sorry if I am wrong. A simple use case might be a type safe routing framework, e.g. {{{ get :: Route "/a/:id" $ do idA <- param :: Param "idA" ... }}} I spoke with pedro at hacberlin last weekend and he told me simonp and iavor might tell me where to start looking. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9649> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9356: scanl does not participate in stream fusion
by GHC 08 Oct '14

08 Oct '14

#9356: scanl does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- nomeata came up with a fusing version of a strict `scanl'` in a comment on #9345. It's not entirely clear to me whether that's entirely safe, but a non-strict version of it for `scanl` would be, as both a good producer and good consumer, presumably made efficient using the same sorts of magic used in HEAD for `foldl`. The strict `scanl'` is obviously safe to write as a good consumer; only the production side remains to be proved. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9356> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx
by GHC 08 Oct '14

08 Oct '14

#9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I am having problems building yi on 32 bit architectures (i386, hurd-i386, kfreebsd-i386) on Debian: {{{ Loading package parallel-3.2.0.4 ... linking ... done. Loading package reflection-1.2.0.1 ... linking ... done. Loading package split-0.2.2 ... linking ... done. Loading package utf8-string-0.3.7 ... linking ... done. Loading package void-0.6.1 ... linking ... done. Loading package zlib-0.5.4.1 ... linking ... done. Loading package lens-4.1.2.1 ... linking ... done. Loading package parsec-3.1.3 ... linking ... done. Loading package terminfo-0.3.2.5 ... linking ... done. GHCi runtime linker: fatal error: I found a duplicate definition for symbol __x86.get_pc_thunk.bx whilst processing object file /usr/lib/haskell-packages/ghc/lib/i386-freebsd- ghc-7.6.3/vty-5.2.1/libHSvty-5.2.1.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. }}} (Full log at https://buildd.debian.org/status/fetch.php?pkg=yi&arch=kfreebsd-i386&ver=0.…) It does not happen on amd64. This happens on the Debian auto-builders and I did not reproduce it locally yet, but maybe someone can already tell me what’s wrong from looking at it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9657> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #7015: Add support for 'static'
by GHC 07 Oct '14

07 Oct '14

#7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Changes (by simonpj): * status: patch => new Comment: Taking out of patch status. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7015: Add support for 'static'
by GHC 07 Oct '14

07 Oct '14

#7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by simonpj): Here is the state of play on `StaticPtr`, as I understand it today, is this: * [https://ghc.haskell.org/trac/ghc/blog/simonpj/StaticPointers My blog post] represents, I believe, a consensus. * In that blog post, Plan A requires some support from `Typable`/`TypeRep`. A new wiki page [wiki:Typeable] describes a design to do exactly that. This will be new to most of you; take a look. * The [wiki:StaticPointers] wiki page is out of date; Matthieu and Facundo are planning to update it None of this amounts to a full Plan; but it does represent progress. I think Matthieu and Facundo are the main driving forces. I'm hoping that you (perhaps with help from others) will * work through the proposed design a bit more, to check that it does what you need; * develop a plan for how we can more from where we are to the new glorious story with minimum disruption * develop an implementation Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7928: GHC fails to terminate while compiling with optimization level 2
by GHC 07 Oct '14

07 Oct '14

#7928: GHC fails to terminate while compiling with optimization level 2 -------------------------------------+------------------------------------- Reporter: Ptharien's | Owner: Flame | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: #7898, #7944 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * difficulty: => Unknown Comment: Given that it may be related to #8852 that was fixed in HEAD, does it still fail? Could you try HEAD? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7928#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7068: Extensive Memory usage (regression)
by GHC 07 Oct '14

07 Oct '14

#7068: Extensive Memory usage (regression) -------------------------------------+------------------------------------- Reporter: waldheinz | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by tibbe): * milestone: 7.10.1 => 7.8.4 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7068#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc-citeproc
by GHC 07 Oct '14

07 Oct '14

#8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc- citeproc ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It's mostly a http://www.haskell.org/pipermail/ghc- devs/2014-March/004363.html rechecked on ghc-7.8.1: I attempted to leave original packages as-is. Steps to reproduce: {{{ $ cd /tmp/ $ wget -c http://code.haskell.org/~slyfox/selfcontained-eater- ghc-7.8-rc2.tar.gz $ tar -xzf selfcontained-eater-ghc-7.8-rc2.tar.gz $ cd selfcontained-eater-ghc-7.8-rc2 $ ./mk.sh ... [279 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( highlighting- kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, highlighting- kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o ) stack overflow: use +RTS -K<size> to increase it }}} I did prepare this testcase for ghc-7.6.3 where it failed only on last 452 module. '''./mk.sh''' is a dumb script calling '''ghc -O2''' + cabal-generated bits. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4