April 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] #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 30 Jun '13

30 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 29 Jun '13

29 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 29 Jun '13

29 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] #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

[GHC] #7787: modifyMVar does not restore value if callback returns error value
by GHC 22 Jun '13

22 Jun '13

#7787: modifyMVar does not restore value if callback returns error value ----------------------------------------+----------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- `modifyMVar` is currently implemented as follows: {{{ modifyMVar :: MVar a -> (a -> IO (a,b)) -> IO b modifyMVar m io = mask $ \restore -> do a <- takeMVar m (a',b) <- restore (io a) `onException` putMVar m a putMVar m a' return b }}} The problem is that it forces the `(a',b)` outside of the exception handler. If forcing this throws an exception, `putMVar` will not be called, and a subsequent `withMVar` or similar will hang. Example: {{{ > import Control.Concurrent.MVar > mv <- newMVar 'x' > modifyMVar mv $ \_ -> return undefined *** Exception: Prelude.undefined > withMVar mv print -- hang -- }}} Perhaps we can fix it like this: {{{ - (a',b) <- restore (io a) `onException` putMVar m a + (a',b) <- restore (io a >>= evaluate) `onException` putMVar m a }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7787> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 4

[GHC] #7842: Incorrect checking of let-bindings in recursive do
by GHC 22 Jun '13

22 Jun '13

#7842: Incorrect checking of let-bindings in recursive do --------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- I have run into a problem with the type-checking of recursive do blocks, which reduces to the following example: {{{ {-# LANGUAGE RecursiveDo #-} module Bug where bug :: (Int -> IO Int) -> IO (Bool, Char) bug m = mdo i <- m i1 -- RECURSION let i1 :: Int i1 = i -- RECURSION -- This appears to be monomorphic, despite the type signature. f :: b -> b f x = x return (f True, f 'a') }}} This program is rejected with the errors shown below. The problem appears to be that somehow `f` has become monomorphic, despite its type-signature. This seems to happen only when `f` is part of a `let` block that is also involved in the recursion. Here is the error reported by GHC 7.7.20130215: {{{ Bug.hs:15:23: Couldn't match expected type `Char' with actual type `Bool' In the return type of a call of `f' In the expression: f 'a' In the first argument of `return', namely `(f True, f 'a')' Bug.hs:15:25: Couldn't match expected type `Bool' with actual type `Char' In the first argument of `f', namely 'a' In the expression: f 'a' In the first argument of `return', namely `(f True, f 'a')' }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7842> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 2

[GHC] #7713: Panic! make_exp (App _ (Coercion _)) when compiled with -fext-core
by GHC 21 Jun '13

21 Jun '13

#7713: Panic! make_exp (App _ (Coercion _)) when compiled with -fext-core -------------------------------+-------------------------------------------- Reporter: EduardSergeev | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: -fext-core panic Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- An attempt to compile the attached file with 7.6.2 (and 7.4.2) with "-O2 -fext-core" leads to: ghc: panic! (the 'impossible' happened) (GHC version 7.6.2 for x86_64-unknown-linux): make_exp (App _ (Coercion _)) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7713> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 6