September 2015 - ghc-tickets

[GHC] #10747: Infix pattern synonyms fail to parse (regression)
by GHC 22 Oct '15

22 Oct '15

#10747: Infix pattern synonyms fail to parse (regression) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE PatternSynonyms #-} pattern head `Cons` tail = head : tail }}} In v7.11 I get: {{{ [1 of 1] Compiling Main ( pat.hs, interpreted ) pat.hs:2:14: parse error on input ?`? }}} In v7.10 I get: {{{ *Main> :set -XPatternSynonyms *Main> let h `Cons` t = "ht" *Main> h 'h' *Main> t "t" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10747> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10149: The argument of mask does not always restore the masking state
by GHC 22 Oct '15

22 Oct '15

#10149: The argument of mask does not always restore the masking state -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In the documentation of `mask` and `uninterruptibleMask` it is claimed that the `restore` argument restores the masking state. However this is not true in the following programs: {{{#!hs mask_ $ -- start with exceptions masked mask $ \restore -> forkIOWithUnmask $ \unmask -> unmask $ restore $ getMaskingState >>= print }}} {{{#!hs uninterruptibleMask_ $ -- start with exceptions uninterruptibly masked uninterruptibleMask $ \restore -> forkIOWithUnmask $ \unmask -> unmask $ restore $ getMaskingState >>= print }}} The expected state is that `getMaskingState` would produce `MaskedInterruptible` and `MaskedUninterruptible`, however, in both cases it gives Unmasked. Either the documentation needs to be changed, or the implementation must really restore the masking state in these cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10498: "if ... then \case -> else ..." causes a "missing else clause" error
by GHC 22 Oct '15

22 Oct '15

#10498: "if ... then \case -> else ..." causes a "missing else clause" error -------------------------------------+------------------------------------- Reporter: | Owner: dramforever | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple (Parser) | Type of failure: Other Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following program: {{{#!hs {-# LANGUAGE LambdaCase #-} foo = if True then \case -> 1 -> 2 else id }}} Produces this message: {{{ problem.hs:4:5: parse error in if statement: missing required else clause }}} The problem in the code is that there's a -> after the \case. I don't know if a better error message can be generated, but this one is really unhelpful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10498> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10375: arm: ghci.debugger tests hit illegal instruction
by GHC 22 Oct '15

22 Oct '15

#10375: arm: ghci.debugger tests hit illegal instruction ---------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------+------------------------------------- Some GHCi tests on arm/linux ie: {{{ (cd testsuite ; make TEST="print018 print020 print021 print022 print025") }}} fail, all with the same error: {{{ Stderr: Illegal instruction }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10375> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 68

[GHC] #10829: Simplification in the RHS of rules
by GHC 22 Oct '15

22 Oct '15

#10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 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: 10528 Differential Revisions: | -------------------------------------+------------------------------------- HERMIT users depend on RULES to specify equational properties. 7.10.2 performed both inlining and simplification in both sides of the rules, meaning they can't really be used for this. This breaks most HERMIT use cases. Note that this behavior was a change from 7.8 and prior, due to this commit: https://git.haskell.org/ghc.git/commitdiff/8af219adb914b292d0f8c737fe0a1e3f… The following commit disables the inlining/simplification in the LHS of rules, which fixes half the problem, but it has yet to be merged and released (attached to ticket #10528): https://git.haskell.org/ghc.git/commitdiff/bc4b64ca5b99bff6b3d5051b57cb2bc5… This ticket is to ask that inlining/simplification also be disabled in the RHS of rules. As an example of what is happening, we are seeing rules like this: {{{ repH :: [a] -> [a] -> [a] {-# RULES "repH ++" [~] forall xs ys. repH (xs ++ ys) = repH xs . repH ys #-} }}} get to HERMIT as: {{{ "repH ++" forall xs ys. repH (xs ++ ys) = let f = repH xs g = repH ys in \ z -> f (g z) }}} In this case it is just an unfolding of composition, but some rules get rather gross on the RHS. The extra junk makes equational reasoning with these rules very fiddly and sort of breaks the correspondence with the source-level code. For instance, it is almost impossible to apply these right-to-left, which is a common thing to do when performing equational reasoning. Some possible solutions: 1. Don't inline/apply rules in the RHS at all (just like the LHS). 2. Don't inline/apply rules in the RHS of rules marked with the NeverActive notation (rules intended for HERMIT use are generally marked NeverActive). Since NeverActive rules are not applied by GHC anyway, this should actually save compile-time work and not affect real programs/rules. Would either of those be acceptable/possible? Option 1 would be ideal, because it would match the behavior of 7.8 (AFAICT). Option 2 would be sufficient, however. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10829> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type
by GHC 22 Oct '15

22 Oct '15

#10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type -----------------------------------+--------------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+--------------------------------------- ghc: internal error: scavenge: unimplemented/strange closure type 0 @ 0xac103240 (GHC version 7.10.1 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted I can consistently get either this crash, or a segfault from ghc, building git-annex on an arm system. Seems about 50/50. In either case, it crashes either before ghc has printed out any "Compiling" lines, or within the first 1 or 2 files compiled. I got lucky and found out a way to avoid the crash.. cabal was passing -j2 to ghc. If I remove the -j2, the build proceeds without a crash. The hardware is a CubieTruck arm board, with 2 gb of ram, and 1 cpu core, running Debian armel unstable, with kernel 3.4.103. I was able to use cabal to install the entire dependencies of git-annex, all the way up to yesod, which takes hours on this hardware, and all that built ok.. so I think the hardware is pretty stable, but still cannot really rule out a hardware problem. Happy to debug further, although this machine is a bit resource constrained to do things like building ghc on it. ghc 7.8.4 and 7.10.1 both crash the same way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10469> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10014: Data.Array.Base.elems needlessly calls bounds.
by GHC 21 Oct '15

21 Oct '15

#10014: Data.Array.Base.elems needlessly calls bounds. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Core | Operating System: Unknown/Multiple Libraries | Type of failure: Runtime Keywords: | performance bug Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ elems arr = case bounds arr of (_l, _u) -> [unsafeAt arr i | i <- [0 .. numElements arr - 1]] }}} It never uses the result. I'd propose simplifying it to {{{ elems arr = [unsafeAt arr i | i <- [0 .. numElements arr - 1]] }}} It appears at some point someone optimized it to use the `unsafeAt`, but never removed the bounds check. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10014> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10049: Lower level memcpy primop
by GHC 21 Oct '15

21 Oct '15

#10049: Lower level memcpy primop -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm doing some really low-level buffer stuff, and it would be quite helpful if there were lower-level memcpy primitives. I'm thinking something like: {{{#!hs copyBytes# :: Addr# -> Addr# -> Int# -> State# s -> State# s copyBytes dst src size _ = ... }}} I would expect it to compile, on x86, into "rep movsb", which is frequently optimal on Ivy Bridge and Haswell. The other memcpy primitives use Array# or MutableArray#, and it's not clear how, if all you have is an Addr#, how to get the corresponding Array# or MutableArray#. (Can you just cast?) It may be appropriate to have corresponding 16-bit and 32-bit operations; "rep movsw" and "rep movsd", respectively. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10049> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10494: Representational equalities over AppTys are not hard failures
by GHC 21 Oct '15

21 Oct '15

#10494: Representational equalities over AppTys are not hard failures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If I say {{{ module App where import Data.Coerce foo :: Coercible (a b) (c d) => a b -> c d foo = undefined }}} I get {{{ App.hs:5:8: error: Couldn't match representation of type ‘a b’ with that of ‘c d’ Inaccessible code in the type signature for: foo :: Coercible (a b) (c d) => a b -> c d In the ambiguity check for the type signature for ‘foo’: foo :: forall (a :: * -> *) b (c :: * -> *) d. Coercible (a b) (c d) => a b -> c d To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ‘foo’: foo :: Coercible (a b) (c d) => a b -> c d }}} This is very silly, indeed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10494> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10899: Polytype accepted in RHS of default associated type
by GHC 21 Oct '15

21 Oct '15

#10899: Polytype accepted in RHS of default associated type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.3 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 Revisions: | -------------------------------------+------------------------------------- This hogwash is accepted: {{{ class C a where type F a type F a = forall m. m a }}} I will fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10899> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4