- ghc-tickets - Haskell.org

Re: [GHC] #4370: Bring back monad comprehensions
by GHC 04 May '15

04 May '15

#4370: Bring back monad comprehensions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@… (removed) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4370#comment:69> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4800: Memory Leak when Compiling qtHaskell
by GHC 04 May '15

04 May '15

#4800: Memory Leak when Compiling qtHaskell -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash | developer.berlios.de/project/showfiles.php?group_id=10072 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@… (removed) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4800#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4479: Implement Dot as Postfix Function Apply
by GHC 04 May '15

04 May '15

#4479: Implement Dot as Postfix Function Apply -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.5 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@… (removed) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4479#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3046: Generalized newtype deriving with associated types
by GHC 04 May '15

04 May '15

#3046: Generalized newtype deriving with associated types -------------------------------------+------------------------------------- Reporter: LouisWasserman | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * failure: => None/Unknown Comment: I don't think this is a duplicate of #2850, but I do think it is a duplicate of #8165. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3046#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10364: Feature request: Add support for FMA
by GHC 04 May '15

04 May '15

#10364: Feature request: Add support for FMA -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 Component: Core | Operating System: Unknown/Multiple Libraries | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- FMA (fused-multiply-add) has been around for quite some-time, and is natively supported by many of the newer processors. It's an operation that is heavily used in HPC applications. I think it's time for Haskell to have native support for it as well. Ideally, it should be added to the `Num` class as a method. Assuming that is a possibility, we would have the following signature and default definition: {{{#!hs class Num a where ... fma :: a -> a -> a -> a fma x y z = x * y + z }}} Except of course the `Float` and `Double` instances would ensure that the rounding is done only once. If adding it to the `Num` class is not an option, then `RealFloat` class would be the next best place; and perhaps that's arguably also a better place because those types are the ones one usually have in mind when using FMA. I think either `Num` or `RealFloat` would be fine choices. Implementation: * If the underlying architecture supports it (which is very common), directly emit FMA instruction * Otherwise, FFI out to C and use `fma` and `fmaf` from the math library A direct software implementation might also be possible for platforms where neither choice above is an option, but that bridge can be crossed when we get there. As a final note; while supporting these functions might seem going-out-of- our-way; it is indeed a big selling point in HPC applications. Furthermore, hardware manufacturers are putting big resources to make these supported naively in the instruction sets. Supporting FMA right out of the box would be a very good step in wider adaptation of Haskell in the HPC community. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10364> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #9564: Floating point subnormals overrounded on output
by GHC 04 May '15

04 May '15

#9564: Floating point subnormals overrounded on output -------------------------------------+------------------------------------- Reporter: jrp | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following test suggests that GHC is overrounding Float subnormals, when printing them out {{{ Prelude> 2**(-149) 1.401298464324817e-45 Prelude> 2**(-149) :: Float 1.0e-45 Prelude> isDenormalized it True Prelude> Prelude> 2**(-149) * 2**(100) * 2**(49) :: Float 1.0 }}} By comparison {{{ #include <stdio.h> #include <stdlib.h> int main (void) { float clang_dec, clang_hex, libc_dec, libc_hex; clang_dec = 1.401298464324817e-45; clang_hex = 0x0.000002P-126; printf("clang (from decimal) = %a\n",clang_dec); printf("clang (from decimal) = %g\n",clang_dec); printf("clang (from hex) = %a\n",clang_hex); printf("clang (from hex) = %g\n",clang_hex); libc_dec = strtod("1.401298464324817e-45",NULL); libc_hex = strtod("0x0.000002P-126",NULL); printf("libc (from decimal) = %a\n",libc_dec); printf("libc (from decimal) = %g\n",libc_dec); printf("libc (from hex) = %a\n",libc_hex); printf("libc (from hex) = %g\n",libc_hex); } }}} produces {{{ clang (from decimal) = 0x1p-149 clang (from decimal) = 1.4013e-45 clang (from hex) = 0x1p-149 clang (from hex) = 1.4013e-45 libc (from decimal) = 0x1p-149 libc (from decimal) = 1.4013e-45 libc (from hex) = 0x1p-149 libc (from hex) = 1.4013e-45 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9564> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10373: Haiku: ghc-stage1 compiler crashes at exit
by GHC 02 May '15

02 May '15

#10373: Haiku: ghc-stage1 compiler crashes at exit -------------------------------------+------------------------------------- Reporter: jessicah | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Other Architecture: x86 | Type of failure: Building GHC Test Case: | failed Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- When trying to build GHC on Haiku, the ghc-stage1 compiler will occasionally crash whilst shutting down the GHC RTS. However, if mk/build.mk is modified to EXCLUDE the vanilla way (GhcLibWays = dyn), then the ghc-stage1 compiler will NOT crash. Attached is a debug report of an example crash. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10373> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #703: all binaries built by ghc have executable stacks
by GHC 02 May '15

02 May '15

#703: all binaries built by ghc have executable stacks -------------------------------------+------------------------------------- Reporter: duncan | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (NCG) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: T703 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * testcase: N/A => T703 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/703#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10356: Couldn't match type ‘a’ with ‘Int’ / ‘a’ is untouchable / inside the constraints ()
by GHC 27 Apr '15

27 Apr '15

#10356: Couldn't match type ‘a’ with ‘Int’ / ‘a’ is untouchable / inside the constraints () -------------------------------------+------------------------------------- Reporter: radix | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Sadly I'm a Haskell newbie, so this won't be a very good bug report, but I am working on a codebase and I triggered a GHC bug (at least according to GHC itself). {{{ Building json-log-viewer-0.0.1... Preprocessing executable 'json-log-viewer' for json-log-viewer-0.0.1... [3 of 3] Compiling Main ( src/Main.hs, dist/build/json-log- viewer/json-log-viewer-tmp/Main.o ) src/Main.hs:316:41: Couldn't match type ‘a’ with ‘Int’ ‘a’ is untouchable inside the constraints () bound by the inferred type of refreshMessages :: IO () at src/Main.hs:(300,7)-(324,48)ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): No skolem info: a_al2w[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I saved the state of the code in a git branch and put it here: https://github.com/radix/json-log-viewer/tree/ghc-bug I'll also attach my list of cabal dependencies installed. The only tricky one is that I'm working off of an unreleased version of `vty-ui`, at this revision: https://github.com/jtdaugherty/vty- ui/commit/c3a0c4b660119a4d5862a6f549a98739a3fc5fa7 I also don't know if the program is "valid" -- I'm in the middle of a refactor, and it's a big cluttered program that I know is very poorly written. Sorry about that. I would not usually report a bug in such a situation but the compiler implored me to, so I am. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10356> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7478: setSessionDynFlags does not always work
by GHC 26 Apr '15

26 Apr '15

#7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: ghc- Related Tickets: | api/T7478 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bherzog): A better solution is the following, I think: Have `defaultFlags` include `Opt_Static` in its result if `pc_DYNAMIC_BY_DEFAULT` is False. Reasoning: comment:17 shows that `ways` and `generalFlags` need to be coordinated wrt. dynamic/static linking: `generalFlags` needs to contain `Opt_Static` exactly when `ways` does not contain `WayDyn`. The values of both fields are derived from the settings passed to `defaultDynFlags`. In particular, `ways` will either be `[WayDyn]` or `[]`, depending on whether `pc_DYNAMIC_BY_DEFAULT` is True or False respectively. Therefore, `defaultFlags` should include `Opt_Static` in its result if `pc_DYNAMIC_BY_DEFAULT` is False. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7478#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0