[Git][ghc/ghc][wip/backports-9.8] 14 commits: x86 Codegen: Implement MO_S_MulMayOflo for W16

Tue Aug 8 16:58:53 UTC 2023

Ben Gamari pushed to branch wip/backports-9.8 at Glasgow Haskell Compiler / GHC

Commits:
8ee88300 by Sven Tennie at 2023-08-08T12:58:43-04:00
x86 Codegen: Implement MO_S_MulMayOflo for W16

- - - - -
a212b3d4 by Sven Tennie at 2023-08-08T12:58:43-04:00
x86 CodeGen: MO_S_MulMayOflo better error message for rep > W64

It's useful to see which value made the pattern match fail. (If it ever
occurs.)

- - - - -
a289717e by Sven Tennie at 2023-08-08T12:58:43-04:00
x86 CodeGen: Implement MO_S_MulMayOflo for W8

This case wasn't handled before. But, the test-primops test suite showed
that it actually might appear.

- - - - -
3b6303cf by Ben Gamari at 2023-08-08T12:58:47-04:00
testsuite: Mark MulMayOflo_full as broken rather than skipping

To ensure that we don't accidentally fix it.

See #23742.

(cherry picked from commit fd7ce39c70f8922e26b8be8a5fc4d6797987f66f)

- - - - -
5c8dec81 by Ben Gamari at 2023-08-08T12:58:47-04:00
nativeGen/AArch64: Fix sign extension in MulMayOflo

Previously the 32-bit implementations of MulMayOflo would use the
a non-sensical sign-extension mode. Rewrite these to reflect what gcc 11
produces. Also similarly rework the 16- and 8-bit cases.

This now passes the MulMayOflo tests in ghc/test-primops> in all four
widths, including the precision tests.

Fixes #23721.

(cherry picked from commit 824092f28f52d32b6ea3cd26e1e576524ee24969)

- - - - -
59e2c969 by sheaf at 2023-08-08T12:58:47-04:00
Update inert_solved_dicts for ImplicitParams

When adding an implicit parameter dictionary to the inert set, we must
make sure that it replaces any previous implicit parameter dictionaries
that overlap, in order to get the appropriate shadowing behaviour, as in

  let ?x = 1 in let ?x = 2 in ?x

We were already doing this for inert_cans, but we weren't doing the same
thing for inert_solved_dicts, which lead to the bug reported in #23761.

The fix is thus to make sure that, when handling an implicit parameter
dictionary in updInertDicts, we update **both** inert_cans and
inert_solved_dicts to ensure a new implicit parameter dictionary
correctly shadows old ones.

Fixes #23761

(cherry picked from commit 41bf2c09f17aa00bf4dd13332c6d07adf21af4f8)

- - - - -
1d2f96e6 by Jan Hrček at 2023-08-08T12:58:47-04:00
Fix haddock markup in code example for coerce

(cherry picked from commit 1b15dbc4e6ee5af87cc8b36c9a50287ae5d16b03)

- - - - -
bdf2adf7 by Sylvain Henry at 2023-08-08T12:58:47-04:00
JS: implement getMonotonicTime (fix #23687)

(cherry picked from commit 33598ecb624867dce36a71b265c054b689ed9701)

- - - - -
60f54b39 by Matthew Pickering at 2023-08-08T12:58:47-04:00
Fix pretty printing of WARNING pragmas

There is still something quite unsavoury going on with WARNING pragma
printing because the printing relies on the fact that for decl
deprecations the SourceText of WarningTxt is empty. However, I let that
lion sleep and just fixed things directly.

Fixes #23465

(cherry picked from commit 822ef66b54bd48df7c01fcafb99b7694952cae28)

- - - - -
347ae2d6 by Matthew Craven at 2023-08-08T12:58:47-04:00
Kill off gen_bytearray_addr_access_ops.py

The relevant primop descriptions are now
generated directly by genprimopcode.

This makes progress toward fixing #23490, but it is not
a complete fix since there is more than one way in which
cabal-reinstall (hadrian/build build-cabal) is broken.

(cherry picked from commit 32cae784b7bfcb6562a9ad041e7608dbcf0f5d72)

- - - - -
e050d1f4 by Jens Petersen at 2023-08-08T12:58:47-04:00
user_guide/flags.py: python-3.12 no longer includes distutils

packaging.version seems able to handle this fine

(cherry picked from commit 026991d7fcf9e3ce013081ab6d1e3d2200b694bb)

- - - - -
240b1a75 by Matthew Pickering at 2023-08-08T12:58:47-04:00
simplifier: Correct InScopeSet in rule matching

The in-scope set passedto the `exprIsLambda_maybe` call lacked all the
in-scope binders. @simonpj suggests this fix where we augment the
in-scope set with the free variables of expression which fixes this
failure mode in quite a direct way.

Fixes #23630

(cherry picked from commit 4f5538a8e2a8b9bc490bcd098fa38f6f7e9f4d73)

- - - - -
5f60f945 by Ilias Tsitsimpis at 2023-08-08T12:58:47-04:00
ghc-prim: Link against libatomic

Commit b4d39adbb58 made 'hs_cmpxchg64()' available to all architectures.
Unfortunately this made GHC to fail to build on armel, since armel needs
libatomic to support atomic operations on 64-bit word sizes.

Configure libraries/ghc-prim/ghc-prim.cabal to link against libatomic,
the same way as we do in rts/rts.cabal.

(cherry picked from commit fc186b0c0ac56d6ff6225d3f6607be37770fcb52)

- - - - -
fc09110b by Matthew Pickering at 2023-08-08T12:58:47-04:00
Allow users to override non-essential haddock options in a Flavour

We now supply the non-essential options to haddock using the `extraArgs`
field, which can be specified in a Flavour so that if an advanced user
wants to change how documentation is generated then they can use
something other than the `defaultHaddockExtraArgs`.

This does have the potential to regress some packaging if a user has
overridden `extraArgs` themselves, because now they also need to add
the haddock options to extraArgs. This can easily be done by appending
`defaultHaddockExtraArgs` to their extraArgs invocation but someone
might not notice this behaviour has changed.

In any case, I think passing the non-essential options in this manner is
the right thing to do and matches what we do for the "ghc" builder,
which by default doesn't pass any optmisation levels, and would likewise
be very bad if someone didn't pass suitable `-O` levels for builds.

Fixes #23625

(cherry picked from commit e4350b41b54c604e222fe3b0c4edb80beee2c0b3)

- - - - -

30 changed files:

- − compiler/GHC/Builtin/gen_bytearray_addr_access_ops.py
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/Core/Rules.hs
- compiler/GHC/Hs/Decls.hs
- compiler/GHC/Tc/Solver/Dict.hs
- compiler/GHC/Tc/Solver/InertSet.hs
- compiler/GHC/Tc/Solver/Monad.hs
- compiler/GHC/Unit/Module/Warnings.hs
- docs/users_guide/flags.py
- hadrian/src/Rules/Generate.hs
- hadrian/src/Settings/Builders/Haddock.hs
- hadrian/src/Settings/Default.hs
- hadrian/src/Settings/Default.hs-boot
- hadrian/src/Settings/Flavours/Benchmark.hs
- hadrian/src/Settings/Flavours/Development.hs
- hadrian/src/Settings/Flavours/Performance.hs
- hadrian/src/Settings/Flavours/Validate.hs
- libraries/base/GHC/Clock.hsc
- libraries/base/GHC/Conc/POSIX.hs
- + libraries/base/tests/T23687.hs
- libraries/base/tests/all.T
- libraries/ghc-prim/ghc-prim.cabal → libraries/ghc-prim/ghc-prim.cabal.in
- testsuite/tests/codeGen/should_run/all.T
- testsuite/tests/printer/Makefile
- + testsuite/tests/printer/Test23464.hs
- testsuite/tests/printer/all.T
- + testsuite/tests/simplCore/should_compile/T23630.hs
- testsuite/tests/simplCore/should_compile/all.T

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e0a5bc622b256bccc2f7608becd298cef8a65bb6...fc09110bf5e2e3ee34df8ba277e920e0783d3b31

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e0a5bc622b256bccc2f7608becd298cef8a65bb6...fc09110bf5e2e3ee34df8ba277e920e0783d3b31
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/20230808/5599a272/attachment-0001.html>