July 2016 - ghc-tickets

[GHC] #12227: regression: out of memory with -O2 -ddump-hi on a complex INLINE function
by GHC 25 Aug '16

25 Aug '16

#12227: regression: out of memory with -O2 -ddump-hi on a complex INLINE function -------------------------------------+------------------------------------- Reporter: j6carey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Summary: Unlike GHC 7.10.2, when GHC 8.0.1 tries to compile a certain complex INLINE function with -O2 -ddump-hi, it runs out of memory. Dropping either -O2 or -ddump-hi enables successful compilation. Oddly enough, triggering the issue requires using the function argument indirectly through a variable bound by a "where" clause, even though it is obvious to a human reader that the indirection is trivial. (Even after simplifying the original code to work around the out of memory issue, that indirection greatly increases the size of the ".dump-hi" file. It might be that the "out of memory" would not happen if one had sufficient RAM.) Using INLINABLE instead of INLINE seems to result in a much smaller RHS being recorded for the function in question, and does not trigger the problem. (Perhaps INLINABLE records a more optimized RHS than does INLINE, though that is not obvious to me from the GHC User's Guide.) The attached files contain a reduced version of the original code that still triggers the problem. (Of course, the reduced version is rather artificial and pointless, other than to demonstrate the problem.) Probably someone with sufficient understanding could shrink the example further. Please note that I have worked around the issue, and so I am not blocked by this problem, at least not currently. Attachments: - crash.bash - Crash.hs Observed behavior: On 64-bit x86 Ubuntu 16.04 LTS, with the attached files in the current directory, GHC 7.10.2 succeeds: {{{ $ ./crash.bash The Glorious Glasgow Haskell Compilation System, version 7.10.2 [1 of 1] Compiling Crash ( Crash.hs, Crash.o ) }}} whereas GHC 8.0.1 runs out of memory (or wedges my system if I comment out both "ulimit" commands in the script): {{{ $ ./crash.bash The Glorious Glasgow Haskell Compilation System, version 8.0.1 [1 of 1] Compiling Crash ( Crash.hs, Crash.o ) ghc: out of memory }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12227> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12195: RTS GetTime.c is broken on Darwins that include clock_gettime
by GHC 25 Aug '16

25 Aug '16

#12195: RTS GetTime.c is broken on Darwins that include clock_gettime -------------------------------------+------------------------------------- Reporter: mistydemeo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC fails to build on versions of Darwin which include `clock_gettime`. On Darwin versions which include `clock_gettime`, the `#ifdef`s are structured to prefer using `clock_gettime` over the mach-specific time functions and structs; however, a couple of places in GetTime.c use the mach functions unconditionally even though the `mach/mach_time.h` header won't be included if `clock_gettime` is available. The attached patch fixes this by checking `HAVE_CLOCK_GETTIME` first before checking if the OS is Darwin. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12195> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12354: Word foldl' isn't optimized as well as Int foldl'
by GHC 25 Aug '16

25 Aug '16

#12354: Word foldl' isn't optimized as well as Int foldl' -------------------------------------+------------------------------------- Reporter: kjslag | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs import Data.List test :: Int -> Int test n = foldl' (+) 0 [1..n] main :: IO () main = do print $ test $ 10^8 }}} GHC optimizes the above code to the point that the garbage collector doesn't even have to do anything: {{{ $ ghc -rtsopts -O2 testInt && ./testInt +RTS -s [1 of 1] Compiling Main ( testInt.hs, testInt.o ) Linking testInt ... 5000000050000000 51,752 bytes allocated in the heap 3,480 bytes copied during GC 44,384 bytes maximum residency (1 sample(s)) 17,056 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.000s 0.000s 0.0001s 0.0001s INIT time 0.000s ( 0.000s elapsed) MUT time 0.101s ( 0.101s elapsed) GC time 0.000s ( 0.000s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.103s ( 0.102s elapsed) %GC time 0.1% (0.1% elapsed) Alloc rate 511,162 bytes per MUT second Productivity 99.8% of total user, 100.9% of total elapsed }}} However, if I change the type of {{{test}}} to {{{test :: Word -> Word}}}, then a lot of garbage is produced and the code runs 40x slower: {{{ ghc -rtsopts -O2 testWord && ./testWord +RTS -s [1 of 1] Compiling Main ( testWord.hs, testWord.o ) Linking testWord ... 5000000050000000 11,200,051,784 bytes allocated in the heap 1,055,520 bytes copied during GC 44,384 bytes maximum residency (2 sample(s)) 21,152 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 21700 colls, 0 par 0.077s 0.073s 0.0000s 0.0000s Gen 1 2 colls, 0 par 0.000s 0.000s 0.0001s 0.0001s INIT time 0.000s ( 0.000s elapsed) MUT time 4.551s ( 4.556s elapsed) GC time 0.077s ( 0.073s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 4.630s ( 4.630s elapsed) %GC time 1.7% (1.6% elapsed) Alloc rate 2,460,957,186 bytes per MUT second Productivity 98.3% of total user, 98.3% of total elapsed }}} I expected the performance to be nearly identical. I'm using GHC version 8.0.1 on x86_64 Arch Linux. I asked about this on stackoverflow, and the issue appears to be related to rewrite rules: [http://stackoverflow.com/a/38113639/6531137] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12354> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12194: ghc-pkg, package database path containing a trailing slash, and ${pkgroot}
by GHC 25 Aug '16

25 Aug '16

#12194: ghc-pkg, package database path containing a trailing slash, and ${pkgroot} -------------------------------------+------------------------------------- Reporter: dudebout | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.0.1 Keywords: pkgroot | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When passing a package database to ghc-pkg via GHC_PACKAGE_PATH or --package-db, ${pkgroot} does not get computed properly if the input path contains a trailing slash. Default behavior: $ ghc-pkg describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2" Correct behavior (no trailing slash): $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2" $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d ghc-pkg describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2" Incorrect behavior (with trailing slash): $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d/ describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d" $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d/ ghc-pkg describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d" When this bug happens, ghc-pkg check complains about missing files for packages using ${pkgroot}. This bug happens because ${pkgroot} is computed using takeDirectory. It should instead use (takeDirectory . dropTrailingPathSeparator) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12194> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12242: panic with complicated type/kind/class expressions
by GHC 25 Aug '16

25 Aug '16

#12242: panic with complicated type/kind/class expressions -------------------------------------+------------------------------------- Reporter: Ashley | Owner: Yakeley | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tried to simplify this as much as I could, but I couldn't boil it down further than this: {{{#!hs -- ghc -O -ddump-hi -ddump-to-file Bug.hs {-# LANGUAGE TypeInType #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE GADTs #-} module Bug where { import Data.Kind; data HetEq (a :: ka) (b :: kb) where { ReflH :: forall (k :: *) (t :: k). HetEq t t; }; data Rep :: forall (k :: *). k -> * where { SimpleRep :: forall (k :: *) (a :: k). Rep a; ApplyRep :: forall (k1 :: *) (k2 :: *) (p :: k1 -> k2) (a :: k1). Rep p -> Rep a -> Rep (p a); }; class TestHetEquality (w :: forall k. k -> *) where { testHetEquality :: forall (ka :: *) (a :: ka) (kb :: *) (b :: kb). w a -> w b -> Maybe (HetEq a b); }; instance TestHetEquality Rep where { testHetEquality (ApplyRep tfa ta) (ApplyRep tfb tb) = do { ReflH <- testHetEquality tfa tfb; ReflH <- testHetEquality ta tb; return ReflH; }; testHetEquality _ _ = Nothing; }; bug :: forall (a :: *). Rep (Maybe a) -> Maybe (Rep a); bug (ApplyRep tf ta) = case testHetEquality tf SimpleRep of { Just ReflH -> Just ta; Nothing -> Nothing; }; bug _ = Nothing; } }}} You'll need `-O` and `-ddump-hi` to trigger it. {{{ $ stack exec -- ghc -O -ddump-hi -ddump-to-file Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): pprIfaceCo Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12242> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12067: warn-unused-imports does not detect coersions
by GHC 25 Aug '16

25 Aug '16

#12067: warn-unused-imports does not detect coersions -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using `coerce`, GHC can erroneously warn that imports are unnecessary. For example: Foo.hs {{{ module Foo (MT(..), M) where import Control.Monad.Identity newtype MT m b = MT (m b) type M b = MT Identity b }}} Main.hs {{{ import Control.Monad.Identity import Data.Coerce import Foo foo :: M [a] -> MT [] a foo = coerce }}} GHC (with `-fwarn-unused-imports`) warns {{{ Main.hs:1:1: Warning: The import of ‘Control.Monad.Identity’ is redundant except perhaps to import instances from ‘Control.Monad.Identity’ To import instances alone, use: import Control.Monad.Identity() }}} But this is incorrect: we need the constructor `Identity` to be in scope in order for the coercion to succeed. Thus the import is not redundant, nor is it needed to import instances. In particular, the two implied suggestions 1. remove the import altogether 2. change the import to `import Control.Monad.Identity` both (correctly) result in compile errors. At a minimum, the warning message should be updated to include this possibility, but it would be even better if GHC could detect this and not throw a warning at all. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12067> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12217: PowerPC NCG: Remove TOC save for calls.
by GHC 25 Aug '16

25 Aug '16

#12217: PowerPC NCG: Remove TOC save for calls. -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 (NCG) | Keywords: | Operating System: Unknown/Multiple Architecture: powerpc | Type of failure: Runtime | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D2328 | Wiki Page: -------------------------------------+------------------------------------- On AIX and 64-bit Linux the TOC pointer is saved even before a call to a C function. This is redundant as the link editor takes care of saving the TOC pointer if necessary. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12217> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12134: PowerPC 64-bit: Foreign functions with more than 8 float parameters broken
by GHC 25 Aug '16

25 Aug '16

#12134: PowerPC 64-bit: Foreign functions with more than 8 float parameters broken -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (NCG) | Keywords: ccall | Operating System: Linux Architecture: powerpc64 | Type of failure: Incorrect result | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following: {{{#!c void many_floats(float f1, float f2, float f3, float f4, float f5, float f6, float f7, float f8, float f9, float f10, float f11, float f12, float f13, float f14) { printf("%f\n%f\n%f\n%f\n%f\n%f\n%f\n%f\n%f\n%f\n%f\n%f\n%f\n%f\n", f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11, f12, f13, f14); } }}} and {{{#!hs foreign import ccall "many_floats" many :: CFloat -> CFloat -> CFloat -> CFloat -> CFloat -> CFloat -> CFloat -> CFloat -> CFloat -> CFloat -> CFloat -> CFloat -> CFloat -> CFloat -> IO () main = many 1.5 2.5 3.5 4.5 5.5 6.5 7.5 8.5 9.5 10.5 11.5 12.5 13.5 14.5 }}} gives {{{ 1.500000 2.500000 3.500000 4.500000 5.500000 6.500000 7.500000 8.500000 0.000000 0.000000 3.000000 14.500000 13.500000 0.000000 }}} on PowerPC 64-bit Linux. According to the ABI for PowerPC 64-bit ELF v1.9 and ELF v2.0 the first 13 floating or double parameters are passed in floating point registers. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12134> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12182: Sparks for CAFs get GC'd too eagerly
by GHC 25 Aug '16

25 Aug '16

#12182: Sparks for CAFs get GC'd too eagerly -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See http://stackoverflow.com/questions/36270447/frequent-gc-preventing- sparks-from-running-in-parallel/37751110#37751110 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12182> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12064: tcIfaceGlobal error with existentially quantified types
by GHC 25 Aug '16

25 Aug '16

#12064: tcIfaceGlobal error with existentially quantified types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: hs-boot | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program: {{{ -- A.hs-boot module A where data D -- B.hs module B where import {-# SOURCE #-} A class K a where method :: D -> a -- A.hs {-# LANGUAGE ExistentialQuantification #-} module A where import A data D = forall n. K n => D }}} We get a `tcIfaceGlobal` error in this case (one-shot of course.) I reduced this case out of prog006. So for some reason we're tugging on `K` too early—that's as far as I know at this point. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7