Dear Maintainer, https://buildd.debian.org/status/fetch.php?pkg=haskell-random&arch=powerpc&ver=1.2.1.1-2&stamp=1667433395&raw=0 Here is the gdb backtrace with libc6-dbg installed. ,---- | Reading symbols from /home/marillat/haskell-random-1.2.1.1/debian/hlibrary.setup... | (No debugging symbols found in /home/marillat/haskell-random-1.2.1.1/debian/hlibrary.setup) | [New LWP 9082] | [Thread debugging using libthread_db enabled] | Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1". | Core was generated by `debian/hlibrary.setup build --builddir=dist-ghc'. | Program terminated with signal SIGSEGV, Segmentation fault. | #0 __GI_kill () at ../sysdeps/unix/syscall-template.S:122 | 122 ../sysdeps/unix/syscall-template.S: No such file or directory. | (gdb) bt | #0 __GI_kill () at ../sysdeps/unix/syscall-template.S:122 | #1 0x108f27b4 in exitBySignal () | #2 0x108f29f4 in shutdownHaskellAndSignal () | #3 0x1088c828 in ?? () | #4 0x108f55a0 in scheduleWaitThread () | #5 0x108f21c8 in hs_main () | #6 0x10007408 in main () | (gdb) `---- Christian
On 08 nov. 2022 09:03, "Debian Bug Tracking System" <owner@bugs.debian.org> wrote: Hi, In the original bug report I didn't report all backtraces. We have two SIGSEGV : ,---- | Tue 2022-11-08 07:34:02 CET 9084 1000 1000 SIGSEGV present /usr/lib/ghc/bin/ghc 49.1M | Tue 2022-11-08 07:34:02 CET 9082 1000 1000 SIGSEGV present /home/marillat/haskell-random-1.2.1.1/debian/hlibrary.setup 1.1M `---- Here is the backtace for the first SIGSEGV : ,---- | Reading symbols from /usr/lib/ghc/bin/ghc... | (No debugging symbols found in /usr/lib/ghc/bin/ghc) | [New LWP 9084] | [New LWP 9088] | [New LWP 9085] | [New LWP 9087] | [New LWP 9086] | [Thread debugging using libthread_db enabled] | Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1". | Core was generated by `/usr/lib/ghc/bin/ghc -B/usr/lib/ghc --make -fbuilding-cabal-package -O -static'. | Program terminated with signal SIGSEGV, Segmentation fault. | #0 0x0e4126e4 in base_GHCziFloat_floatToDigits_closure () from /usr/lib/ghc/bin/../base-4.15.1.0/libHSbase-4.15.1.0-ghc9.0.2.so | [Current thread is 1 (Thread 0xf7eab520 (LWP 9084))] | (gdb) bt | #0 0x0e4126e4 in base_GHCziFloat_floatToDigits_closure () from /usr/lib/ghc/bin/../base-4.15.1.0/libHSbase-4.15.1.0-ghc9.0.2.so | #1 0x0d8d7dcc in ghczmbignum_GHCziNumziBigNat_bigNatIsPowerOf2zh_info () from /usr/lib/ghc/bin/../ghc-bignum-1.1/libHSghc-bignum-1.1-ghc9.0.2.so | #2 0x0d48a380 in ?? () from /usr/lib/ghc/bin/../rts/libHSrts_thr-ghc9.0.2.so | Backtrace stopped: previous frame inner to this frame (corrupt stack?) `---- Christian
Hi! Note that this issue also prevents us from building the latest version of the GHC compiler [1]. I have tried to cross-compile GHC 9.4.6 to work around this issue and also tried building an unregisterised compiler. Both without success. I have forwarded the issue upstream [2]. I think the only way forward will be to bisect the problem unless a GHC expert can figure out what the problem is. Adrian
Hello! I have been bisecting this issue but in order to be successful, I need a simple reproducer which isn't trivial since I cannot just reuse the build directory of an unsuccessful build due to the changing Haskell libraries for different GHC versions. Ideally, we should have a single command line with GHC which will trigger the segmentation fault. To bisect, I have done the following: # git bisect start # git bisect good ghc-8.10.7-release # git bisect bad ghc-9.2.7-release # git submodule update --init # ./boot ; python3 boot # echo "SRC_HC_OPTS += -lffi -latomic -optl-pthread" >> mk/build.mk && \ echo "Stage1Only := YES" >> mk/build.mk && \ echo 'utils/genprimopcode_CONFIGURE_OPTS += "-f-build-tool-depends"' \ >> mk/build.mk && echo 'compiler_CONFIGURE_OPTS += "-f-build-tool-depends"' \ >> mk/build.mk && echo 'utils/hpc_CONFIGURE_OPTS += "-f-build-tool-depends"' \ >> mk/build.mk && echo "HADDOCK_DOCS := NO" >> mk/build.mk \ && echo "BUILD_SPHINX_HTML := NO" >> mk/build.mk && echo "BUILD_SPHINX_PDF := NO" \ >> mk/build.mk # ./configure && make -j32 For newer versions, the build has to be performed with Hadrian, so the last step would be: # ./hadrian/build -j Prior to using Hadrian for the first time, the package database needs to be updated: # cabal update Now, if I had a simple reproducer, it would be rather easy to bisect the issue. Adrian
Hi Adrian, Thanks for working on this, comments inline. Are you bisecting the segfault issue? If yes, then a simple reproducer would be to try and compile haskell-random. Since you already have cabal-install on your system, you can do something like: $ cabal install --with-ghc=/usr/bin/ghc --with-ghc-pkg=/usr/bin/ghc-pkg random-1.2.1.1 (replace ghc and ghc-pkg with the ones you have built). Since this issue is also present in ghc-9.0.2, maybe we can start from there. Keep in mind that hadrian doesn't take into account 'mk/build.mk'. You will have to configure hadrian in the same way, see also https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html. Let me summarize the current state to make sure we are not missing anything: 1. GHC 9.0.2 with the native code generator is currently broken on powerpc and segfaults while building (at least) haskell-random and GHC-9.4.6. Strangely enough, we can compile GHC 9.0.2 itself. 2. An unregisterised GHC 9.0.2 is *also* broken on powerpc, producing code that overflows integers. We are also seeing unregisterised GHC 9.4.6 on i386 being broken, since the tests for haskell-quickcheck fail (see https://buildd.debian.org/status/package.php?p=haskell-quickcheck&suite=sid). The plan for i386 is to registerise GHC and use the LLVM backend by default (to avoid the baseline violation). 3. We cannot cross-compile GHC 9.4 and newer any more (we are discussing this here as well https://gitlab.haskell.org/ghc/ghc/-/issues/23975). Given the above, I can think of the following: 1. Fix the native code generator in GHC 9.0.2 2. Fix unregisterised GHCs on 32-bit architectures 3. Try and use the LLVM backend in GHC 9.0.2 on powerpc, and see if this produces valid code and allows us to compile GHC 9.4.6. For the record, I have started working on migrating GHC in Debian to use the new Hadrian build system, you can find the latest code here https://salsa.debian.org/haskell-team/DHG_packages/-/tree/hadrian. I am at a really good state right now where I can build GHC, and doing a lot of tests to verify I haven't missed anything. If you are working on GHC right now as well, I would appreciate if you can take a look, and/or start using this branch for all your tests, so we catch any errors early. Best,
Hi Ilias! Thanks for the useful hints! Thanks, this is the exact reproducer I need. I can reproduce the crash using this command line inside a 32-bit PowerPC chroot on perotto with ghc 9.0.2. Yes, that's what I am trying now as well. Thanks, good to know! I see. This can be trivially fixed with the help of this patch: FWIW, I am seeing the overflow on 32-bit PowerPC only. I don't see it on m68k, for example. Ah, that's actually a possible approach to take. FWIW, I have not been able to build GHC from git on 32-bit PowerPC even for 8.10.7. I assume, I will need to add some of Debian's patches on top of vanilla GHC in order to get the build to succeed. Trying to build GHC 9.0.2 fails for example with: I want to get the build issue on 32-bit PowerPC sorted out first. Adrian
Hi! Looking at the ghc package in openSUSE, I found this patch [1] which disables unboxed arrays in order to fix the build on big-endian systems. And, indeed, disabling unboxed arrays in libraries/containers/containers/include/containers.h allows me to fully build ghc from git on 32-bit PowerPC. See also [2]. I have now a working reproducer and can now start bisecting between 8.10.7 and 9.0.2. Adrian
Hi Ilias!
ba089952f034d91718c71f5ef297fe54818559df is the first bad commit
commit ba089952f034d91718c71f5ef297fe54818559df
Author: Sylvain Henry <sylvain@haskus.fr>
Date: Fri Jan 15 12:33:40 2021 +0100
Bignum: add Natural constant folding rules (#15821)
* Implement constant folding rules for Natural (similar to Integer ones)
* Add mkCoreUbxSum helper in GHC.Core.Make
* Remove naturalTo/FromInt
We now only provide `naturalTo/FromWord` as
the semantics is clear (truncate/zero-extend). For Int we have to deal
with negative numbers (throw an exception? convert to Word
beforehand?) so we leave the decision about what to do to the caller.
Moreover, now that we have sized types (Int8#, Int16#, ..., Word8#,
etc.) there is no reason to bless `Int#` more than `Int8#` or `Word8#`
(for example).
* Replaced a few `()` with `void#`
compiler/GHC/Builtin/Names.hs | 310 +++++++---
compiler/GHC/Core/Make.hs | 14 +-
compiler/GHC/Core/Opt/ConstantFold.hs | 670 +++++++++++----------
compiler/GHC/HsToCore/Expr.hs | 6 +-
compiler/GHC/Types/Id/Make.hs-boot | 1 +
libraries/base/GHC/Enum.hs | 4 +-
libraries/base/GHC/Float.hs | 6 +-
libraries/base/GHC/Int.hs | 16 +-
libraries/base/GHC/Natural.hs | 20 +-
libraries/base/GHC/Num.hs | 12 +-
libraries/base/GHC/Real.hs | 2 +-
libraries/ghc-bignum/src/GHC/Num/BigNat.hs | 64 +-
libraries/ghc-bignum/src/GHC/Num/Integer.hs | 14 +-
libraries/ghc-bignum/src/GHC/Num/Natural.hs | 162 +++--
libraries/ghc-bignum/src/GHC/Num/Primitives.hs | 4 +-
libraries/ghc-bignum/src/GHC/Num/WordArray.hs | 4 +-
.../integer-gmp/src/GHC/Integer/GMP/Internals.hs | 8 +-
testsuite/tests/lib/integer/Makefile | 50 +-
testsuite/tests/lib/integer/all.T | 1 +
.../tests/lib/integer/naturalConstantFolding.hs | 172 ++++++
.../lib/integer/naturalConstantFolding.stdout | 38 ++
testsuite/tests/perf/compiler/T16473.stdout | 2 +-
.../tests/simplCore/should_compile/T15445.stderr | 2 +-
23 files changed, 1057 insertions(+), 525 deletions(-)
create mode 100644 testsuite/tests/lib/integer/naturalConstantFolding.hs
create mode 100644 testsuite/tests/lib/integer/naturalConstantFolding.stdout
And I have verified that this commit actually introduced the segfault on 32-bit PowerPC.
Adrian
Hi Christian! Could you provide the disassembled code for the affected code section? Thanks, Adrian
Hi Adrian, [...] I don't remember but now I can install ghc (>= 9.4) only 9.0.2 is available. Is it important ? Christian
Hi Christian! The bug affects GHC 9.0.2 as the change was backported. GHC 9.4.x was never available for powerpc at the moment due this particular bug. It would save me some time, so it would be very helpful. Adrian
Hi Adrian, Is this enough ? ,---- | Dump of assembler code for function __GI_kill: | 0xf7644b94 <+0>: li r0,37 | 0xf7644b98 <+4>: sc | => 0xf7644b9c <+8>: bnslr+ | 0xf7644ba0 <+12>: b 0xf762a200 <__syscall_error> | End of assembler dump. `---- Christian
Hi Christian! I think the interesting part would be the disassembly of base_GHCziFloat_floatToDigits_closure () where the actual crash happened. Your disassembly seems to show parts of the segfault handler. Adrian
On 09 oct. 2023 09:32, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote: [...] ,---- | 10a19f20 <base_GHCziFloat_zdwzdsfloatToDigits_closure>: | 10a19f20: 10 83 c0 48 vmulouh v4,v3,v24 | 10a19f24: 10 a2 0d bc vaddeuqm v5,v2,v1,v22 | 10a19f28: 10 a1 9e 80 vsubuws v5,v1,v19 | 10a19f2c: 10 a1 9e b0 maddhd r5,r1,r19,r26 | 10a19f30: 10 a1 9e d0 zvdotphssui r5,r1,r19 | 10a19f34: 10 a1 9f 10 .long 0x10a19f10 | 10a19f38: 00 00 00 00 .long 0x0 | 10a19f3c: 10 90 f7 d0 .long 0x1090f7d0 | 10a19f40: 10 a1 9c 18 vextdubvlx v5,v1,v19,r16 | 10a19f44: 10 a1 9c c0 vsubudm v5,v1,v19 | 10a19f48: 00 00 00 00 .long 0x0 | 10a19f4c: 10 90 f7 f0 maddhd r4,r16,r30,r31 | 10a19f50: 10 a1 9c 08 vpmsumb v5,v1,v19 | 10a19f54: 10 a1 9f 00 vsubsbs v5,v1,v19 | 10a19f58: 10 a1 9f 3c vaddeuqm v5,v1,v19,v28 | 10a19f5c: 00 00 00 00 .long 0x0 | 10a19f60: 10 90 f7 d0 .long 0x1090f7d0 | 10a19f64: 10 a1 9f 20 vmhaddshs v5,v1,v19,v28 | 10a19f68: 10 a1 9f 4c psq_lux f5,r1,r19,1,6 | 10a19f6c: 00 00 00 00 .long 0x0 `---- Christian
Hi Adrian, A small update here. I didn't manage to use the LLVM backend on i386, seems to be broken [1]. Instead, I believe I have managed to fix unregisterised GHC on 32-bit, by backporting these two patches [2] [3]. Can you try building an unregisterised GHC 9.4.7 on powerpc and see if this resolves the issues you have with integer overflows? Note that GHC 9.4.7 *with* the Hadrian build system is now available on experimental. [1] https://gitlab.haskell.org/ghc/ghc/-/issues/24018 [2] https://salsa.debian.org/haskell-team/DHG_packages/-/blob/a38be7c092b024de04280f0a72642baf283cea01/p/ghc/debian/patches/fix-32-bit-unreg [3] https://salsa.debian.org/haskell-team/DHG_packages/-/blob/a38be7c092b024de04280f0a72642baf283cea01/p/ghc/debian/patches/fix-hs_cmpxchg64
Hi Ilias! I think you created a little hen and egg problem here by incorporating both the switch to the Hadrian build system as well as the 32-bit unregisterised and sparc64 build fixes into the same upload. Might a good idea to upload the two build fixes unstable first to get a working 9.4.x compiler for all targets so we're able to build haskell-hadrian first. Adrian
Unfortunately we cannot currently build GHC from unstable, unless we use the Hadrian build system, see https://bugs.debian.org/1051493. It was a mistake uploading GHC 9.4.6 to unstable, without noticing that we need the new build system first. I think our best bet here is to bootstap GHC on these architectures, that's why I have introduced the 'pkg.ghc.nohadrian' build profile. Let me know if I can help, or if there is a better way to do it that I am missing.
OK, good to know about the build profile. However, on powerpc I will most likely still have to cross-compile the package as I don't really have a working native 9.0.x compiler on the target at the moment unless there is a 9.0.x version without the patch [1] that introduced the regression. Adrian
Hello! I have built a patched version 9.0.1 of GHC for powerpc with a forged 9.0.3 version number and uploaded it to unreleased so that we have a working bootstrap compiler to build 9.4.7 for powerpc once the bug has been fixed. Unfortunately, we're running into another familiar problem which is a missing -latomic when building hadrian using the bootstrap.py script which does not take any build flags, the build of the »shake« package fails with the linker complaining about unresolved references to 64-bit atomic helper functions: Linking /home/glaubitz/ghc18/ghc-9.4.7/hadrian/_build/dists/shake-0.19.4/build/shake/shake ... /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(STM.thr_o): in function `stmStartTransaction': (.text.stmStartTransaction+0xe4): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.stmStartTransaction+0xfc): undefined reference to `__atomic_store_8' /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(STM.thr_o): in function `stmCommitTransaction': (.text.stmCommitTransaction+0x40): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.stmCommitTransaction+0x118): undefined reference to `__atomic_load_8' /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(ThreadPaused.thr_o): in function `threadPaused': (.text.threadPaused+0x314): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.threadPaused+0x32c): undefined reference to `__atomic_store_8' /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(Threads.thr_o): in function `tryWakeupThread': (.text.tryWakeupThread+0x194): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.tryWakeupThread+0x1a8): undefined reference to `__atomic_store_8' /usr/bin/ld: (.text.tryWakeupThread+0x1c4): undefined reference to `__atomic_load_8' (...) /usr/bin/ld: (.text.throwToMsg+0x444): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.throwToMsg+0x458): undefined reference to `__atomic_store_8' /usr/bin/ld: (.text.throwToMsg+0x478): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.throwToMsg+0x490): undefined reference to `__atomic_store_8' /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(SpinLock.thr_o): in function `acquire_spin_lock_slow_path': (.text.acquire_spin_lock_slow_path+0x64): undefined reference to `__atomic_fetch_add_8' /usr/bin/ld: (.text.acquire_spin_lock_slow_path+0x80): undefined reference to `__atomic_fetch_add_8' collect2: error: ld returned 1 exit status `powerpc-linux-gnu-gcc' failed in phase `Linker'. (Exit code: 1) When building hadrian with "./hadrian/build -j", it's possible to pass the necessary "-latomic" with the help of "*.*.ghc.link.opts = -latomic". I assume, for the bootstrap python script, will have to patch either the Haskell sources or the Python script. Adrian
Hi Adrian, This is a problem with your custom GHC (9.0.3). I believe you need to use this patch as well [1], when building your custom GHC. I am surprised this didn't fail during build time. Also, take a look at the patches we have in Debian, there might be others that you need to use as well. [1] https://sources.debian.org/src/ghc/9.0.2-4/debian/patches/latomic-64bit/ Note that "*.*.ghc.link.opts = -latomic" is parsed by hadrian itself, it will not affect how hadrian is built. I haven't tested it but I believe './hadrian/build -j "*.*.ghc.link.opts = -latomic"' will fail as well in your case. Best,
I am trying to figure out now what it takes to build GHC using the LLVM backed on 32-bit PowerPC but it currently doesn't seem to be supported. I am not sure what needs to be patched to enable LLVM code generation for this target, but we will most likely need at least modify the script utils/llvm-targets/gen-data-layout.sh and probably a little more. If enabling LLVM support for a given target is not too involved, we could also look into enabling it for loong64, m68k and sparc64 which also have LLVM backends although the one for m68k is still in development. Adrian
Hi, I finally figured out what the problem is. After realizing that the two-stage build of GHC works without problems, I realized it can be a configuration issue only and, indeed, it is. Looking at /usr/lib/ghc/lib/settings, the default linker is set to gold: "C compiler link flags", "-fuse-ld=gold" Since gold is broken on powerpc and shouldn't really be used anymore since it's basically unmaintained upstream, we must use bfd on powerpc by default. Editing the file and switching back to bfd fixes the problem for me. Now we just need to figure out how to actually set the default linker back to bfd as it was actually explicitly supposed to happen according to debian/rules. This will most likely also unbreak GHC on m68k. Adrian
Good job, Adrian. That's quite a bit of work to track down the issue. Jeff
Hi Jeff, Thanks. In the meantime I filed a bug upstream for this [1]. I will actually open a second bug report since this bug report is about the broken NGC on 32-bit PowerPC which is a different issue. Adrian
Hey Adrian, Great job! I completely missed the fact this needs to be passes to the bindist's configure script as well. You need to edit debian/rules here https://sources.debian.org/src/ghc/9.4.7-5/debian/rules/#L78 and add the following line as well: + EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override I will include that in the next upload. Do we still have to build an unregisterised compiler for powerpc or can we switch back to NCG (https://bugs.debian.org/1060196)?
Hi Ilias, Thanks! It took me forever to figure this out ;-). Yes, that's what I suggested, see my patch in [1]. Great, thank you. I uploaded a patched version to unreleased in the mean time. I have not verified that yet. Please let's stay unregisterised for now and have me verify first whether the NGC has been fixed with 9.6.x or newer. Please let's keep this bug report open and use #1073159 [1] for adding the flag --disable-ld-override to EXTRA_INSTALL_CONFIGURE_FLAGS. Adrian
Hi Ilias,
# rts/include/rts/prof/LDV.h
| Run Ghc CompileHs Stage1: rts/HeapStackCheck.cmm => _build/stage1/rts/build/cmm/HeapStackCheck.debug_o
| Run Ghc CompileHs Stage1: rts/PrimOps.cmm => _build/stage1/rts/build/cmm/PrimOps.p_o
| Run Ghc CompileHs Stage1: rts/Updates.cmm => _build/stage1/rts/build/cmm/Updates.thr_p_o
| Run Ghc CompileHs Stage1: rts/Compact.cmm => _build/stage1/rts/build/cmm/Compact.thr_p_o
| Run Ghc CompileHs Stage1: rts/Exception.cmm => _build/stage1/rts/build/cmm/Exception.o
| Run Ghc CompileHs Stage1: rts/PrimOps.cmm => _build/stage1/rts/build/cmm/PrimOps.debug_o
| Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.debug_p_o
| Run Ghc CompileHs Stage1: rts/HeapStackCheck.cmm => _build/stage1/rts/build/cmm/HeapStackCheck.p_o
| Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.thr_debug_p_o
| Run Ghc CompileHs Stage1: rts/StgMiscClosures.cmm => _build/stage1/rts/build/cmm/StgMiscClosures.debug_o
| Run Ghc CompileHs Stage1: rts/StgMiscClosures.cmm => _build/stage1/rts/build/cmm/StgMiscClosures.p_o
| Run Ghc CompileHs Stage1: rts/ContinuationOps.cmm => _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o
| Run Ghc CompileHs Stage1: rts/Updates.cmm => _build/stage1/rts/build/cmm/Updates.debug_p_o
| Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.thr_p_o
| Run Ghc CompileHs Stage1: rts/Apply.cmm => _build/stage1/rts/build/cmm/Apply.o
| Run Ghc CompileHs Stage1: rts/Exception.cmm => _build/stage1/rts/build/cmm/Exception.debug_o
| Run Ghc CompileHs Stage1: rts/Apply.cmm => _build/stage1/rts/build/cmm/Apply.thr_dyn_o
Command line: _build/stage0/bin/ghc -Wall -Wcompat -hisuf debug_p_hi -osuf debug_p_o -hcsuf debug_p_hc -static -prof -DDEBUG -optc-DDEBUG -hide-all-packages -no-user-package-db '-package-env -' '-
package-db _build/stage1/inplace/package.conf.d' '-this-unit-id rts-1.0.2' -i -i/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/_build/stage1/rts/build -i/home/glaubitz/ghc-deb-9.6.5-new/ghc-
9.6.5/_build/stage1/rts/build/autogen -i/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/rts -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include
-I_build/stage1/rts/build/@FFIIncludeDir@ -I_build/stage1/rts/build/@LibdwIncludeDir@ -Irts/include -Irts/@FFIIncludeDir@ -Irts/@LibdwIncludeDir@ -optP-include -
optP_build/stage1/rts/build/autogen/cabal_macros.h -ghcversion-file=rts/include/ghcversion.h -outputdir _build/stage1/rts/build -fdiagnostics-color=always -Wnoncanonical-monad-instances -optc-Wno-
error=inline -optP-Wno-nonportable-include-path -c rts/ContinuationOps.cmm -o _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o -O2 -H32m -this-unit-id rts -XHaskell98 -no-global-package-db -
package-db=/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/_build/stage1/inplace/package.conf.d -ghcversion-file=rts/include/ghcversion.h -ghcversion-file=rts/include/ghcversion.h -haddock -Irts -
I_build/stage1/rts/build '-DRtsWay="rts_debug_p"' -DFS_NAMESPACE=rts -DCOMPILING_RTS -DPROFILING -Wno-deprecated-flags -Wcpp-undef
===> Command failed with error code: 1
ghc: panic! (the 'impossible' happened)
GHC version 9.6.5:
PPC.Ppr.pprInstr: JMP to ForeignLabel
CallStack (from HasCallStack):
panic, called at compiler/GHC/CmmToAsm/PPC/Ppr.hs:591:30 in ghc:GHC.CmmToAsm.PPC.Ppr
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
Error when running Shake build system:
at want, called at src/Main.hs:124:44 in main:Main
* Depends on: binary-dist-dir
at need, called at src/Rules/BinaryDist.hs:130:9 in main:Rules.BinaryDist
* Depends on: _build/stage1/lib/package.conf.d/rts-1.0.2.conf
at need, called at src/Rules/Register.hs:134:5 in main:Rules.Register
* Depends on: _build/stage1/rts/build/stamp-rts-1.0.2_debug_p
at need, called at src/Rules/Library.hs:144:3 in main:Rules.Library
* Depends on: _build/stage1/rts/build/libHSrts-1.0.2_debug_p.a
at need, called at src/Rules/Library.hs:220:5 in main:Rules.Library
* Depends on: _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o
at cmd', called at src/Builder.hs:387:23 in main:Builder
at cmdArgs, called at src/Builder.hs:540:8 in main:Builder
at cmdArgs, called at src/Builder.hs:564:18 in main:Builder
at cmdArgs, called at src/Builder.hs:564:18 in main:Builder
at error, called at src/Builder.hs:609:13 in main:Builder
* Raised the exception:
Command failed
Build failed.
Adrian