GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-04-11T11:15:23Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/22789In-tree GMP tarballs lacks the CVE-2021-43618 patch2023-04-11T11:15:23ZCheng ShaoIn-tree GMP tarballs lacks the CVE-2021-43618 patchMost linux distros patch GMP-6.2.1 with https://gmplib.org/repo/gmp-6.2/rev/561a9c25298e, which fixes [CVE-2021-43618](https://github.com/advisories/GHSA-mfg4-w44m-wr4g) that affects 32-bit platforms. Before GMP does another release, we ...Most linux distros patch GMP-6.2.1 with https://gmplib.org/repo/gmp-6.2/rev/561a9c25298e, which fixes [CVE-2021-43618](https://github.com/advisories/GHSA-mfg4-w44m-wr4g) that affects 32-bit platforms. Before GMP does another release, we should also include this patch into `gmp-tarballs` and bump the submodule accordingly.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/22614Use 64-bit GMP limbs on wasm322024-02-14T02:59:45ZCheng ShaoUse 64-bit GMP limbs on wasm32This is a rather low priority feature request, filed since I noticed a fact in GMP configure system: it's possible to forcibly use 64-bit limbs on 32-bit host archs. Our `ghc-bignum` has the assumption that limb size must equals word siz...This is a rather low priority feature request, filed since I noticed a fact in GMP configure system: it's possible to forcibly use 64-bit limbs on 32-bit host archs. Our `ghc-bignum` has the assumption that limb size must equals word size, though I think it's possible to relax that restriction.
Using 64-bit GMP limbs likely improves performance on wasm32 when dealing with large `Integer`s, since wasm32 supports i64 arithmetic perfectly, and in general the same amount of computation can be achieved by less i64 instructions than their i32 equivalents.https://gitlab.haskell.org/ghc/ghc/-/issues/22602Wasm backend testsuite failure: foundation2023-02-01T11:08:16ZCheng ShaoWasm backend testsuite failure: foundation`foundation` fails on unreg+int_gmp with:
```
Group Precedence
Running + and - (1)
Passed 100 iterations
Running + and - (2)
Passed 100 iterations
Running + and * (1)
Passed 100 iterations
...`foundation` fails on unreg+int_gmp with:
```
Group Precedence
Running + and - (1)
Passed 100 iterations
Running + and - (2)
Passed 100 iterations
Running + and * (1)
Passed 100 iterations
Running + and * (2)
Passed 100 iterations
Running - and * (1)
Passed 100 iterations
Running - and * (2)
Passed 100 iterations
Running * and ^ (1)
Error: failed to run main module `foundation.wasm`
Caused by:
0: failed to invoke command default
1: error while executing at wasm backtrace:
0: 0x1667db - <unknown>!__gmpn_toom6h_mul
1: 0x144b02 - <unknown>!__gmpn_mul_n
2: 0x162f1f - <unknown>!__gmpn_toom53_mul
3: 0x11fb0c - <unknown>!__gmpn_mul
4: 0x11f3c8 - <unknown>!__gmpn_mul
5: 0x18aa4d - <unknown>!_blk_c65B
6: 0x1d1f13 - <unknown>!StgRun
7: 0x1b2544 - <unknown>!scheduleWaitThread
8: 0x1a7c27 - <unknown>!rts_evalLazyIO
9: 0x1a7dbf - <unknown>!hs_main
10: 0x2099d - <unknown>!main
11: 0x1f76f1 - <unknown>!__main_void
12: 0x90d1 - <unknown>!_start
2: wasm trap: out of bounds memory access
```
On unreg+int_native, it passes, but the steps `Running * and ^ (1)`/`Running * and ^ (2)` still take pretty long time, around `2m40s` for `wasmtime`.9.6.1Cheng ShaoCheng Shaohttps://gitlab.haskell.org/ghc/ghc/-/issues/20073GHC Alpine bindist is linked against libgmp but the download page says it's not2022-08-28T16:51:00ZNiklas Hambüchenmail@nh2.meGHC Alpine bindist is linked against libgmp but the download page says it's nothttps://www.haskell.org/ghc/download_ghc_8_10_5.html#binaries claims:
> Alpine Linux 3.10 for x86-64. This is a complete build, including interactive system, profiling libraries and documentation. Unlike our other binary distributions, ...https://www.haskell.org/ghc/download_ghc_8_10_5.html#binaries claims:
> Alpine Linux 3.10 for x86-64. This is a complete build, including interactive system, profiling libraries and documentation. Unlike our other binary distributions, this links against the `integer-simple` big-integer backend and therefore does not require `libgmp`.
But it is apparently linked against `libgmp`:
```
$ readelf -d ghc-8.10.5-x86_64-unknown-linux/bin/ghc | grep gmp
0x0000000000000001 (NEEDED) Shared library: [libHSinteger-gmp-1.0.3.0-ghc8.10.5.so]
0x0000000000000001 (NEEDED) Shared library: [libgmp.so.10]
```
Same thing for the [8.10.2 bindist](https://www.haskell.org/ghc/download_ghc_8_10_2.html#binaries); I haven't checked other ones.
CC @bgamariZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/17799In-tree GMP broken on x86-642020-04-13T21:57:33ZSylvain HenryIn-tree GMP broken on x86-64## Summary
GHC fails to build with in-tree GMP on x86-64 (link issue)
## Steps to reproduce
```bash
> make distclean && ./boot && ./configure --with-intree-gmp && make -j
[...]
ld.lld: error: can't create dynamic relocation R_X86_64_6...## Summary
GHC fails to build with in-tree GMP on x86-64 (link issue)
## Steps to reproduce
```bash
> make distclean && ./boot && ./configure --with-intree-gmp && make -j
[...]
ld.lld: error: can't create dynamic relocation R_X86_64_64 against symbol: __gmp_binvert_limb_table in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
>>> defined in libraries/integer-gmp/gmp/objs/mp_minv_tab.o
>>> referenced by libraries/integer-gmp/gmp/objs/bdiv_q_1.o:(__gmpn_bdiv_q_1)
ld.lld: error: can't create dynamic relocation R_X86_64_64 against symbol: __gmp_binvert_limb_table in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
>>> defined in libraries/integer-gmp/gmp/objs/mp_minv_tab.o
>>> referenced by libraries/integer-gmp/gmp/objs/dive_1.o:(__gmpn_divexact_1)
ld.lld: error: can't create dynamic relocation R_X86_64_64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
>>> defined in libraries/integer-gmp/gmp/objs/gcd_1.o
>>> referenced by libraries/integer-gmp/gmp/objs/gcd_1.o:(__gmpn_gcd_1)
ld.lld: error: can't create dynamic relocation R_X86_64_64 against symbol: __gmpn_invert_limb_table in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
>>> defined in libraries/integer-gmp/gmp/objs/invert_limb_table.o
>>> referenced by libraries/integer-gmp/gmp/objs/invert_limb.o:(__gmpn_invert_limb)
ld.lld: error: can't create dynamic relocation R_X86_64_64 against symbol: __gmp_binvert_limb_table in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
>>> defined in libraries/integer-gmp/gmp/objs/mp_minv_tab.o
>>> referenced by libraries/integer-gmp/gmp/objs/mode1o.o:(__gmpn_modexact_1_odd)
collect2: erreur: ld a retourné le statut de sortie 1
`cc' failed in phase `Linker'. (Exit code: 1)
make[1]: *** [libraries/integer-gmp/ghc.mk:4: libraries/integer-gmp/dist-install/build/libHSinteger-gmp-1.0.2.0-ghc8.11.0.20200205.so] Error 1
make[1]: *** Attente des tâches non terminées....
make: *** [Makefile:128: all] Error 2
```
Related: #4366 #8156 and #4022.
## Environment
* GHC version used: HEAD
* Operating System: ArchLinux
* System Architecture: x86-64Sylvain HenrySylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/17756hadrian does not correctly implement in tree gmp support2020-02-19T10:49:36ZCarter Schonwaldhadrian does not correctly implement in tree gmp support## Summary
Hadrian's intree gmp build logic only works if theres a GMP header file in one of the default search paths of the C compiler
## Steps to reproduce
build ghc using hadrian with the intree-gmp configuration, without GMP...## Summary
Hadrian's intree gmp build logic only works if theres a GMP header file in one of the default search paths of the C compiler
## Steps to reproduce
build ghc using hadrian with the intree-gmp configuration, without GMP headers in any of the default header include paths used by your GCC/CLANG/CC.
on OSX you can reproduce as follows (directions follow assume you're using brew to install libraries)
```shell
brew unlink gmp
git clean -fdx
make maintainer-clean
perl boot
./configure --with-intree-gmp # you may also add CC=(which clang) or gcc or whatever
hadrian/build.sh --flavour=quickest -j
```
## Expected behavior
ghc should build! instead we get this
```
| Run Ghc FindHsDependencies Stage1: libraries/integer-gmp/src/GHC/Integer.hs (and 4 more) => _build/stage1/libraries/integer-gmp/.dependencies.mk
libraries/integer-gmp/cbits/wrappers.c:30:3: error: #error __GNU_MP_VERSION not defined
30 | # error __GNU_MP_VERSION not defined
| ^~~~~
libraries/integer-gmp/cbits/wrappers.c:42:3: error: #error WORD_SIZE_IN_BITS != GMP_LIMB_BITS not supported
42 | # error WORD_SIZE_IN_BITS != GMP_LIMB_BITS not supported
| ^~~~~
Error when running Shake build system:
at action, called at src/Rules.hs:71:19 in main:Rules
at need, called at src/Rules.hs:93:5 in main:Rules
* Depends on: _build/stage1/lib/package.conf.d/integer-gmp-1.0.2.0.conf
at need, called at src/Rules/Register.hs:113:5 in main:Rules.Register
* Depends on: _build/stage1/libraries/integer-gmp/build/HSinteger-gmp-1.0.2.0.o
at need, called at src/Rules/Library.hs:102:5 in main:Rules.Library
* Depends on: _build/stage1/libraries/integer-gmp/build/c/cbits/wrappers.o
* Raised the exception:
user error (Development.Shake.cmd, system command failed
Command line: /usr/local/bin/gcc-9 -std=c99 -Wall -E -MM -MG -MF _build/stage1/libraries/integer-gmp/build/c/cbits/wrappers.o.d -MT _build/stage1/libraries/integer-gmp/build/c/cbits/wrappers.o -Iincludes -I_build/stage1/lib -I_build/stage1/libraries/integer-gmp/build -I_build/stage1/libraries/integer-gmp/build/include -Ilibraries/integer-gmp/include -I/Users/carter/Desktop/reposcratcher/triage-gcc-plz/_build/stage1/lib/x86_64-osx-ghc-8.11.0.20200127/rts-1.0/include -x c libraries/integer-gmp/cbits/wrappers.c -I_build/stage1/gmp/include
Exit code: 1
Stderr:
libraries/integer-gmp/cbits/wrappers.c:30:3: error: #error __GNU_MP_VERSION not defined
30 | # error __GNU_MP_VERSION not defined
| ^~~~~
libraries/integer-gmp/cbits/wrappers.c:42:3: error: #error WORD_SIZE_IN_BITS != GMP_LIMB_BITS not supported
42 | # error WORD_SIZE_IN_BITS != GMP_LIMB_BITS not supported
| ^~~~~
)
```
## Environment
* GHC version used: 8.8.1 or 8.6.5
Optional:
* Operating System: OSX
* System Architecture: AMD64
i originally reported this as https://gitlab.haskell.org/ghc/ghc/issues/17741 and friends, incorrectly :)https://gitlab.haskell.org/ghc/ghc/-/issues/17231Incorrect rounding mode used for fromIntegral :: Integer -> Double/Float2021-03-17T23:40:38ZLevent ErkökIncorrect rounding mode used for fromIntegral :: Integer -> Double/Float## Summary
When converting from `Integer` to `Double` (or `Float`), GHC uses round-toward-zero rounding mode. It should use the default mode round-toward-nearest-ties-to-even instead.
It appears up till GHC 7.8.3, GHC did indeed use th...## Summary
When converting from `Integer` to `Double` (or `Float`), GHC uses round-toward-zero rounding mode. It should use the default mode round-toward-nearest-ties-to-even instead.
It appears up till GHC 7.8.3, GHC did indeed use this default mode, but something changed after that at some point, and at least in 8.6.5, the incorrect mode is used.
## Steps to reproduce
As discussed in https://stackoverflow.com/questions/58035248/a-haskell-floating-point-calculation-anomaly/58037815#58037815
This expression:
```haskell
*Main> (fromIntegral $ 4141414141414141*4141414141414141) :: Double
1.7151311090705025e31
```
Produces an unexpected result since the resulting integer is converted using round-toward-zero. While the report is rather silent on rounding-modes, it's general accepted practice that round-nearest-ties-to-even is the default rounding mode to use. As discussed in the stack-overflow question linked, this results in bad results in diverges from other languages. For instance, the equivalent Python produces:
```python
>>> float(long(4141414141414141)*long(4141414141414141))
1.7151311090705027e+31
```
which is a much better result for this expression. (Note the final digit before the exponent, 5 vs 7.)
## Expected behavior
Produce the better conversion result by using round-nearest-ties-to-even rounding mode of IEEE754.
## Analysis
The issue goes to this function: https://hackage.haskell.org/package/integer-gmp-1.0.2.0/docs/src/GHC.Integer.Type.html#doubleFromInteger
which reads:
```haskell
doubleFromInteger :: Integer -> Double#
doubleFromInteger (S# m#) = int2Double# m#
doubleFromInteger (Jp# bn@(BN# bn#))
= c_mpn_get_d bn# (sizeofBigNat# bn) 0#
doubleFromInteger (Jn# bn@(BN# bn#))
= c_mpn_get_d bn# (negateInt# (sizeofBigNat# bn)) 0#
```
which in turn calls: https://github.com/ghc/ghc/blob/master/libraries/integer-gmp/cbits/wrappers.c#L183-L190:
```C
/* Convert bignum to a `double`, truncating if necessary
* (i.e. rounding towards zero).
*
* sign of mp_size_t argument controls sign of converted double
*/
HsDouble
integer_gmp_mpn_get_d (const mp_limb_t sp[], const mp_size_t sn,
const HsInt exponent)
{
```
This function decidedly uses round-towards-zero. Instead, a version that uses round-nearest-ties-to-even should be called.
`Integer -> Float` conversion suffers from the same problem, as it goes through the `Double` value. So, fixing the first would fix the second as well.
## Environment
* GHC version used: 8.6.5 and newer. On the stack-overflow discussion, people noted that GHC 7.8.3 returns the correct value. So, the behavior somehow changed in between these releases.
Optional:
* Operating System: N/A
* System Architecture: N/Ahttps://gitlab.haskell.org/ghc/ghc/-/issues/17046Hadrian doesn't seem to handle integer-simple properly2019-11-27T15:23:10ZJavier SagredoHadrian doesn't seem to handle integer-simple properly## Summary
When trying to build ghc-8.8.1-rc1 branch using Hadrian and requesting to use the `integer-simple` library, the flags don't get properly propagated. To be precise, the library `text` can't build because it gets `-optP-DINTEGE...## Summary
When trying to build ghc-8.8.1-rc1 branch using Hadrian and requesting to use the `integer-simple` library, the flags don't get properly propagated. To be precise, the library `text` can't build because it gets `-optP-DINTEGER_GMP` as a flag.
## Steps to reproduce
Redefine `userFlavour` in `hadrian/src/UserSettings.hs`:
```
userFlavour :: Flavour
userFlavour = defaultFlavour { name = "simple", integerLibrary = pure integerSimple }
```
and then:
```
./hadrian/build.sh -c -j --flavour=simple
```
And while building, this error arises:
```
Command line: /usr/local/bin/ghc -M -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build/stage0/lib/package.conf.d' '-this-unit-id text-1.2.3.1' '-package-id array-0.5.3.0' '-package-id base-4.12.0.0' '-package-id binary-0.8.7.0' '-package-id bytestring-0.10.8.2' '-package-id deepseq-1.4.4.0' '-package-id ghc-prim-0.5.3' '-package-id integer-simple-0.1.1.1' -i -i_build/stage0/libraries/text/build -i_build/stage0/libraries/text/build/autogen -ilibraries/text/. -I_build/generated -I_build/stage0/libraries/text/build -I_build/stage0/libraries/text/build/include -Ilibraries/text/include -I/usr/local/lib/ghc-8.6.5/bytestring-0.10.8.2/include -I/usr/local/lib/ghc-8.6.5/base-4.12.0.0/include -I/usr/local/lib/ghc-8.6.5/include -I_build/generated -optc-I_build/generated -optP-include -optP_build/stage0/libraries/text/build/autogen/cabal_macros.h -optP-DINTEGER_GMP -outputdir _build/stage0/libraries/text/build -include-pkg-deps -dep-makefile _build/stage0/libraries/text/.dependencies.mk -dep-suffix '' libraries/text/Data/Text.hs libraries/text/Data/Text/Array.hs libraries/text/Data/Text/Encoding.hs libraries/text/Data/Text/Encoding/Error.hs libraries/text/Data/Text/Foreign.hs libraries/text/Data/Text/IO.hs libraries/text/Data/Text/Internal.hs libraries/text/Data/Text/Internal/Builder.hs libraries/text/Data/Text/Internal/Builder/Functions.hs libraries/text/Data/Text/Internal/Builder/Int/Digits.hs libraries/text/Data/Text/Internal/Builder/RealFloat/Functions.hs libraries/text/Data/Text/Internal/Encoding/Fusion.hs libraries/text/Data/Text/Internal/Encoding/Fusion/Common.hs libraries/text/Data/Text/Internal/Encoding/Utf16.hs libraries/text/Data/Text/Internal/Encoding/Utf32.hs libraries/text/Data/Text/Internal/Encoding/Utf8.hs libraries/text/Data/Text/Internal/Functions.hs libraries/text/Data/Text/Internal/Fusion.hs libraries/text/Data/Text/Internal/Fusion/CaseMapping.hs libraries/text/Data/Text/Internal/Fusion/Common.hs libraries/text/Data/Text/Internal/Fusion/Size.hs libraries/text/Data/Text/Internal/Fusion/Types.hs libraries/text/Data/Text/Internal/IO.hs libraries/text/Data/Text/Internal/Lazy.hs libraries/text/Data/Text/Internal/Lazy/Encoding/Fusion.hs libraries/text/Data/Text/Internal/Lazy/Fusion.hs libraries/text/Data/Text/Internal/Lazy/Search.hs libraries/text/Data/Text/Internal/Private.hs libraries/text/Data/Text/Internal/Read.hs libraries/text/Data/Text/Internal/Search.hs libraries/text/Data/Text/Internal/Unsafe.hs libraries/text/Data/Text/Internal/Unsafe/Char.hs libraries/text/Data/Text/Internal/Unsafe/Shift.hs libraries/text/Data/Text/Lazy.hs libraries/text/Data/Text/Lazy/Builder.hs libraries/text/Data/Text/Lazy/Builder/Int.hs libraries/text/Data/Text/Lazy/Builder/RealFloat.hs libraries/text/Data/Text/Lazy/Encoding.hs libraries/text/Data/Text/Lazy/IO.hs libraries/text/Data/Text/Lazy/Internal.hs libraries/text/Data/Text/Lazy/Read.hs libraries/text/Data/Text/Read.hs libraries/text/Data/Text/Show.hs libraries/text/Data/Text/Unsafe.hs -O -H32m -Wall -fwarn-tabs -funbox-strict-fields -O2 -XHaskell98 -fno-warn-deprecated-flags
Exit code: 1
Stderr:
libraries/text/Data/Text/Lazy/Builder/Int.hs:40:8: error:
Could not find module ‘GHC.Integer.GMP.Internals’
Perhaps you meant
GHC.Integer.Simple.Internals (from integer-simple-0.1.1.1)
Use -v to see a list of the files searched for.
|
40 | import GHC.Integer.GMP.Internals (Integer(S#))
| ^^^^^^^^^^^^^^^^^^^^^^^^^
```
The flag `-optP-DINTEGER_GMP` is being passed to the library and this shouldn't be the case.
## Expected behavior
I would expect the libraries to build without issues.
## Environment
* GHC version used:
```
> cabal --version
cabal-install version 2.4.0.0
> ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.6.5
```
* Operating System: Ubuntu 19.048.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/16205Printing a large (GMP) Integer in ghci-ext with LLVM causes a segfault2021-01-14T16:25:49ZAlec TheriaultPrinting a large (GMP) Integer in ghci-ext with LLVM causes a segfaultAlthough I haven't reproduced this locally yet, the `validate-x86_64-linux-deb9-llvm` CI pipeline (which is allowed to fail) has continuously been failing for `print037(ghci-ext)`.
Here's the relevant output:
```
--- ghci.debugger/scri...Although I haven't reproduced this locally yet, the `validate-x86_64-linux-deb9-llvm` CI pipeline (which is allowed to fail) has continuously been failing for `print037(ghci-ext)`.
Here's the relevant output:
```
--- ghci.debugger/scripts/print037.run/print037.stdout.normalised 2019-01-19 11:37:48.698917882 +0000
+++ ghci.debugger/scripts/print037.run/print037.run.stdout.normalised 2019-01-19 11:37:48.698917882 +0000
@@ -1,5 +1,4 @@
smallNeg = -53
smallPos = 89
zero = 0
-largeNeg = -4123841823694876543987265438957349857349
-largePos = 5402398759384752938475029384750298347554
+ghc-stage2: ghc-iserv terminated (-11)
*** unexpected failure for print037(ghci-ext)
```
Given that the crash happens only on large integers (i.e. not `S#`), something in the C FFI with the GMP code is probably to blame.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Printing a large (GMP) Integer in ghci-ext with LLVM causes a segfault","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":["integer-gmp","llvm"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Although I haven't reproduced this locally yet, the `validate-x86_64-linux-deb9-llvm` CI pipeline (which is allowed to fail) has continuously been failing for `print037(ghci-ext)`.\r\n\r\nHere's the relevant output:\r\n\r\n{{{\r\n--- ghci.debugger/scripts/print037.run/print037.stdout.normalised\t2019-01-19 11:37:48.698917882 +0000\r\n+++ ghci.debugger/scripts/print037.run/print037.run.stdout.normalised\t2019-01-19 11:37:48.698917882 +0000\r\n@@ -1,5 +1,4 @@\r\n smallNeg = -53\r\n smallPos = 89\r\n zero = 0\r\n-largeNeg = -4123841823694876543987265438957349857349\r\n-largePos = 5402398759384752938475029384750298347554\r\n+ghc-stage2: ghc-iserv terminated (-11)\r\n*** unexpected failure for print037(ghci-ext)\r\n}}}\r\n\r\nGiven that the crash happens only on large integers (i.e. not `S#`), something in the C FFI with the GMP code is probably to blame.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15262GHC and iserv cannot agree on what an Integer is; insanity ensues2020-06-19T14:35:19ZhowtonotwinGHC and iserv cannot agree on what an Integer is; insanity ensuesTested off `ghc-8.6.1-alpha1`, running on macOS 10.13.5.
1. Compile a GHC that uses `integer-gmp`.
2. Compile a GHC that uses `integer-simple`.
3. Make `Main.hs`:
> ```haskell
> {-# LANGUAGE TemplateHaskell #-}
...Tested off `ghc-8.6.1-alpha1`, running on macOS 10.13.5.
1. Compile a GHC that uses `integer-gmp`.
2. Compile a GHC that uses `integer-simple`.
3. Make `Main.hs`:
> ```haskell
> {-# LANGUAGE TemplateHaskell #-}
> main = print $([e| 0 |])
> ```
4. Try to compile the file with `integer-gmp` `ghc` and `integer-simple` `ghc-iserv`.
* Expected behavior: (compiles fine and executable prints `0`) or (outputs to-the-point error message)
* Actual:
```none
[1 of 1] Compiling Main ( Main.hs, Main.o )
Main.hs:2:14: error:
• Exception when trying to run compile-time code:
ghc: ghc-iserv terminated (-11)
Code: [| 0 |]
• In the untyped splice: $([| 0 |])
|
2 | main = print $([e| 0 |])
| ^^^^^^^^^^^
```
4. Try to compile the file with `integer-simple` `ghc` and `integer-gmp` `ghc-iserv`.
* Expected behavior: (compiles fine and executable prints `0`) or (outputs to-the-point error message)
* Actual:
```none
[1 of 1] Compiling Main ( Main.hs, Main.o )
Main.hs:2:14: error:
• Exception when trying to run compile-time code:
heap overflow
Code: [| 0 |]
• In the untyped splice: $([| 0 |])
|
2 | main = print $([e| 0 |])
| ^^^^^^^^^^^
```
For more fun, replace the `0` with a `1`. `gmp` `ghc` + `simple` `iserv` continues to explode. This is better than `simple` `ghc` + `gmp` `iserv`:
```bash
$ ./Main
283468057265
$ ./Main
283468057265
$ $simple_ghc -fexternal-interpreter -pgmi=$gmp_iserv Main.hs # again
# ...
$ ./Main
283468057105
```
Absolutely delicious. There is a similar situation for fractional literals.
It would be nice if there were at least a warning for situations like this.9.0.1John EricsonJohn Ericsonhttps://gitlab.haskell.org/ghc/ghc/-/issues/14085powModInteger sometimes ignores sign of argument2019-07-07T18:18:31ZocheronpowModInteger sometimes ignores sign of argumentFunction `intToSBigNat#` returns a `PosBN` result when input is \< -1, but it should be `NegBN` instead.
As a consequence functions like `powModInteger` give incorrect result for small negative numbers:
```
$ ghci
GHCi, version 8.2.1: ...Function `intToSBigNat#` returns a `PosBN` result when input is \< -1, but it should be `NegBN` instead.
As a consequence functions like `powModInteger` give incorrect result for small negative numbers:
```
$ ghci
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
> :m GHC.Integer.GMP.Internals
> powModInteger (-2) 3 123
8
> (-2)^3 `mod` 123
115
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"powModInteger sometimes ignores sign of argument","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["integer-gmp"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Function `intToSBigNat#` returns a `PosBN` result when input is < -1, but it should be `NegBN` instead.\r\n\r\nAs a consequence functions like `powModInteger` give incorrect result for small negative numbers:\r\n{{{\r\n$ ghci\r\nGHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help\r\n> :m GHC.Integer.GMP.Internals\r\n> powModInteger (-2) 3 123\r\n8\r\n> (-2)^3 `mod` 123\r\n115\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1ocheronocheronhttps://gitlab.haskell.org/ghc/ghc/-/issues/12129Optimize the implementation of minusInteger in the integer-gmp package2019-07-07T18:27:32ZadmockOptimize the implementation of minusInteger in the integer-gmp packageAs mentioned in [https://www.fpcomplete.com/blog/2016/05/weigh-package](https://www.fpcomplete.com/blog/2016/05/weigh-package), the current implementation of `minusInteger` is
```hs
minusInteger x y = inline plusInteger x (inline negate...As mentioned in [https://www.fpcomplete.com/blog/2016/05/weigh-package](https://www.fpcomplete.com/blog/2016/05/weigh-package), the current implementation of `minusInteger` is
```hs
minusInteger x y = inline plusInteger x (inline negateInteger y)
```
which always allocates an additional integer. This could be improved by not always calling `negateInteger` and instead having an implementation more like `plusInteger`'s.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Optimize the implementation of minusInteger in the integer-gmp package","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"As mentioned in [https://www.fpcomplete.com/blog/2016/05/weigh-package], the current implementation of `minusInteger` is \r\n{{{#!hs\r\nminusInteger x y = inline plusInteger x (inline negateInteger y)\r\n}}}\r\nwhich always allocates an additional integer. This could be improved by not always calling `negateInteger` and instead having an implementation more like `plusInteger`'s.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1admockadmockhttps://gitlab.haskell.org/ghc/ghc/-/issues/10944powModInteger slower than computing pow and mod separately2019-07-07T18:32:57ZiagopowModInteger slower than computing pow and mod separately```hs
module Foo where
import GHC.Integer.GMP.Internals ( powModInteger )
test1, test2 :: Integer -> Integer -> Int -> Integer
test1 a b c = (a ^ b) `mod` (2^c)
test2 a b c = powModInteger a b (2^c)
```
I was expecting `test2` to pe...```hs
module Foo where
import GHC.Integer.GMP.Internals ( powModInteger )
test1, test2 :: Integer -> Integer -> Int -> Integer
test1 a b c = (a ^ b) `mod` (2^c)
test2 a b c = powModInteger a b (2^c)
```
I was expecting `test2` to perform better than `test1`, but I'm getting quite the opposite: the use of `powModInteger` seems to be several orders of magnitude slower.
I have tested this with GHC 7.10.2 and integer-gmp 1.0.0.0 too, with similar results.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"powModInteger slower than computing pow and mod separately","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":["integer-gmp"],"differentials":[],"test_case":"","architecture":"","cc":["ekmett"],"type":"Bug","description":"{{{#!hs\r\nmodule Foo where\r\n\r\nimport GHC.Integer.GMP.Internals ( powModInteger )\r\n\r\ntest1, test2 :: Integer -> Integer -> Int -> Integer\r\n\r\ntest1 a b c = (a ^ b) `mod` (2^c)\r\n\r\ntest2 a b c = powModInteger a b (2^c)\r\n}}}\r\n\r\nI was expecting `test2` to perform better than `test1`, but I'm getting quite the opposite: the use of `powModInteger` seems to be several orders of magnitude slower.\r\n\r\nI have tested this with GHC 7.10.2 and integer-gmp 1.0.0.0 too, with similar results.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10282Segfault when calling show on an Integer of a certain size2019-07-07T18:36:46ZgelisamSegfault when calling show on an Integer of a certain sizeYou're not going to believe this.
```
$ ghc -e 'let k = show (10^184000) in k == k'
True
$ ghc -e 'let k = show (10^187000) in k == k'
True
$ ghc -e 'let k = show (10^186000) in k == k'
Bus error
```
That's right: there is a problem wh...You're not going to believe this.
```
$ ghc -e 'let k = show (10^184000) in k == k'
True
$ ghc -e 'let k = show (10^187000) in k == k'
True
$ ghc -e 'let k = show (10^186000) in k == k'
Bus error
```
That's right: there is a problem which affects Integer values which are 186000 digits long, but which does not affect values which are 187000 digits long.
So `10^184000` works fine, `10^187000` works fine, but `10^186000` doesn't. What about `10^185000`? Well, it depends on your version of GHC. And on chance. GHC 7.10.0.20150123 is always happy with `10^185000`, but GHC 7.8.3 crashes about two-thirds of the time:
```
$ ghc -e 'let k = show (10^185000) in k == k'
True
Segmentation fault
```
And it's a different kind of crash, too! A segmentation fault instead of a "bus error".
I have tried all the lengths in `[1000,2000,..,100000]`, and some lengths are fine, some lengths have a bus error, and some lengths segfault. The most helpful lengths I've encountered give an error message about malloc:
```
$ ghc -e 'let k = show (10^264000) in k == k'
True
ghc(72417,0x107081000) malloc: *** error for object 0x107300000: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap
```
Sometimes it gives a slightly different error message:
```
$ ghc -e 'let k = show (10^264000) in k == k'
ghc(72453,0x107381000) malloc: *** error for object 0x107200128: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Abort trap
```
Anyway, a lot more people posted their results in the following reddit thread, without realizing that the problem had to do with the length: http://www.reddit.com/r/haskell/comments/31yajd/can_you_explain_this/
So far, only folks on OS X have managed to reproduce the problem. The problem occurs with `ghci`, `runhaskell` and `ghc -e`, but not with compiled binaries.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Segfault when calling show on an Integer of a certain size","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"You're not going to believe this.\r\n\r\n{{{\r\n$ ghc -e 'let k = show (10^184000) in k == k'\r\nTrue\r\n$ ghc -e 'let k = show (10^187000) in k == k'\r\nTrue\r\n$ ghc -e 'let k = show (10^186000) in k == k'\r\nBus error\r\n}}}\r\n\r\nThat's right: there is a problem which affects Integer values which are 186000 digits long, but which does not affect values which are 187000 digits long.\r\n\r\nSo {{{10^184000}}} works fine, {{{10^187000}}} works fine, but {{{10^186000}}} doesn't. What about {{{10^185000}}}? Well, it depends on your version of GHC. And on chance. GHC 7.10.0.20150123 is always happy with {{{10^185000}}}, but GHC 7.8.3 crashes about two-thirds of the time:\r\n\r\n{{{\r\n$ ghc -e 'let k = show (10^185000) in k == k'\r\nTrue\r\nSegmentation fault\r\n}}}\r\n\r\nAnd it's a different kind of crash, too! A segmentation fault instead of a \"bus error\".\r\n\r\nI have tried all the lengths in {{{[1000,2000,..,100000]}}}, and some lengths are fine, some lengths have a bus error, and some lengths segfault. The most helpful lengths I've encountered give an error message about malloc:\r\n\r\n{{{\r\n$ ghc -e 'let k = show (10^264000) in k == k'\r\nTrue\r\nghc(72417,0x107081000) malloc: *** error for object 0x107300000: pointer being freed was not allocated\r\n*** set a breakpoint in malloc_error_break to debug\r\nAbort trap\r\n}}}\r\n\r\nSometimes it gives a slightly different error message:\r\n{{{\r\n$ ghc -e 'let k = show (10^264000) in k == k'\r\nghc(72453,0x107381000) malloc: *** error for object 0x107200128: incorrect checksum for freed object - object was probably modified after being freed.\r\n*** set a breakpoint in malloc_error_break to debug\r\nAbort trap\r\n}}}\r\n\r\nAnyway, a lot more people posted their results in the following reddit thread, without realizing that the problem had to do with the length: http://www.reddit.com/r/haskell/comments/31yajd/can_you_explain_this/\r\n\r\nSo far, only folks on OS X have managed to reproduce the problem. The problem occurs with {{{ghci}}}, {{{runhaskell}}} and {{{ghc -e}}}, but not with compiled binaries.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9835Add bindings for marshaling to/from mpz_t2020-06-19T13:05:44ZdfrankeAdd bindings for marshaling to/from mpz_tPlease add bindings to allow efficient marshaling between Haskell Integer and C mpz_t's, e.g.:
```
-- Wraps a (struct __mpz_struct*).
type Mpz = Ptr ()
toMpz :: Integer -> IO Mpz
fromMpz :: Mpz -> IO Integer
```
This would be ...Please add bindings to allow efficient marshaling between Haskell Integer and C mpz_t's, e.g.:
```
-- Wraps a (struct __mpz_struct*).
type Mpz = Ptr ()
toMpz :: Integer -> IO Mpz
fromMpz :: Mpz -> IO Integer
```
This would be useful for efficiently interfacing with foreign code that uses GMP.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add bindings for marshaling to/from mpz_t","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":["integer-gmp"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Please add bindings to allow efficient marshaling between Haskell Integer and C mpz_t's, e.g.:\r\n\r\n{{{\r\n -- Wraps a (struct __mpz_struct*).\r\n type Mpz = Ptr ()\r\n\r\n toMpz :: Integer -> IO Mpz\r\n fromMpz :: Mpz -> IO Integer\r\n}}}\r\n\r\nThis would be useful for efficiently interfacing with foreign code that uses GMP.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9281Rewrite `integer-gmp` to use only non-allocating GMP functions2019-07-07T18:41:04ZHerbert Valerio Riedelhvr@gnu.orgRewrite `integer-gmp` to use only non-allocating GMP functionsAfter some promising results with a proof-of-concept implementation, I'm optimistic we can rewrite `integer-gmp` to use only non-allocating GMP lib functions without suffering from serious regressions.
If successful, this would
- allo...After some promising results with a proof-of-concept implementation, I'm optimistic we can rewrite `integer-gmp` to use only non-allocating GMP lib functions without suffering from serious regressions.
If successful, this would
- allow to avoid the custom GMP allocator hack, and thus
- avoid issues when linking against other C libraries using GMP,
- simplify code, as we would perform all heap allocations in Haskell code (and never inside Cmm/C code as its done now),
- and finally maybe even remove a few more superfluous temporary heap allocations.
see also wiki:Design/IntegerGmp27.10.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/8726integer-gmp division regression2019-07-07T18:43:46Zerikdinteger-gmp division regressionWith ghc 7.6.3:
```
ghci> quotRem 0x10000000000000001 (-0x100000)
(-17592186044416,1)
ghci> quotRem 0x10000001 (-0x100000)
(-256,1)
```
with ghc 7.7
```
ghci> quotRem 0x10000000000000001 (-0x100000)
(-17592186044416,-1)
ghci> quotRem ...With ghc 7.6.3:
```
ghci> quotRem 0x10000000000000001 (-0x100000)
(-17592186044416,1)
ghci> quotRem 0x10000001 (-0x100000)
(-256,1)
```
with ghc 7.7
```
ghci> quotRem 0x10000000000000001 (-0x100000)
(-17592186044416,-1)
ghci> quotRem 0x10000001 (-0x100000)
(-256,1)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"integer-gmp division regression","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":["Integer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With ghc 7.6.3:\r\n\r\n{{{\r\nghci> quotRem 0x10000000000000001 (-0x100000)\r\n(-17592186044416,1)\r\nghci> quotRem 0x10000001 (-0x100000)\r\n(-256,1)\r\n}}}\r\n\r\nwith ghc 7.7\r\n\r\n{{{\r\nghci> quotRem 0x10000000000000001 (-0x100000)\r\n(-17592186044416,-1)\r\nghci> quotRem 0x10000001 (-0x100000)\r\n(-256,1)\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/8666integer-gmp fails to compile on Debian Squeeze2020-04-17T09:01:06ZJan Stolarekjan.stolarek@ed.ac.ukinteger-gmp fails to compile on Debian SqueezeI get an error when compiling recent HEAD on Debian Squeeze:
```
"inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H64m -O0 -fasm -package-name integer-gmp-0.5.1.0 -hide-all-packages -i -ilibraries/in...I get an error when compiling recent HEAD on Debian Squeeze:
```
"inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H64m -O0 -fasm -package-name integer-gmp-0.5.1.0 -hide-all-packages -i -ilibraries/integer-gmp/. -ilibraries/integer-gmp/dist-install/build -ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer-gmp/dist-install/build -Ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer-gmp/. -optP-include -optPlibraries/integer-gmp/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -Wall -package-name integer-gmp -XHaskell2010 -O -fasm -no-user-package-db -rtsopts -Ilibraries/integer-gmp/mkGmpDerivedConstants/dist -odir libraries/integer-gmp/dist-install/build -hidir libraries/integer-gmp/dist-install/build -stubdir libraries/integer-gmp/dist-install/build -fno-use-rpaths -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-prim-0.3.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../rts-1.0' -optl-Wl,-zorigin libraries/integer-gmp/dist-install/build/GHC/Integer.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Internals.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Prim.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/Logarithms.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/Logarithms/Internals.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/Type.dyn_o libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.dyn_o libraries/integer-gmp/dist-install/build/cbits/cbits.dyn_o libraries/integer-gmp/gmp/objs/*.o -shared -dynamic -dynload deploy -no-auto-link-packages -o libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0-ghc7.7.20140113.so
Warning: -rtsopts and -with-rtsopts have no effect with -shared.
Call hs_init_ghc() from your main() function to set these options.
/usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation R_X86_64_32 against `__gmpz_sub' can not be used when making a shared object; recompile with -fPIC
libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0-ghc7.7.20140113.so] Error 1
make: *** [all] Error 2
```
I can build in-tree `libgmp` by extracting it and running `./configure make`. Following Austin's and Herbert's suggestions I tried adding `-fPIC` to command line options but with no result - see attachements.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"integer-gmp fails to compile on Debian Squeeze","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I get an error when compiling recent HEAD on Debian Squeeze:\r\n\r\n{{{\r\n\"inplace/bin/ghc-stage1\" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H64m -O0 -fasm -package-name integer-gmp-0.5.1.0 -hide-all-packages -i -ilibraries/integer-gmp/. -ilibraries/integer-gmp/dist-install/build -ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer-gmp/dist-install/build -Ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer-gmp/. -optP-include -optPlibraries/integer-gmp/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -Wall -package-name integer-gmp -XHaskell2010 -O -fasm -no-user-package-db -rtsopts -Ilibraries/integer-gmp/mkGmpDerivedConstants/dist -odir libraries/integer-gmp/dist-install/build -hidir libraries/integer-gmp/dist-install/build -stubdir libraries/integer-gmp/dist-install/build -fno-use-rpaths -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-prim-0.3.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../rts-1.0' -optl-Wl,-zorigin libraries/integer-gmp/dist-install/build/GHC/Integer.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Internals.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Prim.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/Logarithms.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/Logarithms/Internals.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/Type.dyn_o libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.dyn_o libraries/integer-gmp/dist-install/build/cbits/cbits.dyn_o libraries/integer-gmp/gmp/objs/*.o -shared -dynamic -dynload deploy -no-auto-link-packages -o libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0-ghc7.7.20140113.so\r\nWarning: -rtsopts and -with-rtsopts have no effect with -shared.\r\n Call hs_init_ghc() from your main() function to set these options.\r\n/usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation R_X86_64_32 against `__gmpz_sub' can not be used when making a shared object; recompile with -fPIC\r\nlibraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value\r\ncollect2: ld returned 1 exit status\r\nmake[1]: *** [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0-ghc7.7.20140113.so] Error 1\r\nmake: *** [all] Error 2\r\n}}}\r\n\r\nI can build in-tree `libgmp` by extracting it and running `./configure make`. Following Austin's and Herbert's suggestions I tried adding `-fPIC` to command line options but with no result - see attachements.","type_of_failure":"OtherFailure","blocking":[]} -->Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/8647Reduce allocations in `integer-gmp`2019-07-07T18:44:06ZHerbert Valerio Riedelhvr@gnu.orgReduce allocations in `integer-gmp`I've added `printf(3)`s to `integer-gmp`s GMP allocation/reallocation functions, and noticed there to a significant amount of allocations going on.
This is due to the fact that the CMM wrappers call `gmpz_init()` to initialize the resul...I've added `printf(3)`s to `integer-gmp`s GMP allocation/reallocation functions, and noticed there to a significant amount of allocations going on.
This is due to the fact that the CMM wrappers call `gmpz_init()` to initialize the result, and this already allocates a 1-limb `StgArray`. But the actual GMP operations perform a reallocate-call (which by contract also needs `memcpy` the untouched limb over to the newly allocated structure) based on the type of operation and the involved operands, causing the optimistically allocated 1-limb structure to become garbage right away w/o even being written to.
I've been able to get rid of most such superfluous allocations by replacing
```c
ccall __gmpz_init(mp_result1 "ptr");
```
by
```c
MP_INT__mp_alloc(mp_result1) = 0;
MP_INT__mp_size(mp_result1) = 0;
MP_INT__mp_d(mp_result1) = 0; // (1)
```
which is handled properly by all GMP operations we make use of currently. This elegantly lets the very first allocation be performed within the GMP operation (which has better knowledge with respect to how many limbs the result will require)
I've got working proof-of-concept code, which reduces the allocations the big-num heavy `nofib` programs (I've omitted the benchmarks which had a 0% allocation change):
```
--------------------------------------------------------------------------------
Program Size Allocs Runtime Elapsed TotalMem
--------------------------------------------------------------------------------
...
bernouilli -0.1% -5.2% 0.12 0.12 +0.0%
kahan -0.1% -10.5% 0.17 0.17 +0.0%
primetest -0.1% -12.8% 0.07 0.07 +0.0%
rsa -0.1% -13.8% 0.02 0.02 +0.0%
symalg -0.1% -2.3% 0.01 0.01 +0.0%
...
--------------------------------------------------------------------------------
Min -0.1% -13.8% -3.1% -3.1% -6.5%
Max -0.0% +0.4% +4.0% +4.0% +1.5%
Geometric Mean -0.1% -0.5% +0.5% +0.4% -0.1%
```
`(1)` This should actually point to a proper static closure I didn't need this for the proof-of-concept
----
Another place which helps avoiding temporarily allocating 1-limb `StgArrays` which live only for the duration of GMP FFI calls are those caused by the `toBig`-casts, which I'm also experimenting by making use of GMP's big-int/small-int add/sub/mul primitives (the deltas shown above are actually measured on top of this optimization), here's what to expect from such an optimization by itself (i.e. w/o the realloc-optimization from above):
```
bernouilli +0.1% -4.2% 0.12 0.12 +0.0%
kahan +0.1% -12.6% 0.17 0.17 +0.0%
power +0.1% -2.7% +2.2% +2.2% +0.0%
rsa +0.1% -4.1% 0.02 0.02 +0.0%
scs +0.1% -2.6% -1.6% -1.6% +0.0%
```
Thus, the `kahan` benchmark benefits from this optimization by -12.6%, and on top of that another -10.5% by also avoiding the GMP-reallocations.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.6.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Reduce allocations in `integer-gmp`","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"7.8.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"I've added `printf(3)`s to `integer-gmp`s GMP allocation/reallocation functions, and noticed there to a significant amount of allocations going on.\r\n\r\nThis is due to the fact that the CMM wrappers call `gmpz_init()` to initialize the result, and this already allocates a 1-limb `StgArray`. But the actual GMP operations perform a reallocate-call (which by contract also needs `memcpy` the untouched limb over to the newly allocated structure) based on the type of operation and the involved operands, causing the optimistically allocated 1-limb structure to become garbage right away w/o even being written to.\r\n\r\nI've been able to get rid of most such superfluous allocations by replacing\r\n\r\n{{{#!c\r\nccall __gmpz_init(mp_result1 \"ptr\");\r\n}}}\r\n\r\nby\r\n\r\n{{{#!c\r\nMP_INT__mp_alloc(mp_result1) = 0;\r\nMP_INT__mp_size(mp_result1) = 0;\r\nMP_INT__mp_d(mp_result1) = 0; // (1)\r\n}}}\r\n\r\nwhich is handled properly by all GMP operations we make use of currently. This elegantly lets the very first allocation be performed within the GMP operation (which has better knowledge with respect to how many limbs the result will require)\r\n\r\nI've got working proof-of-concept code, which reduces the allocations the big-num heavy `nofib` programs (I've omitted the benchmarks which had a 0% allocation change):\r\n\r\n{{{\r\n--------------------------------------------------------------------------------\r\n Program Size Allocs Runtime Elapsed TotalMem\r\n--------------------------------------------------------------------------------\r\n...\r\n bernouilli -0.1% -5.2% 0.12 0.12 +0.0%\r\n kahan -0.1% -10.5% 0.17 0.17 +0.0%\r\n primetest -0.1% -12.8% 0.07 0.07 +0.0%\r\n rsa -0.1% -13.8% 0.02 0.02 +0.0%\r\n symalg -0.1% -2.3% 0.01 0.01 +0.0%\r\n...\r\n--------------------------------------------------------------------------------\r\n Min -0.1% -13.8% -3.1% -3.1% -6.5%\r\n Max -0.0% +0.4% +4.0% +4.0% +1.5%\r\n Geometric Mean -0.1% -0.5% +0.5% +0.4% -0.1%\r\n}}}\r\n\r\n`(1)` This should actually point to a proper static closure I didn't need this for the proof-of-concept\r\n\r\n----\r\n\r\nAnother place which helps avoiding temporarily allocating 1-limb `StgArrays` which live only for the duration of GMP FFI calls are those caused by the `toBig`-casts, which I'm also experimenting by making use of GMP's big-int/small-int add/sub/mul primitives (the deltas shown above are actually measured on top of this optimization), here's what to expect from such an optimization by itself (i.e. w/o the realloc-optimization from above):\r\n\r\n{{{\r\n bernouilli +0.1% -4.2% 0.12 0.12 +0.0%\r\n kahan +0.1% -12.6% 0.17 0.17 +0.0%\r\n power +0.1% -2.7% +2.2% +2.2% +0.0%\r\n rsa +0.1% -4.1% 0.02 0.02 +0.0%\r\n scs +0.1% -2.6% -1.6% -1.6% +0.0%\r\n}}}\r\n\r\nThus, the `kahan` benchmark benefits from this optimization by -12.6%, and on top of that another -10.5% by also avoiding the GMP-reallocations.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/8638Optimize by demoting "denormalized" Integers (i.e. J# -> S#)2019-07-07T18:44:08ZHerbert Valerio Riedelhvr@gnu.orgOptimize by demoting "denormalized" Integers (i.e. J# -> S#)In the course of a recent [recent reddit discussion](http://www.reddit.com/r/haskell/comments/1twtvm/the_problem_with_integer/) it was highlighted, that `integer-gmp` doesn't try to demote `J#` result-values to the more efficient `S#` ev...In the course of a recent [recent reddit discussion](http://www.reddit.com/r/haskell/comments/1twtvm/the_problem_with_integer/) it was highlighted, that `integer-gmp` doesn't try to demote `J#` result-values to the more efficient `S#` even though they would fit into a machine word.
The attached proof-of-concept patch introduces a "smart" `J#` constructor which constructs a `S#` value instead (if possible):
```hs
-- | Demote 'J#' to 'S#' if possible. See also 'smartJ#'.
toSmall :: Integer -> Integer
toSmall i@(S# _) = i
toSmall (J# 0# _) = S# 0#
toSmall (J# 1# mb#) | isTrue# (v ># 0#) = S# v
where
v = indexIntArray# mb# 0#
toSmall (J# -1# mb#) | isTrue# (v <# 0#) = S# v
where
v = negateInt# (indexIntArray# mb# 0#)
toSmall i = i
-- | Smart 'J#' constructor which tries to construct 'S#' if possible
smartJ# :: Int# -> ByteArray# -> Integer
smartJ# s# mb# = toSmall (J# s# mb#)
```
The patch replaces a couple of `J#`-invocations which are likely to produce a `S#`-fitting `Integer`. A `nofib` comparison for vanilla GHC HEAD vs. patched GHC HEAD is attached for further discussion.7.8.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.org