GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-26T14:59:59Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24592Off by one error in seekBinNoExpand2024-03-26T14:59:59ZMatthew PickeringOff by one error in seekBinNoExpandIf `seekBinNoExpand` is called with an offset equal to the buffer size then the function panics.
However, `putPrim` only expands the buffer in the case that the offset plus the size is strictly greater than the buffer size.
Therefore i...If `seekBinNoExpand` is called with an offset equal to the buffer size then the function panics.
However, `putPrim` only expands the buffer in the case that the offset plus the size is strictly greater than the buffer size.
Therefore if you end up writing exactly up to the buffer size and then moving to the end you will get a panic.
I imagine the following program exhibits the failure more directly.
```
bh <- openBinMem 0
bp <- tellBin @() bh
seekBinNoExpand bh bp
```
In general `seekBinNoExpand` with the result of `tellBin` should always succeed.
It might seem surprising this hasn't been discovered before but
* The initial buffer when writing an interface is 1mb, almost all interfaces are smaller than this.
* lazyPut/lazyGet and other functions which call seekBinNoExpand are not used very often.
The fix is simple, replace `>=` with `>` in `seekBin` and `seekBinNoExpand`.Hannes SiebenhandlHannes Siebenhandlhttps://gitlab.haskell.org/ghc/ghc/-/issues/24582Infinite simplifier iteration2024-03-26T15:13:09ZSimon Peyton JonesInfinite simplifier iterationConsider this little program:
```
module Foo(woo) where
foo :: String -> Int -> a
{-# NOINLINE foo #-}
foo s _ = error s
f :: (Int->Int) -> Int
{-# NOINLINE f #-}
f g = g 3
x :: Int -> a
x = foo "urk"
woo = f x
```
When compiling wi...Consider this little program:
```
module Foo(woo) where
foo :: String -> Int -> a
{-# NOINLINE foo #-}
foo s _ = error s
f :: (Int->Int) -> Int
{-# NOINLINE f #-}
f g = g 3
x :: Int -> a
x = foo "urk"
woo = f x
```
When compiling with HEAD we get
```
bash$ ~/code/HEAD/$s1 -c -O -fmax-simplifier-iterations=10 Foo.hs
WARNING:
Simplifier bailing out
Foo, after 10 iterations [12, 2, 2, 2, 2, 2, 2, 2, 2, 2]
Size = {terms: 85, types: 55, coercions: 4, joins: 0/0}
Call stack:
CallStack (from HasCallStack):
warnPprTrace, called at compiler/GHC/Core/Opt/Simplify.hs:191:9 in ghc:GHC.Core.Opt.Simplify
WARNING:
Simplifier bailing out
Foo, after 10 iterations [46, 3, 3, 3, 3, 3, 3, 3, 3, 3]
Size = {terms: 85, types: 45, coercions: 4, joins: 0/0}
Call stack:
CallStack (from HasCallStack):
warnPprTrace, called at compiler/GHC/Core/Opt/Simplify.hs:191:9 in ghc:GHC.Core.Opt.Simplify
WARNING:
Simplifier bailing out
Foo, after 10 iterations [3, 3, 3, 3, 3, 3, 3, 3, 3, 3]
Size = {terms: 85, types: 45, coercions: 4, joins: 0/0}
Call stack:
CallStack (from HasCallStack):
warnPprTrace, called at compiler/GHC/Core/Opt/Simplify.hs:191:9 in ghc:GHC.Core.Opt.Simplify
```
Clearly the Simplifier is not reaching a fixed point.
This is true in HEAD, and goes back to at least GHC 9.6 probably earlier.
## Diagnosis
We end up with
```
s1 = "urk#"
s2 = unpackSString# s1
x = foo s2 -- A partial application, since foo has arity 2
-- but x is bottoming so we don't inline it
```
The Simplifier is
* doing `preInlineUnconditionally` to inline `s1` into `s2`, and `s2` into `x`
* and then ANF-ising the RHS `foo (unpackCString# "urk"#)` to get back what we started with.
The (long-standing) bug is that the `certainly_inline` predicate in `GHC.Core.Opt.OccurAnal.mkNonRecRhsCtxt` is not tracking `preInlineUnconditionally` correctly; see Note [Cascading inlines] in that module. (In this case it is not accounting for the fact that `x` a top-level is bottoming binding.
## Solution
Update `certainly_inline`. It's not very satisfactory that this out-of-sync-ness can
happen but I don't see an easy solution.Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/24242GHC 9.8.1 panic on poly library2024-02-12T17:40:45ZDaniel FirthGHC 9.8.1 panic on poly libraryGHC 9.8.1 is panicking when trying to build the `poly` library. Seems to be fine with older compilers.
Trace here:
https://gitlab.horizon-haskell.net/package-sets/horizon-advance/-/jobs/695569
```
poly> [20 of 21] Compiling Data.Poly...GHC 9.8.1 is panicking when trying to build the `poly` library. Seems to be fine with older compilers.
Trace here:
https://gitlab.horizon-haskell.net/package-sets/horizon-advance/-/jobs/695569
```
poly> [20 of 21] Compiling Data.Poly.Sparse.Laurent ( src/Data/Poly/Sparse/Laurent.hs, dist/build/Data/Poly/Sparse/Laurent.p_o )
poly> <no location info>: error:
poly> panic! (the 'impossible' happened)
poly> GHC version 9.8.1:
poly> lookupIdSubst
poly> step1_Xh
poly> InScope {eta_B0 n1_X2 ipv_X3 ipv_X6 ipv1_X7 ipv2_X8 n1_Xf ipv_Xg
poly> v2_adj0 n1_adj1 ipv_adj3 x_aeYl wild_ag11 ds_ag12 ds1_ag13 ds2_ag14
poly> ds3_ag15 wild1_ag17 s_ag19 step1_ag1d t_ag1e ds5_ag1g wild2_ag1j
poly> x_ag1k s'_ag1l wild2_ag2F a_a1Mnj v_a1Mnk w_a1Mnl $dEq_a1Mnm
poly> $dSemiring_a1Mnn $dVector_a1Mno $dVector_a1Mnp nt_i1abe ipv_i1abf
poly> ipv1_i1abg ipv2_i1abh wild_i1Mtc ps_i1Mtd c_i1Mte ww_i1MJw
poly> ww1_i1MJx wild1_i1MJz ww2_i1MJA ww3_i1MJB monomial scale ^- eval
poly> subst deriv $mX $bX $trModule $trModule_s1Myo $trModule_s1Myp
poly> $trModule_s1Myq $trModule_s1Myr $dKnownNat_s1Myz $dKnownNat_s1MyD
poly> $dKnownNat_s1MyF $dKnownNat_s1MyV $dSemiring1_s1MyX xs_s1Mz1
poly> v1_s1Mzf v2_s1Mzh off_s1Mzt v1_s1Mzv v2_s1Mzx $j_s1MzF
poly> $dKnownNat_s1MzJ $szipWithM_s1MAz $sunstream_s1MB4 $sunstream_s1MBz
poly> $snew_s1MBB $snew_s1MBD $smapM_s1MBJ $snull_s1MBP $sfoldlM'_s1MBU
poly> $sunsafeIndex_s1MBY $sunsafeIndex_s1MC2 $sclone_s1MC9 lvl_s1MCd
poly> lvl_s1MCe lvl_s1MCx lvl_s1MCQ lvl_s1MCU lvl_s1MCV lvl_s1MD4
poly> lvl_s1MD7 lvl_s1MDa lvl_s1MDd lvl_s1MDe lvl_s1MDf lvl_s1MDg
poly> lvl_s1MDh lvl_s1MDi lvl_s1MDl lvl_s1MDo lvl_s1MDr lvl_s1MDu
poly> lvl_s1MDv lvl_s1MDw lvl_s1MDx lvl_s1MDy lvl_s1MDz lvl_s1MDC
poly> lvl_s1MDF lvl_s1MDI lvl_s1MDL lvl_s1MDM lvl_s1MDN lvl_s1MDO
poly> lvl_s1MDP lvl_s1MDQ lvl_s1MDT lvl_s1MDW lvl_s1MDZ lvl_s1ME2
poly> lvl_s1ME3 lvl_s1ME4 lvl_s1ME5 lvl_s1ME6 lvl_s1ME7 lvl_s1ME8
poly> lvl_s1ME9 lvl_s1MEa lvl_s1MEb lvl_s1MEc lvl_s1MEd lvl_s1MEf
poly> lvl_s1MEg lvl_s1MEh lvl_s1MEi lvl_s1MEl lvl_s1MEv f_s1MEx lvl_s1MEy
poly> eta1_s1MEA lvl_s1MEB eta_s1MED lvl_s1MEE lvl_s1MEG lvl_s1MEH
poly> lvl_s1MEJ lvl_s1MEK lvl_s1MEM lvl_s1MEN lvl_s1MEP lvl_s1MEQ
poly> lvl_s1MER lvl_s1MES lvl_s1MET lvl_s1MEU lvl_s1MEV lvl_s1MEW
poly> eta3_s1MF1 lvl_s1MF2 lvl_s1MF3 lvl_s1MF4 lvl_s1MF5 lvl_s1MF6
poly> lvl_s1MF7 lvl_s1MF9 lvl_s1MFc lvl_s1MFj lvl_s1MFk lvl_s1MFm
poly> lvl_s1MFo lvl_s1MFp lvl_s1MFq lvl_s1MFr lvl_s1MFt lvl_s1MFv
poly> lvl_s1MFx lvl_s1MFA lvl_s1MFH lvl_s1MFI lvl_s1MFK lvl_s1MFL
poly> lvl_s1MFM lvl_s1MFO lvl_s1MFP lvl_s1MFQ eta_s1MFS lvl_s1MFU
poly> lvl_s1MFV lvl_s1MG1 lvl_s1MG4 lvl_s1MG8 loc22_s1MGb lvl_s1MGc
poly> loc11_s1MGf lvl_s1MGg loc12_s1MGj loc1_s1MGl loc2_s1MGn loc17_s1MGp
poly> loc3_s1MGr lvl_s1MGs $dIP2_s1MGv $dIP3_s1MGx lvl_s1MHq lvl_s1MHs
poly> lvl_s1MHt lvl_s1MHv lvl_s1MHw lvl_s1MHy lvl_s1MHz lvl_s1MHB
poly> lvl_s1MHC lvl_s1MHD lvl_s1MHE lvl_s1MHF lvl_s1MHG lvl_s1MHH
poly> lvl_s1MHI lvl_s1MHL lvl_s1MHP lvl_s1MHQ lvl_s1MLp lvl_s1MLq
poly> lvl_s1MLr lvl_s1MLs lvl_s1MLt lvl_s1MLu lvl_s1MLv lvl_s1MLw
poly> lvl_s1MLx lvl_s1MLy lvl_s1MLz lvl_s1MLA lvl_s1MLB lvl_s1MLC
poly> lvl_s1MLD lvl_s1MLE $j_s1MTI lvl_s1N0f lvl_s1N0h lvl_s1N0j
poly> lvl_s1N0l lvl_s1N2v lvl_s1N2x ds4_s1NeX ww_s1Nf2 ww_s1Nf3 ww_s1Nf4
poly> ww_s1Nf6 s1_s1Nf8 $wfoldlM'_loop_s1Nfa nt_s1Njn}
poly> Call stack:
poly> CallStack (from HasCallStack):
poly> callStackDoc, called at compiler/GHC/Utils/Panic.hs:191:37 in ghc-9.8.1-inplace:GHC.Utils.Panic
poly> pprPanic, called at compiler/GHC/Core/Subst.hs:197:17 in ghc-9.8.1-inplace:GHC.Core.Subst
poly> CallStack (from HasCallStack):
poly> panic, called at compiler/GHC/Utils/Error.hs:503:29 in ghc-9.8.1-inplace:GHC.Utils.Error
poly> Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
poly>
poly> [21 of 21] Compiling Data.Poly.Sparse.Semiring ( src/Data/Poly/Sparse/Semiring.hs, dist/build/Data/Poly/Sparse/Semiring.p_o )
error: builder for '/nix/store/43v57lzxyb57jk8jlfmq3fmak418phq6-poly-0.5.1.0.drv' failed with exit code 1;
last 10 log lines:
> CallStack (from HasCallStack):
> callStackDoc, called at compiler/GHC/Utils/Panic.hs:191:37 in ghc-9.8.1-inplace:GHC.Utils.Panic
> pprPanic, called at compiler/GHC/Core/Subst.hs:197:17 in ghc-9.8.1-inplace:GHC.Core.Subst
> CallStack (from HasCallStack):
> panic, called at compiler/GHC/Utils/Error.hs:503:29 in ghc-9.8.1-inplace:GHC.Utils.Error
>
>
> Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
>
> [21 of 21] Compiling Data.Poly.Sparse.Semiring ( src/Data/Poly/Sparse/Semiring.hs, dist/build/Data/Poly/Sparse/Semiring.p_o )
```
Reproduce with:
```
git clone https://gitlab.horizon-haskell.net/package-sets/horizon-advance
cd horizon-advance
git checkout poly-failure
nix build .#poly
```9.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/23972GHC-9.4 panics due to failing lookupIdSubst for KnownNat2023-09-19T19:09:46ZLars KuhtzGHC-9.4 panics due to failing lookupIdSubst for KnownNat## Summary
GHC panics when compiling the module that is shown below.
The issue happens with GHC-9.4 (tested with GHC 9.4.6 and 9.4.7) and optimization enabled (`-O1` and `-O2`) on all tested operating systems and platforms.
GHC-8.10.7...## Summary
GHC panics when compiling the module that is shown below.
The issue happens with GHC-9.4 (tested with GHC 9.4.6 and 9.4.7) and optimization enabled (`-O1` and `-O2`) on all tested operating systems and platforms.
GHC-8.10.7, GHC-9.2 and GHC-9.6 are not affected.
## Steps to reproduce
```hs
{-# LANGUAGE DataKinds #-}
module Bug where
import Numeric.Natural (Natural)
import GHC.TypeNats (KnownNat, natVal)
import Data.Proxy (Proxy(..))
newtype M (n :: Natural) = M Natural
-- Using a smaller value for `PC` makes the issue go away.
type PC :: Natural
type PC = 0x1_0000_0000_0000_0000
-- remove (or simplifying) one case makes the issue go away.
f :: forall n . KnownNat n => M n -> M n
f (M 0) = M 0
f (M x) = M (natVal @n Proxy + x)
-- removing one invocation of `f` makes the issue go away.
g :: KnownNat n => M n -> M n
g x = f (f x)
-- removing the let binding or one invocation of `g` makes the issue go away.
h :: M PC -> M PC
h x = let a = g (g x) in a
```
Compiling this module with GHC-9.4.7 and `-O1` or `-O2` as follows
```sh
ghc -O1 Bug.hs
```
Results in the output
```
[1 of 1] Compiling Bug ( Bug.hs, Bug.o ) [Source file changed]
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.4.7:
lookupIdSubst
$dKnownNat_sUW
InScope {wild_X2 z_anJ $krep_aQG $krep_aQH $krep_aQI $krep_aQJ
$krep_aQK h $tc'M $trModule $tcM f g $trModule_sUK $trModule_sUL
$trModule_sUM $trModule_sUN $krep_sUO $tcM_sUP $tcM_sUQ $krep_sUR
$tc'M_sUS $tc'M_sUT $sg_sV3}
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:182:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Core/Subst.hs:260:17 in ghc:GHC.Core.Subst
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
## Expected behavior
GHC compiles the module.
## Environment
The issue was reproduced with
* GHC-9.4.6 and GHC-9.6.7
* ubuntu/linux (amd64) and macOS (amd64 as well as aarch64).https://gitlab.haskell.org/ghc/ghc/-/issues/23891heap overflow panic with 9.2 (but not 9.0 or 9.4)2023-08-29T14:50:04Zquarkheap overflow panic with 9.2 (but not 9.0 or 9.4)## Summary
We observed a failure when compiling code in [the BSC project](https://github.com/B-Lang-org/bsc) with GHC 9.2.8, that does not occur when compiling with earlier GHC 9.0.2 or later GHC 9.4.6 and 9.6.2. We have boiled it down...## Summary
We observed a failure when compiling code in [the BSC project](https://github.com/B-Lang-org/bsc) with GHC 9.2.8, that does not occur when compiling with earlier GHC 9.0.2 or later GHC 9.4.6 and 9.6.2. We have boiled it down to a small two-file example, in case you wanted to investigate -- in case the issue still exists in 9.4+ and is just being masked. The error we see is:
```
[1 of 2] Compiling Util ( Util.hs, Util.o )
[2 of 2] Compiling GenABin ( GenABin.hs, GenABin.o )
ghc-9.2.8: panic! (the 'impossible' happened)
(GHC version 9.2.8:
heap overflow
```
## Steps to reproduce
Place the following three files in a directory and run `make`:
[Util.hs](/uploads/fbe6a7b5611a7f17e6fbac1a69527654/Util.hs) (20 lines),
[GenABin.hs](/uploads/0e2cdd7e19878e41e0648d05c6c23724/GenABin.hs) (365 lines),
[Makefile](/uploads/478a658aaea2289c9dbfddceb886e736/Makefile). That will run the following command:
```
ghc \
-O2 \
-hide-all-packages \
-Wall \
-fno-warn-unused-binds \
-package base \
-package bytestring \
-package containers \
-package text \
+RTS -M4G -A128m -RTS \
GenABin.hs
```
The file `Util.hs` contains two small definitions that are imported by the top file `GenABin.hs`. If those definitions are merged into the top file, then it compiles without error. So the separation into two files is necessary. If the numbers of fields of the `Flags` datatype is reduced (from 125 to a dozen or so), then it compiles fine; so many fields is necessary (though we haven't experimented with other amounts). Without the RTS flags, I think that GHC starts to use up all the memory and swaps, so the RTS flags may be necessary to get it to fail early.
I can't determine if this is a duplicate of existing issues. For example, #20683.
## Expected behavior
If I try with GHC 9.4.6, it compiles without an error:
```
[1 of 2] Compiling Util ( Util.hs, Util.o )
[2 of 2] Compiling GenABin ( GenABin.hs, GenABin.o )
```
## Environment
I observe these behaviors on both macOS 11.7.8 (x86_64) and Debian 11.7 (x86_64).Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/23533Windows, GHC 9.6.2, munmapForLinker: m32_release_page: Failed to unmap ... At...2023-09-16T12:01:43ZMike PilgremWindows, GHC 9.6.2, munmapForLinker: m32_release_page: Failed to unmap ... Attempt to access invalid address.## Summary
The [CI for a pull request in the Hpack project](https://github.com/sol/hpack/pull/518) for Windows only, using the 'system' GHC 9.6.2 supplied by the GitHub hosted runner and `cabal-3.10.1.0` dies with complaints about unkno...## Summary
The [CI for a pull request in the Hpack project](https://github.com/sol/hpack/pull/518) for Windows only, using the 'system' GHC 9.6.2 supplied by the GitHub hosted runner and `cabal-3.10.1.0` dies with complaints about unknown symbols:
~~~text
ghc-9.6.2.exe: | C:\cabal\store\ghc-9.6.2\tls-1.7.0-8d58f20e9eccc9f7873d67e5a2bfbab4adac37aa\lib\libHStls-1.7.0-8d58f20e9eccc9f7873d67e5a2bfbab4adac37aa.a: unknown symbol `gettimeofday'
ghc-9.6.2.exe: | C:\cabal\store\ghc-9.6.2\tls-1.7.0-8d58f20e9eccc9f7873d67e5a2bfbab4adac37aa\lib\libHStls-1.7.0-8d58f20e9eccc9f7873d67e5a2bfbab4adac37aa.a: unknown symbol `tlszm1zi7zi0zm8d58f20e9eccc9f7873d67e5a2bfbab4adac37aa_NetworkziTLSziHandshakeziCommon13_zdwmakeCipherChoice_info'
ghc-9.6.2.exe: | C:\cabal\store\ghc-9.6.2\crypton-conne_-0.3.1-8964bf584322945dcb53418157c8e69109bc0668\lib\libHScrypton-conne_-0.3.1-8964bf584322945dcb53418157c8e69109bc0668.a: unknown symbol `tlszm1zi7zi0zm8d58f20e9eccc9f7873d67e5a2bfbab4adac37aa_NetworkziTLSziCore_bye1_closure'
ghc-9.6.2.exe: | C:\cabal\store\ghc-9.6.2\http-client-t_-0.3.6.2-887fc88ddae31b1bedf678cc8338c500c876074d\lib\libHShttp-client-t_-0.3.6.2-887fc88ddae31b1bedf678cc8338c500c876074d.a: unknown symbol `cryptonzmconnezuzm0zi3zi1zm8964bf584322945dcb53418157c8e69109bc0668_NetworkziConnection_zdfExceptionLineTooLong3_closure'
ghc-9.6.2.exe: | D:\a\hpack\hpack\dist-newstyle\build\x86_64-windows\ghc-9.6.2\hpack-0.35.2\t\spec\build\spec\spec-tmp\Hpack\Defaults.o: unknown symbol `httpzmclientzmtzuzm0zi3zi6zi2zm887fc88ddae31b1bedf678cc8338c500c876074d_NetworkziHTTPziClientziTLS_tlsManagerSettings_closure'
ghc-9.6.2.exe: Could not load Object Code D:\a\hpack\hpack\dist-newstyle\build\x86_64-windows\ghc-9.6.2\hpack-0.35.2\t\spec\build\spec\spec-tmp\Hpack\Defaults.o.
<no location info>: error:
~~~
then a series of 33 of the following messages at different memory addresses:
~~~text
ghc-9.6.2.exe: munmapForLinker: m32_release_page: Failed to unmap 4096 bytes at 00007ff7e06e6000: Attempt to access invalid address.
~~~
and then
~~~text
Access violation in generated code when reading 0x20
Attempting to reconstruct a stack trace...
Frame Code address
* 0x8f3c7fd840 0x7ff7d2d06636 C:\ghcup\ghc\9.6.2\bin\ghc-9.6.2.exe+0x4286636
* 0x8f3c7fd8c0 0x7ff7d19de05f C:\ghcup\ghc\9.6.2\bin\ghc-9.6.2.exe+0x2f5e05f
* 0x8f3c7fd8f0 0x7ff7d19deaf8 C:\ghcup\ghc\9.6.2\bin\ghc-9.6.2.exe+0x2f5eaf8
* 0x8f3c7fd8f8 0x7ff7d24818af C:\ghcup\ghc\9.6.2\bin\ghc-9.6.2.exe+0x3a018af
* 0x8f3c7fd900 0x7ef4f69385d0
* 0x8f3c7fd908 0x1ba0652d860
* 0x8f3c7fd910 0x4ee39
* 0x8f3c7fd918 0x7ef4f2ae7c40
Error: cabal-3.10.1.0.exe: Failed to build test:spec from hpack-0.35.2. The
build process terminated with exit code 11
~~~
At the [Haskell Community](https://discourse.haskell.org/t/cabals-foreign-library-stanza/6516/8?u=mpilgrem), it has been speculated that perhaps the fix of https://gitlab.haskell.org/ghc/ghc/-/issues/19421 has introduced a bug.
This may be Windows-specific, as the ubuntu-latest/GHC 9.6 and macos-latest/'system' GHC CI both pass. The ubuntu-latest/GHC 8.2 to GHC 9.4 also all pass. However, the CI does not test Windows pre-GHC 9.6.2.
## Steps to reproduce
I don't yet have a reproducer outside of the Hpack project CI script. Also, I can build and test the Hpack project at the commit in the PR using Stack and GHC 9.6.2, without a problem.
## Environment
* GHC version used: GHC 9.6.2
Optional:
* Operating System: Windows Server 2022
* System Architecture: x86_64Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23451Build error: fixup value out of range when ipe flavour transformer turned on2023-09-07T09:12:05ZIan-Woo KimBuild error: fixup value out of range when ipe flavour transformer turned onWhen I try to build GHC with `ipe` flavour transformer, the build failed here: (when compiling GHC.Parser)
```
$ hadrian/build -j --flavour=Quick+ipe
...
| Run Ghc CompileHs Stage1: compiler/GHC/Tc/Solver.hs => _build/stage1/compiler/bui...When I try to build GHC with `ipe` flavour transformer, the build failed here: (when compiling GHC.Parser)
```
$ hadrian/build -j --flavour=Quick+ipe
...
| Run Ghc CompileHs Stage1: compiler/GHC/Tc/Solver.hs => _build/stage1/compiler/build/GHC/Tc/Solver.o
Command line: _build/stage0/bin/ghc -Wall -Wcompat -dynamic-too -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage1/inplace/package.conf.d' '-this-unit-id ghc-9.7-inplace' '-package-id array-0.5.5.0-inplace' '-package-id base-4.18.0.0-inplace' '-package-id binary-0.8.9.1-inplace' '-package-id bytestring-0.11.4.0-inplace' '-package-id containers-0.6.7-inplace' '-package-id deepseq-1.4.8.1-inplace' '-package-id directory-1.3.8.1-inplace' '-package-id exceptions-0.10.7-inplace' '-package-id filepath-1.4.100.1-inplace' '-package-id ghc-boot-9.7-inplace' '-package-id ghc-heap-9.7-inplace' '-package-id ghci-9.7-inplace' '-package-id hpc-0.6.2.0-inplace' '-package-id process-1.6.17.0-inplace' '-package-id semaphore-compat-1.0.0-inplace' '-package-id stm-2.5.1.0-inplace' '-package-id template-haskell-2.20.0.0-inplace' '-package-id time-1.12.2-inplace' '-package-id transformers-0.6.1.0-inplace' '-package-id unix-2.8.1.0-inplace' -i -i/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/compiler/build -i/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/compiler/build/autogen -i/Users/ianwookim/repo/srcc/ghcHEAD/compiler -Irts/include -I_build/stage1/compiler/build -I_build/stage1/compiler/build/. -Icompiler/. -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/process/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/process/build/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/directory -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/directory/build -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/unix/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/unix/build/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/time/lib/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/time/build/lib/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/containers/containers/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/containers/containers/build/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/bytestring/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/bytestring/build/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/base/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/base/build/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/ghc-bignum/include/ -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/ghc-bignum/build/include/ -I/Users/ianwookim/repo/srcc/ghcHEAD/rts/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/rts/build/include -optP-include -optP_build/stage1/compiler/build/autogen/cabal_macros.h -optc--target=arm64-apple-darwin -optP-DHAVE_INTERNAL_INTERPRETER -optP-DCAN_LOAD_DLL -outputdir _build/stage1/compiler/build -fdiagnostics-color=always -Wall -Wno-name-shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monoid-instances -XHaskell2010 -XNoImplicitPrelude -XBangPatterns -XScopedTypeVariables -XMonoLocalBinds -XTypeOperators -no-global-package-db -package-db=/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/inplace/package.conf.d -ghcversion-file=rts/include/ghcversion.h -ghcversion-file=rts/include/ghcversion.h -Wnoncanonical-monad-instances -optc-Wno-unknown-pragmas -optP-Wno-nonportable-include-path -c _build/stage1/compiler/build/GHC/Parser.hs -o _build/stage1/compiler/build/GHC/Parser.o -O0 -H64m -finfo-table-map -fdistinct-constructor-tables -fno-ignore-interface-pragmas -fcmm-sink -haddock -Winvalid-haddock -Wno-deprecated-flags -Wcpp-undef
===> Command failed with error code: 1
/tmp/nix-shell.eNdd3H/ghc58850_0/ghc_3.s:36865:2: error:
error: fixup value out of range
b.hi LcHST
^
|
36865 | b.hi LcHST
| ^
/tmp/nix-shell.eNdd3H/ghc58850_0/ghc_3.s:36883:2: error:
error: fixup value out of range
b.hi LcHSW
^
|
36883 | b.hi LcHSW
| ^
...
```
building GHC 9.7.20230522
on Aarch64 macbook m1, macOS 13.2.19.8.2Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/23375RTS error: scavenge_one: strange object 23 while using byte-code linking in c...2023-10-18T17:02:42ZIan-Woo KimRTS error: scavenge_one: strange object 23 while using byte-code linking in compilationOn x86_64 linux system, we turn on byte-code linking (`-fprefer-byte-code -fbyte-code-and-object-code`) and we increasingly get this error in GC during compiling a project (the following is an excerpt from CI message)
```
> ghc-9....On x86_64 linux system, we turn on byte-code linking (`-fprefer-byte-code -fbyte-code-and-object-code`) and we increasingly get this error in GC during compiling a project (the following is an excerpt from CI message)
```
> ghc-9.6.1: internal error: scavenge_one: strange object 23
> Stack trace:
> 0x7fffef186bc0 set_initial_registers (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffeeddd5c8 dwfl_thread_getframes (/nix/store/sd6nsyj6v8qmdr07g5hl5rp8mpkbzasp-elfutils-0.189/lib/libdw-0.189.so)
> 0x7fffeeddd11b get_one_thread_cb (/nix/store/sd6nsyj6v8qmdr07g5hl5rp8mpkbzasp-elfutils-0.189/lib/libdw-0.189.so)
> 0x7fffeeddd42a dwfl_getthreads (/nix/store/sd6nsyj6v8qmdr07g5hl5rp8mpkbzasp-elfutils-0.189/lib/libdw-0.189.so)
> 0x7fffeeddd957 dwfl_getthread_frames (/nix/store/sd6nsyj6v8qmdr07g5hl5rp8mpkbzasp-elfutils-0.189/lib/libdw-0.189.so)
> 0x7fffef187297 libdwGetBacktrace (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef18fb27 rtsFatalInternalErrorFn (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef18fd1d barf (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef1bccb4 scavenge_one (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef1bd1ef scavenge_mutable_list (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef1bd420 scavenge_capability_mut_lists (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef1b322a GarbageCollect (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef193fdd scheduleDoGC (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef194c02 schedule (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef19585c scheduleWorker (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef199edd workerStart (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffeeed2e24 start_thread (/nix/store/1n2l5law9g3b77hcfyp50vrhhssbrj5g-glibc-2.37-8/lib/libc.so.6)
> 0x7fffeef549b0 __clone3 (/nix/store/1n2l5law9g3b77hcfyp50vrhhssbrj5g-glibc-2.37-8/lib/libc.so.6)
>
> (GHC version 9.6.1 for x86_64_unknown_linux)
> Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
> /nix/store/5s1yg5l36wzgy1dj0vv1ibarc4g7vrdr-stdenv-linux/setup: line 1595: 103601 Aborted (core dumped) ./Setup build
```9.6.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23217Test of atomic fetches fails on i386 with allocateRegsAndSpill panic2023-04-05T16:12:10ZBodigrimTest of atomic fetches fails on i386 with allocateRegsAndSpill panicAn i386 job for !10228 (https://gitlab.haskell.org/ghc/ghc/-/jobs/1435453#L4752) fails with:
```
Compile failed (exit code 1) errors were:
ghc-9.7.20230402: panic! (the 'impossible' happened)
GHC version 9.7.20230402:
allocateRegsAndS...An i386 job for !10228 (https://gitlab.haskell.org/ghc/ghc/-/jobs/1435453#L4752) fails with:
```
Compile failed (exit code 1) errors were:
ghc-9.7.20230402: panic! (the 'impossible' happened)
GHC version 9.7.20230402:
allocateRegsAndSpill: Cannot read from uninitialized register
%vHi_H3
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:189:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/CmmToAsm/Reg/Linear.hs:837:20 in ghc:GHC.CmmToAsm.Reg.Linear
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:480:29 in ghc:GHC.Utils.Error
```
`GHC.CmmToAsm.Reg.Linear` says
```haskell
pprPanic "allocateRegsAndSpill: Cannot read from uninitialized register" (ppr r)
-- NOTE: if the input to the NCG contains some
-- unreachable blocks with junk code, this panic
-- might be triggered. Make sure you only feed
-- sensible code into the NCG. In GHC.Cmm.Pipeline we
-- call removeUnreachableBlocks at the end for this
-- reason.
```
This might be very well the case: !10228 adds a test case with hand-written CMM. However, while the code in question is silly, up to my (very limited) understanding all blocks should be reachable. And all 64-bit jobs succeed.
This is not a blocker for !10228 (#23206) which is concerned only with adding `%fetch_fooXX` primops to CMM parser. I'm going to disable i386 job there.Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/23138GHC Panic: loadArchive trying to load Nix's clang++ wrapper (darwin-aarch64)2024-03-10T11:39:42ZTravis Whitakerpi.boy.travis@gmail.comGHC Panic: loadArchive trying to load Nix's clang++ wrapper (darwin-aarch64)It seems something has changed about archive loading in the 9.x series (at least 9.2.7 and 9.4.4) that makes GHC not like the shell environment that Nix provides on darwin-aarch64. As is the case strangely often for me, accelerate is the...It seems something has changed about archive loading in the 9.x series (at least 9.2.7 and 9.4.4) that makes GHC not like the shell environment that Nix provides on darwin-aarch64. As is the case strangely often for me, accelerate is the only package I've found that reproduces this. Please forgive the annoying repro, I'm still searching for a smaller one.
First, clone the `loadarchive-bug` branch of my fork of accelerate [here](https://github.com/TravisWhitaker/accelerate/tree/loadarchive-bug). All I've done here is bump `base` in `accelerate.cabal`, and provided two minimal `shell.nix` files that give GHC 9.2.7 or GHC 9.4.4, plus Nixpkgs' current stdenv for darwin-aarch64. Then, all you have to do (with either the 927-shell.nix or 944-shell.nix) is:
```
$ cat shell.nix
let pkgsrc = builtins.fetchGit
{
url = "https://github.com/nixos/nixpkgs";
ref = "master";
rev = "38637c5c8fddf9c5b454918acf309c55e3809af1";
};
in with import pkgsrc {};
let thisghc = haskell.packages.ghc927.ghcWithPackages (p: [p.cabal-install]);
in mkShell
{
packages = [thisghc];
}
$ nix-shell --pure
[nix-shell:~/sources/accelerate]$ cabal clean
[nix-shell:~/sources/accelerate]$ cabal build
Resolving dependencies...
Build profile: -w ghc-9.2.7 -O1
In order, the following will be built (use -v for more details):
- accelerate-1.3.0.0 (lib:accelerate) (first run)
[1 of 1] Compiling Main ( /Users/twhitaker/sources/accelerate/dist-newstyle/build/aarch64-osx/ghc-9.2.7/accelerate-1.3.0.0/setup/setup.hs, /Users/twhitaker/sources/accelerate/dist-newstyle/build/aarch64-osx/ghc-9.2.7/accelerate-1.3.0.0/setup/Main.o )
Linking /Users/twhitaker/sources/accelerate/dist-newstyle/build/aarch64-osx/ghc-9.2.7/accelerate-1.3.0.0/setup/setup ...
Configuring accelerate-1.3.0.0...
Preprocessing library for accelerate-1.3.0.0..
Building library for accelerate-1.3.0.0..
[ 1 of 109] Compiling Crypto.Hash.XKCP ( src/Crypto/Hash/XKCP.hs, /Users/twhitaker/sources/accelerate/dist-newstyle/build/aarch64-osx/ghc-9.2.7/accelerate-1.3.0.0/build/Crypto/Hash/XKCP.o, /Users/twhitaker/sources/accelerate/dist-newstyle/build/aarch64-osx/ghc-9.2.7/accelerate-1.3.0.0/build/Crypto/Hash/XKCP.dyn_o )
ghc: loadArchive: Neither an archive, nor a fat archive: `/nix/store/wqjp99m9d4dzi4ydwj87xr0z2dfygv9b-clang-wrapper-11.1.0/bin/clang++'
ghc: panic! (the 'impossible' happened)
(GHC version 9.2.7:
loadArchive "/nix/store/wqjp99m9d4dzi4ydwj87xr0z2dfygv9b-clang-wrapper-11.1.0/bin/clang++": failed
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
Initially I was surprised that compiling modules needs to load archives in the first place, but then I realized it's because of the Template Haskell in `src/Crypto/Hash/XKCP.hs`. I'm not sure why it's picking on `clang++` in particular. I think it might have something to do with the fact that accelerate depends on double-conversion, which in turn depends on some C++ something or other.
Both https://gitlab.haskell.org/ghc/ghc/-/issues/16590#note_195984 and https://gitlab.haskell.org/ghc/ghc/-/issues/16063 seem related, but not exactly the same (and at least partially solved on the 9.x series).9.8.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23060Bytecode interpreter: ASSERT failed - conflation of isUnliftedType == Addr#2023-06-21T17:36:40ZMatthew PickeringBytecode interpreter: ASSERT failed - conflation of isUnliftedType == Addr#```
<no location info>: error:
ASSERT failed!
CallStack (from HasCallStack):
massert, called at compiler/GHC/StgToByteCode.hs:1802:15 in ghc:GHC.StgToByteCode
```
The `UnlGadt1` test
```haskell
{-# LANGUAGE UnliftedDatatypes ...```
<no location info>: error:
ASSERT failed!
CallStack (from HasCallStack):
massert, called at compiler/GHC/StgToByteCode.hs:1802:15 in ghc:GHC.StgToByteCode
```
The `UnlGadt1` test
```haskell
{-# LANGUAGE UnliftedDatatypes #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE KindSignatures #-}
import GHC.Exts
import GHC.Types
data T a :: UnliftedType where
TInt :: T Int
f :: T a -> Int
f _ = 0
g :: T a -> T a
g TInt = TInt
{-# NOINLINE g #-}
main = do
case g TInt of TInt -> putStrLn "should see this"
print (f (error "boom")) -- crashes!
```
```
"/home/matt/ghc-9.6-backports/_debug_clean/stage1/bin/ghc" UnlGadt1.hs -dcore-lint -dstg-lint -dcmm-lint --interactive
```Alexis KingAlexis Kinghttps://gitlab.haskell.org/ghc/ghc/-/issues/21118InScope ASSERT failure with break0062022-02-23T14:10:21ZMatthew PickeringInScope ASSERT failure with break006```
+panic! (the 'impossible' happened)
+ GHC version 9.3.20220221:
+ ASSERT failed!
+ in_scope InScope {wild_00}
+ tenv [ams :-> LiftedRep, amt :-> LiftedRep, amu :-> a_I16g[rt],
+ amv :-> ()]
+ tenvFVs {a_I16g[rt]}
+ cenv [...```
+panic! (the 'impossible' happened)
+ GHC version 9.3.20220221:
+ ASSERT failed!
+ in_scope InScope {wild_00}
+ tenv [ams :-> LiftedRep, amt :-> LiftedRep, amu :-> a_I16g[rt],
+ amv :-> ()]
+ tenvFVs {a_I16g[rt]}
+ cenv []
+ cenvFVs {}
+ tys [q_ams]
+ cos []
+ Call stack:
+ CallStack (from HasCallStack):
+ assertPpr, called at compiler/GHC/Core/TyCo/Subst.hs:<line>:<column> in <package-id>:GHC.Core.TyCo.Subst
+ checkValidSubst, called at compiler/GHC/Core/TyCo/Subst.hs:<line>:<column> in <package-id>:GHC.Core.TyCo.Subst
+ substTy, called at compiler/GHC/Core/Opt/Simplify/Env.hs:<line>:<column> in <package-id>:GHC.Core.Opt.Simplify.Env
```
Related to #21113https://gitlab.haskell.org/ghc/ghc/-/issues/20519Cross-compiled riscv64 binary fails to execute under qemu-user-riscv642021-11-04T08:13:46ZhexchainCross-compiled riscv64 binary fails to execute under qemu-user-riscv64## Summary
Bootstrapping a riscv64 toolchain on x64 results in some unusable stage2 binaries.
## Steps to reproduce
0. Create a working directory (e.g. `~/build`) and clone the ghc repository into it.
1. Prepare a Debian sid x64 chroo...## Summary
Bootstrapping a riscv64 toolchain on x64 results in some unusable stage2 binaries.
## Steps to reproduce
0. Create a working directory (e.g. `~/build`) and clone the ghc repository into it.
1. Prepare a Debian sid x64 chroot (I am using `debian-sid-tar` from https://hub.nspawn.org/images/).
2. Mount the directory inside the chroot and start it. Personally I found it very simple with systemd-nspawn:
```
systemd-nspawn -D /path/to/debian/x64 --bind=~/build:/build
```
3. Install required tools in the chroot (git, build-essential, gcc-12, autoconf, python3, riscv64-linux-gnu-gcc, llvm-12, ghc 8.10.6 from experimental, happy, alex).
4. Build the `ghc-9.2` branch with !6765 because rv64 gcc requires explicitly linking to libatomic for sub-word atomic operations.
```
(debian-sid-x64-chroot) $ ./boot
(debian-sid-x64-chroot) $ ./configure --target=riscv64-linux-gnu
(debian-sid-x64-chroot) $ make
```
build.mk:
```
...
BuildFlavour = quick
...
WITH_TERMINFO = NO
BUILD_EXTRA_PKGS = NO
HADDOCK_DOCS = NO
BUILD_MAN = NO
BUILD_SPHINX_HTML = NO
BUILD_SPHINX_PDF = NO
GhcRtsCcOpts += -fkeep-inline-functions
DYNAMIC_GHC_PROGRAMS = NO
GhcLibWays = v
GhcRTSWays = debug
GhcThreaded = NO
GhcDebugged = YES
```
5. Setup `qemu-user-static` and binfmt-misc, and prepare a riscv64 chroot (may refer to [this Debian wiki article](https://wiki.debian.org/RISC-V#Qemu), starting from the "Qemu" section).
6. Mount the working directory into the chroot and start it:
```
systemd-nspawn -D /path/to/debian/rv64 --bind=~/build:/build
```
7. Try to execute the stage2 binary:
```
(debian-rv64-chroot) $ inplace/bin/ghc-stage2
ghc-stage2: internal error: ASSERTION FAILED: file rts/dist/build/AutoApply.cmm, line 2317
(GHC version 9.2.0.20211020 for riscv64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
Aborted (core dumped)
```
A more detailed log, with `+RTS -Di -Da -Ds -DS`, can be found at https://ix.io/3CkH.
I've also tried to pull in 8b5e5b0524f614679a20ffaebab731c54dc6dee9 and cb862ecfc3d9d421ff64af35c0d87f6d6f835fa0 (the branch is at https://gitlab.haskell.org/hexchain/ghc/-/tree/ghc-9.2-rv64-bootstrap). The compiler still crashes, but only with a "Segmentation fault". With `+RTS -Di -Da -Ds -DS` there is not much difference.
## Expected behavior
The stage2 binary should work without any problem.
## Environment
* GHC version used: 8.10.6 (from debian experimental)
* LLVM: 12.0
* GCC: riscv64-linux-gnu-gcc 11.2.0
Optional:
* Operating System: Arch Linux
* System Architecture: x64https://gitlab.haskell.org/ghc/ghc/-/issues/19919Fail when calling the function from the Haskell shared library (that uses FFI...2021-06-02T10:17:44ZOlga PhillipsFail when calling the function from the Haskell shared library (that uses FFI and GHC API) on Visual studio 64-bit project## Summary
I work on the Visual Studio 2015/2017 C++ project, which uses the Haskell library. There are some metadata, processed by the Haskell library functions in the following way: the data are translated to Haskell code, compiled by...## Summary
I work on the Visual Studio 2015/2017 C++ project, which uses the Haskell library. There are some metadata, processed by the Haskell library functions in the following way: the data are translated to Haskell code, compiled by the GHC 8.10.4, then some 'root' function is calculated and the result is returned to the C++ code. We had been working with the 32-bit architecture, and everything was fine, until we moved to the 64-bit version. After that I started to face different misbevaior, depending on the Windows version:
`Exception “hPutChar: invalid argument (Bad file descriptor)”` on Windows 7
`Error: :”ghcDLL: internal error: IMAGE_REL_AMD64_ADDR32[NB]: High bits are set in 133505844b0 for .text$.Lsow_info”`on Windows 10
I also came along with this issue: [Internal error running FFI interpreter on Visual Studio](https://gitlab.haskell.org/ghc/ghc/-/issues/19686), it illustrates the similar problem.Anyway, I decided to illustrate the issue with my own sample (see "Steps to reproduce") that includes also Haskell sources and probably may help to investigate deeper into the problem. Unfortunately, it was very hard to reproduce exactly the same behavior in the much less sample than the project we work on, but still I managed to reproduce a failure of the program.
## Brief source description
Here we have the Haskell library, which exports, in particular, the following functions:
- `c_create_context`: creates the contexts and imports some standard modules (Prelude and Control.DeepSeq in this case)
- `c_bring_decls_to_context`: takes Haskell source code, interprets it and bring the names to the given context
- `c_execute`: takes the function name, evaluates it and returns the string representation of the result .
- `c_ghc_has_exception`: checks, if the previous manipulation with the Context cause an exception.
- `c_has_pref_error`: checks, if the function evaluation caused an error and extracts partial evaluated result.
- `c_show_result`: print the result of c_execute.
For minimizing purposes modules names, passed to `c_create_context` and the Haskell source code, passed to `c_bring_decls_to_context` are hard-coded.
The `HSCodeGen.cpp` inter-layer is needed, because the MSVC doesn't support some language constructions that are used in Rts.h.
## Steps to reproduce
1. Clone [Haskell_FFI_GHC_API_64-bit_fail](https://github.com/Valoisa/Haskell_FFI_GHC_API_64-bit_fail).
2. Build the project, Debug x64 configuration.
3. Run the program.
## Expected behavior
Should print "Hello, world!"
## Actual behavior
Fails on c_execute.
## Environment
* GHC version used: 8.10.4
* OS Windows 10
* System architecture 64-bit
* Visual studio 2015https://gitlab.haskell.org/ghc/ghc/-/issues/19866GHC version 8.10.4 panic! (the 'impossible' happened, indeed)2022-04-06T13:06:34Zraph2705GHC version 8.10.4 panic! (the 'impossible' happened, indeed)## Summary
GHC panic while building `cardano-node` ([on github](https://github.com/input-output-hk/cardano-node)), error message displayed :
> `ghc: panic! (the 'impossible' happened)`\
> ` (GHC version 8.10.4:`\
> `Loading temp share...## Summary
GHC panic while building `cardano-node` ([on github](https://github.com/input-output-hk/cardano-node)), error message displayed :
> `ghc: panic! (the 'impossible' happened)`\
> ` (GHC version 8.10.4:`\
> `Loading temp shared object failed: /tmp/ghc54158_0/libghc_10.so: failed to map segment from shared object`
## Steps to reproduce
1. Have `/tmp` filesystem mounted with flags \``noexec,nosuid,nodev`' (protection against exploit execution, I believe `noexec` is the only culprit here)
2. Get `cardano-node` [source code](https://github.com/input-output-hk/cardano-node) and checkout tag `1.27.0` (detailed guide [here](https://developers.cardano.org/en/testnets/cardano/get-started/installing-and-running-the-cardano-node/building-the-node-from-source/))
3. Launch compilation with `$ cabal -v build cardano-node` from `cardano-node` src directory on `/home` filesystem
4. Wait for the GHC panic
5. Eventually do it over again, after `$ sudo mount -o remount,exec /tmp`
<details>
<summary markdown="span">Hic sunt dracones</summary>
```
Component build order: library
/usr/local/bin/ghc-pkg-8.10.4 init dist/package.conf.inplace
creating dist/build
creating dist/build/autogen
creating dist/build/autogen
Preprocessing library for th-orphans-0.13.11..
Building library for th-orphans-0.13.11..
creating dist/build
/usr/local/bin/ghc-8.10.4 --make -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir dist/build -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -isrc -idist/build/autogen -idist/build/global-autogen -Idist/build/autogen -Idist/build/global-autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -this-unit-id th-orphans-0.13.11-bc6d1defe77cbdee4ce1b13900dfcf7bfa6a03e0c1b75296ae151bc8951da94f -hide-all-packages -Wmissing-home-modules -no-user-package-db -package-db /home/raph/.cabal/store/ghc-8.10.4/package.db -package-db dist/package.conf.inplace -package-id base-4.14.1.0 -package-id mtl-2.2.2 -package-id template-haskell-2.16.0.0 -package-id th-compat-0.1.2-d27ac856dec8c28ef3a10ee6e1b5096cccb90c3b120cf83a7ec953297d678a7f -package-id th-lift-0.8.2-3df3c85ae4b51b59aa779ddfd371e1ef04a08fea56c6bc0d3f4eb3244e5f00f5 -package-id th-lift-instances-0.1.18-c922ba81f113bb068dd922d8caecc87c25b143d38851baca3fbac63b2544806d -package-id th-reify-many-0.1.9-409fd9217fb040a8a61c2933f9703291ff548974de219f262c8b5188db52835b -XHaskell2010 Language.Haskell.TH.Instances Language.Haskell.TH.Instances.Internal -Wall -Wno-star-is-type -hide-all-packages
[1 of 2] Compiling Language.Haskell.TH.Instances.Internal ( src/Language/Haskell/TH/Instances/Internal.hs, dist/build/Language/Haskell/TH/Instances/Internal.o, dist/build/Language/Haskell/TH/Instances/Internal.dyn_o )
[2 of 2] Compiling Language.Haskell.TH.Instances ( src/Language/Haskell/TH/Instances.hs, dist/build/Language/Haskell/TH/Instances.o, dist/build/Language/Haskell/TH/Instances.dyn_o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.10.4:
Loading temp shared object failed: /tmp/ghc54158_0/libghc_10.so: failed to map segment from shared object
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
cabal: Failed to build byron-spec-chain-0.1.0.0 because it depends on
byron-spec-chain-0.1.0.0 which itself failed to build.
Failed to build byron-spec-ledger-0.1.0.0 because it depends on
byron-spec-ledger-0.1.0.0 which itself failed to build.
Failed to build cardano-api-1.27.0 because it depends on cardano-api-1.27.0
which itself failed to build.
```
</details>
## Expected behavior
No panic. Maybe some nice and useful message displaying.
## Environment
* GHC version used: `8.10.4`
Optional:
* Operating System: GNU/Linux Debian 10
* System Architecture: `amd64`https://gitlab.haskell.org/ghc/ghc/-/issues/19710ghci - running a :reloaded module always causes a fatal linker error2021-04-25T20:33:14ZHai / @BestYeenghci - running a :reloaded module always causes a fatal linker error## Summary
After upgrading to GHC 8.10.4 with a fresh computer and Windows install, I can't run reloaded code anymore because it always fails with a fatal linker error.
## Steps to reproduce
I have a program with a bunch of .hs files ...## Summary
After upgrading to GHC 8.10.4 with a fresh computer and Windows install, I can't run reloaded code anymore because it always fails with a fatal linker error.
## Steps to reproduce
I have a program with a bunch of .hs files that are loaded in the order of their dependencies.
I basically first type `:l Badger` to load my program.
Then I change something in that top-level compilation unit (e.g. add a space).
Type `:r` and get this error:
GHC runtime linker: fatal error: I found a duplicate definition for symbol
Main_main_closure
The very verbatim new log messages point out the error in detail:\
`[38 of 38] Compiling Main ( Badger.hs, D:\\Projects\Haskell\final\..\_temp\ghci-temp\ghc6688_0\ghc_4.o )`\
`Ok, 38 modules loaded.`\
`Main> :ma`\
`Badger 2021-04-14/00`\
`[...]`\
`Main> :r`\
`[38 of 38] Compiling Main ( Badger.hs, D:\\Projects\Haskell\final\..\_temp\ghci-temp\ghc6688_0\ghc_192.o )`\
`Ok, 38 modules loaded.`\
`Main> :ma`\
`GHC runtime linker: fatal error: I found a duplicate definition for symbol`\
` Main_main_closure`\
`whilst processing object file`\
` D:\Projects\Haskell\_temp\ghci-temp\ghc6688_0\ghc_192.o`\
`The symbol was previously defined in`\
` D:\Projects\Haskell\_temp\ghci-temp\ghc6688_0\ghc_4.o`
The compilation unit is first persisted in ghc_4.o, then in ghc_192.o, and both are named as part of this conflict.
The function in question is a simple main :: IO ().
This problem seems to be universal - I can't run any :reloaded code anymore. This makes it really hard to use GHCI for anything because everything would always have to be loaded completely from scratch.
## Expected behavior
Code that was reloaded with :reload should work without a fatal linker error.
The previous GHC(I) 8.8.3 version that was in Stack LTS worked just fine.
## Environment
* GHC version used: 8.10.4
* my full ghci command line: `ghci -freverse-errors -I"D:\Projects\Haskell\final\..\headers" -tmpdir "D:\Projects\Haskell\final\..\_temp\ghci-temp" -odir "D:\Projects\Haskell\final\..\_temp\ghci-o" -hidir "D:\Projects\Haskell\final\..\_temp\ghci-hi" -Weverything -Wmissing-signatures -Wno-missed-specialisations -Wno-all-missed-specialisations -Wno-implicit-prelude -Wno-missing-deriving-strategies -Wno-missing-fields -Wno-missing-home-modules -Wno-missing-import-lists -Wno-missing-local-signatures -Wno-monomorphism-restriction -Wno-name-shadowing -Wno-orphans -Wno-partial-fields -Wno-safe -Wno-tabs -Wno-unsafe -Wno-prepositive-qualified-module -Wno-missing-safe-haskell-mode -Wno-compat-unqualified-imports -XNoImplicitPrelude -threaded -fno-gen-manifest -with-rtsopts --nonmoving-gc -XBangPatterns -XCApiFFI -XConstrainedClassMethods -XConstraintKinds -XDisambiguateRecordFields -XDuplicateRecordFields -XEmptyCase -XEmptyDataDeriving -XExistentialQuantification -XExplicitForAll -XExplicitNamespaces -XFlexibleContexts -XFlexibleInstances -XForeignFunctionInterface -XFunctionalDependencies -XGADTs -XGADTSyntax -XGeneralizedNewtypeDeriving -XKindSignatures -XLiberalTypeSynonyms -XMagicHash -XMonoLocalBinds -XMultiParamTypeClasses -XNamedFieldPuns -XParallelListComp -XQuantifiedConstraints -XRankNTypes -XScopedTypeVariables -XStandaloneDeriving -XTypeFamilies -XTypeFamilyDependencies -XTypeOperators -XTypeSynonymInstances -XUnboxedSums -XUnboxedTuples`
Optional:
* Operating System: Win 10 x64 Pro
* System Architecture: Intelhttps://gitlab.haskell.org/ghc/ghc/-/issues/19480ghc: panic! aarm7, ghc 8.10.2 and 8.10.42021-03-04T01:49:39ZRichard Goerwitzghc: panic! aarm7, ghc 8.10.2 and 8.10.4## Summary
I am not a Haskell programmer - but here's what I see:
```
-------------------------------
[198 of 199] Compiling Ouroboros.Consensus.Protocol.PBFT.State ( src/Ouroboros/Consensus/Protocol/PBFT/State.hs, dist/build/Ouroboros/...## Summary
I am not a Haskell programmer - but here's what I see:
```
-------------------------------
[198 of 199] Compiling Ouroboros.Consensus.Protocol.PBFT.State ( src/Ouroboros/Consensus/Protocol/PBFT/State.hs, dist/build/Ouroboros/Consensus/Protocol/PBFT/State.o, dist/build/Ouroboros/Consensus/Protocol/PBFT/State.dyn_o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.10.2:
tcIfaceExtId
$fEqSeq_$c==
Type constructor ‘MuxPeer’
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1179:37 in ghc:Outputable
pprPanic, called at compiler/iface/TcIface.hs:1710:38 in ghc:TcIface
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
cabal: Failed to build cardano-ledger-test-1.3.0 (which is required by
test:cardano-node-test from cardano-node-1.25.1 and test:cardano-cli-test from
```
## Steps to reproduce
On Raspberry Pi 4 system with GHC 8.10.2 - also same bug with GHC 8.10.4
```
git clone https://github.com/input-output-hk/cardano-node.git
cd cardano-node
git fetch --all --recurse-submodules --tag
git checkout tags/1.25.1
cabal configure -O0 -w ghc-8.10.2
echo -e "package cardano-crypto-praos\n flags: -external-libsodium-vrf" > cabal.project.local
cabal build cardano-cli cardano-node
```
## Expected behavior
I evpect cardano-node to compile :-)
## Environment
* GHC version used: cabal build cardano-cli cardano-node
Optional:
* Operating System: Raspberry Pi 4, Raspbian OS
* System Architecture: arm7https://gitlab.haskell.org/ghc/ghc/-/issues/19442ghci panic! upon initial installation in VSCode2021-04-17T16:30:41Ztinawingghci panic! upon initial installation in VSCode## Summary
Upon installation of Haskell in VSCode using Chocolatey and ghc, I wind up with this error:
```
ghc.exe: Could not load 'libwinpthread-1.dll'. Reason: addDLL: libwinpthread-1.dll or dependencies not loaded. (Win32 error 1920...## Summary
Upon installation of Haskell in VSCode using Chocolatey and ghc, I wind up with this error:
```
ghc.exe: Could not load 'libwinpthread-1.dll'. Reason: addDLL: libwinpthread-1.dll or dependencies not loaded. (Win32 error 1920)
ghc.exe: panic! (the 'impossible' happened)
(GHC version 8.6.5 for x86_64-unknown-mingw32):
loadArchive "C:\\ProgramData\\chocolatey\\lib\\ghc\\tools\\ghc-8.6.5\\mingw\\x86_64-w64-mingw32\\lib\\libpthread.dll.a": failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
## Steps to reproduce
0. Uninstall Haskell if already installed
1. Install [Chocolatey](https://chocolatey.org/install) using Windows Powershell
2. Run `choco install -y msys2` in Powershell
3. Open an MSYS terminal with `C:\tools\msys64\msys2.exe`. Run `pacman -Syuu` in the window. Close MSYS window when done.
4. Run `choco install -y ghc --version 8.6.5` to install GHC.
5. Install VSCode
6. In VSCode, install "Haskell Syntax Highlighting" and "haskell-ghcid" extensions
7. Run `ghci` in VSCode inbuilt terminal
## Environment
* GHC version used: 8.6.5
* Operating System: Windows 10 v10.0.19041 Build 19041
* Device: Surface Pro 6
* System Architecture: x64https://gitlab.haskell.org/ghc/ghc/-/issues/18984Pandoc-2.11.2 build failed on FreeBSD-11.4 i386 system2020-12-04T21:16:18ZwenhepingPandoc-2.11.2 build failed on FreeBSD-11.4 i386 system
Pandoc-2.11.2 build failed on FreeBSD-11.4 i386 system, while success on amd64 system. The last lines of buildlog is:
```
\[118 of 184\] Compiling Text.Pandoc.Writers.ConTeXt
\[119 of 184\] Compiling Text.Pandoc.PDF
\[120 of 184\] Comp...
Pandoc-2.11.2 build failed on FreeBSD-11.4 i386 system, while success on amd64 system. The last lines of buildlog is:
```
\[118 of 184\] Compiling Text.Pandoc.Writers.ConTeXt
\[119 of 184\] Compiling Text.Pandoc.PDF
\[120 of 184\] Compiling Text.Pandoc.Lua.Module.Utils
\[121 of 184\] Compiling Text.Pandoc.Writers.OpenDocument
\[122 of 184\] Compiling Text.Pandoc.Writers.ODT
\[123 of 184\] Compiling Text.Pandoc.Writers.MediaWiki
\[124 of 184\] Compiling Text.Pandoc.Writers.XWiki
\[125 of 184\] Compiling Text.Pandoc.Writers.JATS.Table
\[126 of 184\] Compiling Text.Pandoc.Writers.JATS
\[127 of 184\] Compiling Text.Pandoc.Writers.ICML
\[128 of 184\] Compiling Text.Pandoc.Writers.HTML
ghc: panic! (the 'impossible' happened) (GHC version 8.10.2: ghc: panic! (the 'impossible' happened) (GHC version 8.10.2: ghc: panic! (the 'impossible' happened) (GHC version 8.10.2: exprToType
Call stack: CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1179:37 in ghc:Outputable
pprPanic, called at compiler/coreSyn/CoreSyn.hs:2087:28 in ghc:CoreSyn
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```https://gitlab.haskell.org/ghc/ghc/-/issues/18918Potential for FastString uniques clashing with others2020-11-10T21:10:15ZBen GamariPotential for FastString uniques clashing with othersCurrently the `getUnique` implementation for `FastString` derives the unique from a sequential counter (starting at 0) associated with the global `FastStringTable`. One can argue that this is okay since the `\x00` unique tag isn't used b...Currently the `getUnique` implementation for `FastString` derives the unique from a sequential counter (starting at 0) associated with the global `FastStringTable`. One can argue that this is okay since the `\x00` unique tag isn't used by any `UniqueSupply`. However, if we allocate allocate enough `FastString`s we will overflow the zero-tag into regions of the tag-space used by other `UniqueSupply`s. This will result in unique collisions.Ben GamariBen Gamari