| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There ware some old file names (.lhs, ...) at comments.
* mk/config.mk.in
- compiler/hsSyn/HsExpr.lhs -> HsExpr.hs
* utils/ghc-pkg/Main.hs
- compiler/main/Packages.lhs -> Packages.hs
* utils/genapply/Main.hs
- CgRetConv.lhs -> * REMOVE THIS COMMENT (OLDER FILE THAN GHC6) *
- Constants.lhs -> Constants.hs
- compiler/codeGen/CgCallConv.lhs -> compiler/codeGen/StgCmmLayout.hs
- Apply.hc -> Apply.cmm
- HeapStackCheck.hc -> HeapStackCheck.cmm
Reviewers: mpickering, austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D3077
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 266a9dc4c changed = to := in one place in mk/config.mk.in.
This broke SupportsSplitSections because the variable LdIsGNULd
that it depends on is not defined until later in the file.
Test Plan: pushed to a wip/ branch for perf to build
Reviewers: DemiMarie, austin, bgamari, mpickering
Reviewed By: mpickering
Subscribers: mpickering, thomie
Differential Revision: https://phabricator.haskell.org/D3070
GHC Trac Issues: #13230
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The submodule repository contains the latest version of the GMP source
distribution (6.1.2) with the doc/ subdirectory removed, as described
in gmp/ghc.mk. Rather than applying the old patch from gmp/tarball/patch
I moved its contents into gmp/gmpsrc.patch, canceling a patch related to
memory management there. Experimentally, the PIC-related patch for OS X
is still necessary.
The upgrade to GMP 6.1.2 fixes #7655.
Test Plan:
Built on OS X with in-tree gmp and tested that the command
`ghc -e 'length (show (2^(5*10^6) :: Integer))'` no longer segfaults.
Reviewers: mpickering, hvr, austin, bgamari
Reviewed By: bgamari
Subscribers: mpickering, thomie
Differential Revision: https://phabricator.haskell.org/D3044
GHC Trac Issues: #7655
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: GHC CI
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2879
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Power ISA says the result of a division by zero is undefined. So
ignore stdout on PowerPC 64-bit systems.
Disable ext-interp tests on 64-bit PowerPC. We don't have support for
PowerPC 64-bit ELF in the RTS linker, which is needed for the external
interpreter.
Test Plan: ./validate
Reviewers: austin, simonmar, hvr, erikd, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2782
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On non-windows platforms with GNU ld, enable SplitSections in the GHC
build by default.
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: DemiMarie, thomie
Differential Revision: https://phabricator.haskell.org/D1800
GHC Trac Issues: #11445
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: austin, bgamari, RyanGlScott
Reviewed By: bgamari, RyanGlScott
Subscribers: RyanGlScott, thomie
Differential Revision: https://phabricator.haskell.org/D2824
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before the change result of expression
ArchSupportsSMP="$(if $(filter $(ARM_ISA),ARMv5 ARMv6),NO,YES)"
to evaluate to
ArchSupportsSMP="YES"
After the change it's
ArchSupportsSMP=YES
Thanks to orion for the fix!
Fixes Trac #12981
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
|
|
|
|
|
| |
Mention that many GHC testsuite tests will fail with a compiler built with
the quickest profile. See Trac #12141.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This updates the binary dists for windows to GCC 6.2.0 and
binutils 2.27.2 which has fixes required for LLVM.
Test Plan: ./validate
Reviewers: simonmar, erikd, austin, bgamari
Reviewed By: simonmar, bgamari
Subscribers: thomie, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D2749
GHC Trac Issues: #12871, #8974
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Try `./configure HC_OPTS_STAGE0=-foobar` and watch it fail
Reviewers: austin, hvr
Subscribers: thomie, erikd
Differential Revision: https://phabricator.haskell.org/D2674
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was removed long ago in cf403b50900648063d99afa160d2091a7d6f58c1.
Thanks for @rwbarton for catching this.
Updates nofib submodule.
Test Plan: Validate
Reviewers: austin, rwbarton
Subscribers: thomie, rwbarton
Differential Revision: https://phabricator.haskell.org/D2493
GHC Trac Issues: #12443
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Try it
Reviewers: hvr, simonmar, austin, erikd
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1722
GHC Trac Issues: #11094
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The warning for reference:
```
rts/RaiseAsync.c: In function ‘throwToMsg’:
rts/SMPClosureOps.h:65:0: error:
error: inlining failed in call to ‘lockClosure’: call is unlikely
and code size would grow
rts/RaiseAsync.c:305:0: error: error: called from here
rts/SMPClosureOps.h:65:0: error:
error: inlining failed in call to ‘lockClosure’: call is unlikely
and code size would grow
```
This warning triggers on `gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)`
and it doesn't trigger with new GCCs.
Test Plan: build ghc/rts
Reviewers: bgamari, simonmar, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2353
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Configure/build with and without --enable-libdw
Reviewers: trofi, hvr, austin, simonmar, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2276
|
| |
|
|
|
|
| |
[skip ci]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Provoked by Trac #11948, this patch adds a new warning to GHC
-Wsimplifiable-class-constraints
It warns if you write a class constraint in a type signature that
can be simplified by an existing instance declaration. Almost always
this means you should simplify it right now; type inference is very
fragile without it, as #11948 shows.
I've put the warning as on-by-default, but I suppose that if there are
howls of protest we can move it out (as happened for -Wredundant-constraints.
It actually found an example of an over-complicated context in CmmNode.
Quite a few tests use these weird contexts to trigger something else,
so I had to suppress the warning in those.
The 'haskeline' library has a few occurrences of the warning (which
I think should be fixed), so I switched it off for that library in
warnings.mk.
The warning itself is done in TcValidity.check_class_pred.
HOWEVER, when type inference fails we get a type error; and the error
suppresses the (informative) warning. So as things stand, the warning
only happens when it doesn't cause a problem. Not sure what to do
about this, but this patch takes us forward, I think.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The version of `haddock` that ghc has as a submodule has an option
for generating linkified sources. I don't think it hurts to have this
and they are great for exploring the codebase.
I'd be nice if harbormaster or travis published them somewhere, but
I don't know how to do that yet.
Test Plan:
uncomment, run `make` and look at the
nicely linkified sources in `compiler/stage2/doc/html/ghc/`
Reviewers: hvr, austin, bgamari
Reviewed By: bgamari
Subscribers: thomie, simonmar
Differential Revision: https://phabricator.haskell.org/D2119
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than using the non-standard/idiomatic `--with-{gcc,clang}=...`
scheme use the `CC=...` style scheme.
The basic idea is to have Autoconf's CC/CFLAG/CPPFLAG apply to
stage{1,2,3}, while having a separate _STAGE0 set of env-vars
denote the bootstrap-toolchain flags/programs.
This should be simpler, less confusing, and somewhat more in line with
Autoconf's idioms (allowing us to reuse more of Autoconf rather than
(re)inventing our own confusing non-standard m4 macros to do stuff that
Autoconf could almost do already for us)
Morever, expose CC_STAGE0 as a so-called "precious" variable.
So now we can better control which bootstrapping gcc is used
(by default the one used by the stage0 ghc, unless CC_STAGE0 is
overriden)
```
Some influential environment variables:
CC_STAGE0 C compiler command (bootstrap)
CC C compiler command
CFLAGS C compiler flags
...
Use these variables to override the choices made by `configure' or to
help it to find libraries and programs with nonstandard names/locations.
```
Test Plan: I've tested that cross-compiling with
`--target=powerpc-linux-gnu` still works, and tried a few variants of
settting `CC=` and `CC_STAGE0=`; `./validate` passed as well
Reviewers: erikd, austin, bgamari, simonmar
Reviewed By: simonmar
Subscribers: Phyx, thomie
Differential Revision: https://phabricator.haskell.org/D2078
|
|
|
|
|
|
|
| |
This was introduced in 109a1e53287f50103e8a5b592275940b6e3dbb53
but isn't needed anymore because by now we're bootstrapping with
GHC versions which already provide "ld command" in `ghc --info`
(that field was added in GHC 7.8)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This extends the previous work to revive the unregisterised GHC build
for AIX/ppc32. Strictly speaking, AIX runs on POWER4 (and later)
hardware, but the PPC32 instructions implemented in the PPC NCG
represent a compatible subset of the POWER4 ISA.
IBM AIX follows the PowerOpen ABI (and shares many similiarites with the
Linux PPC64 ELF V1 NCG backend) but uses the rather limited XCOFF
format (compared to ELF).
This doesn't support dynamic libraries yet.
A major limiting factor is that the AIX assembler does not support the
`@ha`/`@l` relocation types nor the ha16()/lo16() functions Darwin's
assembler supports. Therefore we need to avoid emitting those. In case
of numeric literals we simply compute the functions ourselves, while for
labels we have to use local TOCs and hope everything fits into a 16bit
offset (for ppc32 this gives us at most 16384 entries per TOC section,
which is enough to compile GHC).
Another issue is that XCOFF doesn't seem to have a relocation type for
label-differences, and therefore the label-differences placed into
tables-next-to-code can't be relocated, but the linker may rearrange
different sections, so we need to place all read-only sections into the
same `.text[PR]` section to workaround this.
Finally, the PowerOpen ABI distinguishes between function-descriptors
and actualy entry-point addresses. For AIX we need to be specific when
emitting assembler code whether we want the address of the function
descriptor `printf`) or for the entry-point (`.printf`). So we let the
asm pretty-printer prefix a dot to all emitted subroutine
calls (i.e. `BL`) on AIX only. For now, STG routines' entry-point labels
are not prefixed by a label and don't have any associated
function-descriptor.
Reviewers: austin, trommler, erikd, bgamari
Reviewed By: trommler, erikd, bgamari
Differential Revision: https://phabricator.haskell.org/D2019
|
|
|
|
|
|
|
| |
Most notably, this update pulls in documentation improvements
and several INLINE pragmas for significant performance gains[1].
[1]: https://groups.google.com/d/msg/haskell-cafe/SUKtkDI84EE/fXMBd-jNDQAJ
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When CrossCompiling=YES or Stage1Only=YES, building the haddocks and the
User's Guide should be skipped, because haddock and mkUserGuidePart
depend on the GHC API.
See Note [No stage2 packages when CrossCompiling or Stage1Only] for
details.
There are several places in the build system where the variables
HADDOCK_DOCS and BUILD_SPHINX_* are checked. Instead of also checking
for the variables CrossCompiling or Stage1Only in all those places,
`make` will now exit with a nice error message when the user requests
the impossible.
Reviewers: rwbarton, austin, bgamari
Reviewed By: bgamari
Differential Revision: https://phabricator.haskell.org/D1882
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the whole point of validation is to test the compiler, assertions
should be enabled at least for some part of the build. Previously
assertions were only enabled (1) in stage 2 compiler (2) when "slow"
setting is used. With this patch we enable assertions in stage 1
compiler in all settings, to test them on (1) the compiler itself (2)
the libraries, even with the "fast" setting.
This will make "fast" setting slower, but the difference should be quite
modest - I didn't realize a significant difference in validation times.
Reviewers: bgamari, austin, thomie
Reviewed By: thomie
Differential Revision: https://phabricator.haskell.org/D1890
|
|
|
|
|
|
| |
-9e is crazy expensive for very little pay-off. See
http://smart-cactus.org/~ben/posts/2016-02-04-compression-comparison.html
for details.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`make install` puts libraries in a direcory containing the version
number. Do the same for the docs, such that multiple installs can live
side-by-side.
Delete unused ghcdocdir.
Test Plan:
```
./boot
./configure
make show! VALUE=docdir
```
Reviewed by: bgamari
Differential Revision: https://phabricator.haskell.org/D1868
GHC Trac Issues: #11354
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In an attempt to catch bugs involving using undef values, replace
undef literals by values likely to cause crashes or test failures.
We do this only when validating since it is a deoptimization.
This depends on D1857 to catch such bugs in the RTS (such as #11487).
Test Plan:
Did a build with
```
BuildFlavour = quick-llvm
SRC_HC_OPTS_STAGE1 = -fllvm-fill-undef-with-garbage
```
The build crashed when running ghc-stage2, as expected.
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1858
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Makes the needed changes to make RemoteGHCi work on Windows.
The approach passes OS Handles areound instead of the Posix Fd
as on Linux.
The reason is that I could not find any real documentation about
the behaviour of Windows w.r.t inheritance and Posix FDs.
The implementation with Fd did not seem to be able to find the Fd
in the child process. Instead I'm using the much better documented
approach of passing inheriting handles.
This requires a small modification to the `process` library.
https://github.com/haskell/process/pull/52
Test Plan: ./validate On Windows x86_64
Reviewers: thomie, erikd, bgamari, simonmar, austin, hvr
Reviewed By: simonmar
Subscribers: #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D1836
GHC Trac Issues: #11100
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are unable to produce load/store barriers for pre-ARMv7 targets.
Phab:D894 added dummy cases to SMP.h for these barriers to prevent the
build from failing under the assumption that there are no SMP-capable
devices of this vintage. However, #10433 points out that it is more
correct to simply set NOSMP for such targets.
Tested By: rwbarton
Test Plan: Validate
Reviewers: erikd, rwbarton, austin
Reviewed By: rwbarton
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1704
GHC Trac Issues: #10433
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A small cosmetic change, but we have to do a bit of work to
actually support it:
- Cabal submodule update, so that Cabal passes us
-this-unit-id when we ask for it. This includes
a Cabal renaming to be consistent with Unit ID, which
makes ghc-pkg a bit more scrutable.
- Build system is updated to use -this-unit-id rather than
-this-package-key, to avoid deprecation warnings. Needs
a version test so I resurrected the old test we had
(sorry rwbarton!)
- I've *undeprecated* -package-name, so that we are in the same
state as GHC 7.10, since the "correct" flag will have only
entered circulation in GHC 8.0.
- I removed -package-key. Since we didn't deprecate -package-id
I think this should not cause any problems for users; they
can just change their code to use -package-id.
- The package database is indexed by UNIT IDs, not component IDs.
I updated the naming here.
- I dropped the signatures field from ExposedModule; nothing
was using it, and instantiatedWith from the package database
field.
- ghc-pkg was updated to use unit ID nomenclature, I removed
the -package-key flags but I decided not to add any new flags
for now.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: austin, hvr, bgamari
Reviewed By: bgamari
Subscribers: 23Skidoo, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D1780
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: validate, check that gz is used
Reviewers: hvr, austin, thomie
Reviewed By: thomie
Differential Revision: https://phabricator.haskell.org/D1788
GHC Trac Issues: #11434
|
|
|
|
| |
Resolves #11434.
|
| |
|
|
|
|
|
|
|
| |
There is CONF_CC_OPTS_STAGE$(N) but not CONF_CC_OPTS
thus option does not work for a while.
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
|
|
|
|
|
|
| |
As we're requiring GHC >= 7.10 now, the conditional handling introduced
in 9e133b9dccec0553c6ec302d6ca0d3bc5eea06c4 for addressing #8182 can be
made unconditional, and thus simplify the build-system a little bit.
|
|
|
|
|
|
| |
This code was introduced in 66218d15b7c27a4a38992003bd761f60bae84b1f to
use `-package-name` for GHC 7.8, whereas GHC 7.10 needs the new
`-this-package-key` flag.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Quoting the POSIX standard for the `-D` C compiler flag:
-D name[=value]
Define name as if by a C-language #define directive.
If no `=value` is given, a value of 1 shall be used.
[...]
Removing this explicit `=1` definition from `-D` flags which are used to
define boolean macro constants makes the CLI invocation a bit more
idiomatic and reduces visual noise in debugging output
(flags containing `=`s are additionally put in single-quotes by GHC)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Cortex A8 hardware apparently has a bug which ld.gold will try to
correct; however in order to do so it must have unstripped executables
lest we see warnings of the form (see #10376, #10464),
/usr/bin/ld.gold: warning: cannot scan executable section 1 of ...
for Cortex-A8 erratum because it has no mapping symbols.
Consequently we disabling stripping by default on this architecture.
A bit more discussion about this issue can be found in this [Android
issue](http://code.google.com/p/android/issues/detail?id=40794).
Test Plan: Try validating on ARM
Reviewers: erikd, austin, thomie
Reviewed By: austin, thomie
Differential Revision: https://phabricator.haskell.org/D1599
GHC Trac Issues: #10376, #10464
|
|
|
|
|
|
|
| |
Also, `binary` now is almost warning free
(except for inlinePerformIO deprecation warnings)
/cc @kolmodin
|
|
|
|
|
|
| |
This is the designated release to go with GHC 8.0.1
/cc @AshleyYakeley
|
|
|
|
|
|
|
| |
So far only `time` (fixed upstream already though) and `xhtml` still require
`-Wno-tabs`, so let's apply that warning suppression flag only there.
This also updates the haskeline submodule to pull in a tab-fix
|
|
|
|
|
|
|
|
|
| |
This is the designated release to go with GHC 8.0.1
This release doesn't need any warning-suppression flags anymore, so
remove those from mk/warnings.mk
/cc @foxik
|
|
|
|
|
| |
And fix a redundant constraint warning in a test that requires
primitive.
|
|
|
|
|
|
|
|
|
| |
This follows a similar change in
4905b83a2d448c65ccced385343d4e8124548a3b, where binaries are installed
in libexecdir/bin instead of libexecdir.
This fixes a problem with ghc not able to find ghc-split, when
SplitObjs=YES.
|
|
|
|
|
|
| |
Cabal is currently warning free. So let's drop the `-w`-flags.
/cc @dcoutts
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces some occurences of `-f(no-)warn` with the new `-W`-aliases
introduced via 2206fa8cdb120932 / #11218, in cases which are guaranteed
to be invoked with recent enough GHC (i.e. the stage1+ GHC).
After this commit, mostly the compiler and the testsuite remain using
`-f(wo-)warn...` because the compiler needs to be bootstrappable with
older GHCs, while for the testsuite it's convenient to be able to quickly
compare the behavior to older GHCs (which may not support the new flags yet).
The compiler-part can be updated to use the new flags once GHC 8.3 development
starts.
Reviewed By: quchen
Differential Revision: https://phabricator.haskell.org/D1637
|