May 2013 - ghc-tickets

[GHC] #7934: usleep hangs, no threads
by GHC 25 May '13

25 May '13

#7934: usleep hangs, no threads ----------------------------------------+----------------------------------- Reporter: gelisam | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.4.2 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: 1156 ----------------------------------------+----------------------------------- import System.Posix.Unistd main = flip mapM_ [0..] $ \i -> do usleep 100000 print i === The above program hangs after a variable number of iterations (usually around 120, sometimes up to 200, often before the first call to print). The documentation for usleep warns about bad interactions with threads, but the above program doesn't use any. The problem also occurs with nanosleep, but not with threadDelay. #1156 sounds related, but this time the problem also occurs without -threaded. === workaround: use threadDelay. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7934> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver
by GHC 25 May '13

25 May '13

#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver -----------------------------+---------------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: #7904 -----------------------------+---------------------------------------------- currently when GHC is used as the compilation driver for C code, it will always compile the C code (*.c) to assembly (*.s) and then in a subsequent phase map the assembly to the various object formats. Thusly: the feature request I have is adding support to ghc (perhaps via indication through a new flag) for running the C compiler as something like {{{ gcc source.c -c }}} rather than {{{ gcc source.c -s -c }}} (these are not necessarily the right flags, but rather a strawman representation of the difference). on certain operating systems, notable OS X, the system provided Assembler (to which there is no, more up to date, alternative) does not support / understand all of the instructions that gcc or clang will emit. Notably, as a general rule, compiling c code with -march=native flag *should not* break. However, on OS X on recent hardware, -march=native will use AVX SIMD instructions / registers if available, which the mac os x assembler doesn't understand. and thus an end user trying to build some haskell and c-code locally will have a very odd error that will take a bit of effort to understand. this took a bit of ef Likewise, when doing -fllvm compilation, the *.c-> *.s phase just slows down the compilation process period. I'm still learning the ghc compilation driver architecture, but it seems like this would be a relatively minimal change, and it'd be valuable along a number of atrributes This is not -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7922> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #7932: haskell-src-exts should depend on happy
by GHC 25 May '13

25 May '13

#7932: haskell-src-exts should depend on happy -----------------------+---------------------------------------------------- Reporter: JasonGross | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 7.4.2 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking: | Related: -----------------------+---------------------------------------------------- cabal-dev install haskell-src-exts-1.13.5 fails with a missing happy: $ cabal-dev install haskell-src-exts-1.13.5 Resolving dependencies... [1 of 1] Compiling Main ( /tmp/haskell-src-exts-1.13.5-24348 /haskell-src-exts-1.13.5/Setup.hs, /tmp/haskell-src-exts-1.13.5-24348 /haskell-src-ext s-1.13.5/dist/setup/Main.o ) /tmp/haskell-src-exts-1.13.5-24348/haskell-src-exts-1.13.5/Setup.hs:1:1: Warning: In the use of `runTests' (imported from Distribution.Simple, but defined in Distribution.Simple.UserHooks): Deprecated: "Please use the new testing interface instead!" Linking /tmp/haskell-src-exts-1.13.5-24348/haskell-src- exts-1.13.5/dist/setup/setup ... Configuring haskell-src-exts-1.13.5... setup: The program happy version >=1.17 is required but it could not be found. Failed to install haskell-src-exts-1.13.5 cabal: Error: some packages failed to install: haskell-src-exts-1.13.5 failed during the configure step. The exception was: ExitFailure 1 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7932> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7919: Heap corruption (segfault) from large 'let' expression
by GHC 24 May '13

24 May '13

#7919: Heap corruption (segfault) from large 'let' expression --------------------------+------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.6.3 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- The attached test program reliably triggers an assertion in the storage manager with the `-debug` rts. {{{ LargeUse: internal error: ASSERTION FAILED: file rts/sm/GCUtils.c, line 208 (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This behaviour is reproducible with many recent ghc versions (tried 7.6.3, 7.4.2, 6.12.3) and all fail at the same assertion when using the `-debug` rts. (Without `-debug` we get a more random variety of segfaults and GC errors.) It looks like a pretty clear case of heap corruption. I'll explain why... The test program uses TH to generate a program that looks like this: {{{ data Large = Large Int Int ... -- 512 non-strict Int fields test = let step (Large i1 i2 ... i512) = let j1 = i1 + i4 j2 = i2 + i7 ... j511 = i511 + i510 j512 = i512 + i1 in Large j1 j2 ... j512 in runSteps step 100000 (Large 1 1 ... 1) -- basically an unfoldr: runSteps :: (state -> (state, Int)) -> Int -> state -> [Int] runSteps f n i | n <= 0 = [] | otherwise = case f i of (i', r) -> r : runSteps f (n - 1) i' }}} We use TH to generate this program, and we use a "size" parameter that determines size of the data constructor (and corresponding letrec). This makes it easy to find the size threshold where it fails. For small sizes this program works fine, and for larger values it triggers the assert. With ghc 7.6.3 on a x86-64 machine, the magic threshold is 511: that is, the program works fine with size 510 and hits the assertion at size 511. This is suspiciously close to 512. And of course on a 64bit machine 512 * 8 is 4k, which is the storage manager's block size. And the failing assertion is in a bit of the storage manager that is dealing with blocks... {{{ // If this block does not have enough space to allocate the // current object, but it also doesn't have any work to push, then // push it on to the scanned list. It cannot be empty, because // then there would be enough room to copy the current object. if (bd->u.scan == bd->free) { ASSERT(bd->free != bd->start); push_scanned_block(bd, ws); } }}} So it looks very much like we have a situation where something is writing over the end of a block and messing up the SM's data structures. But, it is not nearly as simple as the data constructor being too big. We can demonstrate other programs that use much larger data constructors without any problem at all. Our suspicion falls on the big letrec. Indeed with this program if we change the data constructor to have strict fields then it no longer fails, and we can run it with much larger data constructor sizes. What would be different between strict and non-strict fields here? Well, one observation is that when it is strict then ghc can (and does) turn the code into a big cascade of case expressions, while when it is non-strict then the STG code is all 'let's. {{{ case tpl_s6jQ of tpl_s6Ak { __DEFAULT -> case tpl_s6jS of tpl_s6Al { __DEFAULT -> case tpl_s6jU of tpl_s6Am { -- etc for all 500+ elements }}} versus {{{ let { sat_s5UK :: GHC.Types.Int [LclId] = \u [] GHC.Num.$fNumInt_$c+ i511_s5Ly i1_s5E9; } in let { sat_s62X :: GHC.Types.Int [LclId] = \u [] GHC.Num.$fNumInt_$c+ i510_s5R2 i509_s5UG; } in let { sat_s62W :: GHC.Types.Int [LclId] = \u [] GHC.Num.$fNumInt_$c+ i509_s5UG i506_s5UC; } in -- etc for all 500+ elements }}} Note also, that it is nothing to do with the obvious space leak here. If we modify the code to generate an NFData instance and to use deepseq at each iteration then we eliminate the space leak, but we keep the big stg 'let', and it still fails. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7919> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #7916: PolyKinds without type signatures
by GHC 24 May '13

24 May '13

#7916: PolyKinds without type signatures --------------------------------------+------------------------------------- Reporter: monoidal | 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: --------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE PolyKinds, ExplicitForAll #-} f :: forall (m :: k -> *) (a :: k). m a -> m a f = id g = f }}} I would expect GHC to infer the same type for `g` as for `f`. However, it gives the AnyK kind, and `g` is not possible to use: {{{ ghci -Wall X.hs ... X.hs:5:1: Warning: Top-level binding with no type signature: g :: forall (m :: AnyK -> *) (a :: AnyK). m a -> m a Ok, modules loaded: Main. *Main> g "a" <interactive>:2:1: Kind incompatibility when matching types: a0 :: AnyK Char :: * In the first argument of ‛print’, namely ‛it’ In a stmt of an interactive GHCi command: print it }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7916> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #7927: Error in 'lift' line causes the 'impossible' to happen
by GHC 24 May '13

24 May '13

#7927: Error in 'lift' line causes the 'impossible' to happen -------------------------------+-------------------------------------------- Reporter: MitchellSalad | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- import Control.Monad.Trans.Class (lift) import Control.Monad.Trans.Maybe (MaybeT) foo :: MaybeT IO () foo = lift putStrLn "foo" -------- This code caused the following output from GHC: Couldn't match kind `* -> *' with `*' Expected type: [Char] -> MaybeT IO () Actual type: [Char] -> MaybeT IO () Kind incompatibility when matching types: [Char] :: * -> * [Char] :: * The function `lift'ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): kindFunResult <<details unavailable>> -------- The line should of course be 'lift $ putStrLn "foo"'. Apologies if this is a duplicate bug. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7927> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7928: GHC fails to terminate while compiling with optimizations
by GHC 24 May '13

24 May '13

#7928: GHC fails to terminate while compiling with optimizations -----------------------------+---------------------------------------------- Reporter: Ptharien's Flame | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: x86_64 (amd64) Failure: Other | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- When I try to compile random-fu-0.2.4.0 from Hackage, using the command: {{{ cabal install --ghc --ghc-options="-fllvm -O2 -dcore-lint" --enable- optimization=2 random-fu-0.2.4.0 }}} I get the following output: {{{ Resolving dependencies... Configuring random-fu-0.2.4.0... Building random-fu-0.2.4.0... Preprocessing library random-fu-0.2.4.0... [ 1 of 27] Compiling Data.Random.Internal.Find ( src/Data/Random/Internal/Find.hs, dist/build/Data/Random/Internal/Find.o ) [ 2 of 27] Compiling Data.Random.Internal.Fixed ( src/Data/Random/Internal/Fixed.hs, dist/build/Data/Random/Internal/Fixed.o ) [ 3 of 27] Compiling Data.Random.Internal.TH ( src/Data/Random/Internal/TH.hs, dist/build/Data/Random/Internal/TH.o ) [ 4 of 27] Compiling Data.Random.Lift ( src/Data/Random/Lift.hs, dist/build/Data/Random/Lift.o ) [ 5 of 27] Compiling Data.Random.RVar ( src/Data/Random/RVar.hs, dist/build/Data/Random/RVar.o ) [ 6 of 27] Compiling Data.Random.Distribution ( src/Data/Random/Distribution.hs, dist/build/Data/Random/Distribution.o ) [ 7 of 27] Compiling Data.Random.Distribution.Uniform ( src/Data/Random/Distribution/Uniform.hs, dist/build/Data/Random/Distribution/Uniform.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package MonadPrompt-1.0.0.3 ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package syb-0.4.0 ... linking ... done. Loading package th-extras-0.0.0.2 ... linking ... done. Loading package flexible-defaults-0.0.1.1 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package old-time-1.1.0.1 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package random-1.0.1.1 ... linking ... done. Loading package mersenne-random-pure64-0.2.0.3 ... linking ... done. Loading package primitive-0.5.0.1 ... linking ... done. Loading package vector-0.10.0.1 ... linking ... done. Loading package mwc-random-0.12.0.1 ... linking ... done. Loading package stm-2.4.2 ... linking ... done. Loading package stateref-0.3 ... linking ... done. Loading package random-source-0.3.0.4 ... linking ... done. Loading package rvar-0.2.0.1 ... linking ... done. Loading package MonadRandom-0.1.9 ... linking ... done. Loading package random-shuffle-0.0.4 ... linking ... done. Loading package monad-loops-0.4.2 ... linking ... done. Loading package continued-fractions-0.9.1.1 ... linking ... done. Loading package converge-0.1.0.1 ... linking ... done. Loading package gamma-0.9.0.2 ... linking ... done. Loading package erf-2.0.0.0 ... linking ... done. [ 8 of 27] Compiling Data.Random.List ( src/Data/Random/List.hs, dist/build/Data/Random/List.o ) [ 9 of 27] Compiling Data.Random.Distribution.Bernoulli ( src/Data/Random/Distribution/Bernoulli.hs, dist/build/Data/Random/Distribution/Bernoulli.o ) [10 of 27] Compiling Data.Random.Distribution.Categorical ( src/Data/Random/Distribution/Categorical.hs, dist/build/Data/Random/Distribution/Categorical.o ) *** Core Lint warnings : in result of Desugar (after optimization) *** <no location info>: Warning: [RHS of $c>>_aMYc :: forall p_aMMn. GHC.Num.Num p_aMMn => forall a_a3Jr b_a3Js. Data.Random.Distribution.Categorical.Categorical p_aMMn a_a3Jr -> Data.Random.Distribution.Categorical.Categorical p_aMMn b_a3Js -> Data.Random.Distribution.Categorical.Categorical p_aMMn b_a3Js] INLINE binder is (non-rule) loop breaker: $c>>_aMYc }}} It then freezes for an as-far-as-I-known indefinite amount of time; I have tried it several times, and it never moves beyond that. Once, I left it for two whole hours without any change. Every time, I have had to manually interrupt it with {{{ctrl-c}}}. On the other hand, if I instead use the command: {{{ cabal install --ghc --ghc-options="-fllvm -O1 -dcore-lint" --enable- optimization=1 random-fu-0.2.4.0 }}} It produces literally identitical output up to the point that the first command stopped at, but it continues as normal afterwards and finishes installing random-fu as expected. My terminal confirms that the {{{ghc}}} executable (as opposed to, say, {{{opt}}} or {{{llc}}}) is the one that the first command gets stuck on. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7928> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7866: floor (0/0) :: Int is different with -O0 and -O1
by GHC 23 May '13

23 May '13

#7866: floor (0/0) :: Int is different with -O0 and -O1 ----------------------------------------+----------------------------------- Reporter: alang9 | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- This program: {{{ main = print (floor (0/0) :: Int) }}} prints a different result with -O0: {{{ 0 }}} and -O1: {{{ -9223372036854775808 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7866> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4385: Type-level natural numbers
by GHC 23 May '13

23 May '13

#4385: Type-level natural numbers ----------------------------------------+----------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: | Testcase: Blockedby: | Blocking: Related: | ----------------------------------------+----------------------------------- Comment(by darchon): I get a similar error implementing concat for vectors: {{{ data Vec :: Nat -> * -> * where Nil :: Vec 0 a (:>) :: a -> Vec n a -> Vec (n + 1) a vappend :: Vec n a -> Vec m a -> Vec (n + m) a vappend Nil ys = ys vappend (x :> xs) ys = x :> (vappend xs ys) vconcat :: Vec n (Vec m a) -> Vec (n * m) a vconcat Nil = Nil vconcat (x :> xs) = vappend x (vconcat xs) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4385#comment:60> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7043: 32-bit GHC ceiling of negative float SEGFAULT: 11
by GHC 23 May '13

23 May '13

#7043: 32-bit GHC ceiling of negative float SEGFAULT: 11 ------------------------------------------------------+--------------------- Reporter: DrGodCarl | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Keywords: Segfault, ceiling, segmentation fault | Os: MacOS X Architecture: Other | Failure: GHCi crash Difficulty: Unknown | Testcase: arith005(ghci), num010(ghci) Blockedby: 3658 | Blocking: Related: | ------------------------------------------------------+--------------------- Changes (by kazu-yamamoto): * cc: kazu@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7043#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0