| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes use of the new facility introduced via
14d0f7f1221db758cd06a69f53803d9d0150164a which allows
to have certain flags passed only to the non-bootstrapping
GHC. This is needed because sometimes we can't assume the
existence of a certain flag in the bootstrapping compiler
which was only added recently to GHC HEAD.
This also updates the haddock submodule to fix a few
remaining noncanonical instance definitions.
Differential Revision: https://phabricator.haskell.org/D1571
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently libdw requires per-arch implementation of
set_initial_registers() function.
Otherwise build fails with linkage error
(seen on sparc):
rts/dist/build/libHSrts_thr-ghc7.11.20151129.so:
undefined reference to `set_initial_registers'
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1
Converted link-time error to compile-time error,
added arch whitelist.
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
Reviewers: austin, thomie, bgamari
Reviewed By: bgamari
Differential Revision: https://phabricator.haskell.org/D1567
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add stage specific versions of SRC_HC_OPTS. These are currently only
used for -Werror. The previous combination of GhcStage2HcOpts and
GhcLibHcOpts didn't apply to utils/*.
* Add stage specific versions of SRC_HC_WARNING_OPTS. These will later be
used for new warning supression flags that should not be passed to the
bootstrap compiler.
* Move -Wall (and -Werror) related code back to mk/warnings.mk, where it
was before 987d54274. Now all warning related code is nicely together.
Include mk/warnings.mk after mk/custom-settings.mk to make this work.
Reviewed By: bgamari, hvr
Differential Revision: https://phabricator.haskell.org/D1536
|
|
|
|
|
|
|
|
|
| |
31bcf9b62ceaed98bdd3b7605e68d315bcff0c8a changed the behavior of WERROR
such that it would only apply to the stage 2 build. The reason for this
was to avoid silly redundant imports and such breaking validation on
different bootstrap compiler versions.
Document the fact that WERROR now only applies to the stage 2 build.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This hasn't been used for a very long time and will soon be superceded
by perf_events support.
Test Plan: validate
Reviewers: austin, simonmar
Reviewed By: austin, simonmar
Subscribers: thomie, erikd
Differential Revision: https://phabricator.haskell.org/D1493
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a flag -split-sections that does similar things to
-split-objs, but using sections in single object files instead of
relying on the Satanic Splitter and other abominations. This is very
similar to the GCC flags -ffunction-sections and -fdata-sections.
The --gc-sections linker flag, which allows unused sections to actually
be removed, is added to all link commands (if the linker supports it) so
that space savings from having base compiled with sections can be
realized.
Supported both in LLVM and the native code-gen, in theory for all
architectures, but really tested on x86 only.
In the GHC build, a new SplitSections variable enables -split-sections
for relevant parts of the build.
Test Plan: validate with both settings of SplitSections
Reviewers: dterei, Phyx, austin, simonmar, thomie, bgamari
Reviewed By: simonmar, thomie, bgamari
Subscribers: hsyl20, erikd, kgardas, thomie
Differential Revision: https://phabricator.haskell.org/D1242
GHC Trac Issues: #8405
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: 'SRC_HC_OPTS += -Wall' in 'mk/warnings.mk' was getting
overwritten by 'SRC_HC_OPTS = ...' in 'mk/flavours/*.mk'.
It didn't affect the compiler or most other libraries, because most
.cabal files define 'ghc-options: -Wall'.
Bug introduced in commit
2c24fd707f8650205bb574ffac5f376239af3723, when moving validate settings
from 'mk/validate-settings.mk' to 'mk/flavours/validate.mk'.
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D1425
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: it works
Reviewers: bgamari, rwbarton, austin
Reviewed By: austin
Subscribers: rwbarton
Differential Revision: https://phabricator.haskell.org/D1377
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows it to be used by users and packagers to grab the tarballs
necessary to generate a source tarball.
Test Plan: try it
Reviewers: thomie, austin, Phyx
Reviewed By: thomie, austin, Phyx
Subscribers: erikd
Differential Revision: https://phabricator.haskell.org/D1378
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This reverts commit aecf4a5f96d0d3ffcf4cb2c67a20a610d7c64486.
It turns out the Simons are relying on 'mk/are-validating.mk', see
D1307.
The workflow they are using is:
* run ./validate
* find a bug in the compiler
* try to fix the bug, running 'make 1' (or 'make 2') repeatedly. Because
of 'mk/are-validating.mk', this uses the same build settings as validate.
* continue ./validate (--no-clean)
I suggested two alternatives:
A. run 'make 1 Validating=YES' instead of 'make 1'
Problem: when running `./validate --fast` or `./validate --hpc`
instead of a normal `./validate`, validate sets ValidateSpeed and
ValdateHpc in mk/are-validating.mk. You would for example have to run
'make 1 Validating=YES ValidateSpeed=FAST' instead of 'make 1' to get the
same build settings as `./validate --fast`, which is entirely too long and
error prone.
B. uncomment `#BuildFlavour=validate` in mk/build.mk, and include
'mk/validate.mk'.
Problems:
* any other settings you have in build.mk will also get used.
* the distinction between 'mk/validate.mk' and 'mk/build.mk' becomes less
clear.
* it is easy to forget to include 'mk/validate.mk'.
* the build system again doesn't have access to the ValidateSpeed and
ValdateHpc settings set by validate.
Neither of these two options is entirely satisfactory.
Reviewers: austin, bgamari
Differential Revision: https://phabricator.haskell.org/D1383
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds basic support to the RTS for DWARF-assisted unwinding of the
Haskell and C stack via libdw. This only adds the infrastructure;
consumers of this functionality will be introduced in future diffs.
Currently we are carrying the initial register collection code in
Libdw.c but this will eventually make its way upstream to libdw.
Test Plan: See future patches
Reviewers: Tarrasch, scpmw, austin, simonmar
Reviewed By: austin, simonmar
Subscribers: simonmar, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D1196
GHC Trac Issues: #10656
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
| |
A `make` build after running `./validate` earlier should use the normal
mk/build.mk settings, without having to manually delete the leftover
file mk/are-validating or run `make clean` first.
Reviewed by: austin
Differential Revision: https://phabricator.haskell.org/D1307
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: austin, bgamari
Subscribers: erikd
Differential Revision: https://phabricator.haskell.org/D1303
modified: configure.ac
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
See Note [CrossCompiling vs Stage1Only] in mk/config.mk.in.
See Note [Stage1Only vs stage=1] in mk/config.mk.in.
See Note [No stage2 packages when CrossCompiling or Stage1Only].
Also:
* use stage2 to build mkUserGuidePart, as was probably intended.
Now the following represent the same set of packages:
- packages that we build with ghc-stage2
- packages that depend on the ghc library
Those packages are: haddock, mkUserGuidePart and ghctags.
* don't let utils that don't depend on the ghc library depend on its
package-data.mk file. Instead, let those utils directly depend on
the package-data.mk files of the stage1 packages. Not sure if it
improves anything, but I found it easier to explain what's going on
this way.
(partially) reviewed by: austin
Differential Revision: https://phabricator.haskell.org/D1218
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow up to 841924c9587c10488a18e307b573720977bf4f13,
where `-fllvm` was explicitly removed from GhcStage1HcOpts for
perf-cross.
After removing -fllvm from GhcStage1HcOpts, it should be removed from
SRC_HC_OPTS as well, because SRC_HC_OPTS are added to every Haskell
compilation. That's what this patch does.
BuildFlavour bench-cross (added in ddf79ebf69fe4a6e69d69d451a6040a53b1ea12c),
is probably never used. But for consistency, also use -fllvm here, for
building stage2 and the libraries.
Reviewed by: austin
Differential Revision: https://phabricator.haskell.org/D1228
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just install all packages that are built. Don't make an exception for
the dph and extra packages.
You can control whether the dph and extra packages should be build using
the variables BUILD_DPH and BUILD_EXTRA_PKGS. These variables didn't
exist before. But now that they do, InstallExtraPackages isn't really
needed anymore.
Reviewed by: austin
Differential Revision: https://phabricator.haskell.org/D1227
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that SRC_HC_OPTS are added to every Haskell compilation. So
there isn't any need to also add `-fllvm` to GhcStage1HcOpts,
GhcStage2HcOpts and GhcLibHcOpts.
Small bug fix: make sure we test for -fllvm in SRC_HC_OPTS, to check
whether the bootstrap compiler is affected by bug #9439.
Reviewed by: austin
Differential Revision: https://phabricator.haskell.org/D1188
|
|
|
|
|
|
|
|
|
| |
This allows easier diffing of different BuildFlavours, including
`mk/flavours/validate.mk`.
Reviewed By: bgamari, austin
Differential Revision: https://phabricator.haskell.org/D1050
|
|
|
|
|
|
|
|
|
|
| |
This will allow fixing #1851 more easily
("make install-strip" should work).
This reverts 57e2a81c589103b50da80a9e378b1a11285bd521:
"On Cygwin, use a Cygwin-style path for /bin/install's destination"
Update submodule haddock and hsc2hs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We only support building GHC on mys2 nowadays, see
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows.
This (partially) reverts various commits from a few years ago, among which:
* 5775d5142da227d65fb86994d363eb16841ee642
"Add OSTYPE build-system variable, and use it"
* 3fb8c431824aa2f3bd979e35d1a283546fcfbe74
"Fix building libgmp on cygwin"
* cdbb4720c424500adb57cbbef69721d0b039fa46
"Fix cmd invocation by libffi cuild system on Windows 7 cygwin"
* e8121501ee3549a35e954726ccfd871ac9d51f83
"Fix dblatex and xml* tool detection on Windows"
Reviewed by: austin, Phyx
Differential Revision: https://phabricator.haskell.org/D1155
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: using remote validate
Reviewers: austin, hvr, simonpj, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1117
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch suppresses them until they are fixed
libraries/parallel/Control/Parallel/Strategies.hs:513:2: warning:
Rule "parList/rseq" may never fire
because ‘rseq’ might inline first
Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ‘rseq’
libraries/parallel/Control/Parallel/Strategies.hs:582:1: warning:
Rule "evalBuffer/rseq" may never fire
because ‘rseq’ might inline first
Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ‘rseq’
libraries/parallel/Control/Parallel/Strategies.hs:583:1: warning:
Rule "parBuffer/rseq" may never fire
because ‘rseq’ might inline first
Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ‘rseq’
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC now warns if rules compete, so that it's not predicatable
which will work and which will not. E.g.
{-# RULES
f (g x) = ...
g True = ...
#-}
If we had (f (g True)) it's not clear which rule would fire.
This showed up fraility in the libraries.
* Suppress warnigns in Control.Arrow, Control.Category for class
methods. At the moment we simply don't have a good way to write a
RULE with a class method in the LHS. See Trac #1595. Arrow and
Category attempt to do so; I have silenced the complaints with
-fno-warn-inline-rule-shadowing, but it's not a great solution.
* Adjust the NOINLINE pragma on 'GHC.Base.map' to account for the
map/coerce rule
* Adjust the rewrite rules in Enum, especially for the "literal 1"
case. See Note [Enum Integer rules for literal 1].
* Suppress warnings for 'bytestring' e.g.
libraries/bytestring/Data/ByteString.hs:895:1: warning:
Rule "ByteString specialise break (x==)" may never fire
because rule "Class op ==" for ‘==’ might fire first
Probable fix: add phase [n] or [~n] to the competing rule
|