January 2015 - ghc-tickets

[GHC] #9969: panic in T7562
by GHC 07 Jan '16

07 Jan '16

#9969: panic in T7562 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: T7562 | Blocked By: Blocking: | Related Tickets: #7562 Differential Revisions: | -------------------------------------+------------------------------------- Various people observe this test failure: {{{ =====> T7562(normal) 869 of 4389 [0, 0, 0] cd ./typecheck/should_compile && '/home/jojo/build/haskell/ghc- validate/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci- history -c T7562.hs -fno-warn-incomplete-patterns >T7562.comp.stderr 2>&1 Compile failed (status 256) errors were: T7562.hs:3:14: Warning: UNPACK pragma lacks '!' on the first argument of ‘Pair2’ In the definition of data constructor ‘Pair2’ In the data declaration for ‘Pair2’ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150108 for x86_64-unknown-linux): toIfaceBang Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} According to my logs, this was caused by changeset:9564bb8c84cbc0397a414e946cc8c28801f0fbe7/ghc -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9969> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9960: Performance problem with TrieMap
by GHC 07 Jan '16

07 Jan '16

#9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Looking at #9805 reminded me. When investigating the performance of #9872 I found a major performance hole in `TrieMap`. Suppose we have a handful H of entries in a `TrieMap`, each with a very large key, size K. If you fold over such a `TrieMap` you'd expect time O(H). That would certainly be true of an association list! But with `TrieMap` we actually have to navigate down a long singleton structure to get to the elements, so it takes time O(K*H). This is pretty bad. In test `T9872` I found that 90% of compile time was spent in `TrieMap` as we repeatedly built, folded, and then rebuilt `TrieMap`s. I fixed that by keeping smaller `TrieMap`s, but the underlying problem remains. The point of a `TrieMap` is that you need to navigate to the point where only one key remains, and then things should be fast. So I think that `TypeMap`, say, should look like {{{ data TypeMap a = EmptyTM | SingletonTM Type a | TM { tm_var :: VarMap a , tm_app :: TypeMap (TypeMap a) , tm_fun :: TypeMap (TypeMap a) , tm_tc_app :: NameEnv (ListMap TypeMap a) , tm_forall :: TypeMap (BndrMap a) , tm_tylit :: TyLitMap a } }}} The `SingletonTM` means that, once you are down to a single (key,value) pair, you stop and just use `SingletonTM`. Tiresomely, because of the deBruijn thing, it'd need to be {{{ ... | SingletonTM (CMEnv, Type) a ... }}} and we'd need an auxiliary function for equality: {{{ eqTypeModuloDeBruijn :: (CMEnv, Type) -> (CEnv, Type) -> Bool }}} But that's not hard. Very similar to the way `RnEnv2` works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9960> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults
by GHC 07 Jan '16

07 Jan '16

#8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults -------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------+------------------------------------- I built ghc-7.8.1 RC2 on ppc Fedora 21 Development with ghc-7.6.3. When I try to run dynamically linked "helloworld", it segfaults. I don't have direct access yet to a ppc box to investigate further. I guess something about the use of shared libraries on ppc is not working properly. {{{ $ cat > hello.hs main = putStrLn "hi" $ ghc -dynamic hello.hs $ ./hello Segmentation fault (core dumped) ./hello }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8909> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8652: Cross-compiling broken for ARM/Linux target
by GHC 07 Jan '16

07 Jan '16

#8652: Cross-compiling broken for ARM/Linux target ----------------------------+---------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------------- I've attempted to cross compile GHC HEAD on Ubuntu 13.10 with ubuntu's hard-float tool-chain and LLVM. I've configured GHC with: {{{ $ ./configure --target=arm-linux-gnueabihf }}} and compiling by make works till it fails with: {{{ inplace/bin/deriveConstants --gen-header -o includes/dist- derivedconstants/header/DerivedConstants.h --tmpdir includes/dist- derivedconstants/header/ --gcc-program "/usr/bin/gcc" --gcc-flag -fno- stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc- flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/dist- ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "/usr/bin/arm-linux-gnueabihf-nm" /usr/bin/arm-linux-gnueabihf-nm: includes/dist- derivedconstants/header/tmp.o: File format not recognized deriveConstants: readProcess: /usr/bin/arm-linux-gnueabihf-nm "includes /dist-derivedconstants/header/tmp.o" (exit 1): failed make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1 }}} As a workaround for this issue, it's possible to use --with-gcc= and this way deriveConstants gets the right cross GCC. Looks like a bug somewhere in make machinery or configure itself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8652> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122
by GHC 05 Jan '16

05 Jan '16

#8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This may be an artifact of issue #8128 (see https://ghc.haskell.org/trac/ghc/ticket/8128#comment:5) but I'm seeing examples involving data kinds where Typeable isn't deducible. This could be an artifact of other problems, BUT since with 7.7 onwards, we have baked in polykinded Typeable, things should always "just work™" right? the error with current head is as follows (and i'm attaching the code + current finger print too) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8560> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9968: DeriveAnyClass fails on multi-parameter type classes
by GHC 05 Jan '16

05 Jan '16

#9968: DeriveAnyClass fails on multi-parameter type classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE DeriveAnyClass, MultiParamTypeClasses #-} module Bug where class C a b data X deriving (C Int) }}} and load that into GHCi, I see this: {{{ *Main> :load "/Users/rae/temp/DeriveAny.hs" [1 of 1] Compiling Bug ( /Users/rae/temp/DeriveAny.hs, interpreted ) Var/Type length mismatch: [b_a2YW] [] Var/Type length mismatch: [b_a2YW] [] Ok, modules loaded: Bug. *Bug> :info C class C a b -- Defined at /Users/rae/temp/DeriveAny.hs:5:1 instance C X -- Defined at /Users/rae/temp/DeriveAny.hs:7:13 }}} It seems my `Int` parameter to `C` is being dropped. I don't believe I have a debug build in this example, so that debugging output is shipping. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9968> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10045: type holes related ghc panic
by GHC 04 Jan '16

04 Jan '16

#10045: type holes related ghc panic -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ sample.hs:9:13: Couldn't match expected type ‘t’ with actual type ‘()’ ‘t’ is untouchable inside the constraints () bound by the inferred type of foo :: Meta -> t1 at sample.hs:(6,1)-(9,17)ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.0 for x86_64-unknown-linux): No skolem info: t_avJ[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug sample.hs: module Blah where newtype Meta = Meta () foo (Meta ws1) = let copy :: _ copy w from = copy w 1 in copy ws1 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10045> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9590: AMP breaks `haskell2010` package
by GHC 02 Jan '16

02 Jan '16

#9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: | Version: 7.9 libraries/haskell2010 | Operating System: Keywords: AMP | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (and probably also `haskell98`) I hate to be the one pointing this out, but the AMP has one ugly side- effect. Consider the following session: ``` $ inplace/bin/ghc-stage2 --interactive -XHaskell2010 -hide-all-packages -package haskell2010 GHCi, version 7.9.20140914: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim-0.3.1.0 ... linking ... done. Loading package integer-gmp-0.5.1.0 ... linking ... done. Loading package base-4.8.0.0 ... linking ... done. Loading package array-0.5.0.1 ... linking ... done. Loading package haskell2010-1.1.2.1 ... linking ... done. λ:2> data Identity a = Identity a data Identity a = Identity a λ:3> instance Monad Identity <interactive>:3:10: No instance for (base-4.8.0.0:GHC.Base.Applicative Identity) arising from the superclasses of an instance declaration In the instance declaration for ‘Monad Identity’ λ:4> :info Monad class base-4.8.0.0:GHC.Base.Applicative m => Monad (m :: * -> *) where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a fail :: String -> m a -- Defined in ‘base-4.8.0.0:GHC.Base’ instance Monad (Either e) -- Defined in ‘base-4.8.0.0:Data.Either’ instance Monad Maybe -- Defined in ‘base-4.8.0.0:Data.Maybe’ instance Monad [] -- Defined in ‘base-4.8.0.0:GHC.Base’ instance Monad IO -- Defined in ‘base-4.8.0.0:GHC.Base’ instance Monad ((->) r) -- Defined in ‘base-4.8.0.0:GHC.Base’ λ:5> ``` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9590> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #8182: Parser.y.pp needs special treatment with -fcmm-sink
by GHC 31 Dec '15

31 Dec '15

#8182: Parser.y.pp needs special treatment with -fcmm-sink ------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This bug is really more of a reminder, but it's critical for the 7.8.1 release. Right now, `Parser.y.pp` uses a very weird hack to pass `-fcmm-sink` to the compiler. Here's the relevant comment: {{{ -- CPP tricks because we want the directives in the output of the -- first CPP pass. -- -- Clang note, 6/17/2013 by aseipp: It is *extremely* important (for -- some reason) that there be a line of whitespace between the two -- definitions here, and the subsequent use of __IF_GHC_77__ - this -- seems to be a bug in clang or something, where having the line of -- whitespace will make the preprocessor correctly format the rendered -- lines in the 'two step' CPP pass. No, this is not a joke. #define __IF_GHC_77__ #if __GLASGOW_HASKELL__ >= 707 #define __ENDIF__ #endif __IF_GHC_77__ -- Required on x86 to avoid the register allocator running out of -- stack slots when compiling this module with -fPIC -dynamic. {-# OPTIONS_GHC -fcmm-sink #-} __ENDIF__ }}} This is because the parser is first preprocessed before being run with GHC (which again preprocesses,) so we want the resulting `#ifdef` in the final `.hs` file. Things to note: * We really shouldn't be doing this, it's amazingly fragile. I think the correct thing to do is to ensure the build system correctly passes `-fcmm- sink` during the stage[2,3] build. * `./configure.ac` needs to check to see if the bootstrapping compiler is `ghc >= 7.7` (or `7.8`) and if it is, ''also'' pass `-fcmm-sink` during the stage1 build. * This hack needs to be removed once we can rely on >= 7.8 for bootstrap. Probably something like the hypothetical 7.12-7.14 timeframe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8182> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9734: Provide macro __GLASGOW_HASKELL_TH__
by GHC 31 Dec '15

31 Dec '15

#9734: Provide macro __GLASGOW_HASKELL_TH__ -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The Debian packaging added a few hacks to create a CPP macro that can be used to distinguish compilers with Template Haskell support from those that don’t have that support. We need this to compiler some code on non- TH architectures. It works, but we found that we cannot upstream such patches, which is a shame. I propose that among the GHC-defined macros listed at https://www.haskell.org/ghc/docs/latest/html/users_guide/options- phases.html#c-pre-processor there is also `__GLASGOW_HASKELL_TH__=YES`, which is available if the compiler supports splices, or ``__GLASGOW_HASKELL_TH__=NO` if not. (I propose a two-valued comparison so that library authors can decide themselves what the default should be if this symbol is not defined, some might want to use TH on older compilers, some not.) I hope this can be part of 7.10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9734> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6