August 2018 - ghc-tickets

[GHC] #14980: Runtime performance regression with binary operations on vectors
by GHC 23 Oct '18

23 Oct '18

#14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: vector | Operating System: Unknown/Multiple bitwise operations | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Let me briefly explain our use case: we have a machine learning tools created in Haskell. Basically it builds association rules for a database. In plain English: predicates on data rows. We need to score them, so we need to check how many rows are "matched" by the predicate. In order to optimize performance, our code uses two main representations for data: one is a "human readable", where a values are real values. The second one is binarized representation for categorical data. The latter has is actually a family of representation, since we pack bits into tuples of Word64 and use bitwise operation to implement logic. Simplified but representative code is attached. In GHC 8.0.2 binary representation is faster by one order of magnitude than the "human readable" one: {{{ ➜ ghc-bug stack exec performance-bug-pair-1 "Generated" benchmarking 256 columns/raw unbox vectors time 342.6 μs (338.3 μs .. 348.0 μs) 0.999 R² (0.998 R² .. 1.000 R²) mean 339.3 μs (337.5 μs .. 342.0 μs) std dev 7.203 μs (5.596 μs .. 10.07 μs) variance introduced by outliers: 13% (moderately inflated) benchmarking 256 columns/binary packed time 32.07 μs (29.69 μs .. 34.14 μs) 0.982 R² (0.976 R² .. 0.997 R²) mean 29.97 μs (29.41 μs .. 31.03 μs) std dev 2.428 μs (1.526 μs .. 3.750 μs) variance introduced by outliers: 78% (severely inflated) }}} In GHC 8.2.2 (and later) binary representation performance is similar to "human readable", so no performance gain: {{{ ➜ ghc-bug stack exec performance-bug-pair-1 "Generated" benchmarking 256 columns/raw unbox vectors time 442.4 μs (406.7 μs .. 474.5 μs) 0.978 R² (0.969 R² .. 0.993 R²) mean 399.3 μs (391.3 μs .. 415.1 μs) std dev 34.73 μs (20.36 μs .. 53.29 μs) variance introduced by outliers: 71% (severely inflated) benchmarking 256 columns/binary packed time 378.6 μs (295.8 μs .. 488.0 μs) 0.637 R² (0.492 R² .. 0.780 R²) mean 568.1 μs (437.1 μs .. 747.6 μs) std dev 308.7 μs (233.6 μs .. 386.1 μs) variance introduced by outliers: 98% (severely inflated) }}} However, for certain compilation paths, we still can get similar speedup as with GHC 8.0.2. In the above examples we used 4-tuple of Word64 as binary representation. In the following code we run two tests: one on just Word64 and one of 4-tuple of Word64. The difference is that we just add the Word64 case: {{{ ➜ ghc-bug stack exec performance-bug-pair-2 "Generated" benchmarking 64 columns/raw unbox vectors time 337.6 μs (336.1 μs .. 339.3 μs) 0.999 R² (0.998 R² .. 1.000 R²) mean 349.6 μs (344.4 μs .. 359.7 μs) std dev 23.22 μs (15.39 μs .. 38.22 μs) variance introduced by outliers: 60% (severely inflated) benchmarking 64 columns/binary packed time 21.66 μs (21.53 μs .. 21.79 μs) 1.000 R² (0.999 R² .. 1.000 R²) mean 21.68 μs (21.53 μs .. 21.89 μs) std dev 613.2 ns (466.0 ns .. 806.0 ns) variance introduced by outliers: 30% (moderately inflated) benchmarking 256 columns/raw unbox vectors time 344.5 μs (341.6 μs .. 348.2 μs) 0.999 R² (0.999 R² .. 1.000 R²) mean 345.1 μs (342.5 μs .. 349.3 μs) std dev 10.66 μs (7.997 μs .. 16.34 μs) variance introduced by outliers: 25% (moderately inflated) benchmarking 256 columns/binary packed time 28.04 μs (27.70 μs .. 28.46 μs) 0.999 R² (0.999 R² .. 1.000 R²) mean 28.05 μs (27.85 μs .. 28.30 μs) std dev 758.2 ns (628.2 ns .. 907.6 ns) variance introduced by outliers: 27% (moderately inflated) }}} I made a variant of code with simpler accumulating function (in our code we accumulate pair of integers, simplified accumulator work on one integer). GHC 8.2.2 in that case losses speed-up with 4-tuples: {{{ ➜ ghc-bug stack exec performance-bug-2 "Generated" benchmarking 64 columns/raw unbox vectors time 333.8 μs (333.0 μs .. 335.1 μs) 1.000 R² (0.999 R² .. 1.000 R²) mean 333.6 μs (332.4 μs .. 335.8 μs) std dev 5.651 μs (3.233 μs .. 9.582 μs) benchmarking 64 columns/binary packed time 39.06 μs (38.98 μs .. 39.14 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 38.94 μs (38.83 μs .. 39.14 μs) std dev 495.0 ns (310.2 ns .. 782.1 ns) benchmarking 256 columns/raw unbox vectors time 336.9 μs (336.2 μs .. 337.9 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 337.5 μs (336.2 μs .. 339.8 μs) std dev 5.757 μs (2.946 μs .. 8.979 μs) benchmarking 256 columns/binary packed time 239.8 μs (237.6 μs .. 243.0 μs) 0.998 R² (0.996 R² .. 0.999 R²) mean 251.4 μs (247.9 μs .. 259.8 μs) std dev 11.50 μs (5.662 μs .. 19.79 μs) variance introduced by outliers: 37% (moderately inflated) }}} In GHC 8.0.2 we have speed-up in both cases. What may be related: using random-fu to generate random numbers seems to produce broken code on GHC 8.2.2 (the `performance-bug-rfu.hs` source). Short description of attached sources: - performance-bug-pair-2.hs: using two binary representations - performance-bug-pair-1.hs: using one binary representation (one case commented) - performance-bug-1.hs: using one binary representation with simplified accumulator - performance-bug-2.hs: using two binary representation with simplified accumulator - performance-bug-rfu.hs: using random-fu to generate data (optional) - stack-8.0.yaml: stack file for GHC-8.0.2 - stack-8.2.yaml: stack file for GHC-8.2.2 - stack-nightly.yaml: stack file for GHC-8.4 - performance-bug.cabal: to be able to stack build everything. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #15201: GHC 8.4 fails to build on Debian s390x
by GHC 22 Oct '18

22 Oct '18

#15201: GHC 8.4 fails to build on Debian s390x --------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: Other | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- {{{ "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -lffi -optl-pthread -Wall -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -package-db libraries/bootstrapping.conf -this-unit-id ghc-8.4.3 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -Icompiler/stage1/build -icompiler/stage1/build/./autogen -Icompiler/stage1/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -Icompiler/stage1/build/. -Icompiler/stage1/build/parser -Icompiler/stage1/build/utils -Icompiler/stage1/build/stage1 -optP- include -optPcompiler/stage1/build/./autogen/cabal_macros.h -package-id base-4.10.1.0 -package-id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id process-1.6.1.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 -package-id filepath-1.4.1.2 -package-id template-haskell-2.13.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.5.0 -package-id ghc-boot-8.4.3 -package-id ghc-boot- th-8.4.3 -package-id ghci-8.4.3 -package-id unix-2.7.2.2 -package-id terminfo-0.4.1.1 -Wall -Wno-name-shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -Wnoncanonical-monoid-instances -this- unit-id ghc -XHaskell2010 -XNoImplicitPrelude -DNO_REGS -DNOSMP -optc- DNOSMP -DSTAGE=1 -Rghc-timing -Wcpp-undef -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -c compiler/utils/GhcPrelude.hs -o compiler/stage1/build/GhcPrelude.o /tmp/ghcf6ae_0/ghc_3.hc:7:1: error: warning: data definition has no type or storage class EI_(ghczmprim_GHCziTypes_TrNameS_con_info); ^~~ | 7 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:7:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 7 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:7:1: error: warning: parameter names (without types) in function declaration | 7 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ In file included from /tmp/ghcf6ae_0/ghc_3.hc:3:0: error: /tmp/ghcf6ae_0/ghc_3.hc:8:5: error: error: conflicting types for 'ghc_GhcPrelude_zdtrModule4_bytes' EB_(ghc_GhcPrelude_zdtrModule4_bytes); ^ | 8 | EB_(ghc_GhcPrelude_zdtrModule4_bytes); | ^ includes/Stg.h:236:37: error: note: in definition of macro 'EB_' #define EB_(X) extern const char X[] ^ | 236 | #define EB_(X) extern const char X[] | ^ /tmp/ghcf6ae_0/ghc_3.hc:6:6: error: note: previous definition of 'ghc_GhcPrelude_zdtrModule4_bytes' was here char ghc_GhcPrelude_zdtrModule4_bytes[] = "ghc"; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 6 | char ghc_GhcPrelude_zdtrModule4_bytes[] = "ghc"; | ^ /tmp/ghcf6ae_0/ghc_3.hc:10:6: error: error: 'ghczmprim_GHCziTypes_TrNameS_con_info' undeclared here (not in a function) (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule4_bytes ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 10 | (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule4_bytes | ^ /tmp/ghcf6ae_0/ghc_3.hc:13:1: error: warning: data definition has no type or storage class EI_(ghczmprim_GHCziTypes_TrNameS_con_info); ^~~ | 13 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:13:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 13 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:13:1: error: warning: parameter names (without types) in function declaration | 13 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ In file included from /tmp/ghcf6ae_0/ghc_3.hc:3:0: error: /tmp/ghcf6ae_0/ghc_3.hc:14:5: error: error: conflicting types for 'ghc_GhcPrelude_zdtrModule2_bytes' EB_(ghc_GhcPrelude_zdtrModule2_bytes); ^ | 14 | EB_(ghc_GhcPrelude_zdtrModule2_bytes); | ^ includes/Stg.h:236:37: error: note: in definition of macro 'EB_' #define EB_(X) extern const char X[] ^ | 236 | #define EB_(X) extern const char X[] | ^ /tmp/ghcf6ae_0/ghc_3.hc:12:6: error: note: previous definition of 'ghc_GhcPrelude_zdtrModule2_bytes' was here char ghc_GhcPrelude_zdtrModule2_bytes[] = "GhcPrelude"; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 12 | char ghc_GhcPrelude_zdtrModule2_bytes[] = "GhcPrelude"; | ^ /tmp/ghcf6ae_0/ghc_3.hc:16:1: error: error: initializer element is not constant (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule2_bytes ^ | 16 | (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule2_bytes | ^ /tmp/ghcf6ae_0/ghc_3.hc:16:1: error: note: (near initialization for 'ghc_GhcPrelude_zdtrModule1_closure[0]') | 16 | (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule2_bytes | ^ /tmp/ghcf6ae_0/ghc_3.hc:18:1: error: warning: data definition has no type or storage class EI_(ghczmprim_GHCziTypes_Module_con_info); ^~~ | 18 | EI_(ghczmprim_GHCziTypes_Module_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:18:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 18 | EI_(ghczmprim_GHCziTypes_Module_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:18:1: error: warning: parameter names (without types) in function declaration | 18 | EI_(ghczmprim_GHCziTypes_Module_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:19:1: error: warning: data definition has no type or storage class EI_(ghc_GhcPrelude_zdtrModule1_closure); ^~~ | 19 | EI_(ghc_GhcPrelude_zdtrModule1_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:19:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 19 | EI_(ghc_GhcPrelude_zdtrModule1_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:19:1: error: warning: parameter names (without types) in function declaration | 19 | EI_(ghc_GhcPrelude_zdtrModule1_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:20:1: error: warning: data definition has no type or storage class EI_(ghc_GhcPrelude_zdtrModule3_closure); ^~~ | 20 | EI_(ghc_GhcPrelude_zdtrModule3_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:20:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 20 | EI_(ghc_GhcPrelude_zdtrModule3_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:20:1: error: warning: parameter names (without types) in function declaration | 20 | EI_(ghc_GhcPrelude_zdtrModule3_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:22:6: error: error: 'ghczmprim_GHCziTypes_Module_con_info' undeclared here (not in a function); did you mean 'ghczmprim_GHCziTypes_TrNameS_con_info'? (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ghczmprim_GHCziTypes_TrNameS_con_info | 22 | (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL | ^ /tmp/ghcf6ae_0/ghc_3.hc:22:1: error: error: initializer element is not constant (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL ^ | 22 | (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL | ^ /tmp/ghcf6ae_0/ghc_3.hc:22:1: error: note: (near initialization for 'ghc_GhcPrelude_zdtrModule_closure[0]') | 22 | (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL | ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) }}} https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=s390x&ver=8.4.3-1&s… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15201> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14909: Change default armhf target to a newer architecture
by GHC 21 Oct '18

21 Oct '18

#14909: Change default armhf target to a newer architecture -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the default [https://github.com/ghc/ghc/blob/60b06456ddef08bd8a8a47497a6cbefbb5e359fb /llvm-targets#L4 llvm-targets] file specifies the default `arm-unknown- linux-gnueabihf` target to be using `-mcpu=arm1176jzf-s`. Which is an `Armv6` architecture. This has the problem that it's generating memory barriers using `CP15` instructions that are deprecated in `Armv7` and removed in `Armv8`. Because of this there's no way to run the binaries being produced by GHC HQ on Armv8 CPUs without having kernel support for `CP15 Barrier emulation.` which is slow. We're also not taking advantage of new Armv8 instructions this way. The debian folks have a bug report about this as well https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864847 This means that GHC cannot work on most boards people have/can easily buy today. I think the default target should be an `Armv7` architecture at the very least. But realistically `Armv8` would probably be ok as well as I doubt many people use GHC to compile on older cores. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14909> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14461: Reuse free variable lists through nested closures
by GHC 21 Oct '18

21 Oct '18

#14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 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: 7258 Differential Rev(s): | Wiki Page: NestedClosures -------------------------------------+------------------------------------- Consider [wiki:NestedClosures] and [ticket:7258]; essentially, deeply nested closures exhibit quadratic compiler performance due to the fact that when allocating registers, each nesting level will have the compiler unpack the entire parent closure and then re-pack the variables into the child closure. To solve this, check if the parent closure can be carried along wholesale, and pull variables from there so that the repackaging can be bypassed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14461> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #14971: Use appropriatly sized comparison instruction for small values.
by GHC 21 Oct '18

21 Oct '18

#14971: Use appropriatly sized comparison instruction for small values. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: (CodeGen) | 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: -------------------------------------+------------------------------------- GHC currently defaults all comparisons originating from Cmm switch statements to 64bit on x64. This incurs a small overhead in instruction size. Fixing this manually gave a speedup of ~1,5% in microbenchmarks. In detail we generate Cmm of the form: {{{ _s8Dg::P64 = R1; _c8EF::P64 = _s8Dg::P64 & 7; switch [1 .. 2] _c8EF::P64 { case 1 : goto c8Ey; case 2 : goto c8EC; } }}} Which results in assembly like: {{{ andl $7,%ebx cmpq $1,%rbx }}} It's obvious that c8EF fits into a byte, but is sized up to 64 bits. Changing this would enable us to use cmpl instead of cmpq and save us a byte on each comparison. While this isn't major in my microbenchmarks it resultet in a speedup of ~1,5% for such constructs in inner loops. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14971> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15350: gcdExtInteger violates assertion
by GHC 21 Oct '18

21 Oct '18

#15350: gcdExtInteger violates assertion -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!haskell {-# LANGUAGE UnboxedTuples #-} import GHC.Integer.GMP.Internals main = let (# _, s #) = gcdExtInteger 2 (2^65 + 1) in print s }}} fails with {{{#!haskell Assertion failed: (sn <= mp_size_abs(xn)), function integer_gmp_gcdext, file libraries/integer-gmp/cbits/wrappers.c, line 316. Abort trap: 6 }}} It happens because `s = -2^64` and does not fit one-limbed `BigNat`. The implementation of `gcdExtInteger x y` (https://github.com/ghc/ghc/blob/master/libraries/integer- gmp/src/GHC/Integer/Type.hs#L1392) allocates for `s` a buffer, equal to size of `x` (one limb in our case), but according to GMP manual (https://gmplib.org/manual/Number-Theoretic-Functions.html#index- mpz_005fgcdext) it should be equal to size of `y` (two limbs in our case). Hopefully, the diff is simple enough for a PR on GitHub. Otherwise I'll be happy to prepare a patch for Phabricator. {{{#!diff - s@(MBN# s#) <- newBigNat# (absI# xn#) + s@(MBN# s#) <- newBigNat# (absI# yn#) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15350> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15258: Implement CMOV support.
by GHC 20 Oct '18

20 Oct '18

#15258: Implement CMOV support. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: CodeGen | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14830: Use test instead of cmp for comparison against zero.
by GHC 20 Oct '18

20 Oct '18

#14830: Use test instead of cmp for comparison against zero. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: (NCG) | 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: -------------------------------------+------------------------------------- For comparisons `test r, r` and `cmp r, $0` are interchangeable at least on x86. However using test leads to slightly smaller code. (Saves a byte per comparison). A good starting point is stmtToInstrs in compiler/nativeGen/X86/CodeGen starting with how CmmCondBranch is compiled to Instructions. From there it should be not too hard to track down the required changes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15234: WARNING in hptSomeThingsBelowUs when using a source plugin
by GHC 19 Oct '18

19 Oct '18

#15234: WARNING in hptSomeThingsBelowUs when using a source plugin -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple SourcePlugins, plugins | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using a source plugin with a stage2 compiler built with the devel2 flavour, there are a fair few warnings about hptSomeThingsBelowUs. {{{ WARNING in hptSomeThingsBelowUs missing module CoercePlugin Probable cause: out-of-date interface files }}} I don't know if this just started happening or has been going on for a while. Is this warning cause for concern? Everything appears to work as expected despite this hiccup. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15234> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15349: fixST is a bit wrong
by GHC 19 Oct '18

19 Oct '18

#15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.5 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Lazy blackholing lets some `ST` calculations complete that shouldn't. {{{#!hs import Control.Monad.ST.Strict import Control.Monad.Fix import Data.STRef foo :: ST s Int foo = do ref <- newSTRef True mfix $ \res -> do x <- readSTRef ref if x then do writeSTRef ref False return $! (res + 5) else return 10 main = print $ runST foo }}} When this is compiled with `-O -feager-blackholing`, it produces a `<<loop>>` exception as expected. When it's compiled with `-O0` or with `-fno-eager-blackholing`, it prints `15`. Should we reimplement `fixST` to do something like what `fixIO` does? Or should we consider this sometimes-lost bottom tolerable? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15349> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17