September 2017 - ghc-tickets

[GHC] #9429: Alternative to type family Any
by GHC 18 Feb '18

18 Feb '18

#9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 9097, 9380 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In GHC HEAD, `Any` is no longer a datatype. There are good reasons for this change, one of which was explained in #9097, the original ticket, and another in #9380. Unfortunately, a casualty of this change is that it is no longer easy to generalize the [https://hackage.haskell.org/package/rank1dynamic|rank1dynamic package] to rank-1 types with type variables of arbitrary kind (not just `*`). We submitted a way to do so [here], that exploits the fact that `Any` has the very magical property of inhabiting *all* kinds, including closed ones. This works for GHC 7.8, but won't work in HEAD, because we require that there exists a `Typeable` instance for `Any`, just as there are `Typeable` instances for any other type one wishes to have instances for. The reason is that now that `Any` is a type family, `Any` is no longer a legal instance head. There are several possible solutions that I see: * while it's clearly dangerous for the compiler to be inserting the old `Any` during typechecking from the moment that we have computation in types over closed kinds, we may still want the old `Any`, say under a different name, as a backdoor. It wouldn't be used by the compiler during type checking - only by packages such as rank1dynamic. I believe that furthermore, if we restrict the old `Any` to not inhabit closed kinds, then none of the problems cited in the above tickets arise. * Instead of making the new `Any` a type family, keep it a datatype, but ban it from inhabiting closed kinds. I don't know if such an `Any` would be sufficient for the purposes of GHC, however. * Hardwire a `Typeable` instance for the `Any` type family (not sure if this makes sense). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #13852: Can we have more SIMD primops, corresponding to the untapped AVX etc. instructions?
by GHC 18 Feb '18

18 Feb '18

#13852: Can we have more SIMD primops, corresponding to the untapped AVX etc. instructions? -------------------------------------+------------------------------------- Reporter: | Owner: (none) leftaroundabout | Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (LLVM) | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [http://hackage.haskell.org/package/ghc-prim-0.5.0.0/docs/GHC- Prim.html#g:28 GHC.Prim] contains a good couple of vectorised instructions, which can be [http://hackage.haskell.org/package/primitive- simd-0.1.0.0/docs/Data-Primitive-SIMD.html used by libraries] for generating nice fast e.g. sums of floating-point vectors. However, several instructions that modern processors could vectorise are missing there. In particular, I would like to be able to use the VPSLLVD...VPSRAVD shifting operations, and at some point perhaps VPMAXSQ...VPMINUQ maximum/minimum operations. It would be great if corresponding primops could be added. Else I would like to know – where is this stuff even defined? [http://hackage.haskell.org/package/ghc- prim-0.5.0.0/docs/src/GHC.Prim.html GHC.Prim] as such seems to be merely an automatically-generated dummy module, mostly for Haddock. (On the other hand, I find it also a bit strange that there are primops for [http://hackage.haskell.org/package/ghc-prim-0.5.0.0/docs/GHC- Prim.html#v:quotInt8X16-35- integer division], which is apparently [https://stackoverflow.com/questions/16822757/sse-integer-division not supported by SSE/AVX] at all!) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13852> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13943: Compiler infinite loop with GHC-8.2
by GHC 15 Feb '18

15 Feb '18

#13943: Compiler infinite loop with GHC-8.2 -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 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-8.0.1 compile this module in less than one seconds on my machine. Both GHC-8.2rc2 and GHC-8.2rc3 eat all 8GB of memory and don't show any signs of stopping. -dshow-passes shows this: {{{ [1 of 1] Compiling Data.List.Unrolled ( unrolled.hs, unrolled.o ) *** Parser [Data.List.Unrolled]: !!! Parser [Data.List.Unrolled]: finished in 0.00 milliseconds, allocated 3.434 megabytes *** Renamer/typechecker [Data.List.Unrolled]: }}} and then nothing. Only memory consumption grows. Code: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE GADTs #-} module Data.List.Unrolled where import GHC.TypeLits -- | Drop @n@ elements from a list class Drop (n :: Nat) where drop :: [a] -> [a] instance {-# OVERLAPPING #-} Drop 0 where drop xs = xs {-# INLINE drop #-} instance {-# OVERLAPPABLE #-} (Drop (n - 1)) => Drop n where drop [] = [] drop (_ : xs) = drop @(n - 1) xs {-# INLINE drop #-} -- | Take @n@ elements from a list class Take (n :: Nat) where take :: [a] -> [a] instance {-# OVERLAPPING #-} Take 0 where take _ = [] {-# INLINE take #-} instance {-# OVERLAPPABLE #-} (Take (n - 1)) => Take n where take [] = [] take (x : xs) = x : take @(n - 1) xs {-# INLINE take #-} -- | Split list at @n@-th element. splitAt :: forall (n :: Nat) a. (Take n, Drop n) => [a] -> ([a], [a]) splitAt xs = (take @n xs, drop @n xs) -- | Split list into chunks of the given length @c@. @n@ is length of the list. class ChunksOf (n :: Nat) (c :: Nat) where chunksOf :: [a] -> [[a]] instance {-# OVERLAPPING #-} ChunksOf 0 0 where chunksOf _ = [] {-# INLINE chunksOf #-} instance {-# OVERLAPPABLE #-} ChunksOf 0 c where chunksOf _ = [] {-# INLINE chunksOf #-} instance {-# OVERLAPPABLE #-} ChunksOf n 0 where chunksOf _ = [] {-# INLINE chunksOf #-} instance {-# OVERLAPPABLE #-} (Take c, Drop c, ChunksOf (n - 1) c) => ChunksOf n c where chunksOf xs = let (l, r) = splitAt @c xs in l : chunksOf @(n - 1) @c r {-# INLINE chunksOf #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13943> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8258: GHC accepts `data Foo where` in H2010 mode
by GHC 15 Feb '18

15 Feb '18

#8258: GHC accepts `data Foo where` in H2010 mode --------------------------+------------------------------------------------ Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 7.8.1 Component: | Version: 7.0.4 Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC accepts invalid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ According to the Haskell2010 report, The grammar productions relevant for `data` declarations are the following: {{{ topdecl → data [context =>] simpletype [= constrs] [deriving] }}} (from [http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-680004.2 4.2.1 Algebraic Datatype Declarations]) However, GHC 7.0.4/7.4.2/7.6.3/HEAD all happily compile the following Haskell module without any warning when using `-XHaskell2010 -Wall`, even though this is not valid Haskell2010 afaik: {{{#!hs module Foo where data Foo where }}} The trailing `where` in the `data` declaration is not valid Haskell2010 (without language extensions such as `GADT`). At the very least, this divergence from the Haskell Report should be mentioned in [http://www.haskell.org/ghc/docs/latest/html/users_guide /bugs-and-infelicities.html#haskell-standards-divergence 14.1.1. Divergence from Haskell 98 and Haskell 2010]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9269: Type families returning quantified types
by GHC 14 Feb '18

14 Feb '18

#9269: Type families returning quantified types ------------------------------------+------------------------------------- Reporter: pumpkin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Is there a fundamental reason for not being able to use quantification in a type family? I'd very much like to be able to do it, obviously turning on RankNTypes if necessary. I'm looking for things like this: {{{#!haskell type family Foo (x :: Bool) where Foo True = forall a. [a] Foo False = () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9269> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12422: Add decidable equality class
by GHC 14 Feb '18

14 Feb '18

#12422: Add decidable equality class -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | 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: -------------------------------------+------------------------------------- Currently, we have a `TestEquality` class {{{#!hs class TestEquality f where testEquality :: f a -> f b -> Maybe (a :~: b) }}} It would be nice to add a class for fully decidable equality. There are a few options, but this one gets to the point rather quickly: {{{#!hs data EqDec a b where NotEqual :: (forall c . a :~: b -> c) -> EqDec a b Equal :: EqDec a a class DecEq f where decEq :: f a -> f b -> EqDec a b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12422> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12262: Binary output is not deterministic
by GHC 07 Feb '18

07 Feb '18

#12262: Binary output is not deterministic -------------------------------------+------------------------------------- Reporter: niteria | 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: -------------------------------------+------------------------------------- The goal of DeterministicBuilds (#4012) was to get ABI-compatible binaries given the same sources, flags and the environment. There's a stronger goal of getting bit-for-bit identical binaries and this ticket will track that. Known causes of binary nondeterminism: * Unique comparison * Uniques converted to strings for symbol names * everything else from #4012 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12262> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12685: getNumProcessors semantics dont match documentation
by GHC 07 Feb '18

07 Feb '18

#12685: getNumProcessors semantics dont match documentation ----------------------------------------+--------------------------------- Reporter: Llgn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Hi, The documentation of getNumProcessors says : "Returns the number of CPUs that the machine has", but it is true only for program compiled with -threaded option. https://hackage.haskell.org/package/base-4.9.0.0/docs/GHC-Conc- Sync.html#v:getNumProcessors I guess the documentation is just misleading. Or is it a bug ? Regards -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12685> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix
by GHC 05 Feb '18

05 Feb '18

#8684: hWaitForInput cannot be interrupted by async exceptions on unix ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- http://hackage.haskell.org/package/base-4.6.0.1/docs/System-Timeout.html claims that {{{timeout}}} can interrupt {{{hWaitForInput}}}, but in fact that's false (e.g. mentioned in https://ghc.haskell.org/trac/ghc/ticket/7353#comment:4) {{{ -- import Control.Concurrent import System.IO import System.Timeout main = timeout (1 * 1000000) $ hWaitForInput stdin (5 * 1000) }}} will not be killed after 1 second, but instead wait for the full 5 seconds timeout passed to {{{hWaitForInput}}}. The implementation is {{{ready}}} at http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-IO- FD.html, where we have two foreign calls: {{{safe fdReady}}} and {{{unsafe unsafe_fdReady}}}. The actual C implementation is at https://github.com/haskell- suite/base/blob/master/cbits/inputReady.c#L16. It uses {{{select}}} on Unix, and does check for {{{EINTR}}}, so I believe that according to http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/ffi.html#ffi- interruptible both foreign calls can be replaced by a single {{{interruptible}}} one. Is that true? If not, it's a documentation bug in {{{timeout}}} at least. Also, does {{{interruptible}}}, apart from allowing the function to be interrupted, behave more like {{{safe}}} or {{{unsafe}}}? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 32

[GHC] #8228: GHC built under Windows does not generate dyn_hi files
by GHC 04 Feb '18

04 Feb '18

#8228: GHC built under Windows does not generate dyn_hi files ------------------------------+-------------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Windows Architecture: | Type of failure: GHC doesn't work at all Unknown/Multiple | Test Case: cabal01 Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I found cabal01 failing with: {{{ =====> cabal01(normal) 1 of 1 [0, 0, 0] cd . && $MAKE -s --no-print-directory cabal01 VANILLA=--enable-library- vanilla PROF=--disable-l ibrary-profiling DYN=--enable-shared </dev/null >cabal01.run.stdout 2>cabal01.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: Creating library file: dist\build\libHStest-1.0-ghc7.7.20130904.dll.a setup.exe: Error: Could not find module: A with any suffix: ["dyn_hi"] in the search path: ["dist\\build"] make[2]: *** [cabal01] Error 1 }}} but I bet some of the other failures are due to this. Indeed, in dist/build, there are no dyn_hi files When I look more closely at the commands being run, I see: {{{ bash.exe-3.1$ c:/Users/ezyang/Dev/ghc-validate/inplace/bin/ghc-stage2.exe --make -fbuilding-ca bal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir dist/build -odi r dist/build -hidir dist/build -stubdir dist/build -i -idist/build -i. -idist/build/autogen -I dist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -package- name test-1.0 -hide-all- packages -no-user-package-db -package-db local.db -package-db dist/pac kage.conf.inplace -package-id base-4.7.0.0-inplace -XHaskell98 -XForeignFunctionInterface A B. A -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db [1 of 2] Compiling B.A ( B\A.hs, dist\build\B\A.o ) [2 of 2] Compiling A ( A.hs, dist\build\A.o ) }}} which should result in dyn_hi files but does not. I haven't traced it any further yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8228> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17