| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This fixes a regression that led to loss of location information
in error messages about the use of tuple sections in patterns.
(cherry picked from commit df8e8ba267ffd7b8be0702bd64b8c39532359461)
|
| |
|
|
| |
Due to #17945.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
this causes *significant* slowdown on macOS as the linker ends
up looking through all the paths. Slowdown can be as bad as
100% or more.
|
| | |
|
| |
|
|
|
|
|
|
| |
Simon reports that he was previously seeing framework failures due to
an attempt to read the non-existing T13456.stderr. While I don't know
exactly what this is due to, it does seem like a non-existing
.std{out,err} file should be equivalent to an empty file. Teach the
testsuite driver to treat it as such.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit implements a few Windows-specific fixes which get us from a CI
job that can't even get as far as starting the testsuite driver, to a state
where we can run the entire testssuite (but have test failures to fix).
- Don't forget about a potential extension for the haddock program, when
preparing the bindist.
- Build the timeout program, used by the testsuite driver on Windows in place
of the Python script used elsewhere, using the boot compiler. We could
alternatively build it with the compiler that we're going to test but this
would be a lot more tedious to write.
- Implement a wrapper-script less installation procedure for Windows, in
`hadrian/bindist/Makefile.
- Make dependencies a bit more accurate in the aforementioned Makefile.
- Update Windows/Hadrian CI job accordingly.
This patch fixes #17486.
|
| |
|
|
| |
partial backport of !4890
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
We now seem to use -Werror there. Which caused some long standing
warnings to become errors.
I applied changes to remove the warnings allowing the testsuite to
run on windows as well.
|
| |
|
|
|
| |
-Wno-unsupported-llvm-version should suppress the LLVM version
missmatch warning that messes up the output.
|
| | |
|
| | |
|
| |
|
|
| |
Now also for integer-gmp
|
| | |
|
| | |
|
| |
|
|
| |
There is no libstdc++, only libc++
|
| | |
|
| |
|
|
|
|
|
|
| |
Previously we were invoking:
bash -c
"c:/GitLabRunner/builds/eEQrxK4p/0/ghc/ghc/toolchain/bin/ghc.exe.exe
testsuite/mk/ghc-config.hs -o _build/test/bin/ghc-config.exe"
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Notes appear to be 8byte aligned instead of 4 as on x86_64 :facepalm:
See: https://reviews.llvm.org/D70962
> The .note.gnu.property SHT_NOTE sections on AArch64 (a 64-bit target) should have alignment 8 to more closely match the binutils implementation where alignment is 4-bytes on 32-bit machines and 8-bytes on 64-bit machines.
> Previously LLD was using 4 for both 32-bit and 64-bit machines.
> There was a long discussion on the right alignment of the .note.gnu.property section on the binutils mailing list. The basic argument was that generic ELF requires 8-byte alignment for SHT_NOTES sections, however this hadn't been respected by other GNU notes sections. The implementation in GNU ld uses 8 and as there is no binary legacy of using 4 in LLD (BTI is only just being picked up and used) I'd like to keep LLD in line with GNU ld.
> Although at present LLD only does something useful with AArch64 properties, this also applies to X86.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This resolves the following:
Compile failed (exit code 1) errors were:
conc059_c.c:27:5: error:
error: implicitly declaring library function 'exit' with type 'void (int) __attribute__((noreturn))' [-Werror,-Wimplicit-function-declaration]
exit(0);
^
conc059_c.c:27:5: error:
note: include the header <stdlib.h> or explicitly provide a declaration for 'exit'
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
So we did *not* have the stgCallocBytes prototype, and subsequently
the C compiler defaulted to `int` as a return value. Thus generating
sxtw instructions for the return value of stgCalloBytes to produce
the expected void *.
|
| | |
|
| | |
|
| |
|
|
| |
Due to #17607.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
markLiveObject is called by GC worker threads and therefore must be
thread-safe. This was a rather egregious oversight which the testsuite
missed.
|
| | |
|
| | |
|
| |
|
|
|
| |
We don't pass MAKE_ARGS for windows builds, so this should unbreak
them.
|
| | |
|
| |
|
|
| |
We now have a proper periodic clean-up script installed on the runners.
|
| |
|
|
| |
See https://gitlab.haskell.org/ghc/ghc/-/issues/17018
|
| | |
|
