July 2017 - ghc-tickets

[GHC] #12970: Add default implementation for Bits.bitSize
by GHC 17 Jun '18

17 Jun '18

#12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 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 think it would be a good idea to provide a default implementation for bitSize, example: {{{#!hs bitSize b = fromMaybe (error "bitSize is undefined") (bitSizeMaybe b) }}} The advantage is that from now on new instances of Bits no longer need to define bitSize. And once bitSize has been removed there will be no errors about it not being a method of class Bits. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #13576: Runtime crashes on arm64 (iOS)
by GHC 16 Jun '18

16 Jun '18

#13576: Runtime crashes on arm64 (iOS) ----------------------------------------+---------------------------------- Reporter: jp.rider63 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- I compiled GHC from source (ff84d052850b637b0) with a few modifications to create a cross-compiler for arm64. This was the configuration: {{{ CC=aarch64-apple-darwin14-clang ./configure --prefix=/usr/local/ghc-ios --target=aarch64-apple-darwin14 --disable-large-address-space --enable- bootstrap-with-devel-snapshot }}} Here's my "mk/build.mk": {{{ HADDOCK_DOCS=NO WITH_TERMINFO=NO DYNAMIC_BY_DEFAULT=NO DYNAMIC_GHC_PROGRAMS=NO DYNAMIC_TOO=NO }}} I used the stage1 compiler to export an arm64 library. The application (which links the library) crashes when run on my device (iOS 10.2.1). The application runs without issue on x86 and arm32. When I initialize with -DS, I get the following error: {{{ internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 88 (GHC version 8.3.20170408 for aarch64_apple_ios) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug // SIGABRT at line 182 in RtsMessages.c }}} To narrow down the offending code, I replaced all my functions with print statements and slowly added the functionality back until I could reproduce the crash. It looks like the crash happens around a call to this function: {{{ foreign export ccall hs_AAPublicKeyAlgorithm :: StablePtr AA.PublicKey -> IO CString hs_AAPublicKeyAlgorithm :: StablePtr AA.PublicKey -> IO CString hs_AAPublicKeyAlgorithm = hs_toAlgorithmIdentifier hs_toAlgorithmIdentifier :: (ToAlgorithm t a, AlgorithmId a) => StablePtr t -> IO CString hs_toAlgorithmIdentifier ptr = do algId <- fmap (toAlgorithmId . toAlgorithm) $ deRefStablePtr ptr newCString algId }}} Oddly, when I add print statements around this call, I get a EXC_BREAKPOINT instead of a SIGABRT. Here's the output for this case: {{{ ****************TEST************ ****************TEST************ ****************TEST************ ****************TEST************ v1K_FZuskg6Bkm-whFvkQ8IzHxnXDSGibCwbqZpM0fk= here ****************TEST************ here1 here2 }}} I've disabled dead code stripping. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13576> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12951: Remove __USE_MINGW_ANSI_STDIO define from PosixSource.h
by GHC 16 Jun '18

16 Jun '18

#12951: Remove __USE_MINGW_ANSI_STDIO define from PosixSource.h -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.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: -------------------------------------+------------------------------------- This was a stop-gap measure to allow users to build GHC 8.2 with 7.10.1 and 7.10.2. It can be removed for 8.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12951> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13008: Cleanup backwards compatibility ifdefs due to stage1 external interpreter work
by GHC 16 Jun '18

16 Jun '18

#13008: Cleanup backwards compatibility ifdefs due to stage1 external interpreter work -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- https://phabricator.haskell.org/D2826 and https://phabricator.haskell.org/D2884 make some code paths that were incompatible with GHC 7.10.x newly built by the stage0 compiler, requiring some CPP hackery to keep our compatibility guarantees. When we can drop that dependency, we should be sure to remove the old code paths. Specifically, the checks for MIN_VERSION_base(4,9,0) and MIN_VERSION_process(1,4,2) can be removed once we're able to assume ghc 8.0.x as stage0. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13008> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[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] #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] #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