GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-27T12:34:17Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24554ghc-9.10.0.20240313 (alpha1) does not install on macOS2024-03-27T12:34:17ZAndreas Abelghc-9.10.0.20240313 (alpha1) does not install on macOSIssue #21506 is back for 9.10-alpha1. Same description, same symptoms, probably same cure.
Spelling it out:
- macOS Monterey 12.7.1
- download https://downloads.haskell.org/~ghc/9.10.0.20240313/ghc-9.10.0.20240313-x86_64-apple-darwin.t...Issue #21506 is back for 9.10-alpha1. Same description, same symptoms, probably same cure.
Spelling it out:
- macOS Monterey 12.7.1
- download https://downloads.haskell.org/~ghc/9.10.0.20240313/ghc-9.10.0.20240313-x86_64-apple-darwin.tar.xz
- `tar xf ...; cd ghc-...; ./configure`
- Produces pop-ups stating that "`libHS...` was blocked, not from an identified developer"
Here is some detailed error, but this is probably not interesting, since it is really a reprise of #21506 only:
```
./configure: line 13507: 8575 Killed: 9 "$GHC_TOOLCHAIN_BIN" -v2 "$@"
dyld[8606]: Library not loaded: '@rpath/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib'
Referenced from: '/Users/abel/bin/soft/ghc-9.10.0.20240313-x86_64-apple-darwin/bin/ghc-toolchain-bin-ghc-9.10.0.20240313'
Reason: tried: '/Users/abel/bin/soft/ghc-9.10.0.20240313-x86_64-apple-darwin/bin/../lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (code signature in <665593BF-2381-30B1-A621-5A18BB60B521> '/Users/abel/bin/soft/ghc-9.10.0.20240313-x86_64-apple-darwin/lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' not valid for use in process: library load disallowed by system policy), '$ORIGIN/../../../lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (no such file), '/Users/abel/bin/soft/ghc-9.10.0.20240313-x86_64-apple-darwin/bin/../lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (code signature in <665593BF-2381-30B1-A621-5A18BB60B521> '/Users/abel/bin/soft/ghc-9.10.0.20240313-x86_64-apple-darwin/lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' not valid for use in process: library load disallowed by system policy), '$ORIGIN/../../../lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (no such file), '/usr/local/lib/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (no such file), '/usr/lib/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (no such file)
```
I would assume it is a packaging error.
See also #23009.
P.S.: Installation succeeds via `ghcup`, thus, not many will bump into this problem.
I dimly remember that `ghcup` implements a work-around (patching the file tree permissions before running installation).9.10.1Rodrigo MesquitaRodrigo Mesquitahttps://gitlab.haskell.org/ghc/ghc/-/issues/24552pattern synonyms changed semantics from 9.8 to 9.10?2024-03-23T12:12:44Zjwaldmannpattern synonyms changed semantics from 9.8 to 9.10?## Summary
For a simple program with pattern synonyms, code generated by ghc-9.10.1 (alpha-1) behaves differently (throws exception) than code from ghc-9.8.2 (no exception, which seems correct to me).
Also, the exception's name is conf...## Summary
For a simple program with pattern synonyms, code generated by ghc-9.10.1 (alpha-1) behaves differently (throws exception) than code from ghc-9.8.2 (no exception, which seems correct to me).
Also, the exception's name is confusing (mentions "lambda" but there is none)
I checked 9.10 release notes (file ghc-9.10.0.20240313/docs/users_guide/9.10.1-notes.rst) they did not mention any change w.r.t. semantics of pattern synonyms.
## Reproduce
the following (silly) example is minimized from real code
```
{-# language PatternSynonyms #-}
import Prelude hiding (Maybe, Nothing,Just)
import qualified Prelude as P
data Maybe a = Nothing_ | Just_ a
pattern Nothing :: Maybe a
pattern Nothing <- Nothing_ where Nothing = Nothing_
pattern Just :: a -> Maybe a
pattern Just x <- Just_ x where Just = Just_
main = print $ do Just x <- [Nothing, Just ()] ; return x
```
## Actual Behaviour
```
$ /opt/ghc/ghc-9.10.0.20240313/bin/runhaskell ps.hs
ps.hs: ps.hs:14:19-24: Non-exhaustive patterns in lambda
HasCallStack backtrace:
collectBacktraces, called at libraries/ghc-internal/src/GHC/Internal/Exception.hs:92:13 in ghc-internal:GHC.Internal.Exception
...
```
## Expected behavior
```
$ /opt/ghc/ghc-9.8.2/bin/runhaskell ps.hs
[()]
```9.10.1Apoorv IngleApoorv Inglehttps://gitlab.haskell.org/ghc/ghc/-/issues/24551Literal string redundantly abstracted over a type variable2024-03-22T12:12:35ZjwaldmannLiteral string redundantly abstracted over a type variable## Summary
(I have no idea what's happening, but GHC asks me to report a bug)
## Steps to reproduce
sorry, didn't have time to minimize
```
git clone https://git.imn.htwk-leipzig.de/waldmann/autotool.git
cd autotool
git submodule ini...## Summary
(I have no idea what's happening, but GHC asks me to report a bug)
## Steps to reproduce
sorry, didn't have time to minimize
```
git clone https://git.imn.htwk-leipzig.de/waldmann/autotool.git
cd autotool
git submodule init
git submodule update
curl https://ghc.gitlab.haskell.org/head.hackage/cabal.project >> cabal.project.local
cabal update
cabal build -w /opt/ghc/ghc-9.10.0.20240313/bin/ghc transport
```
## Observed behaviour
```
...
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.10.0.20240313:
corePrepPgm
Case lzy-ctx _x_r3oD :: forall {atom}. Addr#
[GblId, Unf=OtherCon []]
_x_r3oD = \ (@atom_a2ge) -> "missing"#
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:190:37 in ghc-9.10.0.20240313-inplace:GHC.Utils.Panic
pprPanic, called at compiler/GHC/CoreToStg/Prep.hs:2050:16 in ghc-9.10.0.20240313-inplace:GHC.CoreToStg.Prep
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:507:29 in ghc-9.10.0.20240313-inplace:GHC.Utils.Error
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
## Note
error does NOT happen with `-O0`, or `-O2`, but DOES appear with `-O1` (which is cabal's default?)9.10.1Sebastian GrafSebastian Grafhttps://gitlab.haskell.org/ghc/ghc/-/issues/24546ghcup metadata gives incorrect dlSubdir of testsuite artifact2024-03-27T12:34:17ZBen Gamarighcup metadata gives incorrect dlSubdir of testsuite artifactAs noted in https://github.com/haskell/ghcup-metadata/pull/186#discussion_r1524064965, the `dlSubdir` of the testsuite artifact in the generated ghcup metadata is incorrect. It is listed as `dlSubdir: ghc-$ver` whereas it should be `dlSu...As noted in https://github.com/haskell/ghcup-metadata/pull/186#discussion_r1524064965, the `dlSubdir` of the testsuite artifact in the generated ghcup metadata is incorrect. It is listed as `dlSubdir: ghc-$ver` whereas it should be `dlSubdir: ghc-$ver/testsuite`.9.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24545GHC 9.10.1-alpha1 .tar.gz download does not extract properly2024-03-21T15:50:12ZRyan ScottGHC 9.10.1-alpha1 .tar.gz download does not extract properlyAfter downloading https://downloads.haskell.org/ghc/9.10.1-alpha1/ghc-9.10.0.20240313-x86_64-fedora33-linux.tar.gz, I attempted to extract it, only to be thwarted by this error:
```
$ tar -xvf ghc-9.10.0.20240313-x86_64-fedora33-linux.t...After downloading https://downloads.haskell.org/ghc/9.10.1-alpha1/ghc-9.10.0.20240313-x86_64-fedora33-linux.tar.gz, I attempted to extract it, only to be thwarted by this error:
```
$ tar -xvf ghc-9.10.0.20240313-x86_64-fedora33-linux.tar.gz
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
```
Curiously, this only affects the `.tar.gz` download, as the [`.tar.xz` version](https://downloads.haskell.org/ghc/9.10.1-alpha1/ghc-9.10.0.20240313-x86_64-fedora33-linux.tar.xz) extracts without issue. I haven't tried any other variants of GHC 9.10.1-alpha1.9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/24542Windows binary distribution `settings` contain references to build environmen...2024-03-25T19:13:14ZBen GamariWindows binary distribution `settings` contain references to build environment pathsBinary distributions on Windows contain references to the source distribution build root. For instance, the Windows binary distribution from the most recent 9.10.1-alpha1 candidate (https://gitlab.haskell.org/ghc/ghc/-/pipelines/91514) h...Binary distributions on Windows contain references to the source distribution build root. For instance, the Windows binary distribution from the most recent 9.10.1-alpha1 candidate (https://gitlab.haskell.org/ghc/ghc/-/pipelines/91514) has the following in its `settings` file:
```
[("C compiler command", "C:/GitLabRunner/builds/1/1807575/_build/bindist/ghc-9.10.0.20240313-x86_64-unknown-mingw32/mingw//bin/clang.exe")
...
```Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24529Binary distribution build on Windows fails2024-03-25T17:40:32ZBen GamariBinary distribution build on Windows failsIt appears that the `reloc-binary-dist` target is broken in at least some situations on Windows. Specifically, the `configure` invocation performed by `Rules.BinaryDist.installTo` fails to find the in-place mingw toolchain, causing `ghc-...It appears that the `reloc-binary-dist` target is broken in at least some situations on Windows. Specifically, the `configure` invocation performed by `Rules.BinaryDist.installTo` fails to find the in-place mingw toolchain, causing `ghc-toolchain` to conclude that there is no valid object merging tool available:
```
[Error {errorMessage = "Neither a object-merging tool (e.g. ld -r) nor an ar that supports -L is available", errorLogContexts = []}]
```
What is perplexing is that this appears to work in CI: the build system manages to produce a binary distribution, albeit a broken one for unrelated reasons (#24525).https://gitlab.haskell.org/ghc/ghc/-/issues/24525Windows bindists are quite broken2024-03-20T10:46:50ZBen GamariWindows bindists are quite brokenmingw32 binary distributions are currently quite broken:
```bash
$ wget https://gitlab.haskell.org/ghc/ghc/-/jobs/1805153/artifacts/raw/ghc-x86_64-windows-release.tar.xz
$ tar -xf ../ghc-x86_64-windows-release.tar.xz
$ cd ghc-9.10.0.2024...mingw32 binary distributions are currently quite broken:
```bash
$ wget https://gitlab.haskell.org/ghc/ghc/-/jobs/1805153/artifacts/raw/ghc-x86_64-windows-release.tar.xz
$ tar -xf ../ghc-x86_64-windows-release.tar.xz
$ cd ghc-9.10.0.20240310-x86_64-unknown-mingw32/
$ bin/ghc --info
ghc-9.10.0.20240310.exe: could not detect mingw toolchain in the following paths: ["C:\\msys64\\home\\ben\\tmp\\ghc-9.10.0.20240310-x86_64-unknown-mingw32\\lib\\..\\mingw","C:\\msys64\\home\\ben\\tmp\\ghc-9.10.0.20240310-x86_64-unknown-mingw32\\lib\\..\\..\\mingw","C:\\msys64\\home\\ben\\tmp\\ghc-9.10.0.20240310-x86_64-unknown-mingw32\\lib\\..\\..\\..\\mingw"]
```
It appears that many things that should be in the root of the binary distribution are instead now in `lib` (including `mingw/`):
```bash
$ ls lib/
a.exe config.guess config.status default.host.target.in doc ghc-usage.txt install-sh llvm-targets mk README x86_64-windows-ghc-9.10.0.20240310
bin config.log config.sub default.target docs-utils html latex Makefile package.conf.d settings
build.mk config.mk configure default.target.ghc-toolchain ghc-interp.js include lib manpage post-link.mjs template-hsc.h
completion config.mk.in default.host.target default.target.in ghci-usage.txt INSTALL llvm-passes mingw prelude.js wrappers
```
Moving `lib/mingw` to the root of the distribution appears to be sufficient to make the compiler functional.9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/24507Unsound optimization breaks pattern matching on sum type2024-03-23T22:14:54ZStefano DebenedettiUnsound optimization breaks pattern matching on sum type## Summary
Enabling `-O2` makes a case expression pattern match pick the 7th constructor of a sum type also when called with any constructor from the 2nd to the 6th.
The following factors seem to concur in triggering this behaviour (se...## Summary
Enabling `-O2` makes a case expression pattern match pick the 7th constructor of a sum type also when called with any constructor from the 2nd to the 6th.
The following factors seem to concur in triggering this behaviour (see the Expected behaviour section below for more details):
* `-O2`
* usage of the `streamly-core` library (I could not reproduce without it)
* a strictness annotation on the type used to hold the constructor to pass to the buggy function
* splitting the code into separate modules
On the other hand, using `Debug.Trace.trace` to examine the constructor before feeding it into the case expression fixes the issue, making it a Heisenbug.
## Steps to reproduce
```
$ git clone https://github.com/demaledetti/test-bug
$ cd test-bug
$ cabal clean && cabal build --ghc-options -v > cabal.log.ko 2>&1 && for i in {A..J}; do cabal run testbug -- $i; done
parser: A
testbug: src/TestBug/Parser.hs:(15,18)-(25,34): Non-exhaustive patterns in case
parser: B
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: C
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: D
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: E
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: F
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: G
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: H
OK
parser: I
OK
parser: J
testbug: src/TestBug/Parser.hs:(15,18)-(25,34): Non-exhaustive patterns in case
```
## Expected behaviour
With `-O1`:
```
$ cabal clean && cabal build -O1 --ghc-options -v > cabal.log.ok 2>&1 && for i in {A..J}; do cabal run -O1 testbug -- $i; done
parser: A
testbug: src/TestBug/Parser.hs:(15,18)-(25,34): Non-exhaustive patterns in case
parser: B
OK
parser: C
OK
parser: D
OK
parser: E
OK
parser: F
OK
parser: G
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: H
OK
parser: I
OK
parser: J
testbug: src/TestBug/Parser.hs:(15,18)-(25,34): Non-exhaustive patterns in case
```
For other ways to get the correct behaviour without lowering the optimization level, including the ones mentioned in the Summary section above, see these comments in the source code:
```
$ grep -rnI "the bug" src/ testbug/
src/TestBug/Data.hs:12: -- simplifying it away makes the bug disappear
src/TestBug/Parser.hs:5:-- makes the bug go away (making it a Heisenbug)
src/TestBug/Parser.hs:16: -- uncommenting the next line makes the bug disappear
src/TestBug/Parser.hs:26: -- uncommenting the next line makes the bug disappear
testbug/Main.hs:13:-- makes the bug go away
```
## Environment
* GHC version used: 9.8.2
Optional:
* Operating System:
* System Architecture:
```
$ uname -a
Linux eppere 6.7.5-gentoo #1 SMP Mon Feb 19 15:51:31 CET 2024 x86_64 Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz GenuineIntel GNU/Linux
```
Logs mentioned above:
[cabal.log.ko](/uploads/5c86dcaaac0efe1a297a3534d2e6b3a4/cabal.log.ko)
[cabal.log.ok](/uploads/aa5c0a45405cbf6e9fad05b1219dcd07/cabal.log.ok)
Log of build with `-O2` but removing the strictness annotation in `Main.hs` (commenting line 14, uncommenting line 15):
[cabal.log.lazy](/uploads/b63f0ae3c422538bb04ed7b623c49c50/cabal.log.lazy)
(easier to diff vs cabal.log.ko)9.8.3Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/24485Sort out haddock hyperlinked-sources links2024-03-26T17:46:45ZBen GamariSort out haddock hyperlinked-sources linksCurrently Haddock's hyperlinked sources [fails to account](https://github.com/haskell/haddock/issues/1628) for declaration reexports correctly. This needs to be addressed for 9.10.1 to avoid compromising `base` documentation due to the `...Currently Haddock's hyperlinked sources [fails to account](https://github.com/haskell/haddock/issues/1628) for declaration reexports correctly. This needs to be addressed for 9.10.1 to avoid compromising `base` documentation due to the `ghc-internal` split.9.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24258GHC 9.6.3 intermittently crashes non-deterministically while compiling large ...2024-01-09T10:34:55ZBen GamariGHC 9.6.3 intermittently crashes non-deterministically while compiling large code baseA client has an application which crashes GHC 9.6.3 non-deterministically with either a `SIGSEGV` or `SIGBUS`. Unfortunately this is quite tricky to reproduce. The program in question is being compiled with parallel compilation on an AAr...A client has an application which crashes GHC 9.6.3 non-deterministically with either a `SIGSEGV` or `SIGBUS`. Unfortunately this is quite tricky to reproduce. The program in question is being compiled with parallel compilation on an AArch64 (Graviton 2) machine running Ubuntu 22.04. I have reproduced the crash using both the upstream GHC 9.6.3 bindist and my own build. However, I have yet to observe the issue when compiling `ghc` against the `-debug` RTS.9.6.4Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24197`dumpIPEToEventLog` disregards maximum event length2024-01-30T11:44:36ZBen Gamari`dumpIPEToEventLog` disregards maximum event lengthBuilding a compiler in the `default+ipe+debug_info+ghc_debug` flavour will quickly reveal that `dumpIPEToEventLog` makes no attempt to honor the maximum event length:
```
ghc: internal error: ASSERTION FAILED: file rts/eventlog/EventLog....Building a compiler in the `default+ipe+debug_info+ghc_debug` flavour will quickly reveal that `dumpIPEToEventLog` makes no attempt to honor the maximum event length:
```
ghc: internal error: ASSERTION FAILED: file rts/eventlog/EventLog.c, line 183
Stack trace:
0x110e52c8 set_initial_registers (rts/Libdw.c:294.5)
0x7ffff7b826b8 dwfl_thread_getframes (/nix/store/dbvlgp6fsp0ar1pn9chyc41j8y2lh2jx-elfutils-0.189/lib/libdw-0.189.so)
0x7ffff7b8220b get_one_thread_cb (/nix/store/dbvlgp6fsp0ar1pn9chyc41j8y2lh2jx-elfutils-0.189/lib/libdw-0.189.so)
0x7ffff7b8251a dwfl_getthreads (/nix/store/dbvlgp6fsp0ar1pn9chyc41j8y2lh2jx-elfutils-0.189/lib/libdw-0.189.so)
0x7ffff7b82a47 dwfl_getthread_frames (/nix/store/dbvlgp6fsp0ar1pn9chyc41j8y2lh2jx-elfutils-0.189/lib/libdw-0.189.so)
0x110e519b libdwGetBacktrace (rts/Libdw.c:263.15)
0x1107def8 rtsFatalInternalErrorFn (rts/RtsMessages.c:175.22)
0x1107dab7 barf (rts/RtsMessages.c:49.3)
0x1107db1a errorBelch (rts/RtsMessages.c:68.1)
0x1109959c postString (rts/eventlog/EventLog.c:184.9)
0x1109c6ca postIPE (rts/eventlog/EventLog.c:1449.36)
0x11095807 traceIPE (rts/Trace.c:702.1)
0x11074957 dumpIPEToEventLog (rts/IPE.c:122.50)
0x11099a1d postInitEvent (rts/eventlog/EventLog.c:321.5)
0x1107e721 hs_init_ghc (rts/RtsStartup.c:403.5)
0x1107d93e hs_main (rts/RtsMain.c:57.5)
0x751bc1 (null) (/mnt/data/exp/ghc/ghc-landing/_build/stage1/bin/ghc)
0x7ffff7c09ace __libc_start_call_main (/nix/store/dg8mpqqykmw9c7l0bgzzb5znkymlbfjw-glibc-2.37-8/lib/libc.so.6)
0x7ffff7c09b89 __libc_start_main@@GLIBC_2.34 (/nix/store/dg8mpqqykmw9c7l0bgzzb5znkymlbfjw-glibc-2.37-8/lib/libc.so.6)
0x409055 _start (/mnt/data/exp/ghc/ghc-landing/_build/stage1/bin/ghc)
(GHC version 9.9.20231025 for x86_64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
The offending IPE field appears to be `ty_desc`, which in this case is 76314 characters long (being the `Generic` representation of the `GHC.Tc.Errors.Types.TcRnMessage` type).
Without RTS assertions enabled this results in the program crashing due to non-obvious heap corruption.https://gitlab.haskell.org/ghc/ghc/-/issues/24168ld: warning: -single_module is obsolete2024-02-09T10:35:36ZSimon Michaelld: warning: -single_module is obsolete## Summary
On macos 14.1 (Sonoma), I see "ld: warning: -single_module is obsolete" as each library component is linked. It doesn't happen with executable components, or at least not always. Perhaps related to Apple's newer linker, simil...## Summary
On macos 14.1 (Sonoma), I see "ld: warning: -single_module is obsolete" as each library component is linked. It doesn't happen with executable components, or at least not always. Perhaps related to Apple's newer linker, similar to #24167 ?
## Steps to reproduce
Build packages with stack or cabal.
## Expected behavior
Not show the warning.
## Environment
* GHC version used: 9.6.3
Optional:
* Operating System: macos
* System Architecture: m1Rodrigo MesquitaRodrigo Mesquitahttps://gitlab.haskell.org/ghc/ghc/-/issues/24167ld: warning: ignoring duplicate libraries: '-lm'2024-02-09T10:35:36ZRodrigo Mesquitald: warning: ignoring duplicate libraries: '-lm'## Summary
I've been getting warnings when linking Haskell executables:
AA.hs:
```haskell
module Main where
main = pure()
```
results in:
```
> ghc AA.hs
[1 of 2] Compiling Main ( AA.hs, AA.o ) [Source file changed]
[2 of 2...## Summary
I've been getting warnings when linking Haskell executables:
AA.hs:
```haskell
module Main where
main = pure()
```
results in:
```
> ghc AA.hs
[1 of 2] Compiling Main ( AA.hs, AA.o ) [Source file changed]
[2 of 2] Linking AA [Objects changed]
ld: warning: ignoring duplicate libraries: '-lm'
```
This also seems to have broken CI for aarch64-darwin
## Expected behavior
We should fix the warning
## Environment
* GHC version used: 9.6
* Operating System: macOS
* System Architecture: aarch64Rodrigo MesquitaRodrigo Mesquitahttps://gitlab.haskell.org/ghc/ghc/-/issues/24161iconv regression in recent macOS distributions2024-02-09T10:35:36ZBryan Rbryan@haskell.foundationiconv regression in recent macOS distributionsThe recent macOS Sonoma release distributed an `iconv()` that introduced regression in the `encoding004` test of the `base` testsuite that tests roundtripping of CP936.
The release seems to have also fixed an issue where `LC_ALL=C` woul...The recent macOS Sonoma release distributed an `iconv()` that introduced regression in the `encoding004` test of the `base` testsuite that tests roundtripping of CP936.
The release seems to have also fixed an issue where `LC_ALL=C` would be ignored in macOS and Unicode was by default regardless, which caused failures in `T2507`, `T6037`, and `T8959a`.
```
Unexpected passes:
/var/folders/0p/k15lrkf913923yn8w6nk3kc80000hm/T/ghctest-32bcsuxp/test spaces/testsuite/tests/driver/T2507.run T2507 [unexpected] (normal)
/var/folders/0p/k15lrkf913923yn8w6nk3kc80000hm/T/ghctest-32bcsuxp/test spaces/testsuite/tests/driver/T6037.run T6037 [unexpected] (normal)
/var/folders/0p/k15lrkf913923yn8w6nk3kc80000hm/T/ghctest-32bcsuxp/test spaces/testsuite/tests/driver/T8959a.run T8959a [unexpected] (normal)
Unexpected failures:
/var/folders/0p/k15lrkf913923yn8w6nk3kc80000hm/T/ghctest-32bcsuxp/test spaces/libraries/base/tests/IO/encoding004.run encoding004 [bad exit code (1)] (normal)
```Rodrigo MesquitaRodrigo Mesquitahttps://gitlab.haskell.org/ghc/ghc/-/issues/24055darwin-3 fails nearly all jobs2023-12-15T12:14:25ZBen Gamaridarwin-3 fails nearly all jobsSee, for instance, https://gitlab.haskell.org/ghc/ghc/-/jobs/1681954.
```
Fetching perf notes...
git fetch -f https://gitlab.haskell.org/ghc/ghc-performance-notes.git refs/notes/perf:refs/notes/perf
error: unable to rewind rpc post data...See, for instance, https://gitlab.haskell.org/ghc/ghc/-/jobs/1681954.
```
Fetching perf notes...
git fetch -f https://gitlab.haskell.org/ghc/ghc-performance-notes.git refs/notes/perf:refs/notes/perf
error: unable to rewind rpc post data - try increasing http.postBuffer
error: RPC failed; curl 65 HTTP/2 stream 31 was reset
fatal: expected 'acknowledgments'
```Moritz AngermannBryan Rbryan@haskell.foundationMoritz Angermannhttps://gitlab.haskell.org/ghc/ghc/-/issues/24047Darwin CI seems to fail because of missing xcode installation2023-10-03T13:19:53ZAndreas KlebingerDarwin CI seems to fail because of missing xcode installation## Summary
I get these sort of errors:
```
warning: Nix search path entry '/nix/var/nix/profiles/per-user/root/channels' does not exist, ignoring
/nix/store/ck1slah4x89kplmi4701nwgm152075l0-toolchain
...
Using 9374f116c489443bb61df4f...## Summary
I get these sort of errors:
```
warning: Nix search path entry '/nix/var/nix/profiles/per-user/root/channels' does not exist, ignoring
/nix/store/ck1slah4x89kplmi4701nwgm152075l0-toolchain
...
Using 9374f116c489443bb61df4ff148edb9c641104dd for performance metric baseline...
xcode-select: error: no developer tools were found at '/Applications/Xcode.app', and no install could be requested (perhaps no UI is present), please install manually from 'developer.apple.com'.
```
## Expected behavior
This happened on this CI job: https://gitlab.haskell.org/ghc/ghc/-/jobs/1680663
Seems like a missconfiguration issue?Moritz AngermannBryan Rbryan@haskell.foundationMoritz Angermannhttps://gitlab.haskell.org/ghc/ghc/-/issues/24042Crash & hang with non-moving GC & FFI on GHC 9.6.32023-12-13T14:50:13ZHai / @BestYeenCrash & hang with non-moving GC & FFI on GHC 9.6.3## Summary
I've recently started switching from GHC 8 to GHC 9, and with the inclusion of GHC 9.6.3 in Stackage Nightly, I was able to rule out everything else and pin down a new crash.
## Steps to reproduce
In Windows 10 x64, with St...## Summary
I've recently started switching from GHC 8 to GHC 9, and with the inclusion of GHC 9.6.3 in Stackage Nightly, I was able to rule out everything else and pin down a new crash.
## Steps to reproduce
In Windows 10 x64, with Stack set up with the resolver `nightly-2023-10-01`, this 100% reliably has fatal problems on my system.
In a _new, empty folder_, create `t.hs`:
```plaintext
module Main(main) where
import Data.Int
type INT = Int32
type WINBOOL = Int32
foreign import capi safe "winuser.h SetCursorPos" c_SetCursorPos :: INT -> INT -> IO WINBOOL
main :: IO ()
main = do
putStrLn "Mark 1"
c <- getChar
if c == 'x' then do
_ <- c_SetCursorPos 0 0
pure ()
else
pure ()
putStrLn "Mark 2"
```
And `h.bat` (assuming stack is in your path):
```plaintext
@rd /s/q _temp 2>nul
@del *.exe 2>nul
@md _temp 2>nul
@stack ghc -- -threaded -XCApiFFI -tmpdir _temp -odir _temp -hidir _temp t.hs
@ren t.exe t-works-normally.exe
@stack ghc -- -threaded -with-rtsopts --nonmoving-gc -XCApiFFI -tmpdir _temp -odir _temp -hidir _temp t.hs
@ren t.exe t-crashes-immediately.exe
@stack ghc -- -with-rtsopts --nonmoving-gc -XCApiFFI -tmpdir _temp -odir _temp -hidir _temp t.hs
@ren t.exe t-hangs-after-pressing-return.exe
@exit /b
```
## Expected behavior
All three .exe files should run, first display `Mark 1`, then after pressing return display `Mark 2`.
## Actual behavior
t-works-normally.exe works as intended.
t-crashes-immediately.exe segfaults immediately (before `getChar` is evaluated)
t-hangs-after-pressing-return.exe mostly works, but never terminates after Mark 2.
## Environment
* GHC version used: 9.6.3 (Stackage Nightly 2023-10-01)
Optional:
* Operating System: Windows 10 x64
* System Architecture: -9.6.4Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24037GHC 9.8 regression: Fixity declaration for prefix type family in class no lon...2023-10-10T12:51:59ZRyan ScottGHC 9.8 regression: Fixity declaration for prefix type family in class no longer acceptedGHC 9.8 and HEAD reject the following program (minimized from the [`singletons-base`](https://hackage.haskell.org/package/singletons-base) test suite), which GHC 9.6 and earlier accept:
```hs
{-# LANGUAGE TypeFamilies #-}
module Bug whe...GHC 9.8 and HEAD reject the following program (minimized from the [`singletons-base`](https://hackage.haskell.org/package/singletons-base) test suite), which GHC 9.6 and earlier accept:
```hs
{-# LANGUAGE TypeFamilies #-}
module Bug where
class POrd a where
type Geq a b
infixr 6 `Geq`
```
```
$ ghc-9.6.2 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
$ ghc-9.8.0.20230929 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:6:12: error: [GHC-54721]
‘Geq’ is not a (visible) method of class ‘POrd’
|
6 | infixr 6 `Geq`
| ^^^^^
```
This is likely related to #23664, except that that bug can only be triggered if the type family name consists of symbolic characters. This bug, on the other hand, occurs when the name has alphanumeric characters.9.8.1sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23952Segfault or internal error: stg_ap_v_ret in ghc 9.6.22024-02-25T22:02:13ZJannisSegfault or internal error: stg_ap_v_ret in ghc 9.6.2## Summary
I have a program that crashes with a segfault when run with sanity checks `-Da -DS` or with `internal error: stg_ap_v_ret` when run without them.
Its rather large, and I don't know how to reduce it (mostly because I don't un...## Summary
I have a program that crashes with a segfault when run with sanity checks `-Da -DS` or with `internal error: stg_ap_v_ret` when run without them.
Its rather large, and I don't know how to reduce it (mostly because I don't understand why it happens in the first place). Its the start of a table based ecs implementation.
The core pieces are: [runQuery](https://github.com/1Jajen1/Brokkr/blob/main/brokkr-hecs/hecs-core/src/Hecs/Query/Internal.hs#L87) (and a copy of it which I experimented with: `runQuery2#`). Its called from [progress](https://github.com/1Jajen1/Brokkr/blob/main/brokkr-hecs/hecs-core/src/Hecs/World/Internal.hs#L488) and the system and query data is created and set at [system](https://github.com/1Jajen1/Brokkr/blob/main/brokkr-hecs/hecs-core/src/Hecs/World/Internal.hs#L478) and [query](https://github.com/1Jajen1/Brokkr/blob/main/brokkr-hecs/hecs-core/src/Hecs/World/Internal.hs#L400). Experimentally I confirmed that the first `runQuery` with the `systemQuery` argument runs and calls the second `runQuery`, which fails. `runQuery` works fine on its own (even nested), but fails with the setup in `progress`.
Gdb traced the segfault all the way to `LOOKS_LIKE_CLOSURE_PTR`.
<details><summary>Full output before it crashes:</summary>
```
stg_ap_0_ret... 0x42005e16ba: FUN/2(0x469648, 0x42005e16e8, 0x42005e16d8, 0x42005e1786)
stg_ap_v_ret... 0x42005e16d8: MUT_VAR_CLEAN(var=0x42005e17b8)
Thread 1 "Example" received signal SIGSEGV, Segmentation fault.
0x0000000000bf4c6e in LOOKS_LIKE_CLOSURE_PTR (p=0x1839000000420058)
at rts/include/rts/storage/ClosureMacros.h:269
Downloading source file /builds/ghc/ghc/rts/include/rts/storage/ClosureMacros.h
269 rts/include/rts/storage/ClosureMacros.h: Directory not empty.
(gdb) bt
#0 0x0000000000bf4c6e in LOOKS_LIKE_CLOSURE_PTR (p=0x1839000000420058)
at rts/include/rts/storage/ClosureMacros.h:269
#1 0x0000000000bf4f3b in checkClosureShallow (p=0x183900000042005e)
at rts/sm/Sanity.c:106
#2 0x0000000000bf4e77 in checkSmallBitmap (payload=0x42005fff40, bitmap=0, size=4)
at rts/sm/Sanity.c:75
#3 0x0000000000bf4fe7 in checkStackFrame (c=0x42005fff38) at rts/sm/Sanity.c:133
#4 0x0000000000c09ee9 in stg_ap_v_info ()
#5 0x0000000000000000 in ?? ()
```
</details>
This is as far as I got. I don't really know how to continue from here.
In a previous version I had mutable smallarrays in the mutvars, which I then froze before use. This segfaulted the second anything with the smallarrays was done (getting the size, reading any elements, or freezing). I then changed to immutable smallarrays later, but as you can see it still crashes.
## Steps to reproduce
Use [Brokkr/brokkr-hecs:git](https://github.com/1Jajen1/Brokkr/blob/main/brokkr-hecs/), checkout `minimal-hecs` and run `cabal run hecs:example -- +RTS -Da -DS`. I pushed the last state of my local testing before I gave up.
## Expected behavior
Pls don't segfault :)
## Environment
* GHC version used: ghc 9.6.29.10.1Ben GamariBen Gamari