January 2016 - ghc-tickets

[GHC] #10969: Arm: Investigate Thumb2/Arm interworking
by GHC 13 Jan '16

13 Jan '16

#10969: Arm: Investigate Thumb2/Arm interworking -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: arm, thumb | Operating System: Unknown/Multiple Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #10375 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Arm (32 bit) has two commonly used instruction sets; Thumb2 and Arm. The former is encoded in two bytes per instruction and the latter in four bytes. The CPU also has a bit in the flags register specifyng which code execution mode the CPU is currently in. The important thing to note is that executing Arm code when in Thumb2 mode (or vice versa) will sooner or later result in an illegal insruction or segfault. During debugging of #10375, I found that Haskell code compiled via the LLVM backend was generating Arm instructions, while C code compiled via GCC was generating Thumb2 code. When object code from these two paths are linked by the system linker everything is fine because the system linker knows how to link Thumb code to Arm code to produce a valid binary. The problem in #10375 was that in GHCi, the runtime linker was loading object files without the correct fixups between Thumb2 and Arm so that Thumb2 code in the `StgRun` function was jumping correctly into Arm code in the loaded object and returning to the Thumb2 code in `StgRun` while still in Arm execution mode and then crashing. In commit [changeset:"933adc0f31164cb651d11ecfcfe612ac429f714f/ghc" 933adc0f/ghc] I fixed GHCi for Arm by forcing GHC to generate only Arm code. As discussed in the associated Phab:D1323 it would be nice to investigate this further to see if its possible to make GHC generate Thumb2 code (which potentially has some performance benefits since it encodes all instructions in two bytes) and/or fix Thumb2/Arm interop. However, that interop may not be possible. In one of the comments in the Phab:D1323, @bgamari said: > That being said, I don't think we'll ever be able to support linking of Thumb Haskell code with ARM Haskell code. The reason for this is that interop requires the use of a trampoline, which breaks tables-next-to- code. Two possible outcomes for this ticket are: * We somehow get proper Thumb2/Arm code interoperation working. * We decide that interop is too difficult or not worthwhile and a) document this somewhere in the code and b) remove the Thumb2 relocation code in `rts/Linker.c` and all other references to Thumb2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10969> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

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

13 Jan '16

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving-perf 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

13 Jan '16

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving-perf 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by wilx): * cc: vhaisman@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10968: Type hole cause bad type checking
by GHC 12 Jan '16

12 Jan '16

#10968: Type hole cause bad type checking -------------------------------------+------------------------------------- Reporter: ndtimofeev | 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: -------------------------------------+------------------------------------- I've tried to compile that incorrect code on ghc-7.10.2 linux x86_64: {{{#!hs import Control.Monad.Reader type Tst m = ReaderT () (ReaderT Int m) f :: Monad m => Tst m () f = return () f1 :: ReaderT () m () -> ReaderT () m () f1 ev = f >> _ >> ev main :: IO () main = print $ runReaderT (f1 (return ())) () }}} But тypechecker does not reject f1 and have that: {{{ [1 of 1] Compiling Main ( /home/ndtimofeev/tst.hs, /home/ndtimofeev/tst.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): StgCmmEnv: variable not found $dFunctor_aYS local binds for: f_rsZ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} If switch hole to undefined, i have normal typechecking error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10968> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #4220: EmptyDataDecls + DeriveFunctor == Panic!
by GHC 12 Jan '16

12 Jan '16

#4220: EmptyDataDecls + DeriveFunctor == Panic! -------------------------------------+------------------------------------- Reporter: conal | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.0.1 Component: Compiler | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | deriving/should_compile/T4220 Blocked By: | Blocking: Related Tickets: #4302 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #4302 Comment: commit 6efa3901fd6f1583fb654bd3659e88702dfd579a {{{ Author: simonpj(a)microsoft.com <unknown> Date: Thu Aug 12 13:13:19 2010 +0000 Fix Trac #4220 For deriving Functor, Foldable, Traversable with empty data cons I just generate a null equation f _ = error "urk" There are probably more lurking (eg Enum) but this will do for now. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4220#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4302: Impossible when deriving empty data declaration
by GHC 12 Jan '16

12 Jan '16

#4302: Impossible when deriving empty data declaration -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.4.1 Component: Compiler | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: | deriving/should_compile/T4302 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): commit 2fc5aa708982a414235d3aff68dea4329b546063 {{{ Author: simonpj(a)microsoft.com <unknown> Date: Mon Sep 13 17:03:55 2010 +0000 Fix Trac #4302, plus a little refactoring }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4302#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h"
by GHC 12 Jan '16

12 Jan '16

#8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): This has also come up in the `shaking-up-ghc`[1] project, when trying to move the build products out of the source tree[2]. ---- [1]: https://github.com/snowleopard/shaking-up-ghc [2]: https://github.com/snowleopard/shaking-up-ghc/issues/113 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8040#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11411: GHC allows you to quantify variables over TYPE 'Unlifted (a.k.a, #)
by GHC 12 Jan '16

12 Jan '16

#11411: GHC allows you to quantify variables over TYPE 'Unlifted (a.k.a, #) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This should be disallowed, so [https://phabricator.haskell.org/D1757 sayeth goldfire]: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20160109: http://www.haskell.org/ghc/ :? for help λ> :set -XKindSignatures λ> import GHC.Types λ> data Wat (a :: TYPE 'Unlifted) = Wat a λ> :i Wat data Wat (a :: #) = Wat a -- Defined at <interactive>:3:1 λ> :set -XMagicHash λ> :t Wat 1# Wat 1# :: Wat GHC.Prim.Int# λ> :t Wat 'a'# Wat 'a'# :: Wat GHC.Prim.Char# }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11411> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11360: Test "termination" doesn't pass with reversed uniques
by GHC 11 Jan '16

11 Jan '16

#11360: Test "termination" doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- It fails with (full trace https://phabricator.haskell.org/P80) {{{ *** Core Lint errors : in result of Tidy Core *** <no location info>: warning: In the expression: ReplaceApply @ k_a18o1Q @ (Apply t1_X18o1T t2_X18o1O) @ n_a18o1O @ (Apply r1_X18o1Q r2_X18o1M) @ r2_X18o1M @ t2_X18o1O @ r1_X18o1Q @ t1_X18o1T @~ (<Apply t1_X18o1T t2_X18o1O>_N :: Apply t1_X18o1T t2_X18o1O ~# Apply t1_X18o1T t2_X18o1O) @~ (<Apply r1_X18o1Q r2_X18o1M>_N :: Apply r1_X18o1Q r2_X18o1M ~# Apply r1_X18o1Q r2_X18o1M) dt_a18nR6 dt_a18nR5 Argument value doesn't match argument type: Fun type: (Apply r1_X18o1Q t2_X18o1O ~# Apply t1_X18o1T t2_X18o1O, Apply r1_X18o1Q r2_X18o1M ~# Apply r1_X18o1Q r2_X18o1M) => Replace k_a18o1Q t1_X18o1T n_a18o1O r1_X18o1Q -> Replace k_a18o1Q t2_X18o1O n_a18o1O r2_X18o1M -> Replace k_a18o1Q (Apply r1_X18o1Q t2_X18o1O) n_a18o1O (Apply r1_X18o1Q r2_X18o1M) Arg type: Apply t1_X18o1T t2_X18o1O ~# Apply t1_X18o1T t2_X18o1O Arg: CO: <Apply t1_X18o1T t2_X18o1O>_N }}} Steps to reproduce: 1. Add line `TEST_HC_OPTS += -dinitial-unique=16777000 -dunique-increment=-1` after line `TEST_HC_OPTS = -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-$(GhcPackageDbFlag) -rtsopts $(EXTRA_HC_OPTS)` in `mk/test.mk` 2. `make TESTS=termination` I suspect this is the same problem I'm running at https://mail.haskell.org/pipermail/ghc-devs/2016-January/010902.html, since the same change to `substTyWith` makes the test pass for me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11360> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11387: Typecasting using type application syntax
by GHC 11 Jan '16

11 Jan '16

#11387: Typecasting using type application syntax -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11350 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I created #11350 to allow visible (static) type applications in patterns. I had a [https://ghc.haskell.org/trac/ghc/ticket/11350#comment:2 thought] about translating non-parametric type applications in patterns as a runtime type check (`Typeable`) and decided to create a ticket in case it made any sense. Example: {{{#!hs doubleWhenInt :: forall a. Typeable a => a -> a doubleWhenInt x = case eqT @Int @a of Just Refl -> x + x Nothing -> x -- Becomes… doubleWhenInt :: Typeable a => a -> a doubleWhenInt @Int n = n + n doubleWhenInt @_ x = x }}} Thoughts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11387> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3