- ghc-devs - Haskell.org

Contributing packages?
by Dominick Samperi 04 May '23

04 May '23

I just tried to upload a new Haskell package and ran into some difficulties. If I just try to upload, it fails and says I need to contact somebody in the trustees group to be added to the Uploaders group. If I try to upload a package candidate instead, it says Forbidden, No access for this resource. The Uploading packages help page is not very helpful. Also, I have a Hackage account and I can get to the account management page, and generate an auth key, but I don't know what I can do with that. It seems the package candidate feature is the way to go, since direct uploads are irreversible and more difficult to manage. Any tips would be appreciated. Thanks, Dominick

1 0

Build of GHC 9.6 fails when the build directory is not a child of the source directory
by Viktor Dukhovni 30 Apr '23

30 Apr '23

For some time now I'd been unable to build GHC 9.6 from source. The reason turned out to be that my hadrian command-line selected an explicit build directory that was not an immediate child of the source directory (default it seems is "_build"). With the source tree under "$HOME/dev/ghc/", the hardrian command $ hadrian/build -V -V -o"$HOME/dev/buildghc" --docs=no-sphinx binary-dist-dir after building stage0, and running "configure" in libraries/base, reports an error finding HsFFI.h: Reading parameters from $HOME/dev/buildghc/stage1/libraries/base/build/base.buildinfo /usr/bin/cc '-fuse-ld=gold' /tmp/2303653-4.c -o /tmp/2303653-5 '-D__GLASGOW_HASKELL__=906' \ '-Dlinux_BUILD_OS=1' \ '-Dx86_64_BUILD_ARCH=1' \ '-Dlinux_HOST_OS=1' \ '-Dx86_64_HOST_ARCH=1' \ -I$HOME/dev/buildghc/stage1/libraries/base/build/autogen \ -I$HOME/dev/buildghc/stage1/libraries/base/build/include \ -Ilibraries/base/include \ -Ilibraries/base \ -I/usr/include \ -I$HOME/dev/buildghc/stage1/inplace/../../..//libraries/ghc-bignum/include/ \ -I$HOME/dev/buildghc/stage1/libraries/ghc-bignum/build/include/ \ -I$HOME/dev/buildghc/stage1/inplace/../../..//libraries/ghc-bignum/include \ -I$HOME/dev/buildghc/stage1/libraries/ghc-bignum/build/include \ -I$HOME/dev/buildghc/stage1/inplace/../../..//rts/include \ -I$HOME/dev/buildghc/stage1/rts/build/include \ '-I$HOME/dev/buildghc/stage1/inplace/../../..//rts/@FFIIncludeDir@' \ '-I$HOME/dev/buildghc/stage1/rts/build/@FFIIncludeDir@' \ '-I$HOME/dev/buildghc/stage1/inplace/../../..//rts/@LibdwIncludeDir@' \ '-I$HOME/dev/buildghc/stage1/rts/build/@LibdwIncludeDir@' \ -L$HOME/dev/buildghc/stage1/inplace/../libraries/ghc-bignum/build \ -L$HOME/dev/buildghc/stage1/inplace/../libraries/ghc-prim/build \ -L$HOME/dev/buildghc/stage1/inplace/../rts/build -iquote \ $HOME/dev/ghc/libraries/base \ '-fuse-ld=gold' There are two issues to note here: - "hadrian" fails to substitute @FFIIncludeDir@ and @LibdwIncludeDir@. This used to be handled by "configure", but the job of turning "rts.cabal.in" into "rts.cabal" seems to have been reassigned to "hadrian". - With the build output directory a sibling rather than a child of the source tree, the path to "rts/include" is not constructed correctly. The path: -I$HOME/dev/buildghc/stage1/inplace/../../..//rts/include should have been: -I$HOME/dev/buildghc/stage1/inplace/../../../ghc/rts/include Switching to the default path proved to be a viable work-around, but perhaps other choices should also work. -- Viktor.

2 2

does llvm 16 work with ghc 9.6.1 ?
by George Colpitts 25 Apr '23

25 Apr '23

Hi Does anybody know if llvm 16 works with ghc 9.6.1 ? Thanks George

2 4

GHC 9.6.1 rejects previously working code
by Harendra Kumar 25 Apr '23

25 Apr '23

The following code compiles with older compilers but does not compile with GHC 9.6.1: {-# LANGUAGE KindSignatures #-} module A () where import Control.Monad.IO.Class import Control.Monad.Trans.Class data T (m :: * -> *) a = T instance Functor (T m) where fmap f T = undefined instance Applicative (T m) where pure = undefined (<*>) = undefined instance MonadIO m => Monad (T m) where return = pure (>>=) = undefined instance MonadTrans T where lift = undefined It fails with the following error: xx.hs:20:10: error: [GHC-39999] • Could not deduce ‘MonadIO m’ arising from the head of a quantified constraint arising from the superclasses of an instance declaration from the context: Monad m bound by a quantified context at xx.hs:20:10-21 Possible fix: add (MonadIO m) to the context of a quantified context • In the instance declaration for ‘MonadTrans T’ | 20 | instance MonadTrans T where | ^^^^^^^^^^^^ What is the correct resolution for this? -harendra

4 4

[Haskell] [ANNOUNCE] GHC 9.4.5 released
by Zubin Duggal 18 Apr '23

18 Apr '23

The GHC developers are happy to announce the availability of GHC 9.4.5. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.4.5). Download Page: https://www.haskell.org/ghc/download_ghc_9.4.5.html Blog Post: https://www.haskell.org/ghc/blog/20230418-ghc-9.4.5-released.html This release is primarily a bugfix release addressing a few issues found in 9.4.4. These include: * Fixes for a number of bug fixes in the simplifier (#22623, #22718, #22913, 22695, #23184, #22998, #22662, #22725). * Many bug fixes to the non-moving and parallel GCs (#22264, #22327, #22926, #22927, #22929, #22930, #17574, #21840, #22528) * A fix a bug with the alignment of RTS data structures that could result in segfaults when compiled with high optimisation settings on certain platforms (#22975 , #22965). * Bumping `gmp-tarballs` to a version which doesn't use the reserved `x18` register on AArch64/Darwin systems, and also has fixes for CVE-2021-43618 (#22497, #22789). * A number of improvements to recompilation avoidance with multiple home units (#22675, #22677, #22669, #22678, #22679, #22680) * Fixes for regressions in the typechecker and constraint solver (#22647, #23134, #22516, #22743) * Easier installation of binary distribution on MacOS platforms by changing the installation Makefile to remove the quarantine attribute when installing. * ... and many more. See the [release notes] for a full accounting. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.4.5/docs/html/users_guide/9.4.5-notes.…

1 0

Performance of small allocations via prim ops
by Harendra Kumar 12 Apr '23

12 Apr '23

I was looking at the RTS code for allocating small objects via prim ops e.g. newByteArray# . The code looks like: stg_newByteArrayzh ( W_ n ) { MAYBE_GC_N(stg_newByteArrayzh, n); payload_words = ROUNDUP_BYTES_TO_WDS(n); words = BYTES_TO_WDS(SIZEOF_StgArrBytes) + payload_words; ("ptr" p) = ccall allocateMightFail(MyCapability() "ptr", words); We are making a foreign call here (ccall). I am wondering how much overhead a ccall adds? I guess it may have to save and restore registers. Would it be better to do the fast path case of allocating small objects from the nursery using cmm code like in stg_gc_noregs? -harendra

5 12

[ANNOUNCE] GHC 9.6.1 is now available
by Ben Gamari 02 Apr '23

02 Apr '23

The GHC team is very pleased to announce the availability of GHC 9.6.1. As usual, binaries and source distributions are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.6.1/ Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to WebAssembly and JavaScript. This is an important step towards robust support for compiling Haskell to the Web, but there are a few caveats to be aware of in the 9.6 series: - Both the Javascript and WebAssembly backends are still at an early stage of development and are present in this release as a technology preview - Using GHC as a cross-compiler is not as easy as we would like it to be; in particular, there are challenges related to Template Haskell - GHC is not yet run-time retargetable; a given GHC binary targets exactly one platform, and both WebAssembly and JavaScript are considered platforms for this purpose. Cross-compilers must be built from source by their users We hope to lift all of these limitations in future releases. Additionally, 9.6.1 includes: - Significant latency improvements in the non-moving garbage collector - Efficient runtime support for delimited continuations - Improvements in compiler error messages - Numerous improvements in the compiler's memory usage See the [release notes] for a comprehensive accounting of changes in this release. As always, one can find a migration guide to aid in transitioning from older releases on the [GHC Wiki][migration-guide]. We have also recently started extending our release process to cover a wider set of Linux distributions. In particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions which cover RedHat-derivative and distributions using older glibc releases (namely 2.27), respectively. Thanks to everyone who has contributed code, documentation, testing, and tickets to this release process. As this release represents upstream GHC's first step towards supporting web targets, we are very excited to have this release out the door! Cheers, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/ [migration-guide]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6 [release notes]: https://downloads.haskell.org/ghc/9.6.1/docs/users_guide/9.6.1-notes.html

3 2

GHC 9.2.7 on FreeBSD - HSC2HS_EXTRA issue
by Martin Baulig 30 Mar '23

30 Mar '23

Hello, I am a FreeBSD user, running FreeBSD 13.1 with Clang 13 and GCC 12.2, and still fairly new to the Haskell Platform. When I tried to upgrade a hobby project to Stackage's latest LTS 20.15, I realized that neither the GHC 9.2.6 nor the GHC 9.2.7 binary packages from GHCUP work anymore. There are two issues - and I wrote a detailed article about my investigation on Medium: https://medium.com/@martin.baulig/ghc-9-2-7-on-freebsd-22afab71c715 The first one is a trivial one-line change - in hadrian/src/Rules/BinaryDist.hs, we need to change > ( "HSC2HS_EXTRA=\"" <> unwords ccArgs <> unwords ldFlags <> "\"" into > ( "HSC2HS_EXTRA=\"" <> unwords (ccArgs <> ldFlags) <> "\"" Otherwise, this will break when both ccArgs and ldFlags are non-empty: > HSC2HS_EXTRA="--cflag=--target=x86_64-portbld-freebsd--lflag=--target=x86_64-portbld-freebsd --lflag=-fuse-ld=lld" Unfortunately, this is not quite it just yet. The problem is that Clang supports the --target= argument, but GCC does not - and it looks like Cabal insists on always invoking hsc2hs with an explicit --cc= argument. Overriding that in ~/.cabal/config doesn't work either - because then Cabal passes "-pgmc /usr/bin/cc" to GHC, but no "-pgma" and GHC tries to invoke GCC for assembling with a Clang-only argument. I am a bit lost here now about what the correct path forward is, but would very much like to help fixing this problem, so I created an account on gitlab.haskell.org to report this issue, but got a message saying that it is awaiting admin approval. Looking a bit further in the documentation for new contributors, I saw a comment suggesting I should post on this mailing list and ask for approval. Could an admin please have a look at that? My user name is my last name in lowercase, baulig. Looking forward to hear back from you, Martin

2 3

Windows/R issue with FFI
by Dominick Samperi 30 Mar '23

30 Mar '23

Hello, FFI code that used to work now fails under Windows (still seems to work under Ubuntu), and I wonder if anybody has seen anything like this and can provide some pointers... The code uses FFI to fetch information from the R side like R_NilValue, using something like this; -- Fetch R's R_NilValue... foreign import ccall unsafe "&R_NilValue" r_NilValue_ptr :: Ptr R_EXP r_NilValue :: IO R_EXP r_NilValue = peek r_NilValue_ptr rNilValue1 :: IO REXP rNilValue1 = do x <- r_NilValue traceShow("addr=",x) extREXP x Under Windows the address displayed is obviously bad, and this causes the app to crash. This does not happen under Linux (Ubuntu). Now, replace the line containing peek with r_NilValue = trace "PEEK" peek r_NilValue_ptr The address is now valid! It seems that adding the trace "PEEK" adds some delay and somehow resolves the problem. This problem is intermittent, so it is hard to come up with a simple example that fails every time. A little background: R_NilValue is a pointer to a SEXP that is not initialized until an embedded instance of R is initialized, and the code above is not triggered until this happens. Perhaps there is a race condition between the time R initializes itself and Haskell performs the peek? I don't think R_NilValue is garbage collected once initialized. Any tips would be appreciated. Dominick

3 6

Understanding how warnings on unused functions work
by Razetime 27 Mar '23

27 Mar '23

This message is related to a feature in the futhark compiler <https://github.com/diku-dk/futhark/issues/550>, which is a language with a similar module system. I am trying to create a tool to detect unused top-level functions in Futhark, and I have been looking in the ghc codebase to find out how it does so. So far I have found these areas: 1. warning flag <https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Driver/Flags.…> 2. WarnUnusedTopBinds <https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Rename/Utils.…> The project is a bit too big for my machine to take, so HLS is not helping me with finding where the computation of unused bindings (specifically functions) is done. I would like some help with finding where ghc does this computation, and maybe some help with the naming conventions of the code. Thanks in advance.

2 1