September 2016 - ghc-tickets

[GHC] #11629: reify returns Dec that use ConT instead of PromotedT
by GHC 29 Nov '16

29 Nov '16

#11629: reify returns Dec that use ConT instead of PromotedT -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | 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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11629> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9007: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object
by GHC 29 Nov '16

29 Nov '16

#9007: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object ----------------------------------+---------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- Building HEAD on Debian wheezy with the Debian packaging setup fails: {{{ configure: Building in-tree ghc-pwd /usr/bin/ld: utils/ghc-pwd/dist-boot/Main.o: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object; recompile with -fPIC utils/ghc-pwd/dist-boot/Main.o: could not read symbols: Bad value collect2: error: ld returned 1 exit status configure: error: Building ghc-pwd failed }}} http://deb.haskell.org/dailies/2014-04-16/ghc_7.9.20140416-0.daily_amd64.bu… This is possibly related to the Hardening flags added by Debian: {{{ ~ $ dpkg-buildflags --get LDFLAGS -Wl,-z,relro ~ $ dpkg-buildflags --get CFLAGS -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror =format-security }}} Other related bug might be #3668 and https://bugs.debian.org/712228 I’ll disable the hardening flags and see if it helps. The error first occurred 2014-03-27. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9007> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #11656: Alllow static pointers to local closed definitions
by GHC 29 Nov '16

29 Nov '16

#11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- A limitation of the original patch implementing `-XStaticPointers` is that while the following all work, {{{#!hs t1 = static not t2 = static (\x -> case x of True -> False; False -> True) }}} the below does not: {{{#!hs t3 = static foo where foo True = False }}} Yet `foo` is perfectly "static": it's a closed expression that can readily be floated to top-level. So in short: `-XStaticPointers` should not consider only expressions with top-level identifiers, but in general any closed expression (which may involve local closed identifiers too). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11656> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #12558: GHCi Segmentation fault/access violation in generated code
by GHC 28 Nov '16

28 Nov '16

#12558: GHCi Segmentation fault/access violation in generated code ------------------------------+------------------------------- Reporter: lazac | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------+------------------------------- GHCi crashes with the error message `Segmentation fault/access violation in generated code`. The problem arises when trying to use the [https://github.com/haskell-tools/haskell-tools Haskell Tools project] from GHCi. The program can be successfully compiled with the ghc compiler. The cause of this behavior is that there are elements thats type is computed by a type family application. When I changed the representation to eliminate these, the problem was gone. I can turn the problem on and off only by adding an import or removing it. To solve the problem simply comment out the modules that use the information with the complex calculated type, as done in the attached diff. To try out use a minimal program: {{{#!hs module Main where import Language.Haskell.Tools.Refactor main = demoRefactor "" "." "A" }}} Execute the `ghci -package ghc -isrc\ast;src\ast-ghc;sr c\ast-trf;src\ast-ppr;src\ast-gen;src\refactor;src Main` command from the project root. That will search for a simple `A.hs` file in the working directory. A minimalistic module is enough to trigger the problem: {{{#!hs module A where }}} PS: I tried to create a smaller example, but the problem just appears and disappears without "reason" when I try to modify the code. (For example importing a module that is not actually used.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12558> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial
by GHC 25 Nov '16

25 Nov '16

#11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- Look at `CoreUtils.exprIsTrivial` and `CorePrep.cpe_ExprIsTrivial`. They are identical! The latter has a comment saying {{{ cpe_ExprIsTrivial :: CoreExpr -> Bool -- Version that doesn't consider an scc annotation to be trivial. }}} but the code does not treat ticks any differently. So the question is: '''are they supposed to be different'''? And if not, can we just combine them? Peter W, Simon M: this is your territory. I don't understand tick stuff well enough. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11158> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #12526: regression in type inference with respect to type families
by GHC 25 Nov '16

25 Nov '16

#12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following bug is present in ghc-8.0.1.20160725, ghc-8.0.1.20160822 (ghc-8.0.2) and ghc-8.1.20160819 (ghc-head) and was not there in ghc-8.0.1. When compiling the head version of synthesizer-llvm package from http://code.haskell.org/synthesizer/llvm/ I get the following error: {{{ src/Synthesizer/LLVM/Server/CausalPacked/Instrument.hs:296:23: error: • Couldn't match type ‘Synthesizer.Causal.Class.ProcessOf t0’ with ‘CausalP.T (SampleRate Real, ())’ Expected type: CausalP.T (SampleRate Real, ()) (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float)), (Serial.Value (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Real, VectorValue)) (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float))) Actual type: Synthesizer.Causal.Class.ProcessOf t0 (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float)), (Serial.Value (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float, Serial.Value (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float)) (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float))) The type variable ‘t0’ is ambiguous • In the first argument of ‘($&)’, namely ‘osci’ In the second argument of ‘liftA2’, namely ‘(osci $& shapeCtrl &|& (expo &|& fmap Stereo.left freqs))’ In the expression: liftA2 Stereo.cons (osci $& shapeCtrl &|& (expo &|& fmap Stereo.left freqs)) (osci $& shapeCtrl &|& (negate expo &|& fmap Stereo.right freqs)) • Relevant bindings include osci :: Synthesizer.Causal.Class.ProcessOf t0 (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float)), (Serial.Value (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float, Serial.Value (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float)) (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float))) (bound at src/Synthesizer/LLVM/Server/CausalPacked/Instrument.hs:294:19) }}} The type for `t0` should be known and then the type checker should be able to check that `ProcessOf t0` equals `CausalP.T`. It did so in earlier versions but now fails on that part. I still have to reduce that example, but for now I want to alert you that there seems to be a regression in the type inference. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12526> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12538: Incorrect uses of overlapping instances and data families sends GHC into loop
by GHC 25 Nov '16

25 Nov '16

#12538: Incorrect uses of overlapping instances and data families sends GHC into loop -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- Sorry for the lack of descriptive title, as I can't nail down the source of this specific bug. This is the minimal example to trigger the loop: {{{#!hs {-# LANGUAGE CPP #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module Main where import GHC.TypeLits import GHC.Types data Tagged t a = Tagged a type family Tag a where Tag (Tagged t a) = Tagged t a Tag a = Tagged Int a class (r ~ Tag a) => TagImpl a r | a -> r where tag :: a -> r instance {-# OVERLAPPING #-} (r ~ Tag (Tagged t a)) => TagImpl (Tagged t a) r where tag = id #ifdef WRONG instance {-# OVERLAPPING #-} (r ~ Tagged t a, r ~ Tag a) => TagImpl a r where #else instance {-# OVERLAPPING #-} (r ~ Tagged Int a, r ~ Tag a) => TagImpl a r where #endif tag = Tagged @Int data family DF x data instance DF (Tagged t a) = DF (Tagged t a) class ToDF a b | a -> b where df :: a -> b #ifdef WRONG instance (TagImpl a a', b ~ DF a') => ToDF a b where #else instance (TagImpl a (Tagged t a'), b ~ DF (Tagged t a')) => ToDF a b where #endif df = DF . tag main :: IO () main = pure () }}} When compiled with `-DWRONG`, it causes GHC (both 8.0.1 and HEAD@20160823) to loop: {{{ $ ghc --version && ghc -fno-code Main.hs -DWRONG The Glorious Glasgow Haskell Compilation System, version 8.1.20160823 [1 of 1] Compiling Main ( Main.hs, nothing ) (loops indefinitely...) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12538> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11575: Program crashes only when compiled via LLVM
by GHC 23 Nov '16

23 Nov '16

#11575: Program crashes only when compiled via LLVM --------------------------------------+---------------------------------- Reporter: Guest00000 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 7.10.3 Keywords: llvm | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- `llvm-test.hs`: {{{#!hs import System.IO import Foreign.Storable import Foreign.Marshal.Alloc import Data.Word main = do hSetBuffering stdout NoBuffering test 1000 test 5000 where test n = do allocaBytes (n * 4) $ \p -> do sequence_ [ pokeByteOff p (i * 4) (0x12345678 :: Word32) | i <- [ 0 .. n - 1 ] ] putStrLn $ show n ++ " fine" }}} ---- Cygwin shell: {{{ user@pc ~ $ ghc llvm-test.hs && ./llvm-test.exe [1 of 1] Compiling Main ( llvm-test.hs, llvm-test.o ) Linking llvm-test.exe ... 1000 fine 5000 fine user@pc ~ $ touch llvm-test.hs user@pc ~ $ ghc llvm-test.hs -fllvm && ./llvm-test.exe [1 of 1] Compiling Main ( llvm-test.hs, llvm-test.o ) Linking llvm-test.exe ... 1000 fine Segmentation fault }}} ---- {{{ <erikd> `Guest00000: try adding -O2 to the compiler command line. <`Guest00000> erikd: it now segfaults even before printing "1000 fine" <`Guest00000> wait, one time it printed one character "1" before crashing }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11575> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8300: split-objs doesn't split on LLVM
by GHC 22 Nov '16

22 Nov '16

#8300: split-objs doesn't split on LLVM ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | 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: | ------------------------------------+------------------------------------- `-split-objs` is allowed with `-fllvm`, but it doesn't really do anything. E.g. in my perf-llvm build I have a `libHSbase-4.7.0.0.a` with `Applicative__1.o`, `Arrow__1.o` etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8300> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12024: GHC leaks GHC.Prim.~# into type
by GHC 21 Nov '16

21 Nov '16

#12024: GHC leaks GHC.Prim.~# into type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | 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: -------------------------------------+------------------------------------- {{{#!hs data A a where X :: A [xxx] pattern X' = X }}} the inferred type of which is {{{ >>> :info X' pattern X' :: () => t GHC.Prim.~# [xxx] => A t }}} Casts use unlifted equality as I understand it, but lifted would present a nicer UI: {{{#!hs pattern X' :: () => t ~> [xxx] => A t pattern X' = X }}} In my own code this means I get the following monster {{{#!hs pattern MkArr :: () => (GetTy a, GetTy b, GetTy t, a GHC.Prim.~# 'Sca ('Number 'I32), b GHC.Prim.~# 'Sca a1, t GHC.Prim.~# 'Arr a1, GetSca a1) => Exp a -> Id -> Exp b -> Exp t }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12024> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6