- ghc-tickets - Haskell.org

[GHC] #8553: ASSERT failed compiler/typecheck/TcMType.lhs line 809
by GHC 22 Nov '13

22 Nov '13

#8553: ASSERT failed compiler/typecheck/TcMType.lhs line 809 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: Unknown/Multiple | crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- With current master (9c2dade94fae5f4fe19cd972ca1f1049c633e4ed) I get {{{ [1 of 1] Compiling ShouldCompile ( ../ghc/gadt6.hs, ../ghc/gadt6.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131121 for x86_64-unknown-linux): ASSERT failed! file compiler/typecheck/TcMType.lhs line 809 [W] cobox_aBx{v} [lid] :: t_aBv{tv} [tau[0]] ghc-prim:GHC.Types.~{(w) tc 31Q} t_aBu{tv} [tau[0]] (CIrredEvCan) }}} (And it took me a while to figure out that it was not my code that was introducing the bug.) According to `git log -L 809,809:compiler/typecheck/TcMType.lhs` (a useful feature) the history of the ASSERT is: * SPJ, “Accommodate Derived constraints in two places”, Sep 17, 8cfbdccb7f8716c2b6b13b3c7884f52b1087d782 * SPJ, “Fix an ASSERT”, Oct 1 2012, adb6bcb7b85410dd42828a4824962ce9c6e9d667 * SPJ, “Tidy up and simplify TcMType.zonkFlats”, Sep 17, 2012, bd6b183e092fc7667fc55b3aa15d857f257ec73f -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8553> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8537: confusing error message for specialize pragma
by GHC 22 Nov '13

22 Nov '13

#8537: confusing error message for specialize pragma ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I get the following confusing error/warning about SPECIALIZE {{{ SPECIALISE pragma for non-overloaded function `$cfmap' }}} with the following example module {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE CPP #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoImplicitPrelude #-} module Numerical.Types.Shape where import Control.Applicative import Data.Foldable import Data.Monoid import Data.Functor import Prelude (seq, ($!),($),Show(..),Eq(),Int) data Nat = S !Nat | Z --deriving (Eq,Show,Read) {- not doing the HLIST style shape because I don't want to have any pattern matchings going on. Also would play hell with locality quality in the address translation hackery, because there'd be an extra load to get those ints! -} infixr 3 :* {- the concern basically boils down to "will it specialize / inline well" -} data Shape (rank :: Nat) a where Nil :: Shape Z a (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a --deriving instance (Show (Shape rank a)) -- deriving instance Eq (Shape rank a) -- #if defined( __GLASGOW_HASKELL__ ) && ( __GLASGOW_HASKELL__ >= 707) --deriving instance Typeable (Shape rank a) -- #endif instance Functor (Shape Z) where fmap = \ f Nil -> Nil {-# INLINABLE fmap #-} {-# SPECIALIZE fmap :: (Int ->Int )-> (Shape Z Int)-> (Shape Z Int) #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8537> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work
by GHC 22 Nov '13

22 Nov '13

#2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work -------------------------------------------------+------------------------- Reporter: ajd | Owner: Type: feature request | Status: Priority: normal | closed Component: Compiler | Milestone: 6.12 Resolution: fixed | branch Operating System: Unknown/Multiple | Version: Type of failure: None/Unknown | 6.10.1 Test Case: | Keywords: indexed_types/should_compile/T2850 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by goldfire): As far as I can tell, my comment above (comment 10) is pure gibberish. There was a thought in my head somewhere, but every time I feel like I'm getting close to it, it runs away. Besides, after a little while trying, I was unable to come up with a relevant example. If there really is an issue here, we'll wait for someone to really hit it and yell. Otherwise, I'll move on. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2850#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8450: can't match type Bool with (), but shouldn't have to
by GHC 22 Nov '13

22 Nov '13

#8450: can't match type Bool with (), but shouldn't have to ------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The following (definitely type-incorrect) file: {{{ {-# LANGUAGE ScopedTypeVariables #-} runEffect :: Either Bool r -> r runEffect = undefined run :: forall a. a run = runEffect $ (undefined :: Either a ()) }}} produces the following error: {{{ test.hs:7:7: Couldn't match type `Bool' with `()' Expected type: a Actual type: () In the expression: runEffect $ (undefined :: Either a ()) In an equation for `run': run = runEffect $ (undefined :: Either a ()) }}} This is strange because one of the two types it claims it can't unify (Bool) doesn't appear in either the expected or actual type. Note that removing the ($) gets a different error message that makes it a bit more clear what's going on: {{{ test.hs:7:18: Couldn't match type `Bool' with `()' Expected type: Either Bool a Actual type: Either a () In the first argument of `runEffect', namely `(undefined :: Either a ())' In the expression: runEffect (undefined :: Either a ()) In an equation for `run': run = runEffect (undefined :: Either a ()) }}} So it seems it's trying to unify Bool and () because it's unifying both a with Bool and a with (); however, the usual comments about rigid type variables aren't there, which makes even this error message a bit confusing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8450> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8526: -fforce-recomp does not re-summarise modules
by GHC 22 Nov '13

22 Nov '13

#8526: -fforce-recomp does not re-summarise modules ------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- -fforce-recomp should re-summarise modules so that the source file will get re-preprocessed. Otherwise a modification to an `#include`'d file will not get picked up. {{{ $ ghci -XCPP -v0 -fforce-recomp Prelude> :! echo '#include "A.hs-inc"' > A.hs Prelude> :! echo 'a = True' > A.hs-inc Prelude> :l A *Main> a True *Main> :! echo 'a = False' > A.hs-inc *Main> :r *Main> a True *Main> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8526> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 22 Nov '13

22 Nov '13

#5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------ Reporter: igloo | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3658 | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: 7.8.1 => 7.10.1 Comment: I've temporarily fixed this in HEAD by lowering the unfolding threshold for the stage2 build on windows. We're still extremely close to the symbol limit, but it should stay OK for 7.8. I'm leaving this highest priority and bumping to 7.10.1 - we must find a better fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8551: Fix formatting in docs at one place
by GHC 22 Nov '13

22 Nov '13

#8551: Fix formatting in docs at one place ------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- See to-be-attached patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8551> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr
by GHC 22 Nov '13

22 Nov '13

#8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr ----------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: patch | Operating System: Unknown/Multiple Architecture: arm | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------------- Numerous ghci tests in the testsuite currently fail on ARM due to the lack of a `mkJumpToAddr` definition. These failures look like, {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130927 for arm-unknown-linux): mkJumpToAddr not defined for ArchARM {armISA = ARMv7, armISAExt = FPv3,NEON], armABI = HARD} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} As it turns out `mkJumpToAddr` is fairly straightforward to implement. I've done this in https://github.com/bgamari/ghc/tree/arm. This brings the number of unexpected failures in `tests/ghci` from 44 to 4. These four failures are segmentation faults that I need to look more closely at. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8380> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #5013: sporadic failures during compilation under solaris
by GHC 22 Nov '13

22 Nov '13

#5013: sporadic failures during compilation under solaris ----------------------------------+--------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.4 Resolution: worksforme | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Changes (by maeder): * status: new => closed * resolution: => worksforme Comment: This change improved the situation for me. I did not observe the failure again for a patched ghc-6.8.3, but also only twice for the original ghc-6.8.2 (running 400 test compilations each). I don't know if the change makes a difference for other architectures. At least others may find a solution if they observe a similar behavior. Therefore I close this ticket now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5013#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8533: Extend new getPhysicalMemorySize ifdef to ios_HOST_OS
by GHC 22 Nov '13

22 Nov '13

#8533: Extend new getPhysicalMemorySize ifdef to ios_HOST_OS -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Other Architecture: arm | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- A very tiny patch to extend thoughtpoice's recent commit "Fix getPhysicalMemorySize on OS X (#8481)" to extend the ifdef to ios_HOST_OS, which also requires the fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8533> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2