December 2013 - ghc-tickets

[GHC] #8301: error BaseReg must be in a register for THREADED_RTS
by GHC 17 Feb '14

17 Feb '14

#8301: error BaseReg must be in a register for THREADED_RTS -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------+---------------------------------------- Compiling git HEAD on powerpc64-linux. This was working as recently as two weeks ago. Now getting: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name ghc-7.7.20130914 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage2 -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.18.1 -package array-0.4.0.2 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.3.0 -package containers-0.5.3.1 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.2.0.0 -package time-1.4.1 -package transformers-0.3.0.0 -package unix-2.7.0.0 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -XNondecreasingIndentation -DNO_REGS -optc-DTHREADED_RTS -DSTAGE=2 -O2 -fwarn-tabs -fno-warn-amp -O -dcore-lint -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -c compiler/utils/Platform.hs -o compiler/stage2/build/Platform.o In file included from /home/erikd/PPC64/ghc-ppc64/includes/Stg.h:232:0: 0, from /tmp/ghc10950_0/ghc10950_2.hc:3: /home/erikd/PPC64/ghc-ppc64/includes/stg/Regs.h:359:2: error: #error BaseReg must be in a register for THREADED_RTS }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8301> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #8365: stage2 build fails on Solaris (SmartOS)
by GHC 17 Feb '14

17 Feb '14

#8365: stage2 build fails on Solaris (SmartOS) ----------------------------------+---------------------------------------- Reporter: oddsignals | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Keywords: | Operating System: Solaris Architecture: x86 | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- I'm getting some missing symbols building on 32-bit SmartOS. 'quick' flavour build, DYNAMIC_BY_DEFAULT = NO, DYNAMIC_GHC_PROGRAMS = NO. {{{ $ uname -a SunOS pkgx86 5.11 joyent_20130919T215407Z i86pc i386 i86pc Solaris }}} {{{ "inplace/bin/ghc-stage1" -o ghc/stage2/build/tmp/ghc-stage2 -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -hide-all-packages -i -ighc/. -ighc/stage2/build -ighc/stage2/build/autogen -Ighc/stage2/build -Ighc/stage2/build/autogen -optP-DGHCI -optP-include -optPghc/stage2/build/autogen/cabal_macros.h -package array-0.4.0.2 -package base-4.7.0.0 -package bytestring-0.10.3.0 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package ghc-7.7.20130926 -package haskeline-0.7.0.4 -package process-1.2.0.0 -package transformers-0.3.0.0 -package unix-2.7.0.0 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -XPatternGuards -XNondecreasingIndentation -XForeignFunctionInterface -XUnboxedTuples -XFlexibleInstances -XMagicHash -O0 -fasm -threaded -no-user-package-db -rtsopts -odir ghc/stage2/build -hidir ghc/stage2/build -stubdir ghc/stage2/build ghc/stage2/build/Main.o ghc/stage2/build/InteractiveUI.o ghc/stage2/build/GhciMonad.o ghc/stage2/build/GhciTags.o ghc/stage2/build/hschooks.o <no location info>: Warning: Couldn't figure out linker information! Make sure you're using GNU ld, GNU gold or the built in OS X linker, etc. Undefined first referenced symbol in file base_GHCziConcziIO_ensureIOManagerIsRunning_closure /opt/src/ghc/rts/dist/build/libHSrts_thr.a(RtsStartup.thr_o) base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure /opt/src/ghc/rts/dist/build/libHSrts_thr.a(RtsStartup.thr_o) base_GHCziPack_unpackCString_closure /opt/src/ghc/rts/dist/build/libHSrts_thr.a(RtsAPI.thr_o) ld: fatal: symbol referencing errors. No output written to ghc/stage2/build/tmp/ghc-stage2 collect2: error: ld returned 1 exit status make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8365> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8305: ghci macros override built-ins for command expansion
by GHC 13 Feb '14

13 Feb '14

#8305: ghci macros override built-ins for command expansion ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | 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: #8113 | ------------------------------------+------------------------------------- I have a ghci macro `:tsu` from the ghc-vis package, which I installed a long time ago. In HEAD ghci (since the patch for #8113) this causes `:t` to expand to `:tsu`, rather than `:type`. That happened to result in a weird error the first time I tried to use `:t` (something like `Prelude.read: no parse`), and it took me a while to diagnose that my `.ghci` file was the issue! I don't like this new behavior because it forces me to either change my ghci habits (start using `:type` instead of `:t`) or avoid macros starting with any letter that I currently use as a single-letter ghci command. I set this ticket priority to highest because in any event this new behavior shouldn't sneak in to a GHC release unnoticed. Below is my proposal for how `:commands` should be interpreted now that built-in commands can be overridden (#8113), copied from a comment I made recently on that ticket. ---- I suppose what I specifically want to happen when I enter a `:command` is an algorithm like this. If the name I entered is an exact match for a macro or built-in, use that name. Otherwise, try to complete the name to the name of a ''built-in'' in the traditional way. If this succeeds, use the resulting name. Otherwise, try to complete the name to the name of a macro, and use the resulting name if that succeeds, otherwise give up. In all cases where we got a name, use the ''macro'' of that name if there is one, and otherwise use the built-in. (Obviously, for `::command`, ignore macros entirely.) In other words, built-ins should take precedence over macros for the purpose of name ''completion'', but macros should take precedence over built-ins for the purpose of name ''lookup''. This is backwards- compatible from the perspective of the user who is not aware of the change—`:t` will always mean `:type`, as long as the user has no macro named `:t`, just like in previous versions of ghci—while still allowing the aware user to redefine exactly what `:type` means. And it's flexible enough in that if the user really wants `:t` to complete to some other macro `:test` that they've written, they can always define another macro `:t` to expand to `:test`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8305> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #8429: GHC.Base.{breakpoint, breakpointCond} do nothing
by GHC 12 Feb '14

12 Feb '14

#8429: GHC.Base.{breakpoint, breakpointCond} do nothing ------------------------------------+------------------------------------- Reporter: refold | 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: 1377 | ------------------------------------+------------------------------------- The `GHC.Exts` module exports functions [[http://hackage.haskell.org/package/base-4.6.0.1/docs/GHC- Exts.html#g:6|breakpoint and breakpointCond]]. Right now they are no-ops, but apparently at some point in the past could be used to set breakpoints programmatically. From my reading of the source code, this feature was removed (either accidentally or on purpose) when the implementation of breakpoints [[changeset:cdce647711c0f46f5799b24de087622cb77e647f/ghc|was reworked]]. Relevant commits: * 31751ccacc24ebe5d15a0af84b10dc612d455440 * 3a99fa889bdff0c86df20cb18c71d30e30a79b43 * cdce647711c0f46f5799b24de087622cb77e647f Initially reported [http://stackoverflow.com/questions/19283911/how-do-i -use-ghc-exts-breakpoint here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[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