June 2016 - ghc-tickets

[GHC] #10332: AArch64 : divbyzero test fails
by GHC 07 Dec '16

07 Dec '16

#10332: AArch64 : divbyzero test fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: Incorrect result Test Case: | at runtime testsuite/tests/rts/divbyzero.hs | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- On AArch64/Linux the test in `testsuite/tests/rts/divbyzero.hs` which is: {{{ main :: IO () main = print (5 `divInt` 0) }}} just prints "0" and exits with a zero status code. From the "ARMv8 Instriction Set Overview" document I found (wasn't able to find anything more recent): https://www.element14.com/community/servlet/JiveServlet/downloadBody/41836-… Section 3.6 says "There is no hardware check for “divide by zero”, but this check can be performed in the shadow of a long latency division. A divide by zero writes zero to the destination register." Looks like we need extra code to check for this, but not sure how to report it. Should probably look at what GCC and Clang do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10332> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel
by GHC 07 Dec '16

07 Dec '16

#10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: Building GHC Test Case: | failed Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Compiling git HEAD (e02ef0e6d4eefa5f0) on AArch64 hardware using ghc-7.6.3 from Debian as the bootstrap compiler. LLVM is version 3.6. It fails with: {{{ "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fllvm \ -this-package-key paral_2NTMt5X9WUG6LNupBFIZti -hide-all-packages -i \ -ilibraries/parallel/. -ilibraries/parallel/dist-install/build \ -ilibraries/parallel/dist-install/build/autogen \ -Ilibraries/parallel/dist-install/build \ -Ilibraries/parallel/dist-install/build/autogen -Ilibraries/parallel/. \ -optP-include -optPlibraries/parallel/dist- install/build/autogen/cabal_macros.h \ -package-key array_BLJREAlFJ4zJ2kSDphVieY -package-key base_8gvrDSBdaidLA14EDtK6ja \ -package-key conta_1uqbEcrmZiO1C91Z8ePoyI -package-key deeps_Bw45clVBNVT4S1LLyUOPfh \ -Wall -feager-blackholing -XHaskell2010 -O -fllvm -no-user-package- db -rtsopts \ -odir libraries/parallel/dist-install/build \ -hidir libraries/parallel/dist-install/build \ -stubdir libraries/parallel/dist-install/build \ -dynamic-too -c libraries/parallel/./Control/Parallel/Strategies.hs \ -o libraries/parallel/dist- install/build/Control/Parallel/Strategies.o \ -dyno libraries/parallel/dist- install/build/Control/Parallel/Strategies.dyn_o libraries/parallel/ghc.mk:5: recipe for target 'libraries/parallel/dist-install/build/Control/Parallel/Strategies.o' failed make[1]: *** [libraries/parallel/dist- install/build/Control/Parallel/Strategies.o] Segmentation fault }}} It seems that `inplace/lib/bin/ghc-stage1` (which is working fine) is statically linked to all the Haskell libraries where as `inplace/lib/bin /ghc-stage2` is dynamically linked which would explain why stage1 works fine and stage2 segfaults. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10174> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11578: Fix GHC on AArch64/Arm64
by GHC 07 Dec '16

07 Dec '16

#11578: Fix GHC on AArch64/Arm64 --------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- Raising this to track discussion about GHC on Arm64. There is already some discussion in ticket #11206 (ARM is generally a disaster), but that ticket is about 32 bit Arm which is vastly different and is now mostly fixed. Information worth saving from #11206: * GHC 7.8.4 from Debian can build the ghc-8.0 branch, but cannot build HEAD because HEAD requires ghc-7.10 to build. * GHC 7.10 from Debian is broken because of an unfixed bug in llvm-3.5.2. * User @mfox reports that ghc-7.10 does build against llvm-3.7 and results in a compiler that can build HEAD. * That GHC 7.10 can be build against llvm-3.7 is a happy accident. Versions of GHC are usually locked to a specific version of LLVM. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11578> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10962: Improved arithmetic primops
by GHC 07 Dec '16

07 Dec '16

#10962: Improved arithmetic primops -------------------------------------+------------------------------------- Reporter: nkaretnikov | Owner: nkaretnikov Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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://ghc.haskell.org/trac/ghc/wiki/ImprovedArithmeticPrimops -------------------------------------+------------------------------------- See the todo list on the wiki page. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10962> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8224: Excessive system time -- new IO manager problem?
by GHC 07 Dec '16

07 Dec '16

#8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Keywords: IO Manager, | Operating System: Linux System Time | Type of failure: Runtime Architecture: x86_64 (amd64) | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- This is an issue that came to light when testing the patches on #910. You can see some of the numbers there. Basically, recent GHC HEAD builds, running a large number of threads blocked on MVars will result in burning a lot of system time. The attached file provides a mediocre reproducer. With it, you can see that building with HEAD as of Aug 31st and running with `-RTS -N32` will result in around 200ms system time, whereas GHC 7.6.3 spends about 30ms in system time. This shows the disparity, but the result is not that egregious. A more noticeable example is on ticket #910, where when running on 31 threads, there is an 8 minutes of system time for 17 minutes of user time, and yet at one thread that system time drops to under two seconds! {{{ 1 thread: real 1m20.028s user 1m17.921s sys 0m1.768s 31 threads: real 1m27.445s user 17m0.314s sys 8m0.175s }}} It needs to be determined whether this system time is a result of the parallel compilation patches on #910, or whether it is a new problem with the runtime system, and in particular with the parallel IO manager. I am inclined to believe that compiling in parallel involves extra IO (repeatedly reading interface files?), but not eight minutes of it!! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40

[GHC] #11548: Absolutely misleading error message on kind error
by GHC 07 Dec '16

07 Dec '16

#11548: Absolutely misleading error message on kind error -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs module Bug where import Data.Proxy fun :: Proxy a -> () fun Proxy = () bug :: () bug = fun (Proxy :: Proxy Maybe) }}} {{{#!hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:12: error: • Expected kind ‘Proxy Maybe’, but ‘Data.Proxy.Proxy :: Proxy Maybe’ has kind ‘Proxy Maybe’ • In the first argument of ‘fun’, namely ‘(Proxy :: Proxy Maybe)’ In the expression: fun (Proxy :: Proxy Maybe) In an equation for ‘bug’: bug = fun (Proxy :: Proxy Maybe) }}} 7.10 gives the appropriate `Couldn't match kind ‘* -> *’ with ‘*’` message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11548> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11485: Very unhelpful message resulting from kind mismatch
by GHC 07 Dec '16

07 Dec '16

#11485: Very unhelpful message resulting from kind mismatch -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (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 following code: {{{#!hs module Foo where import Data.Typeable tyConOf :: Typeable a => Proxy a -> TyCon tyConOf = typeRepTyCon . typeRep tcList :: TyCon tcList = tyConOf (Proxy :: Proxy []) }}} fails because `-XPolyKinds` is not enabled. But the error message that you get is quite different on GHC 7.10 and 8.0. On GHC 7.10.3: {{{ [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Foo.hs:9:19: Couldn't match kind ‘* -> *’ with ‘*’ Expected type: Proxy a0 Actual type: Proxy [] In the first argument of ‘tyConOf’, namely ‘(Proxy :: Proxy [])’ In the expression: tyConOf (Proxy :: Proxy []) In an equation for ‘tcList’: tcList = tyConOf (Proxy :: Proxy []) }}} But on GHC 8.0.1-rc1: {{{ Foo.hs:9:19: error: • Expected kind ‘Proxy []’, but ‘Data.Proxy.Proxy :: Proxy []’ has kind ‘Proxy []’ • In the first argument of ‘tyConOf’, namely ‘(Proxy :: Proxy [])’ In the expression: tyConOf (Proxy :: Proxy []) In an equation for ‘tcList’: tcList = tyConOf (Proxy :: Proxy []) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11485> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12141: Testsuite failures when GHC is built with 'quickest' profile
by GHC 02 Dec '16

02 Dec '16

#12141: Testsuite failures when GHC is built with 'quickest' profile -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After building GHC HEAD with the `quickest` setting and running 'make test', here is the testsuite failures (I've included the perf-related tests' for completeness's sake, although they're probably spurious): {{{ Unexpected results from: TEST="T10083 T8848 linker_unload debug T4930 HyperStrUse integerConstantFolding T9938 T3717 break011 T9938B T7796 break013 T8639_api spec-inline T9220 T4306 T8628 T5623 T7360 T10694 T6056 AmapCoerce T7837 T4018 IntegerConversionRules prog001 T11195 T10482 break024 T9881 EvalTest T4007 UnsatFun T3055 T3234 T4908 T7865 T5327 T8832 dynCompileExpr ghci004 T7116 ghci006 T8598 T2110 tcfail072 ghci025 T10482a T10508_api T3772 T10830 T9872d T4830 T9872a T9872b T9872c T9233 T9020 InlineByteArrayAlloc T5536 T5949 T7954 lazy-bs-alloc T5321Fun T3064 parsing001 T4801 T5030 T5642 T3924 Conversions T5237 T876 T5549 T9848 T7619 T5631 T9203 T8766 T3294 InlineCloneArrayAlloc T4334 MethSharing T7257 InlineArrayAlloc T5205 T3586 T10547 T783 T6048 T4474a T4474c T4474b T9675 T3738 T5113 T5321FD T5837 T4029 T9339 T10359 T7797 T9961 T4978 T1969 T4267 space_leak_001" OVERALL SUMMARY for test run started at Wed Jun 1 18:03:49 2016 EDT 0:15:57 spent to go through 5174 total tests, which gave rise to 16207 test cases, of which 10987 were skipped 71 had missing libraries 4925 expected passes 116 expected failures 0 caused framework failures 1 unexpected passes 51 unexpected failures 56 unexpected stat failures Unexpected passes: /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/T10083 T10083 (normal) Unexpected failures: /tmp/ghctest/_iBKeQ/1/2/3/../../libraries/array/tests/T9220 T9220 [bad stdout] (ghci) /tmp/ghctest/_iBKeQ/1/2/3/./codeGen/should_compile/debug debug [bad stdout] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./driver/T9938 T9938 [bad exit code] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./driver/T9938B T9938B [bad exit code] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./ghc-api/T10508_api T10508_api [bad exit code] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./ghc-api/T8628 T8628 [bad exit code] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./ghc-api/T8639_api T8639_api [bad exit code] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./ghc-api/dynCompileExpr/dynCompileExpr dynCompileExpr [bad exit code] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./ghci.debugger/scripts/break011 break011 [bad stdout] (ghci) /tmp/ghctest/_iBKeQ/1/2/3/./ghci.debugger/scripts/break013 break013 [bad stdout] (ghci) /tmp/ghctest/_iBKeQ/1/2/3/./ghci.debugger/scripts/break024 break024 [bad stdout] (ghci) /tmp/ghctest/_iBKeQ/1/2/3/./ghci/prog001/prog001 prog001 [bad exit code] (ghci-ext) /tmp/ghctest/_iBKeQ/1/2/3/./ghci/scripts/T9881 T9881 [bad stdout] (ghci) /tmp/ghctest/_iBKeQ/1/2/3/./ghci/scripts/ghci004 ghci004 [bad exit code] (ghci-ext) /tmp/ghctest/_iBKeQ/1/2/3/./ghci/scripts/ghci006 ghci006 [bad exit code] (ghci-ext) /tmp/ghctest/_iBKeQ/1/2/3/./ghci/scripts/ghci025 ghci025 [bad stdout] (ghci) /tmp/ghctest/_iBKeQ/1/2/3/./indexed-types/should_compile/T7837 T7837 [stderr mismatch] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./lib/integer/IntegerConversionRules IntegerConversionRules [bad stdout] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./lib/integer/integerConstantFolding integerConstantFolding [bad stdout] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./numeric/should_compile/T7116 T7116 [bad stdout] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T4007 T4007 [bad stdout] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/space_leaks/T4018 T4018 [bad exit code] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./pmcheck/should_compile/T11195 T11195 [exit code non-0] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./rts/linker_unload linker_unload [bad exit code] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/EvalTest EvalTest [bad stdout] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/T3055 T3055 [bad stdout] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/T3234 T3234 [stderr mismatch] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/T3717 T3717 [stderr mismatch] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/T3772 T3772 [bad stdout] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/T4306 T4306 [bad stdout] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/T4908 T4908 [stderr mismatch] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/T4930 T4930 [stderr mismatch] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/T5327 T5327 [bad exit code] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/T5623 T5623 [bad exit code] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/T6056 T6056 [stderr mismatch] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/T7360 T7360 [stderr mismatch] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/T7796 T7796 [bad stdout] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/T7865 T7865 [bad stdout] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/T8832 T8832 [bad stdout] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/T8848 T8848 [stderr mismatch] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_compile/spec-inline spec-inline [stderr mismatch] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_run/AmapCoerce AmapCoerce [bad stdout] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_run/T10830 T10830 [bad exit code] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./simplCore/should_run/T2110 T2110 [bad stdout] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./stranal/should_compile/T10482 T10482 [stderr mismatch] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./stranal/should_compile/T10482a T10482a [stderr mismatch] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./stranal/should_compile/T10694 T10694 [stderr mismatch] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./stranal/sigs/HyperStrUse HyperStrUse [stderr mismatch] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./stranal/sigs/T8598 T8598 [stderr mismatch] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./stranal/sigs/UnsatFun UnsatFun [stderr mismatch] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./typecheck/should_fail/tcfail072 tcfail072 [stderr mismatch] (normal) Unexpected stat failures: /tmp/ghctest/_iBKeQ/1/2/3/../../libraries/base/tests/T8766 T8766 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/../../libraries/base/tests/T9848 T9848 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./callarity/perf/T3924 T3924 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T10547 T10547 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T1969 T1969 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T3064 T3064 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T3294 T3294 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T4801 T4801 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T5030 T5030 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T5321FD T5321FD [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T5321Fun T5321Fun [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T5631 T5631 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T5642 T5642 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T5837 T5837 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T6048 T6048 [stat not good enough] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T783 T783 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T9020 T9020 [stat not good enough] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T9233 T9233 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T9675 T9675 [stat not good enough] (optasm) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T9872a T9872a [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T9872b T9872b [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T9872c T9872c [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T9872d T9872d [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/T9961 T9961 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/compiler/parsing001 parsing001 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/Conversions Conversions [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/InlineArrayAlloc InlineArrayAlloc [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/InlineByteArrayAlloc InlineByteArrayAlloc [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/InlineCloneArrayAlloc InlineCloneArrayAlloc [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/MethSharing MethSharing [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T10359 T10359 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T3586 T3586 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T3738 T3738 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T4267 T4267 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T4474a T4474a [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T4474b T4474b [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T4474c T4474c [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T4830 T4830 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T4978 T4978 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T5113 T5113 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T5205 T5205 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T5237 T5237 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T5536 T5536 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T5549 T5549 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T5949 T5949 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T7257 T7257 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T7619 T7619 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T7797 T7797 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T7954 T7954 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T876 T876 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T9203 T9203 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/T9339 T9339 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/should_run/lazy-bs-alloc lazy-bs-alloc [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/space_leaks/T4029 T4029 [stat too good] (ghci) /tmp/ghctest/_iBKeQ/1/2/3/./perf/space_leaks/T4334 T4334 [stat not good enough] (normal) /tmp/ghctest/_iBKeQ/1/2/3/./perf/space_leaks/space_leak_001 space_leak_001 [stat not good enough] (normal) }}} I can't reproduce these issues when testing with GHC built with the `quick` setting. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12141> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10812: High memory usage
by GHC 02 Dec '16

02 Dec '16

#10812: High memory usage -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hello, lets consider following program: {{{ {-# LANGUAGE NoMonomorphismRestriction #-} import System.Mem.Weak import Control.Concurrent import System.Mem data Tst a = Tst a deriving (Show, Eq) tst a = do let arr = [0 .. a*a*a] v = Tst (seq arr arr) ptr <- mkWeakPtr v Nothing return ptr main = do ptrs <- mapM tst [1..100000000] --performGC --performMajorGC --performMinorGC threadDelay 1000000 xr <- mapM deRefWeak ptrs print $ length $ filter (/= Nothing) xr threadDelay 5000000 return () }}} It simply creates 10 million of weak references to values of {{{Tst}}}. These weak pointers are returned in the main function. After that we sleep a second and ask how meany references are alive. I get the {{{0}}} as a result here - so everything seems ok - garbage collection worked. There is a problem though - somehow the memory was not released, because on the second 5-second sleep the program uses over 14 Gb of RAM on my computer. I'm compiling it simply with {{{ghc -O2 Main.hs}}}. I'm pretty sure this is a bug, because such behaviour is not expected I think. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10812> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P`
by GHC 01 Dec '16

01 Dec '16

#11744: Latest Xcode update violates POSIX compliance of `nm -P` ----------------------------------------+--------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- TLDR: Apple messed up again and broke POSIX compliance luite ran into problems when he installed the latest Xcode update because the derived platform constants were off. He provided me the output of `nm -P ./includes/dist- derivedconstants/header/tmp.o` which turned out have numbers which didn't make sense: {{{ _derivedConstantAP_STACK_SPLIM C 1025 0 _derivedConstantBITMAP_BITS_SHIFT C 7 0 _derivedConstantBLOCKS_PER_MBLOCK C 253 0 _derivedConstantBLOCK_SIZE C 4097 0 _derivedConstantCINT_SIZE C 5 0 _derivedConstantCLONG_LONG_SIZE C 9 0 _derivedConstantCLONG_SIZE C 9 0 _derivedConstantDOUBLE_SIZE C 9 0 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0 ... }}} Which with an older Xcode version would have looked like {{{ _derivedConstantAP_STACK_SPLIM C 401 0 _derivedConstantBITMAP_BITS_SHIFT C 7 0 _derivedConstantBLOCKS_PER_MBLOCK C fd 0 _derivedConstantBLOCK_SIZE C 1001 0 _derivedConstantCINT_SIZE C 5 0 _derivedConstantCLONG_LONG_SIZE C 9 0 _derivedConstantCLONG_SIZE C 9 0 _derivedConstantDOUBLE_SIZE C 9 0 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0 ... }}} So obviously `nm -P`'s output changed from hexadecimal to (non-compliant) decimal formatting of numbers. For reference, here's how POSIX specifies the semantics of `nm`: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/nm.html > `-P` > Write information in a portable output format, as specified in the STDOUT section. ... > If the `-P` option is specified, the previous information shall be displayed using the following portable format. The three versions differ depending on whether `-t d`, `-t o`, or `-t x` was specified, respectively: > > {{{"%s%s %s %d %d\n", <library/object name>, <name>, <type>, <value>, <size>}}} > > {{{"%s%s %s %o %o\n", <library/object name>, <name>, <type>, <value>, <size>}}} > > {{{"%s%s %s %x %x\n", <library/object name>, <name>, <type>, <value>, <size>}}} In the event that Apple can't be bothered to fix this bug (I've had bad experience with Apple and standard-compliance in the past, hence my pessimism) we could try to workaround by using `nm -P -t x` when building on OSX... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22