GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-01-14T16:25:49Zhttps://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/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/8572Building an empty module with profiling requires profiling libraries for inte...2019-07-07T18:44:26ZparcsBuilding an empty module with profiling requires profiling libraries for integer-gmp```haskell
{-# LANGUAGE NoImplicitPrelude #-}
module A where
```
```
$ ghc-stage2 -prof -c A.hs
Top level:
Failed to load interface for ‛GHC.Integer.Type’
Perhaps you haven't installed the profiling libraries for package ‛integ...```haskell
{-# LANGUAGE NoImplicitPrelude #-}
module A where
```
```
$ ghc-stage2 -prof -c A.hs
Top level:
Failed to load interface for ‛GHC.Integer.Type’
Perhaps you haven't installed the profiling libraries for package ‛integer-gmp’?
Use -v to see a list of the files searched for.
```
I can't built module `A` without profiling libraries for `integer-gmp`, even though I don't use `integer-gmp` anywhere in the module.
This happens because the `Tidy Core` pass attempts to look up the `mkInteger` name (in order to desugar integer literals) even when there are no integer literals in the module.
The obvious fix is to lazily look up `mkInteger` in `Coreprep.lookupMkIntegerName`:
```diff
diff --git a/compiler/coreSyn/CorePrep.lhs b/compiler/coreSyn/CorePrep.lhs
index 5e0cd65..9836982 100644
--- a/compiler/coreSyn/CorePrep.lhs
+++ b/compiler/coreSyn/CorePrep.lhs
@@ -56,6 +56,7 @@ import Config
import Data.Bits
import Data.List ( mapAccumL )
import Control.Monad
+import System.IO.Unsafe ( unsafeInterleaveIO )
\end{code}
-- ---------------------------------------------------------------------------
@@ -1119,6 +1120,7 @@ lookupMkIntegerName dflags hsc_env
else if thisPackage dflags == integerPackageId
then return $ panic "Can't use Integer in integer"
else liftM tyThingId
+ $ unsafeInterleaveIO
$ initTcForLookup hsc_env (tcLookupGlobal mkIntegerName)
mkInitialCorePrepEnv :: DynFlags -> HscEnv -> IO CorePrepEnv
```
This way, we don't attempt to look up `mkInteger` until we actually need it, i.e. if there are integer literals that we must desugar.
Relevant commits are 2ef5cd26db27543ac8664a3d18f45550d0109a8b and fdd552e0ecaa17300670a48562995040e1d6687e
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Building an empty module with profiling requires profiling libraries for integer-gmp","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n#!haskell\r\n{-# LANGUAGE NoImplicitPrelude #-}\r\nmodule A where\r\n}}}\r\n\r\n{{{\r\n$ ghc-stage2 -prof -c A.hs\r\n\r\nTop level:\r\n Failed to load interface for ‛GHC.Integer.Type’\r\n Perhaps you haven't installed the profiling libraries for package ‛integer-gmp’?\r\n Use -v to see a list of the files searched for.\r\n}}}\r\n\r\nI can't built module `A` without profiling libraries for `integer-gmp`, even though I don't use `integer-gmp` anywhere in the module.\r\n\r\nThis happens because the `Tidy Core` pass attempts to look up the `mkInteger` name (in order to desugar integer literals) even when there are no integer literals in the module.\r\n\r\nThe obvious fix is to lazily look up `mkInteger` in `Coreprep.lookupMkIntegerName`:\r\n\r\n{{{\r\n#!diff\r\ndiff --git a/compiler/coreSyn/CorePrep.lhs b/compiler/coreSyn/CorePrep.lhs\r\nindex 5e0cd65..9836982 100644\r\n--- a/compiler/coreSyn/CorePrep.lhs\r\n+++ b/compiler/coreSyn/CorePrep.lhs\r\n@@ -56,6 +56,7 @@ import Config\r\n import Data.Bits\r\n import Data.List ( mapAccumL )\r\n import Control.Monad\r\n+import System.IO.Unsafe ( unsafeInterleaveIO )\r\n \\end{code}\r\n\r\n -- ---------------------------------------------------------------------------\r\n@@ -1119,6 +1120,7 @@ lookupMkIntegerName dflags hsc_env\r\n else if thisPackage dflags == integerPackageId\r\n then return $ panic \"Can't use Integer in integer\"\r\n else liftM tyThingId\r\n+ $ unsafeInterleaveIO\r\n $ initTcForLookup hsc_env (tcLookupGlobal mkIntegerName)\r\n\r\n mkInitialCorePrepEnv :: DynFlags -> HscEnv -> IO CorePrepEnv\r\n\r\n}}}\r\n\r\nThis way, we don't attempt to look up `mkInteger` until we actually need it, i.e. if there are integer literals that we must desugar.\r\n\r\nRelevant commits are 2ef5cd26db27543ac8664a3d18f45550d0109a8b and fdd552e0ecaa17300670a48562995040e1d6687e","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/8378Cross-compiling from x86_64-unknown-linux-gnu to x86_64-sun-solaris2 with mkG...2019-07-07T18:45:19ZAlainODeaCross-compiling from x86_64-unknown-linux-gnu to x86_64-sun-solaris2 with mkGmpConstants workaround fails to build objects for integer-gmpHere is the script I used to get build dependencies:
```
sudo apt-get update
sudo apt-get install --assume-yes ghc libncurses5-dev \
mesa-common-dev freeglut3-dev libedit-dev
cabal install happy alex haddock
```
Here is the build boo...Here is the script I used to get build dependencies:
```
sudo apt-get update
sudo apt-get install --assume-yes ghc libncurses5-dev \
mesa-common-dev freeglut3-dev libedit-dev
cabal install happy alex haddock
```
Here is the build bootstrap script I am using on a clean Ubuntu 13.04 install:
{{{
\#!/bin/bash
export TARGET=x86_64-sun-solaris2.11
export PREFIX=$HOME/Documents/gcc/cross/$TARGET
export SYSROOT=$PREFIX/sysroot
export PATH=$PATH:$PREFIX/bin
export GCC=$PREFIX/bin/$TARGET-gcc
export LD=$PREFIX/bin/$TARGET-ld
export NM=$PREFIX/bin/$TARGET-nm
export OBJDUMP=$PREFIX/bin/$TARGET-objdump
git clone git://github.com/ghc/ghc
pushd ghc
echo "Stage1Only = YES" \>\> mk/build.mk
cp mk/build.mk{.sample,}
1. /sync-all --no-dph get
perl boot
patch -d libraries/haskeline/ -p1 \< \\
1. ./ghc-patches/0001-Include-termios.h-for-solaris2-host.-Fixes-8366.patch
cp $SYSROOT/opt/local/include/gmp.h libraries/integer-gmp/gmp/
1. /configure \\
--host=x86_64-unknown-linux-gnu \\
> --build=x86_64-unknown-linux-gnu \\
> --target=x86_64-sun-solaris2 \\
> --with-gcc=$GCC \\
> --with-ld=$LD \\
> --with-nm=$NM \\
> --with-objdump=$OBJDUMP
make
\# will fail with failure to run mkGmpDerivedConstants
scp inplace/lib/bin/mkGmpDerivedConstants root\@ns2:.
ssh root\@ns2 "./mkGmpDerivedConstants" \> \\
> libraries/integer-gmp/mkGmpDerivedConstants/dist/GmpDerivedConstants.h
make
cat \<\< __EOF__ \>\> libraries/base/include/HsBaseConfig.h
\#define HTYPE_DOUBLE Double
\#define HTYPE_FLOAT Float
__EOF__
make
\#make -j $(nproc)
popd
}}}
The log of the run is attached. It is too large for the ticket body and apparently too large for Gist as well.
Somewhere along the way the build forgets integer-gmp and no objects are built for it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cross-compiling from x86_64-unknown-linux-gnu to x86_64-sun-solaris2 with mkGmpConstants workaround fails to build objects for integer-gmp","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":["solaris,integer-gmp"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here is the script I used to get build dependencies:\r\n\r\n{{{\r\nsudo apt-get update\r\nsudo apt-get install --assume-yes ghc libncurses5-dev \\\r\n mesa-common-dev freeglut3-dev libedit-dev\r\ncabal install happy alex haddock\r\n}}}\r\n\r\nHere is the build bootstrap script I am using on a clean Ubuntu 13.04 install:\r\n\r\n{{{\r\n#!/bin/bash\r\nexport TARGET=x86_64-sun-solaris2.11\r\nexport PREFIX=$HOME/Documents/gcc/cross/$TARGET\r\nexport SYSROOT=$PREFIX/sysroot\r\nexport PATH=$PATH:$PREFIX/bin\r\n\r\nexport GCC=$PREFIX/bin/$TARGET-gcc\r\nexport LD=$PREFIX/bin/$TARGET-ld\r\nexport NM=$PREFIX/bin/$TARGET-nm\r\nexport OBJDUMP=$PREFIX/bin/$TARGET-objdump\r\n\r\ngit clone git://github.com/ghc/ghc\r\npushd ghc\r\necho \"Stage1Only = YES\" >> mk/build.mk\r\ncp mk/build.mk{.sample,}\r\n./sync-all --no-dph get\r\nperl boot\r\npatch -d libraries/haskeline/ -p1 < \\\r\n ../ghc-patches/0001-Include-termios.h-for-solaris2-host.-Fixes-8366.patch\r\ncp $SYSROOT/opt/local/include/gmp.h libraries/integer-gmp/gmp/\r\n./configure \\\r\n --host=x86_64-unknown-linux-gnu \\\r\n --build=x86_64-unknown-linux-gnu \\\r\n --target=x86_64-sun-solaris2 \\\r\n --with-gcc=$GCC \\\r\n --with-ld=$LD \\\r\n --with-nm=$NM \\\r\n --with-objdump=$OBJDUMP\r\nmake\r\n# will fail with failure to run mkGmpDerivedConstants\r\nscp inplace/lib/bin/mkGmpDerivedConstants root@ns2:.\r\nssh root@ns2 \"./mkGmpDerivedConstants\" > \\\r\n libraries/integer-gmp/mkGmpDerivedConstants/dist/GmpDerivedConstants.h\r\nmake\r\ncat << __EOF__ >> libraries/base/include/HsBaseConfig.h\r\n#define HTYPE_DOUBLE Double\r\n#define HTYPE_FLOAT Float\r\n__EOF__\r\nmake\r\n#make -j $(nproc)\r\npopd\r\n}}}\r\n\r\nThe log of the run is attached. It is too large for the ticket body and apparently too large for Gist as well.\r\n\r\nSomewhere along the way the build forgets integer-gmp and no objects are built for it.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4374Remove in-tree gmp2022-12-12T20:03:31ZIan Lynagh <igloo@earth.li>Remove in-tree gmpWe already have the binary GMP DLL for Windows in the GHC tree. We should add the binary GMP dev stuff too, and then get rid of the in-tree GMP source. That would reduce build times, and simplify the build system.
I'm assuming installin...We already have the binary GMP DLL for Windows in the GHC tree. We should add the binary GMP dev stuff too, and then get rid of the in-tree GMP source. That would reduce build times, and simplify the build system.
I'm assuming installing GMP on other non-Windows OSes is not painful. We probably want to point to a framework for OS X users to use.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove in-tree gmp","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"7.4.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"igloo"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"We already have the binary GMP DLL for Windows in the GHC tree. We should add the binary GMP dev stuff too, and then get rid of the in-tree GMP source. That would reduce build times, and simplify the build system.\r\n\r\nI'm assuming installing GMP on other non-Windows OSes is not painful. We probably want to point to a framework for OS X users to use.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1