May 2013 - ghc-tickets

[GHC] #7574: Register allocator chokes on certain branches with literals
by GHC 05 Jul '13

05 Jul '13

#7574: Register allocator chokes on certain branches with literals -----------------------------+---------------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: 7571, 7573 -----------------------------+---------------------------------------------- While running the test for #7571 (test is in #7573,) under '''WAY=normal''' instead of '''WAY=llvm''', I encountered this bug in the native backend: {{{ =====> T7571(normal) 6 of 6 [0, 0, 0] cd . && '/Users/a/code/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm -no-hs-main >T7571.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130113 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c7 }}} The test in question is: {{{ #include "Cmm.h" testLiteralBranch (W_ dst, W_ src) { if (1) { prim %memcpy(dst, src, 1024, 4); } else { prim %memcpy(dst, src, 512, 8); } return (); } }}} If you comment out the branch conditionals, the test passes, so clearly something fishy is going on here. The test also fails if you change the condition to ```if (1 == 1)``` I have absolutely no idea how this did not trip the profiling-based build in StgStdThunks.cmm, like in the LLVM build c.f. #7571 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7574> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 17

[GHC] #7940: Building GHC 7.7.20130526 for Windows x86_64 fails with Cmm lint error
by GHC 03 Jul '13

03 Jul '13

#7940: Building GHC 7.7.20130526 for Windows x86_64 fails with Cmm lint error --------------------------------+------------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Windows | Architecture: x86_64 (amd64) Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- Building GHC 7.7.20130526 for Windows x86_64 fails with the following error: {{{ "inplace/bin/ghc-stage1.exe" -static -optc-DDEBUG -ticky -DTICKY_TICKY -O -H256m -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -O0 -c rts/PrimOps.cmm -o rts/dist/build/PrimOps.debug_o Cmm lint error: in basic block cf in MachOp application: I32[ALLOC_PRIM_adm] + (8 + 8) op is expecting: [W32, W32] arguments provide: [I32, I64] Program was: {offset cc: _cd::I64 = R1; if (I64[CurrentNursery + 16] == 0) goto cg; else goto ci; ci: if (I64[I64[g0] + 56] >= %MO_SS_Conv_W32_W64(I32[large_alloc_lim])) goto cg; else goto ch; cg: HpAlloc = 0; R9 = stg_newByteArrayzh; R1 = _cd::I64; call stg_gc_prim_n(R1) args: 8, res: 0, upd: 8; ch: _cj::I64 = (_cd::I64 + 8 - 1) / 8; _cn::I64 = (8 + 8) / 8 + _cj::I64; _cm::I64 = allocate; _cl::I64 = BaseReg - 24; _ck::I64 = _cn::I64; (_ce::P64) = call "ccall" arg hints: [PtrHint,] result hints: [PtrHint] (_cm::I64)(_cl::I64, _ck::I64); I32[ALLOC_PRIM_ctr] = I32[ALLOC_PRIM_ctr] + 1 :: W32; I32[ALLOC_PRIM_adm] = I32[ALLOC_PRIM_adm] + (8 + 8); I32[ALLOC_PRIM_gds] = I32[ALLOC_PRIM_gds] + _cj::I64 * 8; I32[ALLOC_PRIM_slp] = I32[ALLOC_PRIM_slp] + 0; I64[_ce::P64] = stg_ARR_WORDS_info; I64[_ce::P64 + 8 + 0] = _cd::I64; R1 = _ce::P64; call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; } <no location info>: Compilation had errors }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7940> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 7

[GHC] #7830: Error: operand out of range
by GHC 02 Jul '13

02 Jul '13

#7830: Error: operand out of range ----------------------------------+----------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Linux | Architecture: powerpc Failure: Installing GHC failed | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Compiling on linux-powerpc and linux-powerpc64 I get: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall \ -H64m -O0 -package-name time-1.4.0.2 -hide-all-packages -i -ilibraries/time/. \ -ilibraries/time/dist-install/build -ilibraries/time/dist- install/build/autogen \ -Ilibraries/time/dist-install/build -Ilibraries/time/dist- install/build/autogen \ -Ilibraries/time/include -optP-DLANGUAGE_Rank2Types -optP \ DLANGUAGE_DeriveDataTypeable -optP-DLANGUAGE_StandaloneDeriving -optP- include \ -optPlibraries/time/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 \ -package deepseq-1.3.0.2 -package old-locale-1.0.0.5 -Wall -XHaskell2010 -XRank2Types \ -XDeriveDataTypeable -XStandaloneDeriving -XCPP -O2 -O -dcore-lint \ -fno-warndeprecated-flags -no-user-package-db -rtsopts -fno-warn- unused-do-bind \ -fno-warn-deprecations -fno-warn-unused-imports -fno-warn-identities -odir \ libraries/time/dist-install/build -hidir libraries/time/dist- install/build -stubdir \ libraries/time/dist-install/build -dynamic-too -c libraries/time/./Data/Time/Format.hs \ -o libraries/time/dist-install/build/Data/Time/Format.o -dyno \ libraries/time/dist-install/build/Data/Time/Format.dyn_o /tmp/ghc2806_0/ghc2806_1.s: Assembler messages: /tmp/ghc2806_0/ghc2806_1.s:51766:0: Error: operand out of range (0x000000000000adf8 is not between 0xffffffffffff8000 and 0x0000000000007fff) /tmp/ghc2806_0/ghc2806_1.s:51798:0: Error: operand out of range (0x000000000000ad90 is not between 0xffffffffffff8000 and 0x0000000000007fff) /tmp/ghc2806_0/ghc2806_1.s:51830:0: Error: operand out of range (0x000000000000ad28 is not between 0xffffffffffff8000 and 0x0000000000007fff) /tmp/ghc2806_0/ghc2806_1.s:51908:0: Error: operand out of range (0x000000000000ac1c is not between 0xffffffffffff8000 and 0x0000000000007fff) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 11

[GHC] #7647: UNPACK polymorphic fields
by GHC 29 Jun '13

29 Jun '13

#7647: UNPACK polymorphic fields ------------------------------------+--------------------------------------- Reporter: liyang | Owner: simonpj Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: | Related: 3990 ------------------------------------+--------------------------------------- comment:9:ticket:3990 mentions the possibility of unpacking polymorphic fields. To quote: […] What I mean by "polymorphic unpack" is this: {{{ data Poly a = MkP Bool {-# UNPACK #-} a data Mango = MkMango {-# UNPACK #-} (Poly Int) }}} Now a value of type Poly t would be represented using two pointer fields, as usual (ie the UNPACK would have no direct effect on Poly). But a Mango value would be represented thus: {{{ data Mango = MkMangoRep Bool Int# MkMango :: Poly Int -> MangoRep MkMango (MkP b (I# i)) = MkMangoRep b i -- Pattern match (MkMango p -> rhs) -- is transformed to (MkMangoRep b i -> let p = MkP b (I# i) in rhs }}} Something like that would be rather nice. This ticket is just a reminder. Thanks,[[br]] /Liyang -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 3

[GHC] #7858: Fix definitions of abs/signum for Floats/Doubles
by GHC 28 Jun '13

28 Jun '13

#7858: Fix definitions of abs/signum for Floats/Doubles -----------------------------+---------------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.6.3 | Keywords: floating point Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The current definition of abs doesn't work correctly for -0.0 (negative zero); and the signum function doesn't return NaN on NaN. The issue is discussed in detail in the following thread: http://www.haskell.org/pipermail/libraries/2013-April/019677.html To summarize, the proposal is to change both the Float and Double instance definitions for signum/abs as follows: {{{ signum x | x == 0 = x | isNaN x = x | x > 0 = 1 | otherwise = negate 1 abs x | isNegativeZero x = 0 | x >= 0 = x | otherwise = negate x }}} Simon PJ expressed interest in taking advantage of the underlying platforms floating-point instructions when available to speed things up, and the above referenced thread has some discussion regarding how this might be done. However, it might be best to start with a "correct" implementation first, and then later worry about speed. On a related note, this "bug" is actually present in the Haskell'98 standard definition itself, which seems to have overlooked NaN's and negative-0's. It'd be great if the standard got a similar amendment as well. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7858> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 1

[GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 28 Jun '13

28 Jun '13

#7602: Threaded RTS performing badly on recent OS X (10.8?) ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ This ticket is to remind us about the following problem: OS X is now using llvm-gcc, and as a result GHC's garbage collector with -threaded is much slower than it should be (approx 30% slower overall runtime). Some results here: [http://www.haskell.org/pipermail/cvs- ghc/2011-July/063552.html] This is because the GC code relies on having fast access to thread-local state. It uses one of two methods: either a register variable (gcc only) or `__thread` variables (which aren't supported on OS X). To make things work on OS X, we use calls to `pthread_getspecific` instead (see #5634), which is quite slow, even though it compiles to inline assembly. I don't recall which OS X / XCode versions are affected, maybe a Mac expert could fill in the details. We have tried other fixes, such as passing around the thread-local state as extra arguments, but performance wasn't good. Ideally Apple will implement TLS in OS X at some point and we can start to use it. A workaround is to install a real gcc (using homebrew?) and use that to compile GHC. Whoever builds the GHC distributions for OS X should probably do it that way, so everyone benefits. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7602> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 25

[GHC] #7939: RHS of associated type not kind-checked
by GHC 28 Jun '13

28 Jun '13

#7939: RHS of associated type not kind-checked ----------------------------------------+----------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- The following code compiles without complaint: {{{ {-# LANGUAGE TypeFamilies, PolyKinds #-} class Foo a where type Bar a instance Foo Int where type Bar Int = Maybe instance Foo Bool where type Bar Bool = Double }}} We can see here that {{{Bar}}} is ill-kinded. When I try {{{:k Bar}}} in GHCi, I get an assertion failure, not unexpectedly. I will fix in ongoing work. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7939> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 15

[GHC] #7902: Add support for byte endianness swapping exposed as a primops
by GHC 27 Jun '13

27 Jun '13

#7902: Add support for byte endianness swapping exposed as a primops -----------------------------+---------------------------------------------- Reporter: tab | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: bswap endianness Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Add support for W32 and W64 endianness swapping as a new primops (bSwap32# and bSwap64#), supported by code generator change in llvm and ncg to generate efficient code (i.e. X86's bswap instruction support). For other NCG architectures (powerpc, sparc) provide support by 2 ghc-prim C functions. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7902> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 20

[GHC] #7803: Superclass methods are left unspecialized
by GHC 25 Jun '13

25 Jun '13

#7803: Superclass methods are left unspecialized -----------------------------------------+---------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time performance bug | Blockedby: Blocking: | Related: -----------------------------------------+---------------------------------- In the attached code, Foo.foo1 gets compiled (by ghc -O2) into a call to the unspecialized version of Lib.exp5Tail, even though all the related functions are marked INLINE or SPECIALIZE. The problem seems to be that GHC creates a top-level overloaded function after the specialization pass, so the function never gets specialized. This might be the same issue as #7785, but the workaround I posted there does not work here. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7803> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 4

[GHC] #7833: installed GHC refers to libffi in the build directory
by GHC 24 Jun '13

24 Jun '13

#7833: installed GHC refers to libffi in the build directory ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.6.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ In #7806, Kazu reported that on OS X: After "make install", the installed GHC refers to libffi in the build directory. {{{ % otool -L ghc | grep libffi /Users/kazu/work/ghc/libffi/build/inst/lib/libffi.6.dylib (compatibility version 7.0.0, current version 7.0.0) }}} So, after I did "make maintainer-clean", the installed GHC could not find a libffi. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7833> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 12