January 2015 - ghc-tickets

[GHC] #9851: Hoopl library in GHC hides runWithFuel / version number clash
by GHC 05 May '15

05 May '15

#9851: Hoopl library in GHC hides runWithFuel / version number clash -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/hoopl | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The hoopl library on hackage exposes runWithFuel in Compiler.Hoopl. This function is used in the examples distributed with the library (in the testing directory). The version of hoopl distributed in GHC does not expose runWithFuel. Further, the version number of the GHC packaged hoopl is identical to the version number of the hoopl library on hackage. This is (1) confusing, since the haddock docs on hackage for the version in use on the system by default is not accurate, and (2) annoying, since you cannot get the version on hackage by just running a cabal install. Instead, you have to download the package, update the version number, and then cabal install. The fix seems to involve one or both of the following: (1) Bump the version number of hoopl on hackage. (2) Expose runWithFuel in the version distributed with GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9851> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9530: min / max do not always return a NaN when one of the arguments is NaN
by GHC 04 May '15

04 May '15

#9530: min / max do not always return a NaN when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Incorrect Difficulty: Easy (less than 1 | result at runtime hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- I assume that this is well-known, but it tripped me up: {{{ Prelude> let inf = 1/0 Prelude> let nan = 0/0 Prelude> min nan inf Infinity Prelude> min inf nan NaN Prelude> min 3 nan NaN Prelude> min nan 3 3.0 Prelude> max nan inf NaN Prelude> max inf nan Infinity Prelude> max 3 nan 3.0 Prelude> max nan 3 NaN }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9530> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8941: Module that causes GHC-7.8 to exhaust memory compiled with -O2
by GHC 04 May '15

04 May '15

#8941: Module that causes GHC-7.8 to exhaust memory compiled with -O2 ------------------------------------+--------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- The module is JSON.Render in http://src.seereason.com/o2bug. When compiled ghc uses up at least 16GB of RAM and then dies. I haven't been able to simplify it very much, almost any change to JSON.Render causes it to start working properly. I did get it to fail using only packages available in hackage. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8941> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8086: Minimal install for GHC
by GHC 04 May '15

04 May '15

#8086: Minimal install for GHC ------------------------------------+--------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Installing GHC on a shared server requires a minimal footprint, without GHCi, profiling, debugging, documentation, or anything else not needed for regular building and installing. And anything stripable should be striped, if it isn't already. It would be great if the configuration script would support a --minimal option. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8086> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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] #9564: Floating point subnormals overrounded on output
by GHC 03 May '15

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

[GHC] #8743: The impossible happened : Prelude.(!!): index too large
by GHC 22 Apr '15

22 Apr '15

#8743: The impossible happened : Prelude.(!!): index too large ----------------------------------+--------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- Running ghc git HEAD (reports it's version as 7.9.20140206) and when cabal installing postgresql-simple I get: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.9.20140206 for x86_64-unknown-linux): Prelude.(!!): index too large Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: postgresql-simple-0.4.0.2 failed during the building phase. The exception was: }}} postgresql-simple-0.4.0.2 installs fine with 7.6.3. I'm going to compile 7.8-rc1 and see if the same problem exists there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8743> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8928: 64-bit statically linked binary consumes all memory while spinning on 'SIGVTALRM's
by GHC 20 Apr '15

20 Apr '15

#8928: 64-bit statically linked binary consumes all memory while spinning on 'SIGVTALRM's ----------------------------------+---------------------------------- Reporter: cswarth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I actually have no idea if this is a haskell bug or not, but since the earlier reported symptoms are similar, and the "pandoc" program is compiled with GHC, I thought I would report it here as well. This situation sounds exactly like [https://ghc.haskell.org/trac/ghc/ticket/7344 this bug] reported 17 months ago. Symptoms are 'pandoc --version' hangs and consumes memory until the process eventually dies with an OOM error. This seems to only happen when LC_ALL is set in the environment, and only when running the statically linked pandoc. {{{ $ uname -a Linux server 3.5.0-43-generic #66~precise1-Ubuntu SMP Thu Oct 24 14:52:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $ wget https://s3.amazonaws.com/rstudio-buildtools/pandoc-1.12.3.zip $ unzip pandoc-1.12.3.zip $ file pandoc-1.12.3/linux/debian/x86_64/pandoc pandoc-1.12.3/linux/debian/x86_64/pandoc: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.15, BuildID[sha1]=0x9bc69f51b7c213cf58e9f8692f4b46f9f05fb723, not stripped $ LC_ALL=C strace -e trace=open,close pandoc-1.12.3/linux/debian/x86_64/pandoc --version open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/gconv/gconv-modules", O_RDONLY) = -1 ENOENT (No such file or directory) --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- ^C--- SIGINT (Interrupt) @ 0 (0) --- }}} Note this problem does not occur if I run an older dynamically linked pandoc under the same circumstances. {{{ $ /usr/bin/pandoc --version pandoc 1.9.1.1 Compiled with citeproc-hs 0.3.4, texmath 0.6.0.3, highlighting-kate 0.5.0.5. Syntax highlighting is supported for the following languages: Actionscript, Ada, Alert, Alert_indent, Apache, Asn1, Asp, Awk, Bash, Bibtex, Boo, C, Changelog, Clojure, Cmake, Coffeescript, Coldfusion, Commonlisp, Cpp, Cs, Css, D, Diff, Djangotemplate, Doxygen, Dtd, Eiffel, ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8928> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9745: qual_pkg panic with template haskell
by GHC 20 Apr '15

20 Apr '15

#9745: qual_pkg panic with template haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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'm updating some things that use Template Haskell to derive lenses to work with GHC HEAD, but I'm getting the following error. My `cabal- install` a fresh build from the master branch of the `cabal` repository. {{{ src/Lib.hs:11:1:ghc: panic! (the 'impossible' happened) (GHC version 7.9.20141029 for x86_64-unknown-linux): qual_pkg lens-4.5.0.0.1 }}} lenstest.cabal {{{ name: lenstest version: 0.1.0.0 license-file: LICENSE author: Luite Stegeman maintainer: stegeman(a)gmail.com build-type: Simple cabal-version: >=1.10 library build-depends: base >= 4.8 && < 4.9, lens >= 4.5 exposed-modules: Lib default-language: Haskell2010 hs-source-dirs: src }}} src/Lib.hs: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Lib where import Control.Lens data XY = X Int | Y String makeLenses ''XY makePrisms ''XY }}} The `lens` and `free` packages need to be patched to work with the latest GHC, because of a conflict with `Data.Bifunctor`. I've attached updated version that use `PackageImports` to get the module from `bifunctors` as a workaround. Use {{{ cabal install --allow-newer }}} to install, since some dependencies have too restrictive upper bounds. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9745> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7