September 2017 - ghc-tickets

[GHC] #14280: Aarch64 build is broken
by GHC 28 Sep '17

28 Sep '17

#14280: Aarch64 build is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Trying to bootstrap 7446c7f68bd5addd2f2db0d8d5910fb963869c47 on an aarch64 (Debian 8, LLVM 5) box results in a reproducibly segfaulting `ghc-stage2`, {{{ (gdb) run Starting program: /mnt/ext/arm/ghc/inplace/lib/bin/ghc-stage2 -B/mnt/ext/arm/ghc/inplace/lib -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/check-ppr/. -iutils/check-ppr/dist-install/build -Iutils/check-ppr/dist-install/build -iutils/check-ppr/dist-install/build/check-ppr/autogen -Iutils/check-ppr /dist-install/build/check-ppr/autogen -optP-include -optPutils/check-ppr /dist-install/build/check-ppr/autogen/cabal_macros.h -package-id base-4.11.0.0 -package-id bytestring-0.10.8.2 -package-id containers-0.5.10.2 -package-id Cabal-2.0.0.2 -package-id directory-1.3.1.2 -package-id filepath-1.4.1.2 -package-id ghc-8.3 -Wall -XHaskell2010 -no-user-package- db -rtsopts -Wnoncanonical-monad-instances -odir utils/check-ppr/dist- install/build -hidir utils/check-ppr/dist-install/build -stubdir utils /check-ppr/dist-install/build -c utils/check-ppr/./Main.hs -o utils/check- ppr/dist-install/build/Main.dyn_o [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/aarch64-linux- gnu/libthread_db.so.1". [New Thread 0x3fafaff200 (LWP 29429)] Thread 1 "ghc-stage2" received signal SIGSEGV, Segmentation fault. 0x00000000005aa360 in stg_IND_STATIC_info () (gdb) bt #0 0x00000000005aa360 in stg_IND_STATIC_info () #1 0x0000007fb11b3450 in ccib_info$def () from /mnt/ext/arm/ghc/libraries/base/dist- install/build/libHSbase-4.11.0.0-ghc8.3.20170926.so Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14280> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14233: Remove old GetTickCount() code path for Windows
by GHC 27 Sep '17

27 Sep '17

#14233: Remove old GetTickCount() code path for Windows ----------------------------------------+--------------------------------- Reporter: nh2 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Windows XP support was dropped since GHC 8.0 as per https://ghc.haskell.org/trac/ghc/wiki/WindowsGhc In `HsWord64 getMonotonicNSec()` on Windows we still fall back to the 32-bit `GetTickCount()` if `QueryPerformanceFrequency()` is not supported: [https://github.com/ghc/ghc/blob/ghc-8.2.1-release/rts/win32/GetTime.c#L69 Code] But [https://msdn.microsoft.com/en- us/library/windows/desktop/ms644905(v=vs.85).aspx Microsoft's documentation] says that `QueryPerformanceFrequency()` is guaranteed to be supported on Windows >= XP: > On systems that run Windows XP or later, the function will always succeed and will thus never return zero. Thus we can remove the `if (!qpc_supported)` check and all `if (!qpc_frequency.QuadPart)` code paths, and replace it with an assertion or a `./configure` check. We can also add a comment that `getMonotonicNSec()` will indeed always make use of the whole 64-bit domain. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14233> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12376: Allow function definitions in record syntax
by GHC 27 Sep '17

27 Sep '17

#12376: Allow function definitions in record syntax -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- Would it be possible to write {{{#!hs propertyMap :: (Monad m, Ord k) => v -> PropertyMap m k v propertyMap v0 = go v0 Map.empty where go v m = PropertyMap { getP = \k -> return $ maybe v id (Map.lookup k m) , putP = \k v' -> return $ go v (Map.insert k v' m) } }}} as {{{#!hs propertyMap :: (Monad m, Ord k) => v -> PropertyMap m k v propertyMap v0 = go v0 Map.empty where go v m = PropertyMap { getP k = return $ maybe v id (Map.lookup k m) , putP k v' = return $ go v (Map.insert k v' m) } }}} Simpler example `MkFoo { id = \x -> x }` as {{{#!hs MkFoo { id x = x } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12376> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9898: Couldn't match type `(Char, ())' with `()'
by GHC 27 Sep '17

27 Sep '17

#9898: Couldn't match type `(Char, ())' with `()' -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Windows Keywords: | Type of failure: GHC Architecture: x86_64 (amd64) | rejects valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- 'test3' is expected to type check given that 'test1' and 'test2' type check. 'test4' is not expected to type check. {{{ ghc_bug2.hs:24:9: Couldn't match type `(Char, ())' with `()' Expected type: Filter (Equal Int) (Char, Filter (Equal Int) ()) Actual type: () In the expression: () :: Filter (Equal Int) (Char, Filter (Equal Int) ()) In an equation for `test2': test2 = () :: Filter (Equal Int) (Char, Filter (Equal Int) ()) ghc_bug2.hs:28:9: Couldn't match type `(Char, ())' with `()' Expected type: Filter (Equal Int) (Char, ()) Actual type: () In the expression: () In an equation for `test3': test3 = () }}} {{{#!hs {-# LANGUAGE TypeFamilies, UndecidableInstances, DataKinds #-} module Main where type family Filter f xs where Filter f (x, xs) = ApplyFilter (f x) (x, Filter f xs) Filter f () = () -- type family ApplyFilter p xs where ApplyFilter False (x, xs) = xs ApplyFilter p xs = xs -- type family Equal x y where Equal x x = True Equal x y = False -- -- Type checks test1 :: ApplyFilter ((Equal Int) Char) (Char, Filter (Equal Int) ()) test1 = () -- Couldn't match type `(Char, ())' with `()' test2 = () :: Filter (Equal Int) (Char, Filter (Equal Int) ()) -- Couldn't match type `(Char, ())' with `()' test3 :: Filter (Equal Int) (Char, ()) test3 = () -- Type checks, should not test4 :: Filter (Equal Int) (Char, ()) test4 = ('x', ()) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9898> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14286: Different behavior between type application and type annotation.
by GHC 27 Sep '17

27 Sep '17

#14286: Different behavior between type application and type annotation. -------------------------------------+------------------------------------- Reporter: vagarenko | 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: -------------------------------------+------------------------------------- Consider this code: {{{#!hs {-# LANGUAGE FlexibleInstances, TypeApplications #-} module Bug where class Foo t where foo_ :: (IO () -> IO ()) -> t instance (Show a, Foo t) => Foo (a -> t) where foo_ k a = foo_ (\continue -> k (print a >> continue)) instance Foo (IO ()) where foo_ k = k (return ()) foo :: Foo t => t foo = foo_ id bar = foo () (Just "bar") [()] :: IO () baz = foo @(IO ()) () (Just "baz") [()] }}} `bar` is accepted by GHC while `baz` is rejected: {{{ * Couldn't match expected type `() -> Maybe [Char] -> [()] -> t' with actual type `IO ()' * The function `foo' is applied to four arguments, but its type `IO ()' has none In the expression: foo @(IO ()) () (Just "baz") [()] In an equation for `baz': baz = foo @(IO ()) () (Just "baz") [()] * Relevant bindings include baz :: t (bound at bug.hs:19:1) | 19 | baz = foo @(IO ()) () (Just "baz") [()] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Why so? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14286> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7169: Warning for incomplete record field label used as function
by GHC 27 Sep '17

27 Sep '17

#7169: Warning for incomplete record field label used as function -------------------------------------+------------------------------------- Reporter: goldfire | Owner: nakaji_dayo Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Warnings, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): I think addressing this is important, otherwise it can be easy for people to write code that throws exceptions, without realizing it. I don't like the name `-Wpartial-records`, the name could be construed to refer to things like `-Wmissing-fields` and `-Wincomplete-record-updates`, other examples of partiality in records. Perhaps call it `-Wpartial- fields`? I think it also makes sense to have an option to emit warnings for partial record fields. Perhaps call it `-Wpartial-field-usages`? The reason this is helpful is that some libraries may export partial fields. It's still helpful as a sanity check for users of a library to have this as an optional warning. From what I can tell, modern Haskell best practice is to eschew partial field declarations, so I think it makes sense to include `-Wpartial- fields` in `-Wall`, but not `-Wpartial-field-usages`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7169#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13379: Space leak / quadratic behavior when inlining
by GHC 27 Sep '17

27 Sep '17

#13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling the attached example yields quadratic behavior and a big space leak (eventually the oom killer kills it) during inlining. Tested on both ghc 7.10.3 and 8.0.1 I compiled with `-fforce-recomp --make -O2 -ddump-inlinings Main.hs` In cases where the process was able to run for a while I could see that each chunk of inlinings was getting slower linearly (every minute or so you can hit enter and which the line break go up your terminal a little slower than the last time). I assume the slowdown is due to GC over the growing heap due to a leak, but maybe the inlining algorithm is quadratic. Apologies if this is a dupe; I had trouble searching for similar issues. (I did find #13316 but don't understand if this could be related) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13379> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 39

[GHC] #14281: Minor regressions from removal of non-linear behavior from simplifier
by GHC 27 Sep '17

27 Sep '17

#14281: Minor regressions from removal of non-linear behavior from simplifier -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #13397 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- #13379 exposed non-linear behavior simplifying certain nested function applications. Simon PJ fixed that in a1b753e8b1475659440f524b3e66dfbea31c5787, and then made an adjustment in 29d88ee173bc9b04245a33d5268dda032f5dc331. Gipeda revealed a couple of small regressions from this combination (I'm not sure which did what, but IIRC the second patch mostly fixed regressions in the first). {{{ nofib/time/cryptarithm1 time increases 4.87% from 0.513s to 0.538s nofib/size/scs code size increases 5.28% from 1224890 bytes to 1289570 bytes }}} Note that there are a few comments on #13397 relating to these regressions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14281> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2)
by GHC 27 Sep '17

27 Sep '17

#14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On Windows, the situation regarding Ctrl+C in GHCi has always been a little flaky in the sense that some shells (e.g., `mintty`-based ones) don't intercept Ctrl+C properly, causing GHCi to exit prematurely. However, up until 8.0.2, Ctrl+C was being intercepted correctly on `cmd.exe` and PowerShell. In GHC 8.2.1, however, this has changed. If you hit Ctrl+C in GHCi on PowerShell, then GHCi will appear to "exit" (in the sense that the prompt will go back to the PowerShell one). However, if you try typing and entering commands, there's a 50-50 chance it will be interpreted by PowerShell or a lingering GHCi process (indicating that GHCi wasn't really killed!). (Apologies for the rather crude description, but I'm not sure of a better way to report what is going on here.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14150> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #13929: GHC panic with levity polymorphism
by GHC 27 Sep '17

27 Sep '17

#13929: GHC panic with levity polymorphism --------------------------------------+--------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I'm using GHC version 8.2.0.20170507 This code fails to compile {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE AllowAmbiguousTypes #-} module Main where import GHC.Exts import Data.Kind import GHC.Generics class GUnbox (f :: Type -> Type) (r :: RuntimeRep) where type GUnboxed f r :: TYPE r gunbox :: f p -> GUnboxed f r instance (GUnbox f rf, GUnbox g rg) => GUnbox (f :*: g) ('TupleRep '[rf, rg]) where type GUnboxed (f :*: g) ('TupleRep '[rf, rg]) = (# GUnboxed f rf, GUnboxed g rg #) -- if I remove implementation of `gunbox` it compiles successfully gunbox (x :*: y) = (# gunbox x, gunbox y #) main :: IO () main = pure () }}} with message: {{{ [1 of 1] Compiling Main ( Main.hs, .stack- work\dist\f42fcbca\build\Main.o ) ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-unknown-mingw32): isUnliftedType GUnboxed g_a21y rg_a21z :: TYPE rg_a21z Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler\types\Type.hs:1954:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13929> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23