January 2017 - ghc-tickets

[GHC] #12948: Implement unwind rules for non-Intel architectures
by GHC 03 Mar '19

03 Mar '19

#12948: Implement unwind rules for non-Intel architectures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- To support DWARF-based stack unwinding, a platform needs a few things, * Valid unwind records in `stg_stop_thread` (defined in `rts/StgStartup.cmm`) * Support in the native code generator (by implementing the `generateUnwindTable` field of `NcgImpl`) * A mapping of register numbers to DWARF register numbers (see `dwarfRegNo` in `nativeGhc/Dwarf/Constants.hs`) * For unwinding support in the runtime system: * Unwinding support in `libdw` * a `set_initial_registers` implementation (see `rts/Libdw.c`) Currently the only platforms that has all of these implemented is x86_64 and i386. Someone should pick up the other platforms. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12948> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10841: Run handler on STM retry
by GHC 03 Mar '19

03 Mar '19

#10841: Run handler on STM retry -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: libraries | Version: 7.10.2 (other) | Keywords: stm | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- It would be nice to have a function like: {{{#!hs -- | Perform a series of STM actions atomically. -- -- Whenever the transaction retries, run the handler. If it doesn't return 'Nothing', -- stop the retrying and return the value given by the handler. atomicallyWithRetryHandler :: STM a -> IO (Maybe a) -> IO a }}} This would allow tracking retry statistics, printing debug messages on each retry, etc. without resorting to unsafeIOToSTM which can't safely do things like printing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10841> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13002: :set -O does not work in .ghci file
by GHC 03 Mar '19

03 Mar '19

#13002: :set -O does not work in .ghci file --------------------------------------+---------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- {{{#!hs {-# OPTIONS_GHC -Wall #-} module Foo where testFromTo :: Int -> Int testFromTo n = length ([0..(10^n)] :: [Int]) }}} {{{ cat ~/.ghci :set +s :set -fobject-code :set -O bash-3.2$ touch Foo.hs bash-3.2$ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/gcolpitts/.ghci Prelude> :load Foo :load Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo (Foo.o). (0.15 secs,) Prelude Foo> testFromTo 5 testFromTo 5 100001 (0.02 secs, 8,885,888 bytes) Prelude Foo> :quit :quit Leaving GHCi. bash-3.2$ touch Foo.hs bash-3.2$ ghci -fobject-code -O GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/gcolpitts/.ghci Prelude> :load Foo :load Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo (Foo.o). (0.15 secs,) Prelude Foo> testFromTo 5 testFromTo 5 100001 (0.02 secs, 98,400 bytes) }}} While supplying -fobject-code -O as an argument to ghci seems like an easy workaround that isn't feasible as far as I know when using emacs thus setting priority to normal rather than low. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13002> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #12847: ghci -fobject-code -O2 doesn't do the same optimisations as ghc --make -O2
by GHC 03 Mar '19

03 Mar '19

#12847: ghci -fobject-code -O2 doesn't do the same optimisations as ghc --make -O2 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Other Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From IRC: I have a module that takes around 10 seconds to compile on ghc --make -O2, but only around 3 seconds on ghci -fobject-code -O2. > bgamari: that is surprising I've put the -v timing output of the two cases into https://gist.github.com/nh2/e9bc4732111bfe422d8e606c10f8f0ac I'm comparing the 2 files with `meld` for spotting differences easily. Check e.g. `Result size of Tidy Core` which seems to have 3x as many terms for ghc, and `Simplifier [Mymodule]` doesn't seem to run in ghci The first time terms are different is at `Desugar, the first time a factor 3 comes in is after `Specialize`. > bgamari: wow, it sounds like the simplifier isn't getting run as aggressively in GHCi I'm running this on Ubuntu 16.04 inside nix (but happens the same way outside nix). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12847> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11503: TypeError woes (incl. pattern match checker)
by GHC 01 Mar '19

01 Mar '19

#11503: TypeError woes (incl. pattern match checker) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE DataKinds, GADTs, KindSignatures, TypeFamilies, UndecidableInstances #-} {-# OPTIONS_GHC -fwarn-incomplete-patterns #-} module Bug where import GHC.TypeLits import GHC.Exts ( Constraint ) type family NotInt a where NotInt Int = TypeError (Text "That's Int, silly.") NotInt _ = (() :: Constraint) data T a where MkT1 :: a -> T a MkT2 :: NotInt a => T a foo :: T Int -> Int foo (MkT1 x) = x }}} I get {{{ Bug.hs:19:1: warning: Pattern match(es) are non-exhaustive In an equation for ‘foo’: Patterns not matched: MkT2 }}} But I shouldn't. Even worse, perhaps, GHC accepts my pattern-match against `MkT2` if I add it. If I change the `TypeError` to `False ~ True`, I get the correct behavior. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11503> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9121: Presence of dyn_o files not checked? upon recompilation
by GHC 28 Feb '19

28 Feb '19

#9121: Presence of dyn_o files not checked? upon recompilation ------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I interrupt a compilation (initiated with cabal), and then recompile (with cabal), it can happen that gcc fails with missing .dyn_o file. I have "shared:True" in my .cabal/config file. [I can of course do cabal clean to work around, but since a full recompilation is about 10 min, I try to avoid this.] time cabal install --disable-library-profiling --disable-documentation Resolving dependencies... In order, the following will be installed: Agda-2.3.3 (latest: 2.3.2.2) (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring Agda-2.3.3... Building Agda-2.3.3... Preprocessing library Agda-2.3.3... [116 of 273] Compiling Agda.TypeChecking.Monad.Base[boot] ( src/full/Agda/TypeChecking/Monad/Base.hs-boot, dist/build/Agda/TypeChecking/Monad/Base.o-boot ) ... [239 of 273] Compiling Agda.TypeChecking.Conversion ( src/full/Agda/TypeChecking/Conversion.hs, dist/build/Agda/TypeChecking/Conversion.o ) [Agda.Syntax.Translation.InternalToAbstract changed] ^Cmake: *** [install-bin] Interrupt time cabal install --disable-library-profiling --disable-documentation Resolving dependencies... In order, the following will be installed: Agda-2.3.3 (latest: 2.3.2.2) (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring Agda-2.3.3... Building Agda-2.3.3... Preprocessing library Agda-2.3.3... [116 of 273] Compiling Agda.TypeChecking.Monad.Base[boot] ( src/full/Agda/TypeChecking/Monad/Base.hs-boot, dist/build/Agda/TypeChecking/Monad/Base.o-boot ) ... [273 of 273] Compiling Agda.Main ( src/full/Agda/Main.hs, dist/build/Agda/Main.o ) [Agda.Compiler.Epic.Compiler changed] gcc: error: dist/build/Agda/TypeChecking/Conversion.dyn_o: No such file or directory Failed to install Agda-2.3.3 cabal: Error: some packages failed to install: Agda-2.3.3 failed during the building phase. The exception was: ExitFailure 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9121> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10170: Find versioned versions of LLVM tools
by GHC 25 Feb '19

25 Feb '19

#10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 (LLVM) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Since it has become more widely know that the LLVM developers often make breaking changes to the IR language between releases, some Linu distributions (eg Debain and hence Ubuntu) have started doing multi- version LLVM installs. For instance on Debian, the llvm-3.6 programs are installed in `/usr/lib/llvm-3.6/bin` as `llc` and `opt`. I propose that the `configure.ac` and `aclocal.m4` configuration goop be modified to look for `llc` and `opt` in these versioned `/usr/lib/llvm-X.Y` locations. I'm also willing to do the hard yards on implementing this if people think its a good idea. This can be seen as a step along the way to more stringent LLVM versioning requirements. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10170> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #12564: Type family in type pattern kind
by GHC 20 Feb '19

20 Feb '19

#12564: Type family in type pattern kind -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I want to write a type family that is analogous to `!!` for lists but requires the index to be no bigger than the length of the list. Usually, in dependently typed languages finite sets are used for this purpose, here's an attempt to do so in Haskell: {{{#!haskell {-# LANGUAGE TypeInType, TypeFamilies, GADTs, TypeOperators #-} import Data.Kind data N = Z | S N type family Len (xs :: [a]) :: N where Len '[] = Z Len (_ ': xs) = S (Len xs) data Fin :: N -> Type where FZ :: Fin (S n) FS :: Fin n -> Fin (S n) type family At (xs :: [a]) (i :: Fin (Len xs)) :: a where At (x ': _) FZ = x At (_ ': xs) (FS i) = At xs i }}} It fails to compile with this error: {{{ FinAt.hs:16:3: error: • Illegal type synonym family application in instance: 'FZ • In the equations for closed type family ‘At’ In the type family declaration for ‘At’ }}} That's because the kind of the `FZ` pattern (first clause of `At`) has the kind `Fin (Len xs)` and the application of `Len` cannot reduce completely. `checkValidTypePat` then disallows the pattern, as it contains a type family application. I tried to suppress `checkValidTypePat` and the definition of `At` has compiled; however, it's of little use, since `At` doesn't reduce: {{{#!haskell x :: At '[Bool] FZ x = True }}} results in {{{ FinAt.hs:20:5: error: • Couldn't match expected type ‘At * ((':) * Bool ('[] *)) ('FZ 'Z)’ with actual type ‘Bool’ • In the expression: True In an equation for ‘x’: x = True }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12564> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12612: Allow kinds of associated types to depend on earlier associated types
by GHC 18 Feb '19

18 Feb '19

#12612: Allow kinds of associated types to depend on earlier associated types -------------------------------------+------------------------------------- Reporter: davemenendez | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- GHC rejects the following code: {{{#!hs class C t where type K t :: Type type T t :: K t -> Type m :: t -> T t a }}} with this error message {{{ • Type constructor ‘K’ cannot be used here (it is defined and used in the same recursive group) • In the kind ‘K t -> Type’ }}} See [https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-September/026402.html e-mail discussion]. This is connected to #12088, at least as far as defining instances of C. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12612> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12218: Implement -fexternal-interpreter via static linking
by GHC 18 Feb '19

18 Feb '19

#12218: Implement -fexternal-interpreter via static linking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- An interesting idea from @hvr. When using `-fexternal-interpreter`, we can statically link the required packages and object files into a new iconv binary, and use that as our external interpreter. This would mean we could support TH and even limited GHCi without needing a dynamic linker of any kind, which is extremely cool. Apparently this would be useful for AIX where doing dynamic linking is hard. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12218> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3