November 2013 - ghc-tickets

[GHC] #8469: GHCi reports out-of-scope type family instances with :info
by GHC 09 Feb '14

09 Feb '14

#8469: GHCi reports out-of-scope type family instances with :info ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: | ------------------------------------+------------------------------------- I have {{{ {-# LANGUAGE TypeFamilies #-} module A () where type family F a type instance F Int = Bool }}} {{{ module B where import A }}} In GHCi: {{{ Prelude> :load B [1 of 2] Compiling A ( A.hs, interpreted ) [2 of 2] Compiling B ( B.hs, interpreted ) Ok, modules loaded: B, A. *B> :i Int data Int = GHC.Types.I# GHC.Prim.Int# -- Defined in ‛GHC.Types’ <snip> type instance A.F Int -- Defined at A.hs:6:1 *B> }}} This last output from `:info` should be suppressed, I would think. (I agree it should be printed with `:info!`.) Note the `()` in module `A`'s export list. This is a regression from 7.6.3, where the out-of-scope type family instance is not printed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8469> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8264: Canonical way to prevent manual instances
by GHC 07 Feb '14

07 Feb '14

#8264: Canonical way to prevent manual instances -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- For some classes (Typeable) the user must not provide hand-written instances, for other no hand-written instances in Safe mode (old Typeable) and for others no instances at all (Coercible). Currently the Typeable checks are in tcInstDecls1 in [source:compiler/typecheck/TcInstDcls.lhs]; but a more proper place would be in checkValidInstHead in [source:compiler/typecheck/TcValidity.lhs]. Why file a ticket and not just do it? The latter source location does not know whether the instance is a (stand-alone) deriving instance or a hand- written one, so this needs a bit of refactoring. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8264> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8270: unknown symbol "atomic_inc" in GHCi when loading package ghc
by GHC 04 Feb '14

04 Feb '14

#8270: unknown symbol "atomic_inc" in GHCi when loading package ghc ----------------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- I tried to do a "quick-llvm" build of a distclean-ed tree and got an error when some dph package needed to load the ghc package in Template Haskell. I no longer have that exact error message, but I could reproduce it more simply as follows: {{{ rwbarton@adjunction:~/dist/ghc4$ ./inplace/bin/ghc-stage2 --interactive -package ghc-7.7.20130910 GHCi, version 7.7.20130910: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.2 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.3.0 ... linking ... done. Loading package containers-0.5.3.1 ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.1 ... linking ... done. Loading package unix-2.7.0.0 ... linking ... done. Loading package directory-1.2.0.1 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package Cabal-1.18.0 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package bin-package-db-0.0.0.0 ... linking ... done. Loading package hoopl-3.10.0.0 ... linking ... done. Loading package hpc-0.6.0.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package ghc-7.7.20130910 ... linking ... ghc-stage2: /home/rwbarton/dist/ghc4/compiler/stage2/build/libHSghc-7.7.20130910.a: unknown symbol `atomic_inc' ghc-stage2: unable to load package `ghc-7.7.20130910' }}} `atomic_inc` is used by `compiler/cbits/genSym.c`. It's defined in libHSrts of course, but apparently not all rts symbols are automatically available in the GHCi linker? I added a {{{ SymI_HasProto(atomic_inc) \ }}} in `RTS_SYMBOLS` in `rts/Linker.c` and the problem seems to be solved. I'm not really sure what the difference between `SymI_` and `SymE_` is, it looks Windows-related. Maybe other stuff like `atomic_dec` should be added too. I'm pretty sure I didn't run into this problem with a "quick" build, though I have no idea how it could be specific to "quick-llvm". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8270> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8453: segfault/assertion failure with multi-threaded profiling
by GHC 27 Jan '14

27 Jan '14

#8453: segfault/assertion failure with multi-threaded profiling ----------------------------------+---------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- Steps to reproduce: {{{ ghc-stage2 selector_thunks.hs -rtsopts -fforce-recomp -prof -threaded -debug -O2 ./selector_thunk +RTS -N4 }}} In a few seconds, it either segfaults or dies with the following error message: {{{ selector_thunks: internal error: ASSERTION FAILED: file rts/dist/build/sm/Evac_thr.c, line 778 (GHC version 7.7.20131002 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} selector_thunks.hs: {{{ import Control.Monad import Control.Concurrent import Data.IORef main = do gref <- newIORef [return ()] forM_ [0::Int ..10] $ \_ -> forkIO $ do ref <- newIORef [return ()] forever $ do list <- readIORef gref writeIORef ref $! reverse list acts <- readIORef ref last acts forM_ [1..100000099] $ \i -> writeIORef gref $! reverse $ concatMap (replicate 10) $ mapfst $ foldr (\x y -> seq x (x : y)) [] $ map f [1..10+ (div i 1000000)] mapfst :: [(a, b)] -> [a] mapfst [] = [] mapfst (x:xs) = (case x of (a, _) -> a) : mapfst xs f :: Int -> (IO (), Int) f x = (x `seq` return (), x) }}} I only tested the code with a recent HEAD, but I have seen a similar assertion failure with GHC 7.6.3, in a non-contrived application program. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8453> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8180: ghc --make uses wrong way with Template Haskell
by GHC 21 Jan '14

21 Jan '14

#8180: ghc --make uses wrong way with Template Haskell ----------------------------------+--------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- I have the following files: {{{ {-# LANGUAGE TemplateHaskell #-} module THSplice where number3 = [| 3 |] }}} {{{ {-# LANGUAGE TemplateHaskell #-} module Main where import THSplice main = putStrLn (show $number3) }}} When I say `ghc Main.hs`, I get this: {{{ [1 of 2] Compiling THSplice ( THSplice.hs, THSplice.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Main.hs:7:23: cannot find normal object file ‛./THSplice.dyn_o’ while linking an interpreted expression }}} It's possible a different collection of flags could get this to work, but I think this behavior goes against the intended "it just works" flavor of `--make`. This is a regression bug -- ghc 7.6.3 does the right thing. I'm on MacOS 10.7.5, Xcode 4.3.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8180> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8564: Unhandled ELF relocation types on dynamically loading object files with GHCi
by GHC 18 Jan '14

18 Jan '14

#8564: Unhandled ELF relocation types on dynamically loading object files with GHCi ------------------------------------+------------------------------- Reporter: pgj | Owner: pgj Type: task | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: FreeBSD Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------- GHCi cannot handle ELF symbols with relocation types 15 (i386) and 22 (amd64) (such as {{{ThreadRuneLocale}}}, coming from libc on systems later than 9.0) when dynamically loading object files. This can be reproduced by the issuing the following commands: {{{ # pkg install hs-hs-bibutils .. $ ghci Prelude> :m Text.Bibutils Prelude> bibl_init Loading package syb-0.4.0 ... linking ... done. Loading package hs-bibutils-5.0 ... linking ... <interactive>: /usr/local/lib/cabal/ghc-7.6.3/hs-bibutils-5.0/HShs-bibutils-5.0.o: unhandled ELF relocation(Rel) type 15 ghc: unable to load package `hs-bibutils-5.0' Prelude> }}} The source file {{{rts/Linker.c}}}, function {{{do_Elf_Rela_relocations()}}} is missing the case branches for types 15 ({{{R_386_TLS_IE}}}) and 22 ({{{R_X86_64_GOTTPOFF}}}). They shall be implemented for FreeBSD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8564> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8451: Link problem on FreeBSD
by GHC 18 Jan '14

18 Jan '14

#8451: Link problem on FreeBSD ------------------------------+-------------------------------------------- Reporter: kazu- | Owner: yamamoto | Status: new Type: bug | Milestone: Priority: high | Version: 7.7 Component: Compiler | Operating System: FreeBSD Keywords: | Type of failure: GHC doesn't work at all Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- GHC head on FreeBSD causes a link error if -prof and -threaded are specified: {{{ % cat main.hs main = putStrLn "hello" % ghc -prof -threaded main.hs [1 of 1] Compiling Main ( main.hs, main.o ) /usr/local/lib/gcc47/gcc/x86_64-portbld- freebsd9.1/4.7.3/../../../../../x86_64-portbld-freebsd9.1/bin/ld: cannot find -lthr collect2: error: ld returned 1 exit status }}} Note that libHSrts_thr* are certainly installed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8451> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks
by GHC 14 Jan '14

14 Jan '14

#8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks ----------------------------------+---------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: clang | Operating System: MacOS X Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- I'm using GHC 7.6.3 with clang/wrapper (setting is modified). This GHC cannot build GHC head with integer-gmp: {{{ checking for assembler byte directive... .byte checking how to define a 32-bit word... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: can't open file: conftest.o (No such file or directory) /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: can't open file: conftest.o (No such file or directory) /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: can't open file: conftest.o (No such file or directory) configure: error: cannot determine how to define a 32-bit word make[1]: *** [libraries/integer-gmp/gmp/gmp.h] Error 1 make: *** [all] Error 2 }}} With integer-simple, build is OK. For more information, please see http://d.hatena.ne.jp/kazu- yamamoto/20131028/1382921924 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8497> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8502: Document a surprising {{{unsafeDupablePerformIO}}} limitation.
by GHC 07 Jan '14

07 Jan '14

#8502: Document a surprising {{{unsafeDupablePerformIO}}} limitation. -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 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: | -------------------------------------+------------------------------------- We just discussed the following code on #ghc. {{{ import System.IO.Unsafe import Control.Concurrent.MVar import Control.Concurrent import GHC.Conc (par, pseq) x :: MVar Int -> Int -> Int x m a = unsafeDupablePerformIO $ withMVar m $ \i -> do sum [1..1000000 + a] `seq` return i main1 = do m <- newMVar 42 let w = x m 0 w `par` print w {- spark: thread blocked indefinitely in an MVar operation -} main2 = do m <- newMVar 42 let w = x m 0 forkIO $ print w forkIO $ print w print w {- spark: <<loop>> spark: <<loop>> -} main = main2 }}} This is not a bug; what happens is that the RTS suspends one of the duplicated computations of {{{w}}}, effectively killing the IO action that was passed to {{{unsafeDupablePerformIO}}} in the middle. This limitation of {{{unsafeDupablePerformIO}}} should be documented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8502> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8579: Loading a module in GHCi affects shadowing
by GHC 03 Jan '14

03 Jan '14

#8579: Loading a module in GHCi affects shadowing ------------------------------------+------------------------------------- Reporter: monoidal | 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: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In GHCi we can redefine a data declaration; last definition counts. But loading a module has a side effect of bringing the first declaration to front: {{{ λ> data A = X λ> data A = Y λ> :i A data A = Y -- Defined at <interactive>:3:6 λ> :m Data.List λ> :i A data A = X -- Defined at <interactive>:2:6 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8579> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2