| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Until 0472f0f6a92395d478e9644c0dbd12948518099f there was a meaningful
host vs target distinction (though it wasn't used right, in genapply).
After that, they did not differ in meaningful ways, so it's best to just
only keep one.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These prevent multi-target builds. They were gotten rid of in 3 ways:
1. In the compiler itself, replacing `#if` with runtime `if`. In these
cases, we care about the target platform still, but the target platform
is dynamic so we must delay the elimination to run time.
2. In the compiler itself, replacing `TARGET` with `HOST`. There was
just one bit of this, in some code splitting strings representing lists
of paths. These paths are used by GHC itself, and not by the compiled
binary. (They are compiler lookup paths, rather than RPATHS or something
that does matter to the compiled binary, and thus would legitamentally
be target-sensative.) As such, the path-splitting method only depends on
where GHC runs and not where code it produces runs. This should have
been `HOST` all along.
3. Changing the RTS. The RTS doesn't care about the target platform,
full stop.
4. `includes/stg/HaskellMachRegs.h` This file is also included in the
genapply executable. This is tricky because the RTS's host platform
really is that utility's target platform. so that utility really really
isn't multi-target either. But at least it isn't an installed part of
GHC, but just a one-off tool when building the RTS. Lying with the
`HOST` to a one-off program (genapply) that isn't installed doesn't seem so bad.
It's certainly better than the other way around of lying to the RTS
though not to genapply. The RTS is more important, and it is installed,
*and* this header is installed as part of the RTS.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves all URL references to Trac Wiki to their corresponding
GitLab counterparts.
This substitution is classified as follows:
1. Automated substitution using sed with Ben's mapping rule [1]
Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...
New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...
2. Manual substitution for URLs containing `#` index
Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz
New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz
3. Manual substitution for strings starting with `Commentary`
Old: Commentary/XxxYyy...
New: commentary/xxx-yyy...
See also !539
[1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
|
| |
|
|
| |
Our new CPP linter enforces this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The C code in the RTS now gets built with `-Wundef` and the Haskell code
(stages 1 and 2 only) with `-Wcpp-undef`. We now get warnings whereever
`#if` is used on undefined identifiers.
Test Plan: Validate on Linux and Windows
Reviewers: austin, angerman, simonmar, bgamari, Phyx
Reviewed By: bgamari
Subscribers: thomie, snowleopard
Differential Revision: https://phabricator.haskell.org/D3278
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This both says what we mean and silences a bunch of spurious CPP linting
warnings. This pragma is supported by all CPP implementations which we
support.
Reviewers: austin, erikd, simonmar, hvr
Reviewed By: simonmar
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3482
|
| |
|
|
|
|
|
|
| |
This is causing too much platform dependent breakage at the moment. We
will need a more rigorous testing strategy before this can be
merged again.
This reverts commit 7e340c2bbf4a56959bd1e95cdd1cfdb2b7e537c2.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The C code in the RTS now gets built with `-Wundef` and the Haskell code
(stages 1 and 2 only) with `-Wcpp-undef`. We now get warnings whereever
`#if` is used on undefined identifiers.
Test Plan: Validate on Linux and Windows
Reviewers: austin, angerman, simonmar, bgamari, Phyx
Reviewed By: bgamari
Subscribers: thomie, snowleopard
Differential Revision: https://phabricator.haskell.org/D3278
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend the PowerPC 32-bit native code generator for "64-bit
PowerPC ELF Application Binary Interface Supplement 1.9" by
Ian Lance Taylor and "Power Architecture 64-Bit ELF V2 ABI Specification --
OpenPOWER ABI for Linux Supplement" by IBM.
The latter ABI is mainly used on POWER7/7+ and POWER8
Linux systems running in little-endian mode. The code generator
supports both static and dynamic linking. PowerPC 64-bit
code for ELF ABI 1.9 and 2 is mostly position independent
anyway, and thus so is all the code emitted by the code
generator. In other words, -fPIC does not make a difference.
rts/stg/SMP.h support is implemented.
Following the spirit of the introductory comment in
PPC/CodeGen.hs, the rest of the code is a straightforward
extension of the 32-bit implementation.
Limitations:
* Code is generated only in the medium code model, which
is also gcc's default
* Local symbols are not accessed directly, which seems to
also be the case for 32-bit
* LLVM does not work, but this does not work on 32-bit either
* Must use the system runtime linker in GHCi, because the
GHC linker for "static" object files (rts/Linker.c) for
PPC 64-bit is not implemented. The system runtime
(dynamic) linker works.
* The handling of the system stack (register 1) is not ELF-
compliant so stack traces break. Instead of allocating a new
stack frame, spill code should use the "official" spill area
in the current stack frame and deallocation code should restore
the back chain
* DWARF support is missing
Fixes #9863
Test Plan: validate (on powerpc, too)
Reviewers: simonmar, trofi, erikd, austin
Reviewed By: trofi
Subscribers: bgamari, arnons1, kgardas, thomie
Differential Revision: https://phabricator.haskell.org/D629
GHC Trac Issues: #9863
|
| |
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
| | |
|
| |
|
|
|
|
| |
We were getting the installed compiler's MachRegs.h sometimes (in
GenApply.hs, as it turns out). This probably caused some weird
effects...
|
|
|
No functional differences yet
|
