September 2013 - ghc-tickets

Re: [GHC] #5188: Runtime error when allocating lots of memory
by GHC 07 Sep '13

07 Sep '13

#5188: Runtime error when allocating lots of memory ---------------------------------+--------------------------- Reporter: knyblad | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.12.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Comment (by rwbarton): Casting to an unsigned integral type is defined to have "modulo 2^n^" semantics by C99 §6.3.1.3, so casting -1 to any unsigned integral type will result in the largest representable value of that type. But `HS_WORD_MAX` is okay too, and probably easier to read; I just didn't think to look for such a thing in `HsFFI.h`. (I find the proliferation of identical types `StgWord`, `W_`, `HsWord` a little confusing, but I'll get over it.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5188#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3615: GHCi doesn't allow the use of imported data contructors
by GHC 07 Sep '13

07 Sep '13

#3615: GHCi doesn't allow the use of imported data contructors ------------------------------------+--------------------------- Reporter: blamario | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+--------------------------- Changes (by rwbarton): * failure: => None/Unknown Comment: isaacdupree's first idea of keeping copies of every top-level definition in .o files sounds pretty reasonable to me, if bloat is the only concern. Unused definitions could still, in principle, be dropped from libraries or executables. If use of `-split-objs` becomes more widespread, or we move to a `-ffunction-sections`/`--gc-sections` sort of world (either of which would be nice to reduce executable bloat for other reasons), this might become more or less automatic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3615#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8249: Allocation counts should include PAPs
by GHC 07 Sep '13

07 Sep '13

#8249: Allocation counts should include PAPs -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect result Difficulty: Easy (less than 1 | at runtime hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I was looking through the profiling code and I noticed we don't charge the heap allocation for PAPs on slow-calls to the relevant cost center (relevant code is rts/AutoApply.h, the BUILD_PAP macro). This is probably not right, but I would like someone to agree with me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8249> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7253: Top-level bindings in ghci
by GHC 07 Sep '13

07 Sep '13

#7253: Top-level bindings in ghci -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by rwbarton): * cc: rwbarton@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7253#comment:4> 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 07 Sep '13

07 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 rwbarton): * cc: rwbarton@… (added) * difficulty: => Unknown Comment: I agree with the original report. The man page says "**-e expr** Evaluate expr; see for details." (#3351...) If expr doesn't compile, then ghc has failed to evaluate it, IMO. In reality I can pass arbitrary GHCi commands to `ghc -e` and it will run them; but the documentation doesn't say anything about this (either in the man page or in the [http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/modes.html#eval- mode user's guide]). Making `ghc -e expr` return 1 on compile error would also be consistent with other languages: {{{ rwbarton@adjunction:/tmp$ bash -c if ; echo $? bash: -c: line 1: syntax error: unexpected end of file 1 rwbarton@adjunction:/tmp$ python -c if ; echo $? File "<string>", line 1 if ^ SyntaxError: invalid syntax 1 rwbarton@adjunction:/tmp$ perl -e if ; echo $? syntax error at -e line 1, at EOF Execution of -e aborted due to compilation errors. 255 rwbarton@adjunction:/tmp$ ruby -e if ; echo $? -e:1: syntax error, unexpected $end 1 rwbarton@adjunction:/tmp$ ghc -e if ; echo $? <interactive>:1:3: parse error (possibly incorrect indentation) 0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7962#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3351: Generated ghc man page missing xrefs
by GHC 07 Sep '13

07 Sep '13

#3351: Generated ghc man page missing xrefs -------------------------------------+------------------------------------ Reporter: kaol | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Documentation | Version: 6.10.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 rwbarton): * cc: rwbarton@… (added) * failure: => None/Unknown -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3351#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3452: Show type of most recent expression in GHCi
by GHC 07 Sep '13

07 Sep '13

#3452: Show type of most recent expression in GHCi -------------------------------------+------------------------------------ Reporter: ozy | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 7.6.2 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): its worth pointing out that a beginner friendly ghci doesn't need to be baked into ghc, see http://hackage.haskell.org/package/ghci-ng for how to make your own ghci there may be value in having a "beginners-ghci" that is self contained / a client of ghc apis -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3452#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 07 Sep '13

07 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by leroux): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 07 Sep '13

07 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by leroux): @rwbarton, your patch worked. (I thought I posted a comment about this yesterday, but I guess I didn't.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8252: prefetch# isn't as general as it should be (currently the general version isn't type safe)
by GHC 07 Sep '13

07 Sep '13

#8252: prefetch# isn't as general as it should be (currently the general version isn't type safe) ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: 8107 | Blocking: Related Tickets: 8107 | ------------------------------------+------------------------------------- the fully general prefetch# needs to have certain arguments be compile time constants, see #8107 Internally ghc's prefetch# uses the prefetch intrinsic from lvm, compiler/llvmGen/LlvmCodeGen/CodeGen.hs with the following hard coded arguments {{{ ver <= 29 = [mkIntLit i32 0, mkIntLit i32 3] otherwise = [mkIntLit i32 0, mkIntLit i32 3, mkIntLit i32 1] }}} this correspond roughly (ignoring what the int arg to ghc means,it clearly not the analogue of the c compiler prefetch level, as i originally thoug ) prefetch# addr _ | ver <= 29 = llvm29.prefetch addr 0 3 |otherwise = llvm3.prefetch addr 0 3 1 Now: reading the LLVM language spec http://llvm.org/docs/LangRef.html #llvm-prefetch-intrinsic documents what this is supposed to, namely {{{ Syntax:¶ declare void @llvm.prefetch(i8* <address>, i32 <rw>, i32 <locality>, i32 <cache type>) Overview: The ‘llvm.prefetch‘ intrinsic is a hint to the code generator to insert a prefetch instruction if supported; otherwise, it is a noop. Prefetches have no effect on the behavior of the program but can change its performance characteristics. Arguments: address is the address to be prefetched, rw is the specifier determining if the fetch should be for a read (0) or write (1), and locality is a temporal locality specifier ranging from (0) - no locality, to (3) - extremely local keep in cache. The cache type specifies whether the prefetch is performed on the data (1) or instruction (0) cache. The rw, locality and cache type arguments must be constant integers. }}} Its important to note and emphasize that many of the alternative parameter settings have actual implementations on many modern hardware targets (especially x86_64), and can be useful for a variety of workloads. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8252> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1