[Git][ghc/ghc][wip/T22130] 26 commits: nonmoving: Fix race in marking of blackholes
Matthew Pickering (@mpickering)
gitlab at gitlab.haskell.org
Mon Jan 2 23:39:08 UTC 2023
Matthew Pickering pushed to branch wip/T22130 at Glasgow Haskell Compiler / GHC
Commits:
18d2acd2 by Ben Gamari at 2022-12-23T19:09:30-05:00
nonmoving: Fix race in marking of blackholes
We must use an acquire-fence when marking to ensure that the indirectee
is visible.
- - - - -
11241efa by Ben Gamari at 2022-12-23T19:09:30-05:00
nonmoving: Fix segment list races
- - - - -
602455c9 by Ben Gamari at 2022-12-23T19:09:30-05:00
nonmoving: Use atomic when looking at bd->gen
Since it may have been mutated by a moving GC.
- - - - -
9d63b160 by Ben Gamari at 2022-12-23T19:09:30-05:00
nonmoving: Eliminate race in bump_static_flag
To ensure that we don't race with a mutator entering a new CAF we take
the SM mutex before touching static_flag. The other option here would be
to instead modify newCAF to use a CAS but the present approach is a bit
safer.
- - - - -
26837523 by Ben Gamari at 2022-12-23T19:09:30-05:00
nonmoving: Ensure that mutable fields have acquire barrier
- - - - -
8093264a by Ben Gamari at 2022-12-23T19:09:30-05:00
nonmoving: Fix races in collector status tracking
Mark a number of accesses to do with tracking of the status of the
concurrent collection thread as atomic. No interesting races here,
merely necessary to satisfy TSAN.
- - - - -
387d4fcc by Ben Gamari at 2022-12-23T19:09:30-05:00
nonmoving: Make segment state updates atomic
- - - - -
543cae00 by Ben Gamari at 2022-12-23T19:09:30-05:00
nonmoving: Refactor update remembered set initialization
This avoids a lock inversion between the storage manager mutex and
the stable pointer table mutex by not dropping the SM_MUTEX in
nonmovingCollect. This requires quite a bit of rejiggering but it
does seem like a better strategy.
- - - - -
c9936718 by Ben Gamari at 2022-12-23T19:09:30-05:00
nonmoving: Ensure that we aren't holding locks when closing them
TSAN complains about this sort of thing.
- - - - -
0cd31f7d by Ben Gamari at 2022-12-23T19:09:30-05:00
nonmoving: Make bitmap accesses atomic
This is a benign race on any sensible hard since these are byte
accesses. Nevertheless, atomic accesses are necessary to satisfy
TSAN.
- - - - -
d3fe110a by Ben Gamari at 2022-12-23T19:09:30-05:00
nonmoving: Fix benign race in update remembered set check
Relaxed load is fine here since we will take the lock before looking at
the list.
- - - - -
ab6cf893 by Ben Gamari at 2022-12-23T19:09:30-05:00
nonmoving: Fix race in shortcutting
We must use an acquire load to read the info table pointer since if we
find an indirection we must be certain that we see the indirectee.
- - - - -
36c9f23c by Ben Gamari at 2022-12-23T19:09:30-05:00
nonmoving: Make free list counter accesses atomic
Since these may race with the allocator(s).
- - - - -
aebef31c by doyougnu at 2022-12-23T19:10:09-05:00
add GHC.Utils.Binary.foldGet' and use for Iface
A minor optimization to remove lazy IO and a lazy accumulator
strictify foldGet'
IFace.Binary: use strict foldGet'
remove superfluous bang
- - - - -
5eb357d9 by Ben Gamari at 2022-12-24T00:41:05-05:00
compiler: Ensure that GHC toolchain is first in search path
As noted in #22561, it is important that GHC's toolchain look
first for its own headers and libraries to ensure that the
system's are not found instead. If this happens things can
break in surprising ways (e.g. see #22561).
- - - - -
cbaebfb9 by Matthew Pickering at 2022-12-24T00:41:40-05:00
head.hackage: Use slow-validate bindist for linting jobs
This enables the SLOW_VALIDATE env var for the linting head.hackage
jobs, namely the jobs enabled manually, by the label or on the nightly
build now use the deb10-numa-slow-validate bindist which has assertions
enabled.
See #22623 for a ticket which was found by using this configuration
already!
The head.hackage jobs triggered by upstream CI are now thusly:
hackage-lint: Can be triggered on any MR, normal validate pipeline or nightly build.
Runs head.hackage with -dlint and a slow-validate bindist
hackage-label-lint: Trigged on MRs with "user-facing" label, runs the slow-validate
head.hackage build with -dlint.
nightly-hackage-lint: Runs automatically on nightly pipelines with slow-validate + dlint config.
nightly-hackage-perf: Runs automaticaly on nightly pipelines with release build and eventlogging enabled.
release-hackage-lint: Runs automatically on release pipelines with -dlint on a release bindist.
- - - - -
f4850f36 by Matthew Pickering at 2022-12-24T00:41:40-05:00
ci: Don't run abi-test-nightly on release jobs
The test is not configured to get the correct dependencies for the
release pipelines (and indeed stops the release pipeline being run at
all)
- - - - -
c264b06b by Matthew Pickering at 2022-12-24T00:41:40-05:00
ci: Run head.hackage jobs on upstream-testing branch rather than master
This change allows less priviledged users to trigger head.hackage jobs
because less permissions are needed to trigger jobs on the
upstream-testing branch, which is not protected.
There is a CI job which updates upstream-testing each hour to the state
of the master branch so it should always be relatively up-to-date.
- - - - -
63b97430 by Ben Gamari at 2022-12-24T00:42:16-05:00
llvmGen: Fix relaxed ordering
Previously I used LLVM's `unordered` ordering for the C11 `relaxed`
ordering. However, this is wrong and should rather use the LLVM
`monotonic` ordering.
Fixes #22640
- - - - -
f42ba88f by Ben Gamari at 2022-12-24T00:42:16-05:00
gitlab-ci: Introduce aarch64-linux-llvm job
This nightly job will ensure that we don't break the LLVM backend on
AArch64/Linux by bootstrapping GHC.
This would have caught #22640.
- - - - -
6d62f6bf by Matthew Pickering at 2022-12-24T00:42:51-05:00
Store RdrName rather than OccName in Holes
In #20472 it was pointed out that you couldn't defer out of scope but
the implementation collapsed a RdrName into an OccName to stuff it into
a Hole. This leads to the error message for a deferred qualified name
dropping the qualification which affects the quality of the error
message.
This commit adds a bit more structure to a hole, so a hole can replace a
RdrName without losing information about what that RdrName was. This is
important when printing error messages.
I also added a test which checks the Template Haskell deferral of out of
scope qualified names works properly.
Fixes #22130
- - - - -
3c3060e4 by Richard Eisenberg at 2022-12-24T17:34:19+00:00
Drop support for kind constraints.
This implements proposal 547 and closes ticket #22298.
See the proposal and ticket for motivation.
Compiler perf improves a bit
Metrics: compile_time/bytes allocated
-------------------------------------
CoOpt_Singletons(normal) -2.4% GOOD
T12545(normal) +1.0%
T13035(normal) -13.5% GOOD
T18478(normal) +0.9%
T9872d(normal) -2.2% GOOD
geo. mean -0.2%
minimum -13.5%
maximum +1.0%
Metric Decrease:
CoOpt_Singletons
T13035
T9872d
- - - - -
6d7d4393 by Ben Gamari at 2022-12-24T21:09:56-05:00
hadrian: Ensure that linker scripts are used when merging objects
In #22527 @rui314 inadvertantly pointed out a glaring bug in Hadrian's
implementation of the object merging rules: unlike the old `make` build
system we utterly failed to pass the needed linker scripts. Fix this.
- - - - -
a5bd0eb8 by Bodigrim at 2022-12-24T21:10:34-05:00
Document infelicities of instance Ord Double and workarounds
- - - - -
14ee7a04 by Ryan Scott at 2023-01-01T16:48:48+00:00
Windows: Remove mingwex dependency
The clang based toolchain uses ucrt as its math library
and so mingwex is no longer needed. In fact using mingwex
will cause incompatibilities as the default routines in both
have differing ULPs and string formatting modifiers.
```
$ LIBRARY_PATH=/mingw64/lib ghc/_build/stage1/bin/ghc Bug.hs -fforce-recomp && ./Bug.exe
[1 of 2] Compiling Main ( Bug.hs, Bug.o )
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `__imp___p__environ'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `__hscore_get_errno'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_ForeignziCziError_errnoToIOError_info'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziWindows_failIf2_closure'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziEncodingziCodePageziAPI_mkCodePageEncoding_info'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziEncodingziCodePage_currentCodePage_closure'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziEncoding_getForeignEncoding_closure'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_ForeignziCziString_withCStringLen1_info'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziHandleziInternals_zdwflushCharReadBuffer_info'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziHandleziText_hGetBuf1_info'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziFingerprint_fingerprintString_closure'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_DataziTypeableziInternal_mkTrCon_closure'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziException_errorCallWithCallStackException_closure'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziErr_error_info'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\template-haskell-2.19.0.0\libHStemplate-haskell-2.19.0.0.a: unknown symbol `base_DataziMaybe_fromJust1_info'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\template-haskell-2.19.0.0\libHStemplate-haskell-2.19.0.0.a: unknown symbol `templatezmhaskell_LanguageziHaskellziTHziSyntax_IntPrimL_con_info'
ghc.exe: ^^ Could not load 'templatezmhaskell_LanguageziHaskellziTHziLibziInternal_stringL_closure', dependency unresolved. See top entry above.
<no location info>: error:
GHC.ByteCode.Linker.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
templatezmhaskell_LanguageziHaskellziTHziLibziInternal_stringL_closure
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please report this as a GHC bug:
https://www.haskell.org/ghc/reportabug
```
- - - - -
6658c45d by Tamar Christina at 2023-01-02T23:38:30+00:00
linker: Fix BFD import libraries
- - - - -
30 changed files:
- .gitlab-ci.yml
- .gitlab/gen_ci.hs
- .gitlab/jobs.yaml
- compiler/GHC/Builtin/Names/TH.hs
- compiler/GHC/CmmToLlvm/CodeGen.hs
- compiler/GHC/Core/DataCon.hs
- compiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/CoreToIface.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/Iface/Binary.hs
- compiler/GHC/Iface/Type.hs
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Rename/Expr.hs
- compiler/GHC/Rename/HsType.hs
- compiler/GHC/Rename/Module.hs
- compiler/GHC/Settings/IO.hs
- compiler/GHC/Tc/Errors.hs
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Errors/Types.hs
- compiler/GHC/Tc/Gen/HsType.hs
- compiler/GHC/Tc/Solver/Rewrite.hs
- compiler/GHC/Tc/TyCl.hs
- compiler/GHC/Tc/Types/Constraint.hs
- compiler/GHC/Tc/Types/Origin.hs
- compiler/GHC/Tc/Utils/Instantiate.hs
- compiler/GHC/Tc/Utils/Monad.hs
- compiler/GHC/Tc/Utils/TcMType.hs
- compiler/GHC/Tc/Utils/TcType.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/67cfa2cce93bcedbc720f6c6d6df27683d76ad30...6658c45d43de1a85ac4e823a92613b5c3d04d868
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/67cfa2cce93bcedbc720f6c6d6df27683d76ad30...6658c45d43de1a85ac4e823a92613b5c3d04d868
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/20230102/f198cb6f/attachment-0001.html>
More information about the ghc-commits
mailing list