[Git][ghc/ghc][wip/angerman/out-of-range-reloc] 12 commits: gitlab-ci: Allow ARMv7 job to fail

Moritz Angermann gitlab at gitlab.haskell.org
Thu Jun 4 08:56:28 UTC 2020



Moritz Angermann pushed to branch wip/angerman/out-of-range-reloc at Glasgow Haskell Compiler / GHC


Commits:
cb5c31b5 by Ben Gamari at 2020-06-03T17:55:04-04:00
gitlab-ci: Allow ARMv7 job to fail

Due to #18298.

- - - - -
32a4ae90 by John Ericson at 2020-06-04T04:34:42-04:00
Clean up boot vs non-boot disambiguating types

We often have (ModuleName, Bool) or (Module, Bool) pairs for "extended"
module names (without or with a unit id) disambiguating boot and normal
modules. We think this is important enough across the compiler that it
deserves a new nominal product type. We do this with synnoyms and a
functor named with a `Gen` prefix, matching other newly created
definitions.

It was also requested that we keep custom `IsBoot` / `NotBoot` sum type.
So we have it too. This means changing many the many bools to use that
instead.

Updates `haddock` submodule.

- - - - -
c05756cd by Niklas Hambüchen at 2020-06-04T04:35:24-04:00
docs: Add more details on InterruptibleFFI.

Details from https://gitlab.haskell.org/ghc/ghc/issues/8684
and https://github.com/takano-akio/filelock/pull/7#discussion_r280332430

- - - - -
1b975aed by Andrew Martin at 2020-06-04T04:36:03-04:00
Allow finalizeForeignPtr to be called on FinalPtr/PlainPtr.

MR 2165 (commit 49301ad6226d9a83d110bee8c419615dd94f5ded) regressed
finalizeForeignPtr by throwing exceptions when PlainPtr was encounterd.
This regression did not make it into a release of GHC. Here, the
original behavior is restored, and FinalPtr is given the same treatment
as PlainPtr.

- - - - -
2bd3929a by Luke Lau at 2020-06-04T04:36:41-04:00
Fix documentation on type families not being extracted

It looks like the location of the Names used for CoAxioms on type
families are now located at their type constructors. Previously, Docs.hs
thought the Names were located in the RHS, so the RealSrcSpan in the
instanceMap and getInstLoc didn't match up. Fixes #18241

- - - - -
6735b9d9 by Ben Gamari at 2020-06-04T04:37:21-04:00
GHC.Hs.Instances: Compile with -O0

This module contains exclusively Data instances, which are going to be
slow no matter what we do. Furthermore, they are incredibly slow to
compile with optimisation (see #9557). Consequently we compile this with
-O0.  See #18254.

- - - - -
c330331a by nineonine at 2020-06-04T04:37:59-04:00
Add test for #17669

- - - - -
cab684f0 by Ben Gamari at 2020-06-04T04:38:36-04:00
rts: Add Windows-specific implementation of rtsSleep

Previously we would use the POSIX path, which uses `nanosleep`. However,
it turns out that `nanosleep` is provided by `libpthread` on Windows. In
general we don't want to incur such a dependency. Avoid this by simply
using `Sleep` on Windows.

Fixes #18272.

- - - - -
ad44b504 by Ben Gamari at 2020-06-04T04:38:36-04:00
compiler: Disable use of process jobs with process < 1.6.9

Due to #17926.

- - - - -
c1be6601 by Moritz Angermann at 2020-06-04T04:56:24-04:00
[linker] Fix out of range relocations.

mmap may return address all over the place. mmap_next will ensure we get
the next free page after the requested address.

This is especially important for linking on aarch64, where the memory model with PIC
admits relocations in the +-4GB range, and as such we can't work with
arbitrary object locations in memory.

Of note: we map the rts into process space, so any mapped objects must
not be ouside of the 4GB from the processes address space.

- - - - -
9296e593 by Moritz Angermann at 2020-06-04T04:56:24-04:00
Cleanup

- - - - -
72c57cf8 by Moritz Angermann at 2020-06-04T04:56:24-04:00
Cleanup (2)

- - - - -


30 changed files:

- .gitlab-ci.yml
- compiler/GHC.hs
- compiler/GHC/Driver/Backpack.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Driver/MakeFile.hs
- compiler/GHC/Driver/Types.hs
- compiler/GHC/Hs/ImpExp.hs
- compiler/GHC/Hs/Instances.hs
- compiler/GHC/HsToCore/Docs.hs
- compiler/GHC/HsToCore/Monad.hs
- compiler/GHC/HsToCore/Usage.hs
- compiler/GHC/Iface/Load.hs
- compiler/GHC/Iface/Recomp.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/Header.hs
- compiler/GHC/Rename/Env.hs
- compiler/GHC/Rename/Names.hs
- compiler/GHC/Runtime/Linker.hs
- compiler/GHC/SysTools/Process.hs
- compiler/GHC/Tc/Module.hs
- compiler/GHC/Tc/Types.hs
- compiler/GHC/Tc/Utils/Backpack.hs
- compiler/GHC/Tc/Utils/Monad.hs
- compiler/GHC/Unit/Module.hs
- compiler/GHC/Unit/Module/Location.hs
- compiler/GHC/Unit/Types.hs
- docs/users_guide/exts/ffi.rst
- ghc/Main.hs
- libraries/base/GHC/ForeignPtr.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/8c3c316cdd220b8382535a3f2a255107596f7d43...72c57cf86dd1c797e0ffb0b2f286e3c7294b81b9

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/8c3c316cdd220b8382535a3f2a255107596f7d43...72c57cf86dd1c797e0ffb0b2f286e3c7294b81b9
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20200604/0b858958/attachment-0001.html>


More information about the ghc-commits mailing list