August 2016 - ghc-tickets

[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

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 25 Aug '16

25 Aug '16

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => * status: merge => new Comment: Merged comment:41 to `ghc-8.0` as 1c310133bbea168356e86aa38771f0da0d1315af. Reopening as there is likely more to be done here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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

[GHC] #12147: GHC's Linker Should Support Relocation Type 42
by GHC 25 Aug '16

25 Aug '16

#12147: GHC's Linker Should Support Relocation Type 42 ----------------------------------------+--------------------------------- Reporter: gershomb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- As per: https://github.com/DanielG/ghc- mod/issues/762#issuecomment-213743585 "gas >= 2.26 uses some new relocation types (in particular type 42, aka R_X86_64_REX_GOTPCRELX), which are not supported by ghc's linker." This causes problems when linking in libs with certain sorts of c bits via the GHC API (at the very least). Support should be added. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #12115: CoreLint error in safe program
by GHC 25 Aug '16

25 Aug '16

#12115: CoreLint error in safe program -------------------------------------+------------------------------------- Reporter: osa1 | 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: -------------------------------------+------------------------------------- This correct program is failing with a CoreLint error: {{{ {-# LANGUAGE MagicHash, UnboxedTuples #-} module Main where import GHC.Prim import GHC.Types showAlt0 :: (# Void#, (# #) #) -> String showAlt0 (# _, (# #) #) = "()" main :: IO () main = return () }}} Error: {{{ *** Core Lint errors : in result of Desugar (after optimization) *** <no location info>: warning: In the type ‘(# Void#, (# #) #) -> String’ Kind application error in type ‘(# Void#, (# #) #)’ Function kind = * -> * -> TYPE 'UnboxedTupleRep Arg kinds = [('VoidRep, RuntimeRep), ('UnboxedTupleRep, RuntimeRep), (Void#, TYPE 'VoidRep), ((# #), TYPE 'VoidRep)] core_err.hs:13:1: warning: [RHS of showAlt0 :: (# Void#, (# #) #) -> String] The type of this binder doesn't match the type of its RHS: showAlt0 Binder's type: (# Void#, (# #) #) -> String Rhs type: (# Void#, (# #) #) -> String }}} Tried with: GHC HEAD, 8.0.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12115> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12118: Testsuite driver does not normalise platform-dependent .stdout/stderr files
by GHC 25 Aug '16

25 Aug '16

#12118: Testsuite driver does not normalise platform-dependent .stdout/stderr files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | 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: -------------------------------------+------------------------------------- This change was made without explanation in commit 429f0099ab9adfadc779ca76f3aae1c9c160fb8c: {{{ Author: Esa Ilari Vuokko <ei(a)vuokko.info> Date: Sun Aug 13 12:46:49 2006 +0000 Fix driver not to normalise output when using platform specific output files }}} I don't understand why that change was made. It makes `T11223_link_order_a_b_2_fail` and `T11223_simple_duplicate_lib` fail on Windows, when running with `BINDIST=YES` (or, after accepting the `BINDIST=YES` output, when running with `BINDIST=NO`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12118> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4