June 2018 - ghc-tickets

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

17 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 17 Jun '18

17 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 17 Jun '18

17 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 17 Jun '18

17 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] #15255: overflow1 breaks on i386
by GHC 17 Jun '18

17 Jun '18

#15255: overflow1 breaks on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | 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 i386 CircleCI target is showing a mysterious failure of the `overflow1` test: {{{ =====> overflow1(normal) 4082 of 6414 [0, 3, 0] Wrong exit code for overflow1(normal)(expected 251 , actual 0 ) *** unexpected failure for overflow1(normal) }}} Need to work out what is going on here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15255> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15242: Typechecker sometimes doesn't preserve HsPar in original source.
by GHC 17 Jun '18

17 Jun '18

#15242: Typechecker sometimes doesn't preserve HsPar in original source. -------------------------------------+------------------------------------- Reporter: wz1000 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The typechecker doesn't preserve parenthesis that occur at the head of applications. This results in some weird SrcSpans in the TypecheckedSource For example, given code {{{#!hs foo a b c = (bar a) b c }}} The typechecker will emit an HsApp with head spanning over `bar a) b` and tail spanning over `c`. Notice that the opening parenthesis is not included. On the other hand, the renamer will generate the expected SrcSpans that always include both parenthesis, or neither. This becomes an issue when you want to associate RenamedSource with its corresponding TypecheckedSource, as the SrcSpans no longer match and overlap partially. This occurs due to this line in TcExpr.hs {{{#!hs tcApp m_herald (L _ (HsPar _ fun)) args res_ty = tcApp m_herald fun args res_ty }}} I have a work in progress fix here: https://github.com/wz1000/ghc/commit/3b6db5a35dc8677a7187e349a85ffd51f45245… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15242> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

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

17 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] Batch modify: #9221, #9244, #9248, #9775, #9832, #10352, #10431, ...
by GHC 17 Jun '18

17 Jun '18

Batch modification to #9221, #9244, #9248, #9775, #9832, #10352, #10431, #10542, #10599, #10770, #10789, #10803, #10822, #10844, #10853, #10878, #10892, #10962, #10972, #11092, #11149, #11197, #11204, #11222, #11243, #11261, #11307, #11323, #11359, #11369, #11384, #11394, #11409, #11445, #11457, #11474, #11503, #11526, #11549, #11587, #11594, #11634, #11686, #11719, #11749, #11836, #11953, #11955, #12021, #12090, #12193, #12388, #12428, #12581, #12599, #12636, #12652, #12665, #12765, #12774, #12798, #12808, #12875, #12891, #12913, #12926, #12932, #12934, #12937, #12940, #12941, #12949, #12965, #13002, #13003, #13065, #13069 by bgamari: milestone to 8.8.1 Comment: These won't be fixed for 8.6, bumping to 8.8. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=9221%2C9244%2C9248%2C9775%2C9832%2…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

17 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 17 Jun '18

17 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