October 2015 - ghc-tickets

Re: [GHC] #7830: Error: operand out of range
by GHC 22 Oct '15

22 Oct '15

#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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] #10934: Iface type variable out of scope
by GHC 22 Oct '15

22 Oct '15

#10934: Iface type variable out of scope -------------------------------------+------------------------------------- Reporter: mjmrotek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: interface | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- I'm sorry for spamming code and not providing a distilled example, but honestly I have no idea how to even begin pinpointing this. I'm writing a library and hosting it on Github: https://github.com/marcinmrotek/pipes-key-value-csv which compiles fine, but when I try to compile the test suite, GHC crashes with this error message: {{{ /home/marcin/haskell/pipes-key-value-csv/.stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Pipes/KeyValueCsv/Internal/KeyValue.hi Declaration for $fFromKeyValuesf:3: Iface type variable out of scope: k Cannot continue after interface file error }}} when I uncomment the {{{#!hs . KV.foldHeader }}} line in https://github.com/marcinmrotek/pipes-key-value- csv/blob/master/test/Test/KeyValue.hs The thing is, this function does not even use the "FromKeyValues" type class mentioned - https://github.com/marcinmrotek/pipes-key-value- csv/blob/master/src/Pipes/KeyValueCsv/Internal/KeyValue.hs KV.parseLine, which does, compiles fine (the test suite runs and fails with "Prelude: undefined". They're both defined here: https://github.com/marcinmrotek/pipes-key-value- csv/blob/master/src/Pipes/KeyValueCsv/KeyValue.hs I've tried "stack clean", reinstalling both GHC and stack, installing my package globally with cabal-install (although I had to fix the validation-0.5.1 package by removing the Safe pragma; I've tried to use stack again, pointing it to the exact same code for validation-0.5.1, to no avail), the result is always the same - the library compiles, the test suite doesn't. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10934> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[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] #10966: dirtiness checking isn't keeping track of which source file contained Main
by GHC 21 Oct '15

21 Oct '15

#10966: dirtiness checking isn't keeping track of which source file contained Main -------------------------------------+------------------------------------- Reporter: gueux | 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: -------------------------------------+------------------------------------- See https://github.com/commercialhaskell/stack/issues/1127#issuecomment-1467811… for the description of the issue and https://gist.github.com/snoyberg/aa6ce5247f9a0d1b5f95 for a minimal example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10966> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[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

Re: [GHC] #602: Warning Suppression
by GHC 21 Oct '15

21 Oct '15

#602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | Design/LocalWarningPragmas | -------------------------------------+------------------------------------- Changes (by hvr): * wikipage: => Design/LocalWarningPragmas -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/602#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0