- ghc-devs - Haskell.org

Looking for a recent error reporting change
by Chris Smith 15 Jun '20

15 Jun '20

Hi. In GHC 8.6.5, if I compile a main module that both fails to define `main` and also contains other errors, the other errors are not reported because GHC aborts after realizing that there is no `main`. In GHC 8.10.1, all errors are reported. I'm looking for where this change was made, in the hopes that it's easy to backport to a local branch of GHC 8.6.5. Does anyone know off-hand?

4 4

libgmp dependency on alpine linux binary release
by depsterr 12 Jun '20

12 Jun '20

I apologize if this is the wrong mailing list, however I couldn't find another one that seemed fit. On the official binary release page (https://www.haskell.org/ghc/download_ghc_8_10_1.html) under the x86_64 alpine release it states the following: > Unlike our other binary distributions, this links against the`integer-simple`big-integer backend and therefore does not require`libgmp`. However, ldd shows that it DOES link to gmp: libgmp.so.10 => /lib/libgmp.so.10 (0x7f47f4c94000) Additionally, if gmp is not installed then a number of errors appear: Error relocating /usr/bin/../lib/x86_64-linux-ghc-8.10.1/libHSinteger-gmp-1.0.3.0-ghc8.10.1.so: __gmpn_tdiv_qr: symbol not found Error relocating /usr/bin/../lib/x86_64-linux-ghc-8.10.1/libHSinteger-gmp-1.0.3.0-ghc8.10.1.so: __gmpn_gcd_1: symbol not found Error relocating /usr/bin/../lib/x86_64-linux-ghc-8.10.1/libHSinteger-gmp-1.0.3.0-ghc8.10.1.so: __gmpn_add_1: symbol not found Error relocating /usr/bin/../lib/x86_64-linux-ghc-8.10.1/libHSinteger-gmp-1.0.3.0-ghc8.10.1.so: __gmpn_andn_n: symbol not found Error relocating /usr/bin/../lib/x86_64-linux-ghc-8.10.1/libHSinteger-gmp-1.0.3.0-ghc8.10.1.so: __gmpz_gcdext: symbol not found Error relocating /usr/bin/../lib/x86_64-linux-ghc-8.10.1/libHSinteger-gmp-1.0.3.0-ghc8.10.1.so: __gmpn_lshift: symbol not found Error relocating /usr/bin/../lib/x86_64-linux-ghc-8.10.1/libHSinteger-gmp-1.0.3.0-ghc8.10.1.so: __gmpn_rshift: symbol not found Error relocating /usr/bin/../lib/x86_64-linux-ghc-8.10.1/libHSinteger-gmp-1.0.3.0-ghc8.10.1.so: __gmpn_and_n: symbol not found Error relocating /usr/bin/../lib/x86_64-linux-ghc-8.10.1/libHSinteger-gmp-1.0.3.0-ghc8.10.1.so: __gmpz_powm: symbol not found Error relocating /usr/bin/../lib/x86_64-linux-ghc-8.10.1/libHSinteger-gmp-1.0.3.0-ghc8.10.1.so: __gmpn_mod_1: symbol not found Error relocating /usr/bin/../lib/x86_64-linux-ghc-8.10.1/libHSinteger-gmp-1.0.3.0-ghc8.10.1.so: __gmpn_cmp: symbol not found Error relocating /usr/bin/../lib/x86_64-linux-ghc-8.10.1/libHSinteger-gmp-1.0.3.0-ghc8.10.1.so: __gmpn_add: symbol not found Error relocating /usr/bin/../lib/x86_64-linux-ghc-8.10.1/libHSinteger-gmp-1.0.3.0-ghc8.10.1.so: __gmpn_sub_1: symbol not found Error relocating /usr/bin/../lib/x86_64-linux-ghc-8.10.1/libHSinteger-gmp-1.0.3.0-ghc8.10.1.so: __gmpn_xor_n: symbol not found Error relocating /usr/bin/../lib/x86_64-linux-ghc-8.10.1/libHSinteger-gmp-1.0.3.0-ghc8.10.1.so: __gmpz_clear: symbol not found Error relocating /usr/bin/../lib/x86_64-linux-ghc-8.10.1/libHSinteger-gmp-1.0.3.0-ghc8.10.1.so: __gmpz_invert: symbol not found Either this build isn't configured properly or the text on the release page needs to be edited to reflect this.

1 0

Evac.c
by Simon Peyton Jones 11 Jun '20

11 Jun '20

I'm getting this in HEAD. Should I worry? It says "error"! Simon rts/sm/Evac.c:463:5: error: note: called from here ACQUIRE_SPIN_LOCK(&gen->sync); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 463 | ACQUIRE_SPIN_LOCK(&gen->sync); | ^ In file included from includes/Rts.h:196:0: error: 0, from rts/sm/Evac.c:15: includes/rts/SpinLock.h:43:20: error: warning: inlining failed in call to 'ACQUIRE_SPIN_LOCK': call is unlikely and code size would grow [-Winline] INLINE_HEADER void ACQUIRE_SPIN_LOCK(SpinLock * p) ^~~~~~~~~~~~~~~~~ | 43 | INLINE_HEADER void ACQUIRE_SPIN_LOCK(SpinLock * p) | ^ rts/sm/Evac.c:515:31: error: note: called from here if (new_gen != gen) { ACQUIRE_SPIN_LOCK(&new_gen->sync); } ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 515 | if (new_gen != gen) { ACQUIRE_SPIN_LOCK(&new_gen->sync); } | ^

3 2

Marge Bot repeatedly failing due to stat decreases
by Ryan Scott 08 Jun '20

08 Jun '20

Hello, I've been receiving a flurry of e-mails all weekend about Marge Bot failing to validate a batch on CI. Moreover, the failures appear to be consistent each time. From the most recent one [1]: Unexpected stat failures: /builds/ghc/ghc/tmp/ghctest-mel1y5lo/test spaces/testsuite/tests/perf/compiler/T12150.run T12150 [stat decreased from "x86_64-linux-deb9-hadrian" baseline @ HEAD~6] (optasm) /builds/ghc/ghc/tmp/ghctest-mel1y5lo/test spaces/testsuite/tests/perf/compiler/T12234.run T12234 [stat decreased from "x86_64-linux-deb9-hadrian" baseline @ HEAD~6] (optasm) Where T12150(optasm) compile_time/bytes allocated 75982592.000 (baseline @ HEAD~6) 76945688.000 [decreased, -1.3%] T12234(optasm) compile_time/bytes allocated 82149240.000 (baseline @ HEAD~6) 83109896.000 [decreased, -1.2%] Can something be done about this? It's holding one one of my patches. Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/-/jobs/359994

2 4

Change in ~"backport needed" label convention
by Ben Gamari 04 Jun '20

04 Jun '20

Hi everyone, Recently with the increased rate of GHC releases we have had to handle more concurrent stable branches. In particular, currently we have GHC-8.8.4 and GHC-8.10.2 releases both in flight. It has become clear that our current scheme for tracking backports, the ~"baackport needed" GitLab label, doesn't accomodate multiple concurrent stable branches particularly well. Consequently, I have created a new set of labels which are specific to each release series. For instance, ~"backport needed:8.10" means that the MR needs to be backported to the ghc-8.10 branch. The old ~"backport needed" label has been removed. Please do use these new labels on merge requests to indicate that backporting is needed. Cheers, - Ben

1 0

GHC HEAD windows instability
by Csaba Hruska 03 Jun '20

03 Jun '20

Hello, I built GHC HEAD on windows 10, but some time the build process got stopped due to random crash. But when I restart the build process the error disappears. Is this a known issue? Regards, Csaba *Case A:* *compiler\GHC\Driver\Session.hs:285:1: error: Bad interface file: _build/stage1/lib\x86_64-windows-ghc-8.11.0.20200528\transformers-0.5.6.2\Control\Monad\Trans\Reader.hi _build/stage1/lib\x86_64-windows-ghc-8.11.0.20200528\transformers-0.5.6.2\Control\Monad\Trans\Reader.hi: hGetBuf: invalid argument (Invalid argument) |285 | import Control.Monad.Trans.Reader | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^compiler\GHC\Driver\Session.hs:286:1: error: Bad interface file: _build/stage1/lib\x86_64-windows-ghc-8.11.0.20200528\transformers-0.5.6.2\Control\Monad\Trans\Except.hi _build/stage1/lib\x86_64-windows-ghc-8.11.0.20200528\transformers-0.5.6.2\Control\Monad\Trans\Except.hi: hGetBuf: invalid argument (Invalid argument) |286 | import Control.Monad.Trans.Except | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^compiler\GHC\Driver\Session.hs:288:1: error: Bad interface file: _build/stage1/lib\x86_64-windows-ghc-8.11.0.20200528\base-4.14.0.0\Data\Ord.hi _build/stage1/lib\x86_64-windows-ghc-8.11.0.20200528\base-4.14.0.0\Data\Ord.hi: hGetBuf: invalid argument (Invalid argument) |288 | import Data.Ord | ^^^^^^^^^^^^^^^Error when running Shake build system: at action, called at src\Rules.hs:71:19 in main:Rules at need, called at src\Rules.hs:93:5 in main:Rules* Depends on: _build/stage1/lib/package.conf.d/ghc-8.11.0.20200528.conf at need, called at src\Rules\Register.hs:117:5 in main:Rules.Register* Depends on: _build/stage1/compiler/build/libHSghc-8.11.0.20200528.a at need, called at src\Rules\Library.hs:209:5 in main:Rules.Library* Depends on: _build/stage1/compiler/build/GHC/Driver/Session.o at &%>, called at src\Rules\Compile.hs:77:9 in main:Rules.Compile* Depends on: _build/stage1/compiler/build/GHC/Driver/Session.o _build/stage1/compiler/build/GHC/Driver/Session.hi at cmd', called at src\Builder.hs:291:23 in main:Builder at cmd, called at src\Builder.hs:376:8 in main:Builder* Raised the exception:Development.Shake.cmd, system command failedCommand line: _build/stage0/bin/ghc.exe -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db "-package-db _build/stage1/lib/package.conf.d" "-this-unit-id ghc-8.11.0.20200528" "-package-id Win32-2.6.1.0" "-package-id array-0.5.4.0" "-package-id base-4.14.0.0" "-package-id binary-0.8.7.0" "-package-id bytestring-0.10.9.0" "-package-id containers-0.6.2.1" "-package-id deepseq-1.4.4.0" "-package-id directory-1.3.6.0" "-package-id filepath-1.4.2.1" "-package-id ghc-boot-8.11.0.20200528" "-package-id ghc-boot-th-8.11.0.20200528" "-package-id ghc-heap-8.11.0.20200528" "-package-id ghci-8.11.0.20200528" "-package-id hpc-0.6.1.0" "-package-id integer-gmp-1.0.3.0" "-package-id process-1.6.8.2" "-package-id template-haskell-2.17.0.0" "-package-id time-1.9.3" "-package-id transformers-0.5.6.2" -i -iC:\Users\IEUser\haskell\ghc-whole-program-compiler-project\ghc-wpc\_build\stage1\compiler\build -iC:\Users\IEUser\haskell\ghc-whole-program-compiler-project\ghc-wpc\_build\stage1\compiler\build\autogen -iC:\Users\IEUser\haskell\ghc-whole-program-compiler-project\ghc-wpc\compiler -Iincludes -I_build/stage1/lib -I_build/stage1/compiler/build -I_build/stage1/compiler/build/. -I_build/stage1/compiler/build/../rts/dist/build -Icompiler/. -Icompiler/../rts/dist/build -IC:/Users/IEUser/haskell/ghc-whole-program-compiler-project/ghc-wpc/_build/stage1/lib/x86_64-windows-ghc-8.11.0.20200528/process-1.6.8.2/include -IC:/Users/IEUser/haskell/ghc-whole-program-compiler-project/ghc-wpc/_build/stage1/lib/x86_64-windows-ghc-8.11.0.20200528/time-1.9.3/include -IC:/Users/IEUser/haskell/ghc-whole-program-compiler-project/ghc-wpc/_build/stage1/lib/x86_64-windows-ghc-8.11.0.20200528/Win32-2.6.1.0/include -IC:/Users/IEUser/haskell/ghc-whole-program-compiler-project/ghc-wpc/_build/stage1/lib/x86_64-windows-ghc-8.11.0.20200528/bytestring-0.10.9.0/include -IC:/Users/IEUser/haskell/ghc-whole-program-compiler-project/ghc-wpc/_build/stage1/lib/x86_64-windows-ghc-8.11.0.20200528/base-4.14.0.0/include -IC:/Users/IEUser/haskell/ghc-whole-program-compiler-project/ghc-wpc/_build/stage1/lib/x86_64-windows-ghc-8.11.0.20200528/integer-gmp-1.0.3.0/include -IC:/Users/IEUser/haskell/ghc-whole-program-compiler-project/ghc-wpc/_build/stage1/lib/x86_64-windows-ghc-8.11.0.20200528/rts-1.0/include -I_build/stage1/lib -optc-I_build/stage1/lib -optP-include -optP_build/stage1/compiler/build/autogen/cabal_macros.h -optP-DHAVE_INTERNAL_INTERPRETER -optP-DINTEGER_GMP -outputdir _build/stage1/compiler/build -Wnoncanonical-monad-instances -optc-Wno-error=inline -c compiler/GHC/Driver/Session.hs -o _build/stage1/compiler/build/GHC/Driver/Session.o -O0 -H64m -Wall -Wno-name-shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monoid-instances -this-unit-id ghc -XHaskell2010 -XNoImplicitPrelude -ghcversion-file=C:/Users/IEUser/haskell/ghc-whole-program-compiler-project/ghc-wpc/_build/stage1/lib/ghcversion.h -optc-DTHREADED_RTS -Wno-deprecated-flags -Wcpp-undefExit code: 1Stderr and Stdout:compiler\GHC\Driver\Session.hs:285:1: error: Bad interface file: _build/stage1/lib\x86_64-windows-ghc-8.11.0.20200528\transformers-0.5.6.2\Control\Monad\Trans\Reader.hi _build/stage1/lib\x86_64-windows-ghc-8.11.0.20200528\transformers-0.5.6.2\Control\Monad\Trans\Reader.hi: hGetBuf: invalid argument (Invalid argument) |285 | import Control.Monad.Trans.Reader | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^compiler\GHC\Driver\Session.hs:286:1: error: Bad interface file: _build/stage1/lib\x86_64-windows-ghc-8.11.0.20200528\transformers-0.5.6.2\Control\Monad\Trans\Except.hi _build/stage1/lib\x86_64-windows-ghc-8.11.0.20200528\transformers-0.5.6.2\Control\Monad\Trans\Except.hi: hGetBuf: invalid argument (Invalid argument) |286 | import Control.Monad.Trans.Except | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^compiler\GHC\Driver\Session.hs:288:1: error: Bad interface file: _build/stage1/lib\x86_64-windows-ghc-8.11.0.20200528\base-4.14.0.0\Data\Ord.hi _build/stage1/lib\x86_64-windows-ghc-8.11.0.20200528\base-4.14.0.0\Data\Ord.hi: hGetBuf: invalid argument (Invalid argument) |288 | import Data.Ord | ^^^^^^^^^^^^^^^* *Case B:* *Access violation in generated code when writing 0x0 Attempting to reconstruct a stack trace... Frame Code address * 0x3eadb00 0x3063b36 C:\Users\IEUser\haskell\ghc-whole-program-compiler-project\ghc-wpc\_build\stage0\bin\ghc.exe+0x2c63b36 * 0x3eadb08 0x2e12c89 C:\Users\IEUser\haskell\ghc-whole-program-compiler-project\ghc-wpc\_build\stage0\bin\ghc.exe+0x2a12c89 * 0x3eadb10 0x4 * 0x3eadb18 0x7c411e1 * 0x3eadb20 0x3665e20 C:\Users\IEUser\haskell\ghc-whole-program-compiler-project\ghc-wpc\_build\stage0\bin\ghc.exe+0x3265e20 * 0x3eadb28 0x5c2abd0 * 0x3eadb30 0x9ec8010 * 0x3eadb38 0x3fc3c70 * 0x3eadb40 0x5c00320033006d * 0x3eadb48 0x33004d004d0049 * 0x3eadb50 0x4c0044002e0032 * 0x3eadb58 0x4cError when running Shake build system: at action, called at src\Rules.hs:71:19 in main:Rules at need, called at src\Rules.hs:93:5 in main:Rules* Depends on: _build/stage1/lib/package.conf.d/directory-1.3.6.0.conf at apply1, called at src\Development\Shake\Internal\Rules\Oracle.hs:159:32 in shake-0.18.5-JIltN70Z6uA8zMbpBJImj0:Development.Shake.Internal.Rules.Oracle* Depends on: OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Library, pkgName = "directory", pkgPath = "libraries/directory"}, way = v})) at need, called at src\Hadrian\Oracles\Cabal\Rules.hs:53:9 in main:Hadrian.Oracles.Cabal.Rules* Depends on: _build/stage1/libraries/directory/setup-config at need, called at src\Rules\Library.hs:214:18 in main:Rules.Library* Depends on: _build/stage1/libraries/time/build/HStime-1.9.3.o at need, called at src\Rules\Library.hs:165:5 in main:Rules.Library* Depends on: _build/stage1/libraries/time/build/Data/Time/Format/Format/Class.o at &%>, called at src\Rules\Compile.hs:77:9 in main:Rules.Compile* Depends on: _build/stage1/libraries/time/build/Data/Time/Format/Format/Class.o _build/stage1/libraries/time/build/Data/Time/Format/Format/Class.hi at cmd', called at src\Builder.hs:291:23 in main:Builder at cmd, called at src\Builder.hs:376:8 in main:Builder* Raised the exception:Development.Shake.cmd, system command failedCommand line: _build/stage0/bin/ghc.exe -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db "-package-db _build/stage1/lib/package.conf.d" "-this-unit-id time-1.9.3" "-package-id Win32-2.6.1.0" "-package-id base-4.14.0.0" "-package-id deepseq-1.4.4.0" -i -iC:\Users\IEUser\haskell\ghc-whole-program-compiler-project\ghc-wpc\_build\stage1\libraries\time\build -iC:\Users\IEUser\haskell\ghc-whole-program-compiler-project\ghc-wpc\_build\stage1\libraries\time\build\autogen -iC:\Users\IEUser\haskell\ghc-whole-program-compiler-project\ghc-wpc\libraries\time\lib -Iincludes -I_build/stage1/lib -I_build/stage1/libraries/time/build -I_build/stage1/libraries/time/build/lib/include -Ilibraries/time/lib/include -IC:/Users/IEUser/haskell/ghc-whole-program-compiler-project/ghc-wpc/_build/stage1/lib/x86_64-windows-ghc-8.11.0.20200528/Win32-2.6.1.0/include -IC:/Users/IEUser/haskell/ghc-whole-program-compiler-project/ghc-wpc/_build/stage1/lib/x86_64-windows-ghc-8.11.0.20200528/bytestring-0.10.9.0/include -IC:/Users/IEUser/haskell/ghc-whole-program-compiler-project/ghc-wpc/_build/stage1/lib/x86_64-windows-ghc-8.11.0.20200528/base-4.14.0.0/include -IC:/Users/IEUser/haskell/ghc-whole-program-compiler-project/ghc-wpc/_build/stage1/lib/x86_64-windows-ghc-8.11.0.20200528/integer-gmp-1.0.3.0/include -IC:/Users/IEUser/haskell/ghc-whole-program-compiler-project/ghc-wpc/_build/stage1/lib/x86_64-windows-ghc-8.11.0.20200528/rts-1.0/include -I_build/stage1/lib -optc-I_build/stage1/lib -optP-include -optP_build/stage1/libraries/time/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/time/build -Wnoncanonical-monad-instances -optc-Wno-error=inline -c libraries/time/lib/Data/Time/Format/Format/Class.hs -o _build/stage1/libraries/time/build/Data/Time/Format/Format/Class.o -O0 -H64m -Wall -fwarn-tabs -XHaskell2010 -XRank2Types -XDeriveDataTypeable -XStandaloneDeriving -XCPP -ghcversion-file=C:/Users/IEUser/haskell/ghc-whole-program-compiler-project/ghc-wpc/_build/stage1/lib/ghcversion.h -Wno-deprecated-flagsExit code: 11Stderr and Stdout:Access violation in generated code when writing 0x0 Attempting to reconstruct a stack trace... Frame Code address * 0x3eadb00 0x3063b36 C:\Users\IEUser\haskell\ghc-whole-program-compiler-project\ghc-wpc\_build\stage0\bin\ghc.exe+0x2c63b36 * 0x3eadb08 0x2e12c89 C:\Users\IEUser\haskell\ghc-whole-program-compiler-project\ghc-wpc\_build\stage0\bin\ghc.exe+0x2a12c89 * 0x3eadb10 0x4 * 0x3eadb18 0x7c411e1 * 0x3eadb20 0x3665e20 C:\Users\IEUser\haskell\ghc-whole-program-compiler-project\ghc-wpc\_build\stage0\bin\ghc.exe+0x3265e20 * 0x3eadb28 0x5c2abd0 * 0x3eadb30 0x9ec8010 * 0x3eadb38 0x3fc3c70 * 0x3eadb40 0x5c00320033006d * 0x3eadb48 0x33004d004d0049 * 0x3eadb50 0x4c0044002e0032 * 0x3eadb58 0x4c*

2 1

GHCs dependencies (libraries) and maintenance
by Moritz Angermann 01 Jun '20

01 Jun '20

Hi there! so this comes up periodically, and I think we need to discuss this. This is not related to anything right now, so if you wonder if I'm writing this because of something that just happened that I'm involved and you might have missed something, you probably did not. It came up on the #ghc IRC channel a few day ago. GHC depends on quite a set of libraries, and ships those in releases. When ever a new GHC release is cut, all these dependencies need to be on hackage and have release versions. We do not want to produce a GHC release which depends on in-flight packages. In-flight might happen for example due to GHC having to patch dependencies to make them work with HEAD. Everyone who maintains any kind of software online, knows that maintenance can be a drag, and then life happens, and what not. There are many very responsive maintainers and we all owe them a grate amount of gratitude towards their relentless work, keeping those libraries up to date and responding to questions, patches, ... I therefore would like to float the following idea to make the GHC release processes a bit more reliable. GHCHQ (that is those in charge of producing GHC releases for us all), are made co-maintainers on each library GHC depends on, to guarantee that GHC can move forward in the worst of circumstances. Now I would hope that in almost all cases GHCHQ would never have to maintain any of the dependencies actively, they deal with GHC already, so let's try to keep it that way. However GHCHQ can, after a 14day notification period, exercise the co-maintainance and cut releases (and upload them to hackage), should the maintainer not be able to do so on his own for various reasons. I'd like to see this as an insurance policy for GHC continuous development. The only alternative that I see would be that GHCHQ starts forking dependencies and initiates the hackage maintainer takeover protocol, which will cause additional delays, and incurs an extra burden on the GHC maintainers. I hope we can all agree that libraries that end up being dependencies of GHC should be held in high regards and form the very foundation GHC is built upon. As such it should be an honour to have GHCHQ being a co-maintainer for ones library, as it signifies that importances of the library for the continuous development of GHC. Again I don't expect much to change, except for GHCHQ becoming co-maintainers for libraries GHC depends on. The baseline expectation will remain as it is. However we will have ensured the frictionless development of GHC going forward. Cheers, Moritz

4 4

[hadrian] Use LLVM for test and validate target
by Stefan Schulze Frielinghaus 30 May '20

30 May '20

Hi all, Is it possible to force Hadrian to use the LLVM code generator for the test and validate targets? For example, while using the following commands it seems to me that only the native code generator (if available) is used: $ ./hadrian/build -c -j --flavour=quick-llvm test $ ./hadrian/build -c -j --flavour=validate Cheers, Stefan

2 1

STG/CMM questions
by Daneel Yaitskov 29 May '20

29 May '20

Hi, There are 2 questions: 1. How to decipher myThreadId implementation in STG? What is the principle behind STG version? Is it matching first field from TSO by type? "id" is not mentioned anyhow and there is no offset to id field. The whole TSO struct is just mentioned. emitAssign and CmmLocal are used everywhere, so they don't express logic particular to myThreadId function. was: return tso->id; now: currentTSOExpr = CmmReg currentTSOReg MyThreadIdOp -> \[] -> opAllDone $ \[res] -> do emitAssign (CmmLocal res) currentTSOExpr 2. Cmm macro for new TSO field is not found. I added to deriveConstants/Main.hs: ,closureField C "StgTSO" "trace_id" TSO.h: typedef struct StgTSO_ { ... StgClosure* trace_id; PrimsOps.cmm: gcptr p; p = StgTSO_trace_id(CurrentTSO); Linking error happens after make clean && ./boot && ./configure && make -j8 so I guess macros is not defined. Looks like such macros are not written to any file and it is hard to grep them. collect2: error: ld returned 1 exit status `cc' failed in phase `Linker'. (Exit code: 1) utils/iserv/ghc.mk:101: recipe for target 'utils/iserv/stage2/build/tmp/ghc-iserv' failed make[1]: *** [utils/iserv/stage2/build/tmp/ghc-iserv] Error 1 /home/dan/demo/haskell/compiler/ghc/rts/dist/build/libHSrts_thr_p.a(PrimOps.thr_p_o):function stg_getAdamTraceIdzh: error: undefined reference to 'StgTSO_trace_id' /home/dan/demo/haskell/compiler/ghc/rts/dist/build/libHSrts_thr_p.a(PrimOps.thr_p_o):function stg_getAdamTraceIdzh: error: undefined reference to 'n' collect2: error: ld returned 1 exit status `cc' failed in phase `Linker'. (Exit code: 1) utils/iserv/ghc.mk:105: recipe for target 'utils/iserv/stage2_p/build/tmp/ghc-iserv-prof' failed make[1]: *** [utils/iserv/stage2_p/build/tmp/ghc-iserv-prof] Error 1 Makefile:123: recipe for target 'all' failed -- Best regards, Daniil Iaitskov

2 1

Re: keepAlive# primop
by Ben Gamari 27 May '20

27 May '20

Ccing ghc-devs@ since this discussion is something of general interest to the community. Sylvain Henry <sylvain(a)haskus.fr> writes: > Simon, Ben, > > I've been reading and thinking about `readRW#` issues which are very > related to issues we have with `keepAlive#` primop. > > To recap, the problem is that we want some transformations (that Simon > has listed in [1]) to consider: > > ``` > case runRW# f of ... > > case keepAlive# k a of ... > ``` > > as if they were really: > > ``` > case f realWorld# of ... > > case a of ... > ``` > > BUT without breaking the semantics of runRW# and keepAlive#. > > I have been thinking about a solution that I have described on the wiki: > https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/with-combinator#option-… > > The idea is to keep a set of variable names in each Core case-expression > that are kept alive during the evaluation of the scrutinee. > > I think it would work very nicely with your `newState#` primop described > in [2], both for `runST` and for `unsafeDupablePerformIO` (details on > the wiki). > > It requires a little more upfront work to adapt the code involving > case-expressions. But it will force us to review all transformations to > check if they are sound when keep-alive sets are not empty, which we > would have to do anyway if we implemented another option. We could start > by disabling transformations involving non-empty keep-alive sets and > iterate to enable the sound ones. > > I would like your opinions on the approach. I may have totally missed > something. Thanks for writing this down! Indeed it is an interesting idea. However, as expressed on IRC, I wonder whether this problem rises to the level where it warrants an adaptation to our Core representation. It feels a bit like the tail is wagging the dog here, especially given how the "tail" here merely exists to support FFI. That being said, this is one of the few options which remain on the table that doesn't require changes to user code. Moreover, the applicability to runRW# is quite intriguing. Another (admittedly, more ad-hoc) option that would avoid modifying Core would be to teach the simplifier about the class of "continuation-passing" primops (e.g. `keepAlive#` and `runRW#`), allowing it to push case analyses into the continuation argument. That is, case keepAlive# x expr of pat -> rhs ~> keepAlive# x (case expr of pat -> rhs) Of course, doing this is a bit tricky since one must rewrite the application of keepAlive# to ensure that the resulting application is well-typed. Admittedly, this doesn't help the runRW# case (although this could presumably be accommodated by touch#'ing the final state token in the runRW# desugaring emitted by CorePrep). On the whole, I'm not a fan of this ad-hoc option. It increases the complexity of the simplifier all to support a single operation. By comparison, the Core extension looks somewhat appealing. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/with-combinator#option-… P.S. A minor note: the keepAlive# "pseudo-instruction" mentioned on the Wiki [1] is precisely the touch# operation we have today.

3 2