[Git][ghc/ghc][wip/rts-configure] 15 commits: hadrian: Decrease verbosity of cabal commands
John Ericson (@Ericson2314)
gitlab at gitlab.haskell.org
Sun Oct 15 18:07:50 UTC 2023
John Ericson pushed to branch wip/rts-configure at Glasgow Haskell Compiler / GHC
Commits:
9e6ef7ba by Matthew Pickering at 2023-10-12T20:35:00-04:00
hadrian: Decrease verbosity of cabal commands
In Normal, most tools do not produce output to stdout unless there are
error conditions.
Reverts 7ed65f5a1bc8e040e318ccff395f53a9bbfd8217
- - - - -
08fc27af by John Ericson at 2023-10-12T20:35:36-04:00
Do not substitute `@...@` for stage-specific values in cabal files
`rts` and `ghc-prim` now no longer have a `*.cabal.in` to set Cabal flag
defaults; instead manual choices are passed to configure in the usual
way.
The old way was fundamentally broken, because it meant we were baking
these Cabal files for a specific stage. Now we only do stage-agnostic
@...@ substitution in cabal files (the GHC version), and so all
stage-specific configuration is properly confined to `_build` and the
right stage dir.
Also `include-ghc-prim` is a flag that no longer exists for `ghc-prim`
(it was removed in 835d8ddbbfb11796ea8a03d1806b7cee38ba17a6) so I got
rid of it.
Co-Authored-By: Matthew Pickering <matthewtpickering at gmail.com>
- - - - -
a0ac8785 by Sebastian Graf at 2023-10-14T19:17:12-04:00
Fix restarts in .ghcid
Using the whole of `hadrian/` restarted in a loop for me.
- - - - -
fea9ecdb by Sebastian Graf at 2023-10-14T19:17:12-04:00
CorePrep: Refactor FloatingBind (#23442)
A drastically improved architecture for local floating in CorePrep
that decouples the decision of whether a float is going to be let- or case-bound
from how far it can float (out of strict contexts, out of lazy contexts, to
top-level).
There are a couple of new Notes describing the effort:
* `Note [Floating in CorePrep]` for the overview
* `Note [BindInfo and FloatInfo]` for the new classification of floats
* `Note [Floats and FloatDecision]` for how FloatInfo is used to inform
floating decisions
This is necessary ground work for proper treatment of Strict fields and
unlifted values at top-level.
Fixes #23442.
NoFib results (omitted = 0.0%):
```
--------------------------------------------------------------------------------
Program Allocs Instrs
--------------------------------------------------------------------------------
pretty 0.0% -1.6%
scc 0.0% -1.7%
--------------------------------------------------------------------------------
Min 0.0% -1.7%
Max 0.0% -0.0%
Geometric Mean -0.0% -0.0%
```
- - - - -
32523713 by Matthew Pickering at 2023-10-14T19:17:49-04:00
hadrian: Move ghcBinDeps into ghcLibDeps
This completes a5227080b57cb51ac34d4c9de1accdf6360b818b, the
`ghc-usage.txt` and `ghci-usage.txt` file are also used by the `ghc`
library so need to make sure they are present in the libdir even if we
are not going to build `ghc-bin`.
This also fixes things for cross compilers because the stage2
cross-compiler requires the ghc-usage.txt file, but we are using
the stage2 lib folder but not building stage3:exe:ghc-bin so
ghc-usage.txt was not being generated.
- - - - -
ec3c4488 by sheaf at 2023-10-14T19:18:29-04:00
Combine GREs when combining in mkImportOccEnv
In `GHC.Rename.Names.mkImportOccEnv`, we sometimes discard one import
item in favour of another, as explained in Note [Dealing with imports]
in `GHC.Rename.Names`. However, this can cause us to lose track of
important parent information.
Consider for example #24084:
module M1 where { class C a where { type T a } }
module M2 ( module M1 ) where { import M1 }
module M3 where { import M2 ( C, T ); instance C () where T () = () }
When processing the import list of `M3`, we start off (for reasons that
are not relevant right now) with two `Avail`s attached to `T`, namely
`C(C, T)` and `T(T)`. We combine them in the `combine` function of
`mkImportOccEnv`; as described in Note [Dealing with imports] we discard
`C(C, T)` in favour of `T(T)`. However, in doing so, we **must not**
discard the information want that `C` is the parent of `T`. Indeed,
losing track of this information can cause errors when importing,
as we could get an error of the form
‘T’ is not a (visible) associated type of class ‘C’
We fix this by combining the two GREs for `T` using `plusGRE`.
Fixes #24084
- - - - -
257c2807 by Ilias Tsitsimpis at 2023-10-14T19:19:07-04:00
hadrian: Pass -DNOSMP to C compiler when needed
Hadrian passes the -DNOSMP flag to GHC when the target doesn't support
SMP, but doesn't pass it to CC as well, leading to the following
compilation error on mips64el:
| Run Cc (FindCDependencies CDep) Stage1: rts/sm/NonMovingScav.c => _build/stage1/rts/build/c/sm/NonMovingScav.o.d
Command line: /usr/bin/mips64el-linux-gnuabi64-gcc -E -MM -MG -MF _build/stage1/rts/build/c/hooks/FlagDefaults.thr_debug_p_o.d -MT _build/stage1/rts/build/c/hooks/FlagDefaults.o -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -Irts/include -x c rts/hooks/FlagDefaults.c -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Winline -Wpointer-arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls -Wundef -fno-strict-aliasing -DTHREADED_RTS -DDEBUG -fomit-frame-pointer -O2 -g -Irts -I_build/stage1/rts/build -DDEBUG -fno-omit-frame-pointer -g3 -O0
===> Command failed with error code: 1
In file included from rts/include/Stg.h:348,
from rts/include/Rts.h:38,
from rts/hooks/FlagDefaults.c:8:
rts/include/stg/SMP.h:416:2: error: #error memory barriers unimplemented on this architecture
416 | #error memory barriers unimplemented on this architecture
| ^~~~~
rts/include/stg/SMP.h:440:2: error: #error memory barriers unimplemented on this architecture
440 | #error memory barriers unimplemented on this architecture
| ^~~~~
rts/include/stg/SMP.h:464:2: error: #error memory barriers unimplemented on this architecture
464 | #error memory barriers unimplemented on this architecture
| ^~~~~
The old make system correctly passed this flag to both GHC and CC [1].
Fix this error by passing -DNOSMP to CC as well.
[1] https://gitlab.haskell.org/ghc/ghc/-/blob/00920f176b0235d5bb52a8e054d89a664f8938fe/rts/ghc.mk#L407
Closes #24082
- - - - -
13d3c613 by John Ericson at 2023-10-14T19:19:42-04:00
Users Guide: Drop dead code for Haddock refs to `parallel`
I noticed while working on !11451 that `@LIBRARY_parallel_UNIT_ID@` was
not substituted. It is dead code -- there is no `parallel-ref` usages
and it doesn't look like there ever was (going back to
3e5d0f188d6c8633e55e9ba6c8941c07e459fa4b), so let's delete it.
- - - - -
99c23403 by John Ericson at 2023-10-15T14:07:39-04:00
Move function checks to RTS configure
Some of these functions are used in `base` too, but we can copy the
checks over to its configure if that's an issue.
- - - - -
ac8d145c by John Ericson at 2023-10-15T14:07:39-04:00
Move over a number of C-style checks to RTS configure
- - - - -
1d33da2e by John Ericson at 2023-10-15T14:07:39-04:00
Move/Copy more `AC_DEFINE` to RTS config
Only exception is the LLVM version macros, which are used for GHC
itself.
- - - - -
28b1afb7 by John Ericson at 2023-10-15T14:07:39-04:00
Define `TABLES_NEXT_TO_CODE` in the RTS configure
We create a new cabal flag to facilitate this.
- - - - -
419cdb1e by John Ericson at 2023-10-15T14:07:39-04:00
Configure scripts: `checkOS`: Make a bit more robust
`mingw64` and `mingw32` are now both accepted for `OSMinGW32`. This
allows us to cope with configs/triples that we haven't normalized extra
being what GNU `config.sub` does.
- - - - -
9e3bda88 by John Ericson at 2023-10-15T14:07:39-04:00
Generate `ghcplatform.h` from RTS configure
We create a new cabal flag to facilitate this.
- - - - -
9b46cd0a by John Ericson at 2023-10-15T14:07:39-04:00
Get rid of all mention of `mk/config.h`
The RTS configure script is now solely responsible for managing its
headers; the top level configure script does not help.
- - - - -
30 changed files:
- .ghcid
- .gitignore
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Data/OrdList.hs
- compiler/GHC/Rename/Env.hs
- compiler/GHC/Rename/Names.hs
- compiler/GHC/Types/Avail.hs
- compiler/GHC/Types/Name/Reader.hs
- configure.ac
- distrib/cross-port
- docs/coding-style.html
- docs/users_guide/conf.py
- docs/users_guide/ghc_config.py.in
- hadrian/src/Base.hs
- hadrian/src/Builder.hs
- hadrian/src/Hadrian/Haskell/Cabal/Parse.hs
- hadrian/src/Rules/Generate.hs
- hadrian/src/Rules/Lint.hs
- hadrian/src/Rules/Program.hs
- hadrian/src/Rules/Register.hs
- hadrian/src/Rules/SourceDist.hs
- hadrian/src/Settings/Packages.hs
- libraries/ghc-prim/ghc-prim.cabal.in → libraries/ghc-prim/ghc-prim.cabal
- m4/fp_cc_supports__atomics.m4
- m4/fptools_set_haskell_platform_vars.m4
- m4/ghc_convert_os.m4
- rts/.gitignore
- rts/configure.ac
- + rts/ghcplatform.h.bottom
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/47c3672018b1480178cbf81be64537d58cc68dc7...9b46cd0af009721c4846202662e3b83cb29e6a33
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/47c3672018b1480178cbf81be64537d58cc68dc7...9b46cd0af009721c4846202662e3b83cb29e6a33
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/20231015/b5f38bb4/attachment-0001.html>
More information about the ghc-commits
mailing list