September 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] #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] #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] #8275: Loopification breaks profiling
by GHC 02 Dec '13

02 Dec '13

#8275: Loopification breaks profiling ----------------------------------+---------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: high | Milestone: Component: Profiling | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- Profiling is currently broken in HEAD. Setting `BuildFlavour = prof` in `build.mk` leads to a segfault during build. After reverting d61c3ac186c94021c851f7a2a6d20631e35fc1ba (loopification performed in the code generator) everything builds without problems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8275> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40

[GHC] #8220: Macros / functions for source location
by GHC 01 Dec '13

01 Dec '13

#8220: Macros / functions for source location ------------------------------------+------------------------------------- Reporter: wojteknar | Owner: Type: feature request | 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 GNAT (Ada compiler) there is a special package with functions (evaluated at compile time) that return source location and enclosing entity name. This is very useful for logging and debugging. I'd love to have something similar in GHC. http://www.radford.edu/~nokie/classes/320/std_lib_html/gnat- source_info.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8220> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr
by GHC 22 Nov '13

22 Nov '13

#8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr ----------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: patch | Operating System: Unknown/Multiple Architecture: arm | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------------- Numerous ghci tests in the testsuite currently fail on ARM due to the lack of a `mkJumpToAddr` definition. These failures look like, {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130927 for arm-unknown-linux): mkJumpToAddr not defined for ArchARM {armISA = ARMv7, armISAExt = FPv3,NEON], armABI = HARD} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} As it turns out `mkJumpToAddr` is fairly straightforward to implement. I've done this in https://github.com/bgamari/ghc/tree/arm. This brings the number of unexpected failures in `tests/ghci` from 44 to 4. These four failures are segmentation faults that I need to look more closely at. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8380> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8065: Set trac up for multiple git repos
by GHC 20 Nov '13

20 Nov '13

#8065: Set trac up for multiple git repos ------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: Component: None | 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: | ------------------------------------+------------------------------------- Set trac up for multiple git repos: http://trac-hacks.org/wiki/GitPlugin#Multi-RepositoryConfiguration -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8065> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3