February 2014 - ghc-tickets

[GHC] #8773: Require -XIncoherentInstances to write role annotations on class definitions
by GHC 17 Feb '14

17 Feb '14

#8773: Require -XIncoherentInstances to write role annotations on class definitions ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8745 | ------------------------------------+------------------------------------- With a role annotation declaring a representational role for a class parameter, it is very easy to create instance incoherence. See [https://ghc.haskell.org/trac/ghc/ticket/8745#comment:5 this comment]. The solution: require `-XIncoherentInstances` when writing such a role annotation. This also has the knock-on effect (happily) of preventing such shenanigans in Safe Haskell. Class role annotations asking GHC to infer roles or with nominal roles, although rather useless, will still be accepted without `-XIncoherentInstances`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8773> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build: threaded RTS, profiling mode
by GHC 17 Feb '14

17 Feb '14

#8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build: threaded RTS, profiling mode ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 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: | ------------------------------------+------------------------------------- Steps to reproduce: {{{ 0. Pick any platform. I've performed it on amd64, but seen real failures on unreg arches: ia64, ppc64 1. pull sources 2. ./boot 3. ./configure --enable-unregisterised # right, no build.mk 4. make }}} Here we see 2 kinds of bugs at once: 1. threaded RTS misses '''-DNOSMP''' define. Looks like ghc always needs to carry that define (what is the mechanism for it BTW?), it doesn't: {{{ HC [stage 1] compiler/stage2/build/ExtsCompat46.o In file included from /home/slyfox/dev/git/ghc/includes/Stg.h:232:0: 0, from /tmp/ghc6527_0/ghc6527_2.hc:3: /home/slyfox/dev/git/ghc/includes/stg/Regs.h:443:2: error: #error BaseReg must be in a register for THREADED_RTS #error BaseReg must be in a register for THREADED_RTS ^ }}} The implicit declarations are scary as well: {{{ /tmp/ghc1420_0/ghc1420_2.hc: In function 'c7WZ_entry': /tmp/ghc1420_0/ghc1420_2.hc:43:1: warning: implicit declaration of function 'hs_bswap64' [-Wimplicit- function-declaration] _c7X5 = hs_bswap64(*((P_)(R1.w+7))); ^ }}} I naively tried naive approach: {{{ mk/config.mk.in: +# Unregisterised build calls c compiler for every +# .hs file. thus pass it everywhere. +ifneq "$(GhcWithSMP)" "YES" +SRC_HC_OPTS += -optc-DNOSMP +endif }}} but got stage2, which always '''SIGSEGV'''s. Thus it's either incorrect fix or '''UNREG''' is broken. 2. profiling builds (all files with -prof) miss '''enterFunCCS''' declaration: {{{ /tmp/ghc7183_0/ghc7183_1.p_hc: In function 's6Y_entry': /tmp/ghc7183_0/ghc7183_1.p_hc:79:40: error: 'enterFunCCS' undeclared (first use in this function) ghcFunPtr = ((void (*)(void *, void *))enterFunCCS); ^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8748> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #8735: hpc doesn't work on Mac
by GHC 17 Feb '14

17 Feb '14

#8735: hpc doesn't work on Mac ------------------------------------+------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Code Coverage | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8770: ghci dynamic loading on MacOSX assumes .dylib extension (should check .so also)
by GHC 17 Feb '14

17 Feb '14

#8770: ghci dynamic loading on MacOSX assumes .dylib extension (should check .so also) -----------------------------------+--------------------------------- Reporter: z9p | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: dlopen dylib so | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------+--------------------------------- I am using ghc-7.6.3 on MacOSX 10.9.1. I noticed that when -l foo option is specified to ghci, it assumes the shared library extension is .dylib and tries to load foo.dylib. Even though a valid foo.so is present while foo.dylib is not, ghci ignores the .so and signals an error. This is in contradiction to the behavior of gcc and python on MacOSX. gcc would check the existence of both .so and .dylib and try to link them. Python is able to load the .so as well. Notice that here the .so is simply a renamed Mach-O .dylib. The reason I raise this issue is, in my case, I use macports to install cern ROOT and its shared libraries are all installed as .so files under /opt/local/lib. I would like to use them without change or creating .dylib -> .so links. $ ghci -lGui 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. Loading object (dynamic) Gui ... failed. <command line>: user specified .o/.so/.DLL could not be loaded (dlopen(libGui.dylib, 9): image not found) Whilst trying to load: (dynamic) Gui Additional directories searched: (none) $ ln -s libGui.so libGui.dylib $ ghci -lGui 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. Loading object (dynamic) Gui ... done final link ... done Prelude> -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8770> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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] #8722: powerpc64: error Cannot find a way to declare the thread-local gc variable
by GHC 17 Feb '14

17 Feb '14

#8722: powerpc64: error Cannot find a way to declare the thread-local gc variable -----------------------------+---------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------+---------------------------------------- Building 7.8.RC1 on powerpc64 fails with: {{{ [ 2883s] In file included from rts/sm/GCUtils.h:19:0, [ 2883s] from rts/sm/Scav.c:20: [ 2883s] rts/sm/GCTDecl.h:139:2: error: #error Cannot find a way to declare the thread-local gc variable! [ 2883s] #error Cannot find a way to declare the thread-local gc variable! [ 2883s] ^ [ 2883s] rts/ghc.mk:512: recipe for target 'rts/dist/build/.depend-v-l -debug-thr-thr_debug-thr_l.c_asm' failed [ 2883s] make[1]: *** [rts/dist/build/.depend-v-l-debug-thr-thr_debug- thr_l.c_asm] Error 1 }}} The build is unregisterized (default) and does not use dynamic linking (DYNAMIC_GHC_PROGRAMS=NO and DYNAMIC-BY_DEFAULT=NO). It might be related to #8301. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8722> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
by GHC 17 Feb '14

17 Feb '14

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: fixed | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:62> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8698: .ctors handling does not work on Windows 64-bit ghci
by GHC 17 Feb '14

17 Feb '14

#8698: .ctors handling does not work on Windows 64-bit ghci ----------------------------------+------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------- When fixing #7134 I've found .ctors section handling does not work on 64-bit Windows ghci. Patch https://ghc.haskell.org/trac/ghc/attachment/ticket/7134/ghc- w64fix.patch now disables .ctor handling for 64-bit Windows ghci. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8698> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #8706: Kind operators not parsed
by GHC 17 Feb '14

17 Feb '14

#8706: Kind operators not parsed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | 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: | -------------------------------------+------------------------------------- Take the following module: {{{ {-# LANGUAGE DataKinds, TypeOperators, TypeFamilies #-} data a + b = Inl a | Inr b type family Foo :: Bool + Bool }}} HEAD produces {{{ /Users/rae/temp/Bug.hs:5:25: parse error on input ‛+’ }}} It seems that type operators promoted to kinds are not parsed correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8757: Disallow local pattern synonym declarations
by GHC 17 Feb '14

17 Feb '14

#8757: Disallow local pattern synonym declarations -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc1 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC accepts Architecture: Unknown/Multiple | invalid program Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Locally-defined pattern synonyms work by accident in GHC and crash GHCi (see #8749), but certainly not by design. It can be confusing because it introduces shadowing to constructor-like names. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8757> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6