September 2013 - ghc-tickets

Re: [GHC] #7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented
by GHC 11 Sep '13

11 Sep '13

#7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented -------------------------------+--------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+--------------------------- Comment (by RoboTux): Replying to [comment:6 cjwatson]: > > It will be called every time one of the generated chunks of code is called, so I would expect it to be suboptimal, yes. That in itself might be tolerable. > > Much more importantly, though, this patch misses the point of flushing the instruction cache. The point is that we need to flush the cache in order for the processor to reliably read back the code that we just > wrote out; flushing the cache in that very code is not a viable approach to that, because the cache-flushing code itself might not be read. So I'm afraid I don't think this is going to work properly. It might work some of the time, of course, depending on cache locality, but I can't see how it would work reliably. Oh, I didn't realize this was the generated code. I don't know if it's because of the language but I can't make much sense of what the code is doing. I assumed this code was some jit compiler and that the jump was executed when a function has just been compiled in order to actually call that function. If it's part of the generated function indeed it's very suboptimal and won't work as you very well explained. My apologize but I don't think I can bring this further without investing quite some time to understand the code. Thanks for being so quick in looking at the patch. Best regards. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7794#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7678: GHC should compile cleanly with clang
by GHC 10 Sep '13

10 Sep '13

#7678: GHC should compile cleanly with clang ----------------------------------------+---------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: clang Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 7602 | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by carter): @refold, i've comented on the issue. Its fixed, its more subtle than you expect. ghc works -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7678#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7678: GHC should compile cleanly with clang
by GHC 10 Sep '13

10 Sep '13

#7678: GHC should compile cleanly with clang ----------------------------------------+---------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: clang Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 7602 | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by refold): @thoughtpolice Did you manage to compile Cabal with Clang? GHC depends on Cabal, but according to [https://github.com/haskell/cabal/issues/1496 this bug report] Cabal currently fails to build when Clang is used as a preprocessor. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7678#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented
by GHC 10 Sep '13

10 Sep '13

#7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented -------------------------------+--------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+--------------------------- Comment (by cjwatson): Replying to [comment:4 RoboTux]: > Inlining the call of the cacheflush system call (the call behind {{{__clear_cache}}}) should work but it means the cache would be flush every time mkJumpToAddr is called. I don't know enough the context of the code generation but if that function is called several time after 1 code generation then it's suboptimal. It will be called every time one of the generated chunks of code is called, so I would expect it to be suboptimal, yes. That in itself might be tolerable. Much more importantly, though, this patch misses the point of flushing the instruction cache. The point is that we need to flush the cache in order for the processor to reliably read back the code that we just wrote out; flushing the cache in that very code is not a viable approach to that, because the cache-flushing code itself might not be read. So I'm afraid I don't think this is going to work properly. It might work some of the time, of course, depending on cache locality, but I can't see how it would work reliably. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7794#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8233: Type environment when reporting holes
by GHC 10 Sep '13

10 Sep '13

#8233: Type environment when reporting holes -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect Architecture: Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8191 | -------------------------------------+------------------------------------- This is a sequel to #8191. Consider {{{ {-# LANGUAGE TypeHoles #-} u1 = 0 u2 = 0 u3 = 0 u4 = 0 u5 = 0 u6 = 0 f :: a -> (a -> b) -> b f x y = _b v1 = 0 v2 = 0 v3 = 0 v4 = 0 v5 = 0 v6 = 0 }}} Compile with `-fno-max-relevant-binds` and see {{{ Relevant bindings include v6 :: a0 (bound at THoles.hs:18:1) v5 :: a1 (bound at THoles.hs:17:1) v4 :: a2 (bound at THoles.hs:16:1) v3 :: a3 (bound at THoles.hs:15:1) v2 :: a4 (bound at THoles.hs:14:1) v1 :: a5 (bound at THoles.hs:13:1) f :: a -> (a -> b) -> b (bound at THoles.hs:11:1) x :: a (bound at THoles.hs:11:3) y :: a -> b (bound at THoles.hs:11:5) }}} The list is inverted: `v6` is first, while it was last. If we do not use `-fno-max-relevant-binds` then local parameters `x` and `y` are not visible at all, but they are the most important data. Another aspect is that we see `v1, v2` but not `u1, u2`. I'm not sure what is a good solution here. Display everything? Only N bindings above `f` and N bindings below `f`? People usually write code top to bottom, so preceding bindings should be more useful in general than following ones. I think this case deserves some attention because it will often occur in practice (putting a hole in any large file). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8233> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8227: cgLookupPanic (probably invalid Core
by GHC 10 Sep '13

10 Sep '13

#8227: cgLookupPanic (probably invalid Core -----------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: cgLookupPanic | Operating System: MacOS X Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): cgLookupPanic (probably invalid Core; try -dcore-lint) cobox{v a34t} [lid] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8227> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning
by GHC 10 Sep '13

10 Sep '13

#8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning -------------------------------------+------------------------------------ Reporter: asr | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * milestone: 7.8.1 => 7.10.1 Comment: This isn't a big deal. It was an oversight not to have changed Happy a couple of years ago, but hardly a big deal. Let's milestone the change for 7.10 (with high prio so we don't forget again) and meanwhile leave the status quo. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8022#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7962: "ghc -e <invalid expression>" should return non-zero exit status
by GHC 10 Sep '13

10 Sep '13

#7962: "ghc -e <invalid expression>" should return non-zero exit status ------------------------------------+------------------------------------ Reporter: timmaxw | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+------------------------------------ Changes (by leroux): * cc: leroux@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7962#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3195: runghc failing sometimes
by GHC 10 Sep '13

10 Sep '13

#3195: runghc failing sometimes ---------------------------------+--------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: None | Version: 6.10.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Changes (by monoidal): * status: new => closed * resolution: => invalid Comment: I'm closing the ticket: it concerns ghc 6.10 and the links are broken. If you can reproduce on 7.6, please reopen or create a new bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3195#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning
by GHC 09 Sep '13

09 Sep '13

#8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning -------------------------------------+------------------------------------ Reporter: asr | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => patch Comment: Thanks Simon! As for the warning for 7.8: personally, I don't think asking *developers* to upgrade Happy is really that big of a burden, considering there's a small number of us and the fix is rather straightforward (upgrade both Alex and Happy.) The more annoying aspect might be telling users that they need to upgrade if they want to use 7.8, though. I'm attaching my patch for this in any case so it isn't lost. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8022#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0