March 2018 - ghc-tickets

[GHC] #14932: DeriveAnyClass produces unjustifiably untouchable unification variables
by GHC 29 Mar '18

29 Mar '18

#14932: DeriveAnyClass produces unjustifiably untouchable unification variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 (Type checker) | Keywords: deriving | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #13272 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code (courtesy of kosmikus) should typecheck, but does not: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module Zero where import GHC.Exts class Zero a where zero :: a default zero :: (Code a ~ '[xs], All Zero xs) => a zero = undefined type family All c xs :: Constraint where All c '[] = () All c (x : xs) = (c x, All c xs) type family Code (a :: *) :: [[*]] type instance Code B1 = '[ '[ ] ] data B1 = B1 deriving Zero }}} This produces the following error: {{{ GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /nfs/nfs7/home/rgscott/.ghci [1 of 1] Compiling Zero ( Bug.hs, interpreted ) Bug.hs:23:11: error: • Couldn't match type ‘xs0’ with ‘'[]’ arising from the 'deriving' clause of a data type declaration ‘xs0’ is untouchable inside the constraints: All Zero xs0 bound by the deriving clause for ‘Zero B1’ at Bug.hs:23:11-14 • When deriving the instance for (Zero B1) | 23 | deriving Zero | ^^^^ }}} This error is baffling, however, because `xs0` should be a unification variable that readily unifies with `'[]`! As evidence, this typechecks: {{{ instance Zero B1 }}} But the equivalent `deriving` clause does not. I know what is going on here after some sleuthing: `DeriveAnyClass` (specifically, `inferConstraintsDAC`) is producing unification variables whose TcLevel is always bumped to three. However, in the program above, we will not form an implication constraints around those unification variables, since `zero` has no locally quantified type variables or given constraints. Thus, `simplifyDeriv` will try to simplify unification variables with TcLevel 3 at the top level, which results in them being untouchable. Blegh. This was partially noticed in #13272, when we were failing to bump unification variables that //did// appear inside implication constraints. However, we overlooked this one corner case, which kosmikus happened to stumble upon in a `generics-sop` [https://stackoverflow.com/a/49335338/1482749 example]. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14932> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14905: GHCi segfaults with +RTS -Di after hitting a breakpoint
by GHC 29 Mar '18

29 Mar '18

#14905: GHCi segfaults with +RTS -Di after hitting a breakpoint -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.5 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: -------------------------------------+------------------------------------- Steps to reproduce: - Compile stage2 with `-debug` - Run GHCi with `+RTS -Di` - Load an interpreted module with a definition, set a breakpoint on the definition - Evaluate the definition GHCi crashes with a segfault. Backtrace: {{{ #0 0x00007ffff18bcaa9 in disInstr (bco=0x4200013f30, pc=1) at rts/Disassembler.c:71 #1 0x00007ffff18c89e9 in interpretBCO (cap=0x7ffff19431c0 <MainCapability>) at rts/Interpreter.c:986 #2 0x00007ffff18d19fe in schedule (initialCapability=0x7ffff19431c0 <MainCapability>, task=0x7fffe0000910) at rts/Schedule.c:471 #3 0x00007ffff18d4ee2 in scheduleWorker (cap=0x7ffff19431c0 <MainCapability>, task=0x7fffe0000910) at rts/Schedule.c:2553 #4 0x00007ffff18ccab8 in workerStart (task=0x7fffe0000910) at rts/Task.c:444 #5 0x00007ffff0c3c6ba in start_thread (arg=0x7fffee9aa700) at pthread_create.c:333 #6 0x00007ffff06f241d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 }}} in this line: {{{ 71 debugBelch(" %s\n", ((CostCentre*)(literals[instrs[pc+3]]))->label); }}} `literals[instrs[pc+3]]` is null. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14905> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14977: Clang doesn't support -Wsync-nand
by GHC 29 Mar '18

29 Mar '18

#14977: Clang doesn't support -Wsync-nand -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- 94f02547083cf6df686ea0b95fed050184c533de added a `#pragma GCC diagnostic ignored "-Wsync-nand"` pragma to `libraries/ghc-prim/cbits/atomic.c` to silence `-Werror` failures due to GCC's non-actionable `-Wsync-nand` warning. Unfortunately goldfire reports that Apple's Clang chokes on this with, {{{ libraries/ghc-prim/cbits/atomic.c:127:32: error: unknown warning group '-Wsync-nand', ignored [-Werror,-Wunknown-warning-option] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14977> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11)
by GHC 29 Mar '18

29 Mar '18

#13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) -------------------------------------+------------------------------------- Reporter: 2bdkid | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (LLVM) | Keywords: LLVM | Operating System: Linux Optimiser -11 | Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While building [https://hackage.haskell.org/package/unicode-transforms] it fails with: {{{ cabal: Entering directory '/tmp/cabal-tmp-7667/unicode-transforms-0.2.0' Configuring unicode-transforms-0.2.0... Building unicode-transforms-0.2.0... Preprocessing library unicode-transforms-0.2.0... [ 1 of 12] Compiling Data.Unicode.Properties.DecompositionsK ( Data/Unicode/Properties/DecompositionsK.hs, dist/build/Data/Unicode/Properties/DecompositionsK.o ) [ 2 of 12] Compiling Data.Unicode.Properties.Decompositions ( Data/Unicode/Properties/Decompositions.hs, dist/build/Data/Unicode/Properties/Decompositions.o ) [ 3 of 12] Compiling Data.Unicode.Properties.DecomposableK ( Data/Unicode/Properties/DecomposableK.hs, dist/build/Data/Unicode/Properties/DecomposableK.o ) `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) cabal: Leaving directory '/tmp/cabal-tmp-7667/unicode-transforms-0.2.0' }}} Other details: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.1 $ opt --version LLVM (http://llvm.org/) LLVM version 3.7.1 Optimized build. Default target: armv7l-unknown-linux-gnueabihf Host CPU: (unknown) }}} I already submitted an issue to the package's bug tracker, but it is believed to be a GHC bug: [https://github.com/harendra-kumar/unicode- transforms/issues/10] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13062> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14985: GHC flags missing from the user guide flag reference.
by GHC 29 Mar '18

29 Mar '18

#14985: GHC flags missing from the user guide flag reference. -------------------------------------+------------------------------------- Reporter: merijn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 was making a list of flags from the source of GHC command line parser and found the following flags having no entry in the flag reference: `-sig-of`, `-relative-dynlib-paths`, `-dll-split`, `-ddump-file-prefix`, `-haddock`, `-haddock-opts`, `-dno-llvm-mangler`, `-ffloat-lam-args`, `-ffloat-all-lams` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14985> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14266: AllowAmbiguousTypes doesn't play well with default class methods
by GHC 29 Mar '18

29 Mar '18

#14266: AllowAmbiguousTypes doesn't play well with default class methods -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- This example does compile, {{{ {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ExplicitForAll #-} class A t where f :: forall x m. Monoid x => t m -> m f = undefined instance A [] where f = undefined }}} and it seems that the following really ought to be equivalent to it, since all I have done is remove a method definition which is identical to the default: {{{ {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ExplicitForAll #-} class A t where f :: forall x m. Monoid x => t m -> m f = undefined instance A [] }}} But instead GHC 8.0.2 gives an error of "Could not deduce (Monoid x0)" on the instance declaration. (I've also posed the same question on stackoverflow: https://stackoverflow.com/q/46350839/402884.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14266> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

Re: [GHC] #4308: LLVM compiles Updates.cmm badly
by GHC 28 Mar '18

28 Mar '18

#4308: LLVM compiles Updates.cmm badly -------------------------------------+------------------------------------- Reporter: dterei | Owner: (none) Type: bug | Status: infoneeded Priority: low | Milestone: Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * status: new => infoneeded Comment: The current issue, live register tracking is not as good as we'd like, is a bit vague. Would it be possible to give an example of the problem? Also it is 6 years old. Should a new bug be opened and this one closed? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4308#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #855: Improvements to SpecConstr
by GHC 28 Mar '18

28 Mar '18

#855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): A quick update: `ex1` is optimized to similar code as above, but without resorting to forced `SPEC` now. E.g., inference of `ArgOcc`s is now much better, because it looks at occs from specialised RHSs now (specialising for lambdas gives rise to new occs). This entailed a rewrite of the spec loop. Also I had to pass on occs from recursive calls to achieve something like the static argument transformation. I'll write things up in a wiki page once I'm done trying to optimize `ex{2,3}`. This is the code currently generated for `ex1`: {{{ -- RHS size: {terms: 41, types: 23, coercions: 0, joins: 3/3} Main.$wex1 [InlPrag=NOINLINE] :: GHC.Prim.Int# -> GHC.Prim.Int# [GblId, Arity=1, Caf=NoCafRefs, Str=<S,U>, Unf=OtherCon []] Main.$wex1 = \ (ww_s4m8 :: GHC.Prim.Int#) -> joinrec { $s$wgo_s4or :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> Bool -> GHC.Prim.Int# [LclId[JoinId(4)], Arity=4, Str=<S,U><S,U><L,A><L,A>] $s$wgo_s4or (sc_s4oq :: GHC.Prim.Int#) (sc1_s4op :: GHC.Prim.Int#) _ [Occ=Dead] _ [Occ=Dead] = jump $s$wgo2_s4nk sc1_s4op sc_s4oq; $s$wgo1_s4o0 :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# [LclId[JoinId(3)], Arity=3, Str=<S,U><S,U><S,U>] $s$wgo1_s4o0 (sc_s4nZ :: GHC.Prim.Int#) (sc1_s4nY :: GHC.Prim.Int#) (sc2_s4nX :: GHC.Prim.Int#) = jump $s$wgo_s4or (GHC.Prim.+# sc2_s4nX sc_s4nZ) sc1_s4nY sc_s4nZ GHC.Types.False; $s$wgo2_s4nk [Occ=LoopBreaker] :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# [LclId[JoinId(2)], Arity=2, Str=<S,U><S,U>, Unf=OtherCon []] $s$wgo2_s4nk (sc_s4nj :: GHC.Prim.Int#) (sc1_s4ni :: GHC.Prim.Int#) = case GHC.Prim.<# sc_s4nj ww_s4m8 of { __DEFAULT -> sc1_s4ni; 1# -> jump $s$wgo1_s4o0 (GHC.Prim.*# sc_s4nj sc_s4nj) (GHC.Prim.+# sc_s4nj 1#) sc1_s4ni }; } in jump $s$wgo2_s4nk 1# 0# }}} `-flate-dmd-anal` gets rid of the superfluous `$s$wgo_s4or`, but what pass is responsible for contracting the recursive group into a single binding (by inlining until we hit the loopbreaker)? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/855#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14208: Performance with -O2 is worse than with -O0 which is worse than runghc
by GHC 28 Mar '18

28 Mar '18

#14208: Performance with -O2 is worse than with -O0 which is worse than runghc -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In this particular case `-O2` is 2x slower than `-O0` and `-O0` is 2x slower than `runghc`. Please see the github repo: https://github.com /harendra-kumar/ghc-perf to reproduce the issue. Readme file in the repo has instructions to reproduce. The issue seems to occur when the code is placed in a different module. When all the code is in the same module the problem does not occur. In that case `-O2` is faster than `-O0`. However, when the code is split into two modules the performance gets inverted. Also, it does not occur always, when I tried to change the code to make it simpler for repro the problem did not occur. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14208> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40

[GHC] #14775: GHC 8.4.1-alpha3 regression: Build error when `build-type: Custom` and `license: OtherLicense` are in the .cabal file
by GHC 27 Mar '18

27 Mar '18

#14775: GHC 8.4.1-alpha3 regression: Build error when `build-type: Custom` and `license: OtherLicense` are in the .cabal file -------------------------------------+------------------------------------- Reporter: asr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 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'm getting the following error when `build-type: Custom` and `license: OtherLicense` are in the .cabal file: `Foo.cabal`: {{{ name: Foo version: 0.1.0.0 license: OtherLicense build-type: Custom cabal-version: >=1.10 library exposed-modules: Foo build-depends: base default-language: Haskell2010 }}} `Foo.hs`: {{{#!hs module Foo where foo :: Int -> Int foo n = n }}} `Setup.hs`: {{{#!hs import Distribution.Simple main = defaultMain }}} The error: {{{ $ cabal install Failed to install Foo-0.1.0.0 cabal: Error: some packages failed to install: Foo-0.1.0.0-33ReQaKfqaD7MoDL7J5kFM failed during the final install step. The exception was: dieVerbatim: user error (cabal: Couldn't parse the output of 'setup register --gen-pkg-config':NoParse "license" 5 ) }}} `cabal-install` version: {{{ $ cabal --version cabal-install version 2.0.0.1 compiled using version 2.0.1.0 of the Cabal library }}} If I change the `license` field ''or'' the `build` field, the error disappeared. I didn't get the above error using GHC 8.4.1-alpha2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14775> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7