April 2015 - ghc-tickets

[GHC] #8085: Both GHC and its installer don't run on current Debian Stable
by GHC 04 May '15

04 May '15

#8085: Both GHC and its installer don't run on current Debian Stable -------------------------------------+------------------------------------- Reporter: ppetr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHC doesn't work Difficulty: Easy (less than 1 | at all hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Currently it's not possible to run GHC or its installer. It fails with: {{{ ghc: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory }}} The problem is that the current Debian stable is Wheezy and it uses a newer version of libgmp. Proposed solution: Recompile on a recent Debian stable (Wheezy). Applies to x86_64 as well, most likely all architectures supported by Debian are affected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8085> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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] #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

[GHC] #10234: Validate fails on armhf
by GHC 26 Apr '15

26 Apr '15

#10234: Validate fails on armhf -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: llvm | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The failure is: {{{ /usr/bin/install -c -m 644 libraries/prologue.txt "/home/erikd/ghc- git/bindisttest/install dir/share/doc/ghc/html/libraries/" /usr/bin/install -c -m 755 libraries/gen_contents_index "/home/erikd/ghc- git/bindisttest/install dir/share/doc/ghc/html/libraries/" bindisttest/"install dir"/bin/runghc bindisttest/HelloWorld > bindisttest/output diff -U 1 bindisttest/output bindisttest/expected_output bindisttest/"install dir"/bin/ghc --make bindisttest/HelloWorld [1 of 1] Compiling Main ( bindisttest/HelloWorld.lhs, bindisttest/HelloWorld.o ) <no location info>: Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM ghc: could not execute: opt }}} Since this is armhf, this was built with llvm, and the configure process found the correct versions of the llvm tools; ie `/usr/bin/llc-3.6` and `/usr/bin/opt-3.6`. Furthermore, file `inplace/lib/settings` file specifies the correct versions. However, file `bindisttest/install dir/lib/ghc-7.11.20150402/settings` file just uses `llc` and `opt` which don't actually exist. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10234> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10308: GHC 7.10 does not export GHC.Event.Lifetime
by GHC 25 Apr '15

25 Apr '15

#10308: GHC 7.10 does not export GHC.Event.Lifetime -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: D838 | -------------------------------------+------------------------------------- The `base` release shipped with GHC 7.10 does not export the `Lifetime` type, rendering many of the event manager interfaces useless. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10308> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10329: ghc-7.10 is configured to use llvm-3.6 but only compiles with llvm-3.5
by GHC 25 Apr '15

25 Apr '15

#10329: ghc-7.10 is configured to use llvm-3.6 but only compiles with llvm-3.5 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Commit 07da52ce2db1 on the ghc-7.10 branch cherry picks commit 42448e3757f2 from the git master branch, but that commit checks for and insists on using llvm version 3.6. However, the code in the ghc-7.10 branch is not compatible with llvm-3.6. The attatched patch changes the requirement to be for llvm-3.5 and is the ghc-7.10 version of commit 485dba86d2519c in the master branch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10329> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10121: operational semantics is incomplete?
by GHC 25 Apr '15

25 Apr '15

#10121: operational semantics is incomplete? -------------------------------------+------------------------------------- Reporter: javran | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.4 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I was trying to read `docs/core-spec/core-spec.pdf` to understand the operational semantics for core language. So I started off by playing with operational semantics rules manually. But I found the following expression gets stuck: {{{#!hs v1 = let fix = \f -> let x = f x in x pf = \f x -> if x == 0 then x else f (pred x) in (fix pf) 2 -- S_LETNONREC v2 = ((\f -> let x = f x in x) (\f x -> if x == 0 then x else f (pred x))) 2 -- S_APP v3 = (let x = (\f x -> if x == 0 then x else f (pred x)) x in x) 2 -- S_APP; S_LETREC v4 = (let x = (\f x -> if x == 0 then x else f (pred x)) x in (\f x -> if x == 0 then x else f (pred x)) x) 2 -- S_APP v5 = (let x = (\f x -> if x == 0 then x else f (pred x)) x in (\x1 -> if x1 == 0 then x1 else x (pred x1))) 2 }}} at this point `x` is not a free variable so `S_LETRECRETURN` cannot be applied. Did I make it wrong or some rules are missing for the operational semantics? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10121> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9204: Conflicting definition in hs-boot file
by GHC 24 Apr '15

24 Apr '15

#9204: Conflicting definition in hs-boot file ------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Foo.hs: {{{ module Foo where import Bar data Foo a }}} Foo.hs-boot: {{{ module Foo where data Foo a }}} Bar.hs: {{{ module Bar where import {-# SOURCE #-} Foo }}} With GHC 7.8.2 I'm getting the error {{{ Foo.hs-boot:3:1: Type constructor ‘Foo’ has conflicting definitions in the module and its hs-boot file Main module: type role Foo phantom data Foo a Boot file: data Foo a }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9204> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13