GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-04-25T21:14:38Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/23290Wasm testsuite failure: T4801 timeout when unregisterised2023-04-25T21:14:38ZCheng ShaoWasm testsuite failure: T4801 timeout when unregisterisedWhen testing the wasm backend with unregisterised codegen, T4801 times out:
```
Timeout happened...killed process "cd "/builds/ghc/ghc/tmp/ghctest-kxtmj_kx/test spaces/testsuite/tests/perf/compiler/T4801.run" && "/builds/ghc/ghc/_bui...When testing the wasm backend with unregisterised codegen, T4801 times out:
```
Timeout happened...killed process "cd "/builds/ghc/ghc/tmp/ghctest-kxtmj_kx/test spaces/testsuite/tests/perf/compiler/T4801.run" && "/builds/ghc/ghc/_build/stage1/bin/wasm32-wasi-ghc" -c T4801.hs -no-user-package-db -fno-dump-with-ways -rtsopts -optc-fno-builtin -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -static +RTS -V0 -tT4801.comp.stats --machine-readable -RTS"...
Compile failed (exit code 99) errors were:
*** unexpected failure for T4801(normal)
```Cheng ShaoCheng Shaohttps://gitlab.haskell.org/ghc/ghc/-/issues/23260AArch64 NCG doesn't support -falignment-sanitisation2023-05-20T10:34:44ZCheng ShaoAArch64 NCG doesn't support -falignment-sanitisationCompiling a module with `-falignment-sanitisation` using aarch64 ncg produces the following error:
```
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.4.4:
getRegister' (monadic CmmMachOp):
%M...Compiling a module with `-falignment-sanitisation` using aarch64 ncg produces the following error:
```
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.4.4:
getRegister' (monadic CmmMachOp):
%MO_AlignmentCheck_8_W64(R1)
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/CmmToAsm/AArch64/CodeGen.hs:651:14 in ghc:GHC.CmmToAsm.AArch64.CodeGen
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.4.4:
getRegister' (monadic CmmMachOp):
%MO_AlignmentCheck_8_W64(R1)
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/CmmToAsm/AArch64/CodeGen.hs:651:14 in ghc:GHC.CmmToAsm.AArch64.CodeGen
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
This is reported by ghc-9.4.4 on aarch64-darwin, though according to https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/CmmToAsm/AArch64/CodeGen.hs#L653 , it's never implemented in the first place.https://gitlab.haskell.org/ghc/ghc/-/issues/23248getExecutablePath doesn't work on wasm backend2023-04-11T14:16:58ZCheng ShaogetExecutablePath doesn't work on wasm backendOn wasm32, `getExecutablePath` returns only the wasm module's filename (e.g. `foo.wasm`). This makes perfect sense since the information is only available via `argv[0]`, which `wasmtime` will not leak any host filesystem info into, and i...On wasm32, `getExecutablePath` returns only the wasm module's filename (e.g. `foo.wasm`). This makes perfect sense since the information is only available via `argv[0]`, which `wasmtime` will not leak any host filesystem info into, and in the virtual filesystem (if it's provided) there may not even exist `foo.wasm` at all. Consequently, `executablePath` returns `Nothing`.
This may still be surprising to new users of the wasm backend, whose user program relies on `getExecutablePath`/`executablePath` being able to fetch the program's absolute path. So, this ticket serves as a placeholder so the disabled test (`executablePath`) can point to.https://gitlab.haskell.org/ghc/ghc/-/issues/23243Wasm testsuite failure: hpc tests2023-04-08T20:55:27ZCheng ShaoWasm testsuite failure: hpc testsThe `hpc` compile/run way in the testsuite works for the wasm backend, so it seems the code instrumentation logic doesn't break the wasm backend, and the hpc-related logic in RTS doesn't cause harm at runtime. However, there are a few te...The `hpc` compile/run way in the testsuite works for the wasm backend, so it seems the code instrumentation logic doesn't break the wasm backend, and the hpc-related logic in RTS doesn't cause harm at runtime. However, there are a few tests that involve comparing `hpc` output, and those test cases are failing for the wasm backend at the moment. It's likely that more work is needed to get `hpc` actually working for the wasm backend, so opening this ticket to track this issue.https://gitlab.haskell.org/ghc/ghc/-/issues/23238Wasm testsuite failure: typecheck.testeq12023-04-06T23:42:40ZCheng ShaoWasm testsuite failure: typecheck.testeq1```
Wrong exit code for typecheck.testeq1(normal)(expected 0 , actual 1 )
Stderr ( typecheck.testeq1 ):
Error: if you're trying to run a precompiled module, pass --allow-precompiled
Caused by:
0: failed to read input file
1: No ...```
Wrong exit code for typecheck.testeq1(normal)(expected 0 , actual 1 )
Stderr ( typecheck.testeq1 ):
Error: if you're trying to run a precompiled module, pass --allow-precompiled
Caused by:
0: failed to read input file
1: No such file or directory (os error 2)
*** unexpected failure for typecheck.testeq1(normal)
```
Compilation for `typecheck.testeq1` seems to succeed, but the `.wasm` module path passed to `wasmtime` is incorrect. It's a bit odd, since there are other `multimod_compile_and_run` test cases in the tree, but this one is the only error of its kind in the test log. Anyway, skipping this for the time being, will revisit some time later.https://gitlab.haskell.org/ghc/ghc/-/issues/23236Test cases that involve Setup.hs doesn't work for cross GHCs yet2023-04-06T23:37:06ZCheng ShaoTest cases that involve Setup.hs doesn't work for cross GHCs yetSome test cases like `ImpSafe*` require custom `pre_cmd` that compiles and uses a custom `Setup.hs`. The current test suite driver still doesn't handle test cases that require both native/cross GHCs yet, and it'll fail as a framework fai...Some test cases like `ImpSafe*` require custom `pre_cmd` that compiles and uses a custom `Setup.hs`. The current test suite driver still doesn't handle test cases that require both native/cross GHCs yet, and it'll fail as a framework failure:
```
*** framework failure for ImpSafeOnly01(normal) pre_cmd failed: 2
** pre_cmd was "$MAKE -s --no-print-directory mkPackageDatabase.ImpSafeOnly01 VANILLA=--enable-library-vanilla PROF=--enable-library-profiling DYN=--disable-shared".
stdout:
stderr: gmake: pdb.ImpSafeOnly01/setup: No such file or directory
gmake: *** [Makefile:18: mkPackageDatabase.ImpSafeOnly01] Error 127
```
I believe this is also the root cause of #22350.https://gitlab.haskell.org/ghc/ghc/-/issues/23228Cmm lint error in GHC.Bits when compiled without optimisation2023-07-30T17:31:59ZMatthew PickeringCmm lint error in GHC.Bits when compiled without optimisation
Repro, add the `OPTIONS_GHC` pragma to the top of `GHC.Bits`
```
{-# OPTIONS_GHC -O0 -}
```
```
./hadrian/build --flavour=validate -o_validate -j4 _validate/stage1/libraries/base/build/GHC/Bits.o
```
Gives the following Cmm lint e...
Repro, add the `OPTIONS_GHC` pragma to the top of `GHC.Bits`
```
{-# OPTIONS_GHC -O0 -}
```
```
./hadrian/build --flavour=validate -o_validate -j4 _validate/stage1/libraries/base/build/GHC/Bits.o
```
Gives the following Cmm lint error:
```
Cmm lint error:
in basic block c2E2
Shift operation MO_U_Shr W64 has out-of-range offset 64. This will result in undefined behavior
Program was:
{offset
c2CU: // global
_s1YF::P64 = R3; // CmmAssign
_s1YE::P64 = R2; // CmmAssign
if ((old + 0) - <highSp> < SpLim) (likely: False) goto c2CY; else goto c2CZ; // CmmCondBranch
c2CY: // global
R3 = _s1YF::P64; // CmmAssign
R2 = _s1YE::P64; // CmmAssign
R1 = $crotate2_r1Hc_closure; // CmmAssign
call (stg_gc_fun)(R3, R2, R1) args: 8, res: 0, upd: 8; // CmmCall
c2CZ: // global
I64[(young<c2CR> + 8)] = c2CR; // CmmStore
R1 = _s1YE::P64; // CmmAssign
if (R1 & 7 != 0) goto c2CR; else goto c2CS; // CmmCondBranch
c2CS: // global
call (I64[R1])(R1) returns to c2CR, args: 8, res: 8, upd: 8; // CmmCall
c2CR: // global
_s1YG::P64 = R1; // CmmAssign
_s1YH::I64 = I64[_s1YG::P64 + 7]; // CmmAssign
I64[(young<c2CX> + 8)] = c2CX; // CmmStore
R1 = _s1YF::P64; // CmmAssign
if (R1 & 7 != 0) goto c2CX; else goto c2D1; // CmmCondBranch
c2D1: // global
call (I64[R1])(R1) returns to c2CX, args: 8, res: 8, upd: 8; // CmmCall
c2CX: // global
_s1YI::P64 = R1; // CmmAssign
_s1YJ::I64 = I64[_s1YI::P64 + 7]; // CmmAssign
_c2D6::I64 = _s1YJ::I64 & 63; // CmmAssign
_s1YK::I64 = _c2D6::I64; // CmmAssign
switch [-9223372036854775808 .. 9223372036854775807] _s1YK::I64 {
case 0 : goto c2DK;
default: {goto c2Db;}
} // CmmSwitch
c2DK: // global
// slowCall
I64[(young<c2DO> + 8)] = c2DO; // CmmStore
R2 = 1; // CmmAssign
R1 = isTrue#_closure; // CmmAssign
call stg_ap_n_fast(R2,
R1) returns to c2DO, args: 8, res: 8, upd: 8; // CmmCall
c2DO: // global
_s1YQ::P64 = R1; // CmmAssign
// slow_call for isTrue#_closure with pat stg_ap_n
_c2Ec::P64 = _s1YQ::P64 & 7; // CmmAssign
switch [1 .. 2] _c2Ec::P64 {
case 1 : goto c2E0;
case 2 : goto c2E7;
} // CmmSwitch
c2E7: // global
Hp = Hp + 16; // CmmAssign
if (Hp > HpLim) (likely: False) goto c2Ea; else goto c2E9; // CmmCondBranch
c2Ea: // global
HpAlloc = 16; // CmmAssign
R1 = _s1YQ::P64; // CmmAssign
call stg_gc_unpt_r1(R1) returns to c2DO, args: 8, res: 8, upd: 8; // CmmCall
c2E9: // global
// allocHeapClosure
I64[Hp - 8] = W#_con_info; // CmmStore
I64[Hp] = _s1YH::I64; // CmmStore
_c2E6::P64 = Hp - 7; // CmmAssign
R1 = _c2E6::P64; // CmmAssign
call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; // CmmCall
c2E0: // global
Hp = Hp + 16; // CmmAssign
if (Hp > HpLim) (likely: False) goto c2E3; else goto c2E2; // CmmCondBranch
c2E3: // global
HpAlloc = 16; // CmmAssign
R1 = _s1YQ::P64; // CmmAssign
call stg_gc_unpt_r1(R1) returns to c2DO, args: 8, res: 8, upd: 8; // CmmCall
c2E2: // global
_c2DS::I64 = _s1YH::I64 >> 64; // CmmAssign
_s1YR::I64 = _c2DS::I64; // CmmAssign
_c2DV::I64 = _s1YH::I64 | _s1YR::I64; // CmmAssign
_s1YS::I64 = _c2DV::I64; // CmmAssign
// allocHeapClosure
I64[Hp - 8] = W#_con_info; // CmmStore
I64[Hp] = _s1YS::I64; // CmmStore
_c2DY::P64 = Hp - 7; // CmmAssign
R1 = _c2DY::P64; // CmmAssign
call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; // CmmCall
c2Db: // global
// slowCall
I64[(young<c2Df> + 8)] = c2Df; // CmmStore
R2 = 0; // CmmAssign
R1 = isTrue#_closure; // CmmAssign
call stg_ap_n_fast(R2,
R1) returns to c2Df, args: 8, res: 8, upd: 8; // CmmCall
c2Df: // global
_s1YL::P64 = R1; // CmmAssign
// slow_call for isTrue#_closure with pat stg_ap_n
_c2Eb::P64 = _s1YL::P64 & 7; // CmmAssign
switch [1 .. 2] _c2Eb::P64 {
case 1 : goto c2Dx;
case 2 : goto c2DE;
} // CmmSwitch
c2DE: // global
Hp = Hp + 16; // CmmAssign
if (Hp > HpLim) (likely: False) goto c2DH; else goto c2DG; // CmmCondBranch
c2DH: // global
HpAlloc = 16; // CmmAssign
R1 = _s1YL::P64; // CmmAssign
call stg_gc_unpt_r1(R1) returns to c2Df, args: 8, res: 8, upd: 8; // CmmCall
c2DG: // global
// allocHeapClosure
I64[Hp - 8] = W#_con_info; // CmmStore
I64[Hp] = _s1YH::I64; // CmmStore
_c2DD::P64 = Hp - 7; // CmmAssign
R1 = _c2DD::P64; // CmmAssign
call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; // CmmCall
c2Dx: // global
Hp = Hp + 16; // CmmAssign
if (Hp > HpLim) (likely: False) goto c2DA; else goto c2Dz; // CmmCondBranch
c2DA: // global
HpAlloc = 16; // CmmAssign
R1 = _s1YL::P64; // CmmAssign
call stg_gc_unpt_r1(R1) returns to c2Df, args: 8, res: 8, upd: 8; // CmmCall
c2Dz: // global
_c2Dj::I64 = 64 - _s1YK::I64; // CmmAssign
_s1YN::I64 = _c2Dj::I64; // CmmAssign
_c2Dm::I64 = _s1YH::I64 >> _s1YN::I64; // CmmAssign
_s1YO::I64 = _c2Dm::I64; // CmmAssign
_c2Dp::I64 = _s1YH::I64 << _s1YK::I64; // CmmAssign
_s1YM::I64 = _c2Dp::I64; // CmmAssign
_c2Ds::I64 = _s1YM::I64 | _s1YO::I64; // CmmAssign
_s1YP::I64 = _c2Ds::I64; // CmmAssign
// allocHeapClosure
I64[Hp - 8] = W#_con_info; // CmmStore
I64[Hp] = _s1YP::I64; // CmmStore
_c2Dv::P64 = Hp - 7; // CmmAssign
R1 = _c2Dv::P64; // CmmAssign
call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; // CmmCall
}
<no location info>: error:
Compilation had errors
Command failed
Build failed.
```https://gitlab.haskell.org/ghc/ghc/-/issues/23186No easy way to disable the optllvm test way2024-01-30T16:28:03ZCheng ShaoNo easy way to disable the optllvm test wayCurrently, the configure script looks for `llc`/`opt` locations, and accept `LLC`/`OPT` variables to override auto-detection from `PATH`. In https://gitlab.haskell.org/ghc/ghc/-/blob/master/.gitlab/jobs.yaml, we have multiple jobs that e...Currently, the configure script looks for `llc`/`opt` locations, and accept `LLC`/`OPT` variables to override auto-detection from `PATH`. In https://gitlab.haskell.org/ghc/ghc/-/blob/master/.gitlab/jobs.yaml, we have multiple jobs that explicitly specify `LLC=/bin/false`/`OPT=/bin/false` to signal that they don't want LLVM to be involved at all when building/testing.
However, this doesn't work at all actually:
- When `/bin/false` is passed to `LLC`/`OPT` variables, the configure script will fallback to the default `llc`/`opt` values.
- As long as system-wide installation of `llc`/`opt` exists, hadrian will pass `have_llvm=true` to the test suite driver, which then adds the `optllvm` run way automatically.
This is IMHO undesirable behavior, we can't easily rule out `optllvm` test way even by being explicit that we don't want it at all.Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/23168Representation of unlifted wrappers around lifted types2023-03-28T14:21:43ZDavid FeuerRepresentation of unlifted wrappers around lifted types## Motivation
Suppose I want a proper strict array. What's that mean?
1. Elements are forced when stored in the array.
2. Elements read from the array are known to be in WHNF.
Today, there are two ways to do this:
### The hard way
W...## Motivation
Suppose I want a proper strict array. What's that mean?
1. Elements are forced when stored in the array.
2. Elements read from the array are known to be in WHNF.
Today, there are two ways to do this:
### The hard way
We can define
```haskell
newtype StrictMArray s a = StrictMArray (MutableArray s a)
readM :: StrictMArray s a -> Int -> ST s a
readM (StrictMArray mary) i = do
-- We must force this (already WHNF) value so the compiler knows
-- it's been forced, to avoid creating unneeded thunks in certain cases.
!a <- readArray mary i
pure a
writeM :: StrictMArray s a -> Int -> a -> ST s ()
-- We must remember to force `a` before installing it in the array.
writeM (StrictMArray mary) i !a = writeArray mary i a
```
This approach is error prone, and it has silly double forces, but it's probably the best we can do right now. The alternative uses unlifted data:
### The easy way
This requires an API for arrays of unlifted things that doesn't exist yet, but it will soon. You should be able to get the drift.
```haskell
data Unlift :: Type -> UnliftedType where
Unlift :: !a -> Unlift a
newtype StrictMArray s a = StrictMArray (MutableUnliftedArray s (Unlift a))
readM :: StrictMArray s a -> Int -> ST s a
readM (StrictMArray mary) i = do
Box (Unlift a) <- readUnliftedArray mary i
pure a
writeM :: StrictMArray s a -> Int -> a -> ST s ()
writeM (StrictMArray mary) i a = writeUnliftedArray mary i (Unlift a)
```
Wow, that's a lot nicer, isn't it? It's way harder to get things wrong, and there's no more double forcing. Unfortunately ... it's hideously inefficient. The problem is that every element gets its own box for no reason.
## Proposal
When an *unlifted* datatype
1. Has exactly one constructor
2. which has no class constraints and has exactly one field
3. and that field either has kind `UnliftedType` or has kind `Type` and is *strict* but *not unpacked*
then we shouldn't box it. The "not unpacked" condition can be relaxed if the field unpacks to a pointer type.
Some years ago (I can't find the ticket) I (or someone else?) suggested doing something similar for *lifted* types, but that proved tricky due to the need to force on pattern matching. Here, we can just drop the box on the floor when lowering from Core to STG. Operationally, the constructor "worker" turns into a no-op, as does the associated matcher.
What can go wrong? The main issue is if someone does something sketchy like
```haskell
getSolo (unsafeCoerce# (Unlift a))
```
This currently works, though it's explicitly forbidden, and it would stop working with the proposed change. There would also be some profiling changes, which may or may not be okay.https://gitlab.haskell.org/ghc/ghc/-/issues/23158Precomputed static closures for nullary GADT workers and wrappers2024-02-23T00:39:10ZBen GamariPrecomputed static closures for nullary GADT workers and wrappersConsider the program
```haskell
module B where
import GHC.Exts
type NP :: [Type] -> Type
data NP xs where
UNil :: NP '[]
```
This will give rise to the following Cmm:
```c
[UNil_entry() { // []
{ info_tbls: [(cE4,
...Consider the program
```haskell
module B where
import GHC.Exts
type NP :: [Type] -> Type
data NP xs where
UNil :: NP '[]
```
This will give rise to the following Cmm:
```c
[UNil_entry() { // []
{ info_tbls: [(cE4,
label: UNil_info
rep: HeapRep static { Fun {arity: 1 fun_type: ArgSpec 3} }
srt: Nothing)]
stack_info: arg_space: 8
}
{offset
cE4:
unwind Sp = Just Sp;
unwind Sp = Just Sp;
Hp = Hp + 16;
if (Hp > HpLim) (likely: False) goto cE8; else goto cE7;
cE8:
unwind Sp = Just Sp;
HpAlloc = 16;
unwind Sp = Just Sp;
R1 = UNil_closure;
call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8;
cE7:
unwind Sp = Just Sp;
I64[Hp - 8] = UNil_con_info;
R1 = Hp - 7;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
}
},
section ""data" . UNil_closure" {
UNil_closure:
const UNil_info;
}]
```
Note that `UNil_entry` may allocate unnecessarily: If the heap check fails then we correctly return `UNil_closure`. However, If the heap check succeeds then we will allocate a new `UNil` constructor on the dynamic heap. There is no reason to do this.Rodrigo MesquitaRodrigo Mesquitahttps://gitlab.haskell.org/ghc/ghc/-/issues/23111Core Lint error with -fdefer-type-errors and kind error2023-03-14T15:16:29ZKrzysztof GogolewskiCore Lint error with -fdefer-type-errors and kind errorThe following program fails `ghc -dcore-lint -fdefer-type-errors`
```haskell
{-# LANGUAGE TypeFamilies #-}
module M where
import Data.Kind
type F :: Type
type family F
type G :: F
type family G
x :: G
x = ()
```
<details>
```haske...The following program fails `ghc -dcore-lint -fdefer-type-errors`
```haskell
{-# LANGUAGE TypeFamilies #-}
module M where
import Data.Kind
type F :: Type
type family F
type G :: F
type family G
x :: G
x = ()
```
<details>
```haskell
*** Core Lint errors : in result of Desugar (before optimization) ***
<no location info>: warning:
Non-CoVar has coercion type co_awK :: F ~# *
Substitution: <InScope = {}
IdSubst = []
TvSubst = []
CvSubst = []>
*** Offending Program ***
Rec {
co_awK :: F ~# *
[LclId[CoVarId]]
co_awK
= case typeError
@LiftedRep
@()
"M.hs:12:6: error: [GHC-83865]\n\
\ \\226\\128\\162 Expected a type, but \\226\\128\\152G\\226\\128\\153 has kind \\226\\128\\152F\\226\\128\\153\n\
\ \\226\\128\\162 In the type signature: x :: G\n\
\(deferred type error)"#
of wild_00 {
}
$trModule :: Module
[LclIdX]
$trModule = Module (TrNameS "main"#) (TrNameS "M"#)
x :: (G |> co_awK)
[LclIdX]
x = case case typeError
@LiftedRep
@()
"M.hs:13:5: error: [GHC-18872]\n\
\ \\226\\128\\162 Couldn't match kind \\226\\128\\152F\\226\\128\\153 with \\226\\128\\152*\\226\\128\\153\n\
\ When matching types\n\
\ G :: F\n\
\ () :: *\n\
\ \\226\\128\\162 In the expression: ()\n\
\ In an equation for \\226\\128\\152x\\226\\128\\153: x = ()\n\
\(deferred type error)"#
of wild_00 {
}
of co_ayG
{ __DEFAULT ->
case case typeError
@LiftedRep
@()
"M.hs:13:5: error: [GHC-18872]\n\
\ \\226\\128\\162 Couldn't match kind \\226\\128\\152F\\226\\128\\153 with \\226\\128\\152*\\226\\128\\153\n\
\ When matching types\n\
\ G :: F\n\
\ () :: *\n\
\ \\226\\128\\162 In the expression: ()\n\
\ In an equation for \\226\\128\\152x\\226\\128\\153: x = ()\n\
\(deferred type error)"#
of wild_00 {
}
of co_ayH
{ __DEFAULT ->
()
`cast` (Sub (Sym (co_ayH
; Sym (GRefl nominal () (Sym co_ayG)))
; GRefl nominal G co_awK)
:: () ~R# (G |> co_awK))
}
}
end Rec }
```
</details>https://gitlab.haskell.org/ghc/ghc/-/issues/23078Objects loaded via the RTS linker do not expose symbols to GDB2023-03-09T23:25:38ZAlexis KingObjects loaded via the RTS linker do not expose symbols to GDBWhen the RTS linker is used to load objects and archives, any debugging information produced by `-g` is necessarily invisible to GDB. Loading the symbols from the archive manually does not help because only GHC knows the address the obje...When the RTS linker is used to load objects and archives, any debugging information produced by `-g` is necessarily invisible to GDB. Loading the symbols from the archive manually does not help because only GHC knows the address the objects are ultimately loaded at.
It seems possible to dynamically expose these symbols to GDB using its [JIT interface](https://sourceware.org/gdb/download/onlinedocs/gdb/JIT-Interface.html). However, I am not sure how difficult this would be to use in practice, as I don’t currently understand the way the RTS linker works.
On platforms where `ghc` is dynamically linked by default (which I believe is everywhere except Windows), this is probably not a big deal, since GHC just uses `dlopen` on those platforms. Since `-g` is currently only supported on Linux, this doesn’t seem like a particularly big problem. However, when *developing* GHC, I am often using a statically-linked GHC, and sometimes I even run into cases where I can only trigger a bug with GHC statically linked. (Such a case is what prompted me to open this issue.) So it would be very nice to be able to have debugging symbols in that configuration.https://gitlab.haskell.org/ghc/ghc/-/issues/23051Panic with representation polymorphism check2023-06-11T11:58:23ZKrzysztof GogolewskiPanic with representation polymorphism checkSimilar, but not the same as #22743.
This invalid program causes a crash in `typeKind` during representation polymorphism checking in 9.4 and master:
```haskell
{-# LANGUAGE MagicHash #-}
module M where
import GHC.Exts
i :: forall f ...Similar, but not the same as #22743.
This invalid program causes a crash in `typeKind` during representation polymorphism checking in 9.4 and master:
```haskell
{-# LANGUAGE MagicHash #-}
module M where
import GHC.Exts
i :: forall f g (a :: TYPE (f g)). a -> a
i = i
x = i 0#
```
GHC 9.2 gives a correct error
```
M.hs:9:7: error:
• Couldn't match kind ‘'IntRep’ with ‘f g’
When matching types
a :: TYPE (f g)
Int# :: TYPE 'IntRep
• In the first argument of ‘i’, namely ‘0#’
In the expression: i 0#
In an equation for ‘x’: x = i 0#
• Relevant bindings include x :: a (bound at M.hs:9:1)
|
9 | x = i 0#
| ^^
```Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/23020Panic on wrong imports with TypeData2023-02-27T23:54:12ZKrzysztof GogolewskiPanic on wrong imports with TypeDataGiven
```haskell
{-# LANGUAGE TypeData #-}
module TD where
type data A = X | Y | Z
```
This is accepted:
```haskell
module TD2 where
import TD (Y(X))
```
It shouldn't be: `X` is not a constructor of `Y`. Adding one more
```haskell...Given
```haskell
{-# LANGUAGE TypeData #-}
module TD where
type data A = X | Y | Z
```
This is accepted:
```haskell
module TD2 where
import TD (Y(X))
```
It shouldn't be: `X` is not a constructor of `Y`. Adding one more
```haskell
module TD2 where
import TD (Y(X), Z(X))
```
causes a panic:
```
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.7.20230218:
hasParent
parent:Y parent:Z
```Aaron AllenAaron Allenhttps://gitlab.haskell.org/ghc/ghc/-/issues/22984Warnings in ghci -Wmissing-import-lists accumulate2023-05-21T03:06:04ZKrzysztof GogolewskiWarnings in ghci -Wmissing-import-lists accumulateThe warnings given by `ghci -Wmissing-import-lists` accumulate:
```
$ ./_build/stage1/bin/ghc --interactive -Wmissing-import-lists
GHCi, version 9.7.20230204: https://www.haskell.org/ghc/ :? for help
ghci> import Data.List
<interactiv...The warnings given by `ghci -Wmissing-import-lists` accumulate:
```
$ ./_build/stage1/bin/ghc --interactive -Wmissing-import-lists
GHCi, version 9.7.20230204: https://www.haskell.org/ghc/ :? for help
ghci> import Data.List
<interactive>:1:1: warning: [-Wmissing-import-lists]
The module ‘Data.List’ does not have an explicit import list
ghci> import Data.Set
<interactive>:1:1: warning: [-Wmissing-import-lists]
The module ‘Data.List’ does not have an explicit import list
<interactive>:1:1: warning: [-Wmissing-import-lists]
The module ‘Data.Set’ does not have an explicit import list
ghci> import Data.Map
<interactive>:1:1: warning: [-Wmissing-import-lists]
The module ‘Data.List’ does not have an explicit import list
<interactive>:1:1: warning: [-Wmissing-import-lists]
The module ‘Data.Set’ does not have an explicit import list
<interactive>:1:1: warning: [-Wmissing-import-lists]
The module ‘Data.Map’ does not have an explicit import list
```
Low priority.https://gitlab.haskell.org/ghc/ghc/-/issues/22971GHC.TypeError marked as appearing in the wrong base version.2023-02-15T21:21:34ZAndreas KlebingerGHC.TypeError marked as appearing in the wrong base version.See https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9770/diffsSee https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9770/diffs9.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/22916Core lint error when compiling matrix with GHC 9.2.52023-02-07T16:43:59ZZubinCore lint error when compiling matrix with GHC 9.2.5## Summary
`matrix-0.3.6.1` fails to compile with `-dcore-lint`
## Steps to reproduce
```bash
$ cabal get matrix-0.3.6.1
$ cat > cabal.project << EOF
packages: .
package matrix
ghc-options: -dcore-lint
EOF
$ cabal build
```
<detail...## Summary
`matrix-0.3.6.1` fails to compile with `-dcore-lint`
## Steps to reproduce
```bash
$ cabal get matrix-0.3.6.1
$ cat > cabal.project << EOF
packages: .
package matrix
ghc-options: -dcore-lint
EOF
$ cabal build
```
<details><summary>Click to expand</summary>
```
*** Core Lint errors : in result of Static argument ***
Data/Matrix.hs:1307:1: warning:
Mismatch in type between binder and occurrence
Binder: recLUDecomp'_r2jm :: forall {a}.
(Ord a_a7aP, Fractional a_a7aP) =>
Matrix a_a7aP
-> Matrix a_a7aP
-> Matrix a_a7aP
-> Matrix a_a7aP
-> a_a7aP
-> a_a7aP
-> Int
-> Int
-> Maybe
(Matrix a_a7aP, Matrix a_a7aP, Matrix a_a7aP, Matrix a_a7aP,
a_a7aP, a_a7aP)
Occurrence: recLUDecomp' :: forall a.
(Ord a, Fractional a) =>
Matrix a
-> Matrix a
-> Matrix a
-> Matrix a
-> a
-> a
-> Int
-> Int
-> Maybe (Matrix a, Matrix a, Matrix a, Matrix a, a, a)
Before subst: forall a.
(Ord a, Fractional a) =>
Matrix a
-> Matrix a
-> Matrix a
-> Matrix a
-> a
-> a
-> Int
-> Int
-> Maybe (Matrix a, Matrix a, Matrix a, Matrix a, a, a)
In the RHS of recLUDecomp' :: forall a.
(Ord a, Fractional a) =>
Matrix a
-> Matrix a
-> Matrix a
-> Matrix a
-> a
-> a
-> Int
-> Int
-> Maybe (Matrix a, Matrix a, Matrix a, Matrix a, a, a)
In the body of lambda with binder a_a7aP :: *
In the body of lambda with binder $dOrd_a7aQ :: Ord a_a7aP
In the body of lambda with binder $dFractional_a7aR :: Fractional
a_a7aP
In the body of lambda with binder eta_B0 :: Matrix a_a7aP
In the body of lambda with binder eta_B1 :: Matrix a_a7aP
In the body of lambda with binder eta_B2 :: Matrix a_a7aP
In the body of lambda with binder eta_B3 :: Matrix a_a7aP
In the body of lambda with binder eta_B4 :: a_a7aP
In the body of lambda with binder eta_B5 :: a_a7aP
In the body of lambda with binder eta_B6 :: Int
In the body of lambda with binder eta_B7 :: Int
In the RHS of sat_worker_s9pN :: Matrix a_a7aP
-> Matrix a_a7aP
-> Matrix a_a7aP
-> Matrix a_a7aP
-> a_a7aP
-> a_a7aP
-> Int
-> Maybe
(Matrix a_a7aP, Matrix a_a7aP, Matrix a_a7aP,
Matrix a_a7aP, a_a7aP, a_a7aP)
In the body of lambda with binder eta_B0 :: Matrix a_a7aP
In the body of lambda with binder eta_B1 :: Matrix a_a7aP
In the body of lambda with binder eta_B2 :: Matrix a_a7aP
In the body of lambda with binder eta_B3 :: Matrix a_a7aP
In the body of lambda with binder eta_B4 :: a_a7aP
In the body of lambda with binder eta_B5 :: a_a7aP
In the body of lambda with binder eta_B6 :: Int
In the body of letrec with binders recLUDecomp'_r2jm :: forall {a}.
(Ord a_a7aP, Fractional a_a7aP) =>
Matrix a_a7aP
-> Matrix a_a7aP
-> Matrix a_a7aP
-> Matrix a_a7aP
-> a_a7aP
-> a_a7aP
-> Int
-> Int
-> Maybe
(Matrix a_a7aP, Matrix a_a7aP,
Matrix a_a7aP, Matrix a_a7aP,
a_a7aP, a_a7aP)
In the body of letrec with binders $dNum_a7HJ :: Num a_a7aP
In the body of letrec with binders $dEq_a7HI :: Eq a_a7aP
In the body of letrec with binders ds_d8gN :: (Int, Int)
In the body of letrec with binders i_a2BY :: Int
In the body of letrec with binders j_a2BZ :: Int
In the body of letrec with binders u'_a2C0 :: Matrix a_a7aP
In the body of letrec with binders ukk_a2C9 :: a_a7aP
In the body of letrec with binders ds_d8gb :: (Matrix a_a7aP,
Matrix a_a7aP)
In the body of letrec with binders u''_a2C7 :: Matrix a_a7aP
In a case alternative: (False)
In a case alternative: (False)
In an occurrence of recLUDecomp' :: forall a.
(Ord a, Fractional a) =>
Matrix a
-> Matrix a
-> Matrix a
-> Matrix a
-> a
-> a
-> Int
-> Int
-> Maybe (Matrix a, Matrix a, Matrix a, Matrix a, a, a)
Substitution: [TCvSubst
In scope: InScope {a_a7aP}
Type env: [a7aP :-> a_a7aP]
Co env: []]
*** End of Offense ***
<no location info>: error:
Compilation had errors
```
</details>
## Expected behavior
## Environment
* GHC version used: 9.2.5https://gitlab.haskell.org/ghc/ghc/-/issues/22900GHC warns about non-exhaustive pattern match of Word82023-02-08T13:23:42ZOleg GrenrusGHC warns about non-exhaustive pattern match of Word8```haskell
import Data.Word
foo :: Word8 -> Bool
foo 0x00 = True
foo 0x01 = True
foo 0x02 = True
foo 0x03 = True
...
foo 0xFF = True
```
Is exhaustive, one can test that with
```haskell
test = map foo [ minBound .. maxBound ]
```
How...```haskell
import Data.Word
foo :: Word8 -> Bool
foo 0x00 = True
foo 0x01 = True
foo 0x02 = True
foo 0x03 = True
...
foo 0xFF = True
```
Is exhaustive, one can test that with
```haskell
test = map foo [ minBound .. maxBound ]
```
However, GHC seems to disagree an issues a warning.
Complete file is in attachment.
[demo.hs](/uploads/cbb03615afa83b68de37b5f643b8579e/demo.hs)https://gitlab.haskell.org/ghc/ghc/-/issues/22882emitBarf generates incorrect barf() call on wasm target2023-02-07T16:16:39ZCheng ShaoemitBarf generates incorrect barf() call on wasm target`emitBarf` generates a ccall in Cmm that calls `barf()` with a single literal string argument. However, `barf()` is a variadic C function, and this works on other platforms only because their C ABI happens to permit calling `barf()` as i...`emitBarf` generates a ccall in Cmm that calls `barf()` with a single literal string argument. However, `barf()` is a variadic C function, and this works on other platforms only because their C ABI happens to permit calling `barf()` as if it's defined as `void barf(char*);`. But not on wasm.
We should have a non-variadic wrapper for `barf()` in the RTS, and call that wrapper whenever a single string argument is to be passed. This will fix the occasional `wasm-ld: warning: function signature mismatch: barf` warnings, especially when `-dtag-inference-checks` is enabled.https://gitlab.haskell.org/ghc/ghc/-/issues/22846Allow OPTIONS_GHC pragmas in .cmm files.2023-02-07T16:03:49ZAndreas KlebingerAllow OPTIONS_GHC pragmas in .cmm files.Sometimes this would be useful for things like generating dump files in an easy fashion when working on GHC.
Not sure if it's worth the trouble. As I remember the way we make this work for .hs files is rather gnarly.Sometimes this would be useful for things like generating dump files in an easy fashion when working on GHC.
Not sure if it's worth the trouble. As I remember the way we make this work for .hs files is rather gnarly.