July 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

Re: [GHC] #4101: Primitive constant unfolding
by GHC 05 Jul '13

05 Jul '13

#4101: Primitive constant unfolding -------------------------+-------------------------------------------------- Reporter: malosh | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Keywords: | Os: Unknown/Multiple Architecture: x86 | Failure: Runtime performance bug Difficulty: | Testcase: Blockedby: | Blocking: Related: | -------------------------+-------------------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4101#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2132: Optimise nested comparisons
by GHC 05 Jul '13

05 Jul '13

#2132: Optimise nested comparisons --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2132#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5567: LLVM: Improve alias analysis / performance
by GHC 05 Jul '13

05 Jul '13

#5567: LLVM: Improve alias analysis / performance ---------------------------------+------------------------------------------ Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by jstolarek): * cc: jan.stolarek@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5567#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5212: waitForProcess: does not exist (No child processes)
by GHC 04 Jul '13

04 Jul '13

#5212: waitForProcess: does not exist (No child processes) ------------------------------------------+--------------------------------- Reporter: chrisdone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.4.2 Resolution: | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | Difficulty: Testcase: | Blockedby: Blocking: | Related: ------------------------------------------+--------------------------------- Changes (by chrisdone): * status: closed => new * cc: chrisdone@… (added) * component: GHC API => Runtime System * version: 6.12.3 => 7.4.2 * owner: chrisdone => * resolution: worksforme => Comment: Oddly, two years later I am experiencing the same problem. I was never able to reproduce it outside of production, which was a machine I had no control over. In the end I worked around it by running: catch (waitForProcess pid >>= return) (\_ -> return $ ExitSuccess) However, that was a workaround, not a solution. This time with a completely different codebase, XMonad, I can reproduce it in few lines of code: Here's a test-case: {{{ import Control.Concurrent import System.Process import XMonad import XMonad.Config main = do forkIO $ xmonad defaultConfig readProcess "ghc" ["--version"] "" >>= putStrLn }}} Compile and run like this (make sure you don't have xmonad already running): {{{ chris@retina:~$ ghc --make X.hs -threaded [1 of 1] Compiling Main ( X.hs, X.o ) Linking X ... chris@retina:~$ ./X X: waitForProcess: does not exist (No child processes) }}} The GHC version is 7.4.2, but it perhaps it's not so much a GHC bug but some behaviour of the runtime system and interaction with exceptions that is subtle or unclear to me. Can anyone reproduce, and if so, why does this happen? If you comment out the forkIO line, the program succeeds. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5212#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8037: GHC panic when compiling unsafeCoerce
by GHC 04 Jul '13

04 Jul '13

#8037: GHC panic when compiling unsafeCoerce ---------------------------+------------------------------------------------ Reporter: ghc@… | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: ---------------------------+------------------------------------------------ The GHC compiler crashes on the following program. {{{ module Test where import Unsafe.Coerce import Graphics.Rendering.OpenGL (color, Color3, GLdouble) data D4 = D4 Double Double Double Double crash :: D4 -> IO () crash c = color (invalidCast c) invalidCast :: D4 -> Color3 GLdouble invalidCast = unsafeCoerce }}} With the following output: {{{ [1 of 1] Compiling Test ( Test.hs, Test.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.1 for x86_64-apple-darwin): cgLookupPanic (probably invalid Core; try -dcore-lint) ww_s28U{v} [lid] static binds for: local binds for: }}} I've made several attempts to make the input program smaller, but all modifications will result in successful compilation. The cast is invalid but should produce an runtime error, not a compile time error. Changes I made that somehow prevent this bug from appearing: - Changing the `crash` functions into point free style `color . invalidCast`. - Decreasing the amount of doubles in the `D4` datatype. - Inlining the exact definitions from the OpenGL package. - Using the `print` function instead of the `color` function. (btw, I know I shouldn't use unsafeCoerce) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8037> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8038: Old-time is not built when building GHC 7.7.20130704 (perf) for Windows x86_64
by GHC 04 Jul '13

04 Jul '13

#8038: Old-time is not built when building GHC 7.7.20130704 (perf) for Windows x86_64 --------------------------------+------------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Component: libraries/old-time Version: 7.7 | Keywords: Os: Windows | Architecture: x86_64 (amd64) Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- make install fails with {{{ Installing library in G:/Progs/MSys/local/lib\old-time-1.1.0.1 ghc-cabal.exe: Error: Could not find module: System.Time with any suffix: }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8038> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8036: Demand analyser is unpacking too deeply
by GHC 04 Jul '13

04 Jul '13

#8036: Demand analyser is unpacking too deeply ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ The demand analyser reports that fixpoint iterations are sometimes going on forever; in particular, this debug trace trips: {{{ | + = -- pprTrace "dmdFix loop" (ppr n <+> (vcat | + -- [ text "Sigs:" <+> ppr [ (id,lookupVarEnv | (sigEnv env) id, | + -- lookupVarEnv | (sigEnv env') id) | + -- | (id,_) <- pairs], | + -- text "env:" <+> ppr env, | + -- text "binds:" <+> pprCoreBinding (Rec }}} This happens during bootsrapping GHC itself, and maybe somewhere in the testsuite; I forget. The reason is that I thought a neater way to control unpacking of recursive products would work (see the `ae_rec_tc` field of `AnalEnv`) but I was wrong. This doesn't bite often but it's plainly wrong and needs fixing. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8036> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8029: batch-mode recompilation checking sometimes fails
by GHC 04 Jul '13

04 Jul '13

#8029: batch-mode recompilation checking sometimes fails -----------------------------+---------------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: recompilation, batch-mode Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The batch-mode recompilation checker seems to be broken. Suppose you have a source tree with {{{ Data/List.hs Data/Top.hs }}} and Data/List.hs defining 'foo' and Data/Top.hs importing Data.List (local file). Compile Data/Top.hs, then rename Data.List so you have {{{ Data/List.{hi,o} Data/OtherList.hs -- exports 'foo' Data/Top.hs -- imports Data.List and Data.OtherList Data/Top.{hi.o} }}} Attempting to run 'ghc -c Data/Top.hs' will now fail with " Failed to load interface for `Data.OtherList'". This error appears to be specific to built-in modules, if I use a library module (e.g. Data.Vector from the vector package) I instead get an error that multiple definitions of 'foo' are in scope. A test repo is available at https://github.com/JohnLato/tripping-octo- avenger Incidentally, everything works if I use 'ghc -c --make'. I think a reasonable fix would be for --make to be on by default for batch-mode compilation as well. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8029> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8031: Template Haskell gets confused with kind variables introduced in separate foralls
by GHC 03 Jul '13

03 Jul '13

#8031: Template Haskell gets confused with kind variables introduced in separate foralls -----------------------------+---------------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: TemplateHaskell PolyKinds Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following file compiles without complaint: {{{ {-# LANGUAGE TemplateHaskell, RankNTypes, PolyKinds, DataKinds, TypeOperators, GADTs #-} module S2 where import Language.Haskell.TH data Proxy a = Proxy data SList :: [k] -> * where SCons :: Proxy h -> Proxy t -> SList (h ': t) dec :: Q [Dec] dec = [d| foo :: forall (a :: k). Proxy a -> forall (b :: [k]). Proxy b -> SList (a ': b) foo a b = SCons a b |] foo' :: forall (a :: k). Proxy a -> forall (b :: [k]). Proxy b -> SList (a ': b) foo' a b = SCons a b }}} Note that `foo` and `foo'` are identical, just at different compilation stages. However, the following module does not compile: {{{ {-# LANGUAGE TemplateHaskell, DataKinds, PolyKinds, RankNTypes #-} module S3 where import S2 $(dec) }}} The error is {{{ S3.hs:7:3: Couldn't match kind ‛k’ with ‛k1’ ‛k’ is a rigid type variable bound by the type signature for foo :: Proxy k a0 -> forall (k1 :: BOX) (b0 :: [k1]). Proxy [k1] b0 -> SList k1 ((':) k1 a0 b0) at S3.hs:7:3 ‛k1’ is a rigid type variable bound by the type signature for foo :: Proxy k a0 -> Proxy [k1] b -> SList k1 ((':) k1 a0 b) at S3.hs:7:3 Expected type: SList k1 ((':) k1 a0 b) Actual type: SList k ((':) k a0 b) Relevant bindings include foo :: Proxy k a0 -> forall (k1 :: BOX) (b0 :: [k1]). Proxy [k1] b0 -> SList k1 ((':) k1 a0 b0) (bound at S3.hs:7:3) a_aTCB :: Proxy k a0 (bound at S3.hs:7:3) b_aTCC :: Proxy [k1] b (bound at S3.hs:7:3) In the expression: SCons a_aTCB b_aTCC In an equation for ‛foo’: foo a_aTCB b_aTCC = SCons a_aTCB b_aTCC }}} If I change the nested `forall`s in the definition of `foo` to be just one top-level `forall`, the problem goes away. This may seem terribly esoteric, but it's easier to generate nested `forall`s than to float them all to the top-level after processing a type. I received an email requesting that I get the `singletons` library to compile with HEAD, and this seems to be why it doesn't. This is a regression error: the code compiles fine with 7.6.3 but not with HEAD. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8031> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1