May 2018 - ghc-tickets

[GHC] #14295: tagToEnum# leads to some silly closures
by GHC 17 Jun '18

17 Jun '18

#14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: datacon-tags | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I don't know how important this is in practice, but it smells pretty silly. Suppose I write {{{#!hs foo :: (Bool -> a) -> Int# -> a foo f x = f (tagToEnum# x) }}} Since `tagToEnum#` can fail, GHC compiles this to {{{#!hs foo = \ (@ a_a10v) (f_s1by [Occ=Once!] :: GHC.Types.Bool -> a_a10v) (x_s1bz [Occ=Once] :: GHC.Prim.Int#) -> let { sat_s1bA [Occ=Once] :: GHC.Types.Bool [LclId] sat_s1bA = GHC.Prim.tagToEnum# @ GHC.Types.Bool x_s1bz } in f_s1by sat_s1bA }}} That seems pretty silly! We know that `tagToEnum#` is applied to `Bool`, so we can transform this to something like {{{#!hs foo f x = case x <=# 1# of 1# -> f $! tagToEnum# x _ -> f (error "tagToEnum# was used at Bool with tag ...") }}} which avoids an extra closure at the cost of a single `Int#` comparison. The same goes for arbitrary known enumeration types. I suspect the right place to fix this up is in CorePrep. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14295> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[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] #15134: enumFrom... aren't really documented.
by GHC 16 Jun '18

16 Jun '18

#15134: enumFrom... aren't really documented. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The Haddocks for `enumFrom`, `enumFromTo`, etc., say nothing whatsoever about what these functions actually do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15134> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[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] #15062: num009 is incredibly platform-sensitive
by GHC 16 Jun '18

16 Jun '18

#15062: num009 is incredibly platform-sensitive -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.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: -------------------------------------+------------------------------------- The functions tested by `num009` are certainly worthwhile to test, but we really need to find a better way to test them. Currently the test seemingly fails in more places than it passes: * Fails on Darwin (#2370) * Fails on POWER8 (#13634) * Fails on Win32 when in the `ghci` way (no ticket) * Fails under i386 on CircleCI (e.g. https://circleci.com/gh/ghc/ghc/3666) Perhaps we should instead test the output against the same evaluations performed by a C program. This would eliminate spurious failures due to platform or C library differences. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15062> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[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