October 2017 - ghc-tickets

[GHC] #12999: Investigate use of floating-point arithmetic in I/O Event-handler
by GHC 16 Jun '18

16 Jun '18

#12999: Investigate use of floating-point arithmetic in I/O Event-handler -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: | Version: 8.0.1 libraries/base | 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 was asked/made aware of some questionable use of floating-point arithmetic in `GHC.Event.TimerManager`; Specifically, I can't explain why `getMonotonicTime` first gets a timestamp as `Word64`, only to perform a not-necessarily cheap floating- point division, and returns a `Double`... {{{#!hs -- | Return monotonic time in seconds, since some unspecified starting point getMonotonicTime :: IO Double getMonotonicTime = do w <- getMonotonicNSec return (fromIntegral w / 1000000000) foreign import ccall unsafe "getMonotonicNSec" getMonotonicNSec :: IO Word64 }}} which then gets used e.g. by {{{#!hs updateTimeout :: TimerManager -> TimeoutKey -> Int -> IO () updateTimeout mgr (TK key) us = do now <- getMonotonicTime let expTime = fromIntegral us / 1000000.0 + now editTimeouts mgr (Q.adjust (const expTime) key) wakeManager mgr }}} Whereas, the priority queue (`GHC.Event.PSQ`) then uses `Double`s for its priorities... For correctness and performance reasons, I'd expect the use of fixed-width integers (i.e. `Word64` or `Int64`) for such codepaths... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12999> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14123: Figure out invariants surrounding ticks in Core
by GHC 16 Jun '18

16 Jun '18

#14123: Figure out invariants surrounding ticks in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- In the past we have had a number of issues stemming from ticks breaking various Core analyses in GHC, * #13233: a tick separates a levity-polymorphic tycon (e.g. an unboxed tuple tycon) from its levity arguments, resulting in a `typePrimRep` panic. * ticket:8472#comment:22: a tick wraps a primitive string literal, causing `CoreToStg` to fail to notice it is a string resulting in a panic * #14122: Another literal string issue which I have yet to debug but seems very likely to be tick-related. We have merged a stop-gap solution/hack (f5b275a239d2554c4da0b7621211642bf3b10650) to the `ghc-8.2` branch however need a more principled solution in the long-term (e.g. before 8.4). We will need to start by defining precisely where ticks are allowed and add appropriate logic to CoreLint to verify that this invariant is upheld. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14123> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal`
by GHC 16 Jun '18

16 Jun '18

#14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 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: -------------------------------------+------------------------------------- When GHC 8.2.1 compiles this code with `-O`: {{{#!hs {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} module NatVal where import Data.Proxy import GHC.TypeLits foo = natVal $ Proxy @0 }}} it produces the following Core: {{{#!hs -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} NatVal.foo1 :: Integer NatVal.foo1 = 0 -- RHS size: {terms: 41, types: 18, coercions: 0, joins: 0/0} foo :: Integer foo = case NatVal.foo1 of wild_a1iV { integer-gmp-1.0.1.0:GHC.Integer.Type.S# i#_a2ke -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# i#_a2ke 0#) of { False -> case GHC.Natural.underflowError of wild2_00 { }; True -> integer-gmp-1.0.1.0:GHC.Integer.Type.wordToInteger (GHC.Prim.int2Word# i#_a2ke) }; integer-gmp-1.0.1.0:GHC.Integer.Type.Jp# dt_a2km -> case GHC.Prim.uncheckedIShiftRL# (GHC.Prim.sizeofByteArray# dt_a2km) 3# of { __DEFAULT -> case GHC.Prim.sizeofByteArray# dt_a2km of { __DEFAULT -> wild_a1iV; 0# -> case GHC.Natural.underflowError of wild4_00 { } }; 1# -> case GHC.Prim.indexWordArray# dt_a2km 0# of wild2_a2kq { __DEFAULT -> integer-gmp-1.0.1.0:GHC.Integer.Type.wordToInteger wild2_a2kq } }; integer-gmp-1.0.1.0:GHC.Integer.Type.Jn# ipv_a2kt -> case GHC.Natural.underflowError of wild1_00 { } } }}} while GHC-8.0.1 does the right thing: {{{#!hs -- RHS size: {terms: 1, types: 0, coercions: 0} foo :: Integer foo = 0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14170> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances.
by GHC 15 Jun '18

15 Jun '18

#13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. -------------------------------------+------------------------------------- Reporter: Hjulle | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Yes I know, `0` and `"B"` are not technically type constructors, but it's as close as you can get for the kinds Nat and Symbol. Test cases: {{{#!hs {-# LANGUAGE DataKinds, KindSignatures #-} import GHC.TypeLits (Nat, Symbol) class A (n::Nat) instance A 0 class B (s::Symbol) instance B "B" }}} Result: {{{ A.hs:6:10: error: • Illegal instance declaration for ‘A 0’ (All instance types must be of the form (T a1 ... an) where a1 ... an are *distinct type variables*, and each type variable appears at most once in the instance head. Use FlexibleInstances if you want to disable this.) • In the instance declaration for ‘A 0’ A.hs:9:10: error: • Illegal instance declaration for ‘B "B"’ (All instance types must be of the form (T a1 ... an) where a1 ... an are *distinct type variables*, and each type variable appears at most once in the instance head. Use FlexibleInstances if you want to disable this.) • In the instance declaration for ‘B "B"’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13833> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13900: Core lint in BuildFlavour=perf-llvm
by GHC 15 Jun '18

15 Jun '18

#13900: Core lint in BuildFlavour=perf-llvm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found the following Core lint failure when compiling c9977385dca9536f18374242f713b1048a38dec5 with `BuildFlavour=perf-llvm`, {{{ "inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O -H64m -fllvm -Wall -hide-all-packages -i -ighc/. -ighc/stage2/build -Ighc/stage2/build -ighc/stage2/build/ghc/autogen -Ighc/stage2/build/ghc/autogen -optP-DGHCI -optP-include -optPghc/stage2/build/ghc/autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id array-0.5.1.2 -package-id bytestring-0.10.8.2 -package-id directory-1.3.0.2 -package-id process-1.6.0.0 -package-id filepath-1.4.1.2 -package-id ghc-boot-8.3 -package-id ghc-8.3 -package-id unix-2.7.2.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id ghci-8.3 -package-id haskeline-0.7.4.0 -package-id time-1.8.0.1 -package- id transformers-0.5.2.0 -Wall -fno-warn-name-shadowing -XHaskell2010 -O2 -dcore-lint -dcmm-lint -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir ghc/stage2/build -hidir ghc/stage2/build -stubdir ghc/stage2/build -c ghc/./GHCi/UI/Tags.hs -o ghc/stage2/build/GHCi/UI/Tags.dyn_o *** Core Lint errors : in result of Simplifier *** <no location info>: warning: [RHS of $wgo_XtpE :: [Name] -> Session -> State# RealWorld -> (# State# RealWorld, [[TagInfo]] #)] Rule "SC:$wgo0": lhs type: (# State# RealWorld, [[TagInfo]] #) rhs type: (# State# RealWorld, [Maybe TyThing] #) *** Offending Program *** (see attached) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13900> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #14392: `make binary-dist` is broken
by GHC 14 Jun '18

14 Jun '18

#14392: `make binary-dist` is broken -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.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: -------------------------------------+------------------------------------- If we run {{{#!bash ./boot ./configure make make binary-dist }}} We are soon greeted with the following error {{{ cd bindistprep && "/bin/tar" hcf - -T ../bindist-list.uniq | /usr/bin/xz -c > ../bindistprep/ghc-8.3.20171025-x86_64-unknown-linux.tar.xz /bin/tar: ghc-8.3.20171025/testsuite/utils/check-api-annotations/dist- install/build/.depend.c_asm: Cannot stat: No such file or directory /bin/tar: ghc-8.3.20171025/testsuite/utils/check-api-annotations/dist- install/build/.depend.haskell: Cannot stat: No such file or directory /bin/tar: ghc-8.3.20171025/testsuite/utils/check-api-annotations/dist- install/package-data.mk: Cannot stat: No such file or directory /bin/tar: ghc-8.3.20171025/testsuite/utils/check-api-annotations/ghc.mk: Cannot stat: No such file or directory /bin/tar: ghc-8.3.20171025/testsuite/utils/check-ppr/dist- install/build/.depend.c_asm: Cannot stat: No such file or directory /bin/tar: ghc-8.3.20171025/testsuite/utils/check-ppr/dist- install/build/.depend.haskell: Cannot stat: No such file or directory /bin/tar: ghc-8.3.20171025/testsuite/utils/check-ppr/dist-install/package- data.mk: Cannot stat: No such file or directory /bin/tar: ghc-8.3.20171025/testsuite/utils/check-ppr/ghc.mk: Cannot stat: No such file or directory /bin/tar: Exiting with failure status due to previous errors mv bindistprep/*.tar.xz "." }}} I suspect https://github.com/ghc/ghc/commit/1e9f90af7311c33de0f7f5b7dba594725596d675 is to blame: bindist was not updated. A temporary work around I'm using is {{{ + $(filter-out testsuite/utils/check-ppr/% testsuite/utils/check-api- annotations/% %/project.mk mk/config.mk %/mk/install.mk,$(MAKEFILE_LIST)) \ }}} in top level {{{ghc.mk}}} in {{{bindist-list}}} {{{eval}}} section. I have reported this in #ghc to Ben but I am creating this ticket such that we can track the progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14392> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11259: Use system runtime linker in GHCi on PowerPC 64 bit
by GHC 14 Jun '18

14 Jun '18

#11259: Use system runtime linker in GHCi on PowerPC 64 bit -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.11 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: GHCi crash Test Case: ghcilink004, | Blocked By: prog001, and 11 more | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Teach GHCi to use the system runtime linker to load Haskell libraries on powerpc64. See the following test failures. ghcilink004: {{{ ghc-stage2: dir004/libfoo.a: unknown architecture (e_machine == 21) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151219 for powerpc64-unknown-linux): loadArchive "dir004/libfoo.a": failed CallStack (from ImplicitParams): error, called at libraries/ghci/GHCi/ObjLink.hs:91:21 in ghci-0.0:GHCi.ObjLink Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} prog001: {{{ ghc-iserv.bin: /home/peter/ghc/libraries/ghc-prim/dist-install/build /libHSghc-prim-0.5.0.0.a: unknown architecture (e_machine == 21) ghc-iserv.bin: loadArchive "/home/peter/ghc/libraries/ghc-prim/dist- install/build/libHSghc-prim-0.5.0.0.a": failed CallStack (from ImplicitParams): error, called at libraries/ghci/GHCi/ObjLink.hs:91:21 in ghci-0.0:GHCi.ObjLink ghc-stage2: ghc-iserv terminated (1) }}} Using the system runtime linker fixes 13 failing tests. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11259> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13634: num009 fails on POWER8
by GHC 14 Jun '18

14 Jun '18

#13634: num009 fails on POWER8 -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.1 libraries/base | Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Incorrect result Test Case: | at runtime libraries/base/tests/Numeric/num009| Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This failure is produced on a POWER8 running openSUSE Leap 42.2 for powerpc64le: {{{ +uh oh! tanf 1.5707964 +-2.2877334e7 +-2.2877332e7 +(-11438667,1) +(-11438666,1) Done }}} The test passes on a PowerPC 970MP (PowerMac G5) running openSUSE 13.2 powerpc64 (big endian). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13634> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12903: SIGINT is not handled in forked process
by GHC 14 Jun '18

14 Jun '18

#12903: SIGINT is not handled in forked process -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | 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: -------------------------------------+------------------------------------- If haskell program is forked in a toplevel hander that sends UserInterrupt in the main thread doesn't work, because Thread 1 doesn't exists in forked program, so that action is noop. Minimal example: {{{#!hs import Control.Concurrent import Control.Exception import System.Posix main = do pid <- forkProcess $ do handle (\UserInterrupt{} -> putStrLn "caught") $ threadDelay 2000000 signalProcess sigINT pid threadDelay 2000000 }}} Expected result: "caught" printed to stdout. Actual result: nothing is printed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12903> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13564: Why does memory usage increase so much during CoreTidy?
by GHC 13 Jun '18

13 Jun '18

#13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- I made GHC display the live data size before and after each pass and while compiling DynFlags, the live data size increased by almost 50% during the CoreTidy pass, even though the Core program size hardly changed: {{{ ... Result size of Simplifier = {terms: 104,494, types: 264,683, coercions: 15,760, joins: 58/680} !!! Simplifier [DynFlags]: 19.69 221248736: finished in 5337.48 milliseconds, allocated 4416.624 megabytes *** Demand analysis [DynFlags]: 19.69 221248152: Result size of Demand analysis = {terms: 104,494, types: 264,683, coercions: 15,760, joins: 58/680} !!! Demand analysis [DynFlags]: 20.77 248604416: finished in 1349.45 milliseconds, allocated 2298.950 megabytes *** CoreTidy [DynFlags]: 20.77 248603432: Result size of Tidy Core = {terms: 104,440, types: 264,565, coercions: 15,700, joins: 58/679} !!! CoreTidy [DynFlags]: 21.43 342594336: finished in 1124.37 milliseconds, allocated 736.209 megabytes }}} I find the amount of this increase surprising considering what CoreTidy does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13564> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17