February 2018 - 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] #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets:
by GHC 16 Jun '18

16 Jun '18

#14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Build failure on current ghc-HEAD as: Build failure for armv7a-hardfloat-linux-gnueabi: {{{ Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux- gnueabihf","armv7-unknown-linux-gnueabihf","aarch64-unknown-linux- gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386-unknown- linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7-unknown- linux-androideabi","aarch64-unknown-linux-android","arm-unknown-nto-qnx- eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple-ios","aarch64 -apple-ios","i386-apple-ios","x86_64-apple-ios"] }}} Build failure for armv7a-unknown-linux-gnueabi {{{ Failed to lookup the datalayout for armv7a-unknown-linux-gnueabi; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux- gnueabihf","armv7-unknown-linux-gnueabihf","aarch64-unknown-linux- gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386-unknown- linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7-unknown- linux-androideabi","aarch64-unknown-linux-android","arm-unknown-nto-qnx- eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple-ios","aarch64 -apple-ios","i386-apple-ios","x86_64-apple-ios"] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14261> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14656: Nofib: Ignore cr-lineendings in benchmarks
by GHC 16 Jun '18

16 Jun '18

#14656: Nofib: Ignore cr-lineendings in benchmarks -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib | Version: 8.2.2 benchmark suite | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At least the real/eff benchmarks fail because of this. {{{ ==nofib== CS: time to run CS follows... ../../../runstdtest/runstdtest ./CS -o1 CS.stdout -o1 CS.stdout -ghc- timing -stdout-binary ; ../../../runstdtest/runstdtest ./CS -o1 CS.stdout -o1 CS.stdout -ghc-timing -stdout-binary ; ../../../runstdtest/runstdtest ./CS -o1 CS.stdout -o1 CS.stdout -ghc- timing -stdout-binary ; ../../../runstdtest/runstdtest ./CS -o1 CS.stdout -o1 CS.stdout -ghc-timing -stdout-binary ; ../../../runstdtest/runstdtest ./CS -o1 CS.stdout -o1 CS.stdout -ghc- timing -stdout-binary ; real 0m0.173s user 0m0.000s sys 0m0.015s ././CS < /dev/null expected stdout not matched by reality <<ghc: 640047168 bytes, 611 GCs (609 + 2), 0/0 avg/max bytes residency (0 samples), 290232 bytes GC work, 2M in use, 0.000 INIT (0.000 elapsed), 0.125 MUT (0.124 elapsed), 0.000 GC (0.001 elapsed), 0.000 GC(0) (0.001 elapsed), 0.000 GC(1) (0.001 elapsed), 1 balance :ghc>> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14656> 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] #14416: CI with CircleCI
by GHC 16 Jun '18

16 Jun '18

#14416: CI with CircleCI -------------------------------------+------------------------------------- Reporter: chak | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Build System | Version: 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: | ContinuousIntegration -------------------------------------+------------------------------------- Merging the PR with the new CircleCI per-commit builds for Linux/x86_64 and macOS/x86_64: https://github.com/ghc/ghc/pull/83 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14416> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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