- ghc-tickets - Haskell.org

[GHC] #15492: Plugin recompilation check fails when profiling is enabled
by GHC 23 Aug '18

23 Aug '18

#15492: Plugin recompilation check fails when profiling is enabled -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- When compiling with profiling enabled and using a plugin, GHC will panic as follows: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.6.1.20180803 for x86_64-unknown-linux): mkPluginUsage: no dylibs GraphMod Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/deSugar/DsUsage.hs:178:15 in ghc:DsUsage }}} Investigating determines that the following paths are being inspected: {{{ /nix/store/m0ylnbifx5ba1qwi8vzipxq4p7ma3073-graphmod- plugin-0.1.0.0/lib/ghc-8.6.1.20180803/x86_64-linux-ghc-8.6.1.20180803 /libHSgraphmod-plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p- ghc8.6.1.20180803.so /nix/store/q8rg4mca5zqv98arpxd7164pqa72hf1n-ncurses-6.1/lib/libHSgraphmod- plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so /nix/store/hhzvw77vrmn5f506kfyb1yh1sdinkbwf-gmp-6.1.2/lib/libHSgraphmod- plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so }}} None of which exist. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15492> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections
by GHC 22 Aug '18

22 Aug '18

#7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 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 dfeuer): Let me take that back... What I thought I saw in the wild wasn't what I saw. Maybe nobody is taking advantage of that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7670#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections
by GHC 22 Aug '18

22 Aug '18

#7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 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 dfeuer): I've had more thoughts/details on garbage collection in the no-stable- name-table option. I don't think we actually need to store an underlying object pointer in an SNO at all. After running the collector (before compacting), traverse the keys and SNOs in the SN hash table to form the new one. If the key is dead, do nothing. If the SNO is dead, do nothing. If both have been evacuated, insert the new key and new SNO into the hash table for the next generation. The main remaining problem looks unfortunate, and has to do with `hashStableName#`. While that has never been documented as being injective, it actually ''is'' injective under certain circumstances, and indeed it appears that real code on Hackage relies on this (see, e.g., [http://hackage.haskell.org/package/stable-maps-0.0.5/docs/System-Mem- StableName-Map.html stable-maps]). In particular, the way it works now, we can implement a stable name map as `IntMap (StableName k, v)`. Because the map keeps the `StableName`s alive, their stable name table indices won't be reused. The only way to keep such code working is to make such a guarantee. That ''requires'' a way to allocate IDs uniquely. So we need a data structure that can keep track of which IDs are available and allocate them. Ugh. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7670#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families
by GHC 22 Aug '18

22 Aug '18

#14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- I've the following small example {{{ {-# LANGUAGE MagicHash, UnboxedSums, NoImplicitPrelude #-} {-# LANGUAGE TypeFamilies #-} -- {-# LANGUAGE PolyKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE GADTs ,ExplicitNamespaces#-} {-# LANGUAGE UnboxedTuples #-} module Data.Unboxed.Maybe where import GHC.Exts import GHC.Types import Prelude (undefined) import Data.Void data family Maybe(x :: TYPE (r :: RuntimeRep)) data instance Maybe (a :: * ) where MaybeSum :: (# a | (# #) #) -> Maybe a data instance Maybe (x :: TYPE 'UnliftedRep) where MaybeSumU :: (# x | (# #) #) -> Maybe x }}} and then i get the error (made much saner to read by use of printing explicit kinds) {{{ Prelude> :r [1 of 1] Compiling Data.Unboxed.Maybe ( src/Data/Unboxed/Maybe.hs, interpreted ) src/Data/Unboxed/Maybe.hs:22:3: error: • Data constructor ‘MaybeSumU’ returns type ‘Maybe 'LiftedRep x’ instead of an instance of its parent type ‘Maybe 'UnliftedRep x’ • In the definition of data constructor ‘MaybeSumU’ In the data instance declaration for ‘Maybe’ | 22 | MaybeSumU :: (# x | (# #) #) -> Maybe x }}} this is a) a case where printing runtime reps makes things easier to debug :) b) a very confusing type error since the data instance clearly says "x :: TYPE 'UnliftedRep " is there something i'm overlooking, or is this a bug? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14111> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #15540: GHCi does not follow the XDG Base Directory Specification
by GHC 22 Aug '18

22 Aug '18

#15540: GHCi does not follow the XDG Base Directory Specification -------------------------------------+------------------------------------- Reporter: rszibele | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | 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: -------------------------------------+------------------------------------- Hello, GHCi does not follow the XDG Base Directory Specification by default on GNU/Linux based operating systems. It creates for instance the file $HOME/.ghc/ghci_history which belongs in $XDG_CACHE_HOME/ghc/ , or $HOME/.cache/ghc/ if $XDG_CACHE_HOME is not set. $ ghci --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15540> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers
by GHC 22 Aug '18

22 Aug '18

#15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tested with version 8.2.2 and 8.0.2 (stack lts-11.5, lts-9.21, nightly-2018-04-14) with GHC and GHCi on archlinux amd64. **Code that produces wrong results** {{{ map (/2) [9007199254740990..9007199254740991] }}} **Expected behaviour** same as with low values: {{{ map (/2) [5..6] }}} resulting in: {{{ [2.5,3.0] }}} **Actual behaviour** resulting in an infinite list: {{{ [4.503599627370495e15,4.5035996273704955e15,4.503599627370496e15..] }}} **Similar code that produces expected results** multiplication works: {{{ map (*2) [9007199254740990..9007199254740991] }}} slightly smaller number work: {{{ map (/2) [9007199254740989..9007199254740990] }}} using a comma to produce the same list works: {{{ map (/2) [9007199254740990,9007199254740991] }}} **Similar code that also produces unexpected results** more elements in the list: {{{ map (/2) [9007199254740990..9007199254740999] map (/2) [9007199254740990..9007199354740999] }}} substituting the number and doing calculations: {{{ map (/2) [9007199254740990..9007199254740990+1] let a = 9007199254740990 map (/2) [a..a+1] }}} using scan and fold: {{{ foldl1 (/) [9007199254740990..9007199254740991] scanl1 (/) [9007199254740990..9007199254740991] }}} **Notes** This somehow only happens with high numbers when using fractional operations and using .. to construct the list. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15081> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12674: GHC doesn't handle ./ prefixed paths correctly
by GHC 22 Aug '18

22 Aug '18

#12674: GHC doesn't handle ./ prefixed paths correctly -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- GHC doesn't correctly handle paths preceded by `./` on the command line, if their first character (after any number of `./`s) is a `-`. For instance, `ghc ./-a.hs` fails, even if `a.hs` exists. Somewhere, `./-a.hs` is being converted to `-a.hs`. I have not been able to figure out where this happens. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12674> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11409: Cannot instantiate literals using TypeApplications
by GHC 22 Aug '18

22 Aug '18

#11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- {{{ GHCi, version 8.0.1.20160110: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeApplications -fprint-explicit-foralls Prelude> :t 42 42 :: forall {a}. Num a => a Prelude> 42 @Int <interactive>:3:1: error: • Cannot not apply expression of type ‘a0’ to a visible type argument ‘Int’ • In the expression: 42 @Int In an equation for ‘it’: it = 42 @Int }}} (Also, "cannot not" looks like a typo.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11409> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

Re: [GHC] #7674: Separate StablePtr table from StableName table.
by GHC 22 Aug '18

22 Aug '18

#7674: Separate StablePtr table from StableName table. -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.2 Resolution: fixed | Keywords: rts | stable_ptr stable_name performance Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15555 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #15555 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7674#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6077: Respect XDG_CONFIG_HOME
by GHC 22 Aug '18

22 Aug '18

#6077: Respect XDG_CONFIG_HOME -------------------------------------+------------------------------------- Reporter: So8res | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: None | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 5966 | Blocking: Related Tickets: #15540 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by potato44): * related: 15540 => #15540 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6077#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0