August 2015 - ghc-tickets

[GHC] #10157: HSCOLOUR_SRCS=YES fails mysteriously when no HsColour executable available
by GHC 08 Sep '15

08 Sep '15

#10157: HSCOLOUR_SRCS=YES fails mysteriously when no HsColour executable available -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- We seem to fill in the `--with-hscolour=` flag with an empty string, which causes a plain old build failure. Configure probably ought to fail if `HSCOLOUR_SRCS=YES` and there is no hscolours. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10157> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10486: Allow addTopDecls to create annotations
by GHC 08 Sep '15

08 Sep '15

#10486: Allow addTopDecls to create annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently addTopDecls is [https://github.com/ghc/ghc/blob/228ddb95ee137e7cef02dcfe2521233892dd61e0/co… restricted] to creating function, value, and foreign import declarations. Lifting this restriction allows one to create annotations without any issues, as far as I can tell. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10486> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10788: performance regression involving minimum (and maybe Vector)
by GHC 08 Sep '15

08 Sep '15

#10788: performance regression involving minimum (and maybe Vector) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This program (taken from http://stackoverflow.com/questions/32158319 /difference-in-performance-for-coin-change-between-haskell-and-c) runs about 50% slower when compiled with `ghc-7.10.1 -O` compared to `ghc-7.8.4 -O`. {{{ import Data.Vector.Unboxed as U ((!), constructN, length) coinchangev :: Int -> [Int] -> Int coinchangev n cs = v ! n where v = constructN (n+1) f f w = case U.length w of 0 -> 0 m -> 1 + minimum [w ! x | x <- map (m-) cs, x >= 0] main = print $ coinchangev 10000000 [1, 5, 10, 25, 100] }}} However if I change `minimum` to `sum`, while the runtime in 7.8.4 is unchanged, the runtime in 7.10.1 drops by a factor of 5! Allocations also decrease by a large factor. So my guess is that something has gone wrong with call arity analysis for `minimum` (and gone very right for `sum`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10788> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9087: Executables in the 7.8.2 Linux i386 binary tarball are not stripped
by GHC 07 Sep '15

07 Sep '15

#9087: Executables in the 7.8.2 Linux i386 binary tarball are not stripped ----------------------------+-------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+-------------------------- At least on i386 Linux, the executables inside the GHC binary tarball seem to come with debug information. Stripping it noticeably reduces the binary sizes: {{{ $ file /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x6012a4c86cd3f410ca0e59ab4ac872ce740d03c6, not stripped $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc 1,4M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc $ strip -s /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc 1021K /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock 3,2M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock $ strip -s /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock 2,3M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock }}} Do we really need to include the debug info for exes? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9087> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9500: Allow GHC defaults to be modified with an environment variable
by GHC 07 Sep '15

07 Sep '15

#9500: Allow GHC defaults to be modified with an environment variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I wanted to do this to turn -fsimple-list-literals on and off for NoFib without editing a million makefiles or recompiling GHC, but I bet there are other reasons. GHC's validate should probably prompt the user to verify they want to continue of the variable is set, and should issue a loud warning at the very end indicating what options were set by the variable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9500> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8596: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)"
by GHC 06 Sep '15

06 Sep '15

#8596: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)" ----------------------------+--------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------- I have a program (git-annex) which builds successfully on windows, but when I enable any of three optional features which pull in some additional libraries, it fails to link. I will attach the output of cabal build --ghc-options=-v for a failing and a successful build. I hypothesize this is due to a command line length limit. The final failing gcc link command is 43814 characters, vs 30765 in the configuration that succeeds. Right around the 32k boundry. Not sure what I can do to work around this, short of splitting up my program into standalone libraries which will link without referencing every individual module? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8596> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8614: Duplicate symbol error when loading text twice
by GHC 05 Sep '15

05 Sep '15

#8614: Duplicate symbol error when loading text twice ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We are developing some FFI binding to some Kinect Camera library, and came across the following: {{{ GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> import Honi Prelude Honi> import Honi.Types Prelude Honi Honi.Types> initialize 2 Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package text-0.11.3.1 ... linking ... done. Loading package honi-0.1.0.0 ... can't load .so/.DLL for: libfreenect.so (libfreenect.so: cannot open shared object file: No such file or directory) Prelude Honi Honi.Types> Right [d] <- getDeviceList Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package text-0.11.3.1 ... GHCi runtime linker: fatal error: I found a duplicate definition for symbol __stginit_textzm0zi11zi3zi1_DataziText whilst processing object file /home/niklas/.cabal/lib/x86_64-linux- ghc-7.6.3/text-0.11.3.1/libHStext-0.11.3.1.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. }}} Apparently, ghci has no problem linking packages like array and deepseq twice, but when it comes across loading text another time, we get this duplicate symbol error. Does this make sense? Why does it not detect that text is already linked, like for the other packages? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8614> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8290: lookupSymbol API is unsafe
by GHC 05 Sep '15

05 Sep '15

#8290: lookupSymbol API is unsafe -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- lookupSymbol is one of those functions that looks nice and innocuous on the tin, until you realize actually it doesn't actually do what you want, and seduces you into writing code that doesn't work on Mac OS X. Case in point, this recent test suite commit: {{{ commit 29b0521cd9be39b4026103d184d1fec14ef3bc22 Author: Edward Z. Yang <ezyang(a)mit.edu> Date: Fri Sep 13 20:52:57 2013 -0700 Properly provide leading underscore when necessary. Signed-off-by: Edward Z. Yang <ezyang(a)mit.edu> }}} Yes, the API is "correct" in some sense, but from a portability sense, we really want the function to add the underscore itself. If we change this particular function, we will probably break most dynamic loading code (including GHC's). We could also add a safe variant of the function. We just need to decide something to do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8290> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8926: GHC makes unsound references in object code
by GHC 05 Sep '15

05 Sep '15

#8926: GHC makes unsound references in object code ----------------------------+---------------------------------------------- Reporter: | Owner: anton.dubovik | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- To reproduce the bug run script `run.sh` from the attached archive. It will: 1. install `FooPackage` {{{ Resolving dependencies... Configuring FooPackage-0.1... Building FooPackage-0.1... Preprocessing library FooPackage-0.1... [1 of 1] Compiling FooPackage ( src\FooPackage.hs, dist\build\FooPackage.o ) In-place registering FooPackage-0.1... Installing library in C:\Users\Anton\AppData\Roaming\cabal\i386-windows- ghc-7.6.3\FooPackage-0.1 Registering FooPackage-0.1... Installed FooPackage-0.1 }}} 2. compile executable `Client1` which depends on `FooPackage` {{{ [1 of 3] Compiling QuxClient ( QuxClient.hs, obj\QuxClient.o ) [2 of 3] Compiling BarClient ( BarClient.hs, obj\BarClient.o ) [3 of 3] Compiling Client1 ( Client1.hs, obj\Client1.o ) Linking exes/Client1.exe ... }}} 3. compile executable `Client2` which doesn't depend on `FooPackage` At the third step GHC will fall with linker error: {{{ [2 of 2] Compiling Client2 ( Client2.hs, obj\Client2.o ) Linking exes/Client2.exe ... obj\BarClient.o:fake:(.text+0x83): undefined reference to `FooPackagezm0zi1_FooPackage_zdsinsertzuzdsgo5_info' obj\BarClient.o:fake:(.data+0x10): undefined reference to `FooPackagezm0zi1_FooPackage_zdsinsertzuzdsgo5_closure' collect2: ld returned 1 exit status }}} Both `Client1` and `Client2` import `BarClient` module that doesn't depends on `FooPackage`. `Client1` imports `QuxClient` that imports `FooPackage`: {{{ module QuxClient where import FooPackage(foo) import Data.Set qux :: Set String -> Set String qux = foo }}} {{{ module BarClient where import Data.Set bar :: Set String -> Set String bar s = insert "bar" s }}} `FooPackage` uses function `Data.Set.insert` which is marked at `Data.Set` as `INLINABLE`: {{{ module FooPackage where import Data.Set foo :: Set String -> Set String foo s = insert "foo" s }}} GHC emphasizes in interface file, that `FooPackage.o` contains specialized version of `Data.Set.insert`: {{{ > ghc --show-iface FooPackage.hi ... "SPEC Data.Set.Base.insert [GHC.Base.String]" [ALWAYS] forall $dOrd :: GHC.Classes.Ord GHC.Base.String Data.Set.Base.insert @ [GHC.Types.Char] $dOrd = FooPackage.$sinsert ... }}} Later GHC see again the use of `Data.Set.insert@String` at `BarClient` and decides to apply this specialise rule, so that `BarClient` now has reference to `FooPackage`: {{{ > ghc --show-iface BarClient.hi ... bar :: Data.Set.Base.Set GHC.Base.String -> Data.Set.Base.Set GHC.Base.String {- Arity: 1, Strictness: S, Unfolding: (\ s :: Data.Set.Base.Set GHC.Base.String -> FooPackage.$sinsert_$sgo5 BarClient.bar1 s) -} ... }}} `Client2` doesn't depend on `FooPackage`, thus linker throws an error. There are plenty of workarounds here, but all of them are ad hoc (1,2,3) or could affect performance (4): 1. Change the order of `BarClient` and `QuxClient` imports in `Client1` module. 2. Compile `Client1` and `Client2` in opposite order. 3. Add fake import at `Client2` module: {{{ import FooPackage() }}} 4. Build `FooPackage` with ghc-option `-fomit-interface-pragmas`. That will eraise from `FooPackage.hi` all specialisation rules as well as information about strictness and inlining. Some information about the environment: {{{ > ghc-pkg list ... containers-0.5.0.0 base-4.6.0.1 ... > ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 > cabal --version cabal-install version 1.18.0.3 using version 1.18.1.3 of the Cabal library }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8926> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9989: GHCI is slow for precompiled code
by GHC 05 Sep '15

05 Sep '15

#9989: GHCI is slow for precompiled code -------------------------------------+------------------------------------- Reporter: remdezx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hello! We found that loading compiled and optimised `accelerate` code into ghci works much much slower than code run directly. (I'm marking it as a ghc-api bug, because I noticed this behavior while using it) Here is the example: {{{#!hs module Main where import Data.Array.Accelerate as A import Data.Array.Accelerate.CUDA as C import Data.Time.Clock (diffUTCTime, getCurrentTime) main :: IO () main = do start <- getCurrentTime print $ C.run $ A.maximum $ A.map (+1) $ A.use (fromList (Z:.1000000) [1..1000000] :: Vector Double) end <- getCurrentTime print $ diffUTCTime end start }}} When I compile it and run $ ghc -O2 Main.hs -threaded [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main Array (Z) [1000001.0] 0.162204s It takes `0.16 s` to finish When I compile it and load into ghci: $ ghc -O2 -dynamic -c Main.hs $ ghci GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :l Main Ok, modules loaded: Main. Prelude Main> main Loading package transformers-0.3.0.0 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package directory-1.2.1.0 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package stm-2.4.4 ... linking ... done. Loading package SafeSemaphore-0.10.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package fclabels-2.0.2.2 ... linking ... done. Loading package text-1.1.1.3 ... linking ... done. Loading package hashable-1.2.3.1 ... linking ... done. Loading package primitive-0.5.4.0 ... linking ... done. Loading package vector-0.10.12.2 ... linking ... done. Loading package hashtables-1.2.0.1 ... linking ... done. Loading package unordered-containers-0.2.5.1 ... linking ... done. Loading package accelerate-0.15.0.0 ... linking ... done. Loading package byteable-0.1.1 ... linking ... done. Loading package cryptohash-0.11.6 ... linking ... done. Loading package cuda-0.6.5.1 ... linking ... done. Loading package exception-transformers-0.3.0.4 ... linking ... done. Loading package exception-mtl-0.3.0.5 ... linking ... done. Loading package old-time-1.1.0.2 ... linking ... done. Loading package polyparse-1.11 ... linking ... done. Loading package cpphs-1.18.6 ... linking ... done. Loading package haskell-src-exts-1.16.0.1 ... linking ... done. Loading package syb-0.4.4 ... linking ... done. Loading package th-lift-0.7 ... linking ... done. Loading package safe-0.3.8 ... linking ... done. Loading package th-expand-syns-0.3.0.4 ... linking ... done. Loading package th-reify-many-0.1.2 ... linking ... done. Loading package th-orphans-0.8.3 ... linking ... done. Loading package haskell-src-meta-0.6.0.8 ... linking ... done. Loading package srcloc-0.4.1 ... linking ... done. Loading package mainland-pretty-0.2.7 ... linking ... done. Loading package symbol-0.2.4 ... linking ... done. Loading package language-c-quote-0.8.0 ... linking ... done. Loading package accelerate-cuda-0.15.0.0 ... linking ... done. Array (Z) [1000001.0] 0.256128s It takes `0.26 s` to finish. On other computer, using `criterion`, we observed even a `50x` difference. Why is it working so slow, isn't ghci just to load function and simply call it? Here is how execution time changes for different matrix sizes. For comparison we have also measured time of interpreted code (without precompiling). {{{ size | compiled | precompiled | interpreted ---------+-----------+--------------+------------ 100 | 0.054076s | 0.082686s | 0.151857s 1000 | 0.054509s | 0.08305s | 0.135452s 10000 | 0.055405s | 0.08469s | 0.12632s 100000 | 0.057768s | 0.093011s | 0.155359s 1000000 | 0.089811s | 0.251359s | 0.202022s 10000000 | 0.397642s | 1.400603s | 0.898547s }}} We believe that problem lies on the side of `ghci` rather than `accelerate`, how could we confirm this? Moreover and even more important is there any workaround for it, if we need this precompiled code running fast in production environment? Any guidance will be appreciated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9989> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6