June 2014 - ghc-tickets

[GHC] #8707: Kind inference fails in data instance definition
by GHC 18 Sep '15

18 Sep '15

#8707: Kind inference fails in data instance definition ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider the following shenanigans: {{{ {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies, GADTs #-} data family SingDF (a :: (k, k2 -> *)) data Ctor :: k -> * data instance SingDF (a :: (Bool, Bool -> *)) where SFalse :: SingDF '(False, Ctor) }}} HEAD reports (with `-fprint-explicit-kinds`) {{{ Data constructor ‛SFalse’ returns type ‛SingDF Bool k '('False, Ctor k)’ instead of an instance of its parent type ‛SingDF Bool Bool a’ In the definition of data constructor ‛SFalse’ In the data instance declaration for ‛SingDF’ }}} I see two problems here: 1) Kind inference should fix the problem. If I add a kind annotation to `Ctor`, the code works. GHC should be able to infer this kind annotation for me. 2) The error message is not particularly helpful. GHC 7.6.3 had a more verbose, but more helpful message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8707> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9235: Simplifier ticks exhausted on recursive class method
by GHC 16 Sep '15

16 Sep '15

#9235: Simplifier ticks exhausted on recursive class method -----------------------------------+--------------------------------------- Reporter: klao | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- GHC 7.8 and HEAD panic on the following code: {{{#!haskell module C where class C a where c :: C a => a -> Int c a = c a {-# INLINE c #-} instance C () x :: Int x = c () }}} Note that it's the coincidence of the 3 conditions that triggers this bug: 1. the `c` method has to be inlined (explicity or implicitly) 2. it has to be recursive (but, it doesn't have to be as dumbly recursive as in the example) 3. it has to have this weird, slightly mistaken type signature: `C a => a -> Int` instead of simply `a -> Int`. But, when this incidentally happens (in my case, both 2. ''and'' 3. were unintentional), the user gets a very hard to debug issue. They don't even get an indication which module is responsible if `c` is used from a different module than the one with the class definition. Also note that this happens even with a non-optimized build. And in this example `c` has to be explicitly marked NOINLINE to prevent it. (In the instance that I caught in the wild simply removing the INLINE annotation was enough.) Finally, on a side note: shouldn't 3. by itself be an error? Or a warning at least? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9235> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8168: ghc "Simplifier ticks exhausted" "When trying UnfoldingDone"
by GHC 16 Sep '15

16 Sep '15

#8168: ghc "Simplifier ticks exhausted" "When trying UnfoldingDone" -------------------------------------+------------------------------------- Reporter: sp55aa | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Keywords: Simplifier, | Operating System: Windows UnfoldingDone, simpl-tick-factor | Type of failure: GHC rejects Architecture: x86 | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- ghc fail to compile this file: ---- begin Y.hs ---- newtype Rec a = Rec { unRec :: Rec a -> a } y :: (a -> a) -> a y = \f -> (\x -> f (unRec x x)) (Rec (\x -> f (unRec x x))) foo :: (a -> a) -> a -> a foo f n = f n main = print $ y foo 4 ---- end Y.hs ---- C:\Users\user\Desktop>ghc Y.lhs [1 of 1] Compiling Main ( Y.lhs, Y.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): Simplifier ticks exhausted When trying UnfoldingDone a_sqe{v} [lid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 5601 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8168> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8689: confusing comment in compiler/main/SysTools.lhs
by GHC 16 Sep '15

16 Sep '15

#8689: confusing comment in compiler/main/SysTools.lhs ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- on line 341 {{{ -- Hans: this isn't right in general, but you can -- elaborate it in the same way as the others }}} I have NO idea what that comment is referring to -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8689> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8552: Rename StgArrWords to StgArrBytes
by GHC 15 Sep '15

15 Sep '15

#8552: Rename StgArrWords to StgArrBytes ------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Since #3800, `StgArrWords` contains a certain number of words and not bytes. One can easily forget this and make programming mistakes. For example if you try to store the number of words in the `bytes` field, the garbage collector won't honor your decision. (I learned the hard way :)) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8552> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

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