| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When dumping Cmm groups check if the group is empty, to avoid generating
empty sections in dump files like
==================== Output Cmm ====================
[]
Also fixes a few bad indentation in the code around changes.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed tests:
* haddockA039: added to all.T
* haddockE004: replaced with T17561 (marked as expect_broken)
New tests:
* haddockA040: deriving clause for a data instance
* haddockA041: haddock and CPP #include
|
| |
|
|
|
|
|
|
|
|
| |
As noted in #17624, it's quite unstable, especially, for some reason, on
i386 and armv7 (something about 32-bit platforms perhaps?).
Metric Increase:
T1969
|
|
|
|
|
| |
This makes it easier to see the true magnitude of fluctuations.
Also do some house-keeping in the argument parsing department.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would throw away source ticks when the debug level was
non-zero. This is precisely the opposite of what was intended.
Fixes #17616.
Metric Decrease:
T13056
T9020
T9961
T12425
|
|
|
|
| |
Lest we fail to rebuild when they change. Fixes #17611.
|
|
|
|
|
|
| |
LLVM does not guarantee any particular semantics when dereferencing null
pointers. Consequently, this test actually passes when built with the
LLVM backend.
|
|
|
|
|
|
|
|
|
| |
As noted in #17606, Docker disallows the get_mempolicy syscall by
default. This caused numerous tests to fail under CI in the `debug_numa`
way. Avoid this by disabling the NUMA probing logic when --debug-numa is
in use, instead setting n_numa_nodes in RtsFlags.c.
Fixes #17606.
|
|
|
|
|
| |
Previously things like `+RTS --numa-debug` would enable NUMA support,
despite being an invalid flag.
|
|
|
|
|
| |
This was a hack which is no longer necessary now since we introduce a
dedicated entry block for each procedure.
|
|
|
|
|
|
|
|
|
|
| |
The LLVM IR forbids the entry label of a procedure from having any
predecessors. In the case of a simple looping function the LLVM code
generator broke this invariant, as noted in #17589. Fix this by
moving the function prologue to its own basic block, as suggested by
@kavon in #11649.
Fixes #11649 and #17589.
|
| |
|
|
|
|
| |
Fixes #17586.
|
|
|
| |
Previously we used `AC_DEFINE`d variable `CC_LLVM_BACKEND` which has an empty shell expansion.
|
|
|
|
|
| |
As reported in #17554. Only marking on ARM for now although there is
evidence to suggest that the issue may occur on other platforms as well.
|
| |
|
|
|
|
| |
tested with `bash` and `zsh`.
|
|
|
|
| |
Since it routinely times out in CI.
|
|
|
|
|
|
|
| |
There are many spots in `DsMeta` where `panic` or `notHandled` is
used after pattern-matching on a TTG extension constructor. This is
overkill, however, as using `noExtCon` would work just as well. This
patch switches out these panics for `noExtCon`.
|
|
|
|
|
|
| |
- Remove outdated comments
- Move cutils.c from parser to cbits
- Remove unused cutils.h
|
|
|
| |
to be consistent what FP_GCC_VERSION requires
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Include header file `ghcautoconf.h` where the CPP macro
`WORDS_BIGENDIAN` is defined. This finally fixes #17337 (in conjunction
with commit 6c59cc71dc).
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, `lookupBindGroupOcc`'s error message would recommend all
similar names in scope, regardless of whether they were type
constructors, data constructors, or functions, leading to the
confusion witnessed in #17593. This is easily fixed by only
recommending names in the same namespace, using the
`nameSpacesRelated` function.
Fixes #17593.
|
| |
|
|
|
|
|
|
|
|
| |
We can do a heap census with a non-profiling RTS. With a non-profiling
RTS we don't zero superfluous bytes of shrunk arrays hence a need to
handle the case specifically to avoid a crash.
Revert part of a586b33f8e8ad60b5c5ef3501c89e9b71794bbed
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In our codebase we have some code along the lines of
```
newStdout <- hDuplicate stdout
stderr `hDuplicateTo` stdout
```
to avoid stray `putStrLn`s from corrupting a protocol (LSP) that is
run over stdout.
On CI we have seen a bunch of issues where `dup2` returned `EBUSY` so
this fails with `ResourceExhausted` in Haskell.
I’ve spent some time looking at the docs for `dup2` and the code in
`base` and afaict the following race condition is being triggered
here:
1. The user calls `hDuplicateTo stderr stdout`.
2. `hDuplicateTo` calls `hClose_help stdout_`, this closes the file
handle for stdout.
3. The file handle for stdout is now free, so another thread
allocating a file might get stdout.
4. If `dup2` is called while `stdout` (now pointing to something
else) is half-open, it returns EBUSY.
I think there might actually be an even worse case where `dup2` is run
after FD 1 is fully open again. In that case, you will end up not just
redirecting the original stdout to stderr but also the whatever
resulted in that file handle being allocated.
As far as I can tell, `dup2` takes care of closing the file handle
itself so there is no reason to do this in `hDuplicateTo`. So this PR
replaces the call to `hClose_help` by the only part of `hClose_help`
that we actually care about, namely, `flushWriteBuffer`.
I tested this on our codebase fairly extensively and haven’t been able
to reproduce the issue with this patch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add 'dumpAction' hook to DynFlags.
It allows GHC API users to catch dumped intermediate codes and
information. The format of the dump (Core, Stg, raw text, etc.) is now
reported allowing easier automatic handling.
* Add 'traceAction' hook to DynFlags.
Some dumps go through the trace mechanism (for instance unfoldings that
have been considered for inlining). This is problematic because:
1) dumps aren't written into files even with -ddump-to-file on
2) dumps are written on stdout even with GHC API
3) in this specific case, dumping depends on unsafe globally stored
DynFlags which is bad for GHC API users
We introduce 'traceAction' hook which allows GHC API to catch those
traces and to avoid using globally stored DynFlags.
* Avoid dumping empty logs via dumpAction/traceAction (but still write
empty files to keep the existing behavior)
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Due to #17557.
Also accepting spurious performance change.
Metric Decrease:
T1969
|
|
|
|
| |
This reverts commit 6cfc47ec8a478e1751cb3e7338954da1853c3996.
|
| |
|
|
|
|
|
| |
`T5435_v_asm_a`, `T5435_v_asm_b`, and `T5435_v_gcc` all fail on ARMv7.
See #17559.
|
|
|
|
|
|
|
|
|
|
| |
Previously it would hackily look at the flavour name to determine
whether LLVM was used to build stage2 ghc. However, this didn't work at
all with Hadrian and would miss cases like ARM where we use the LLVM
backend by default.
See #16087 for the motivation for why ghc_built_by_llvm is needed at
all. This should catch one of the ARMv7 failures described in #17555.
|
|
|
|
| |
Due to #17558.
|
|
|
|
| |
Due to #17557.
|
|
|
|
| |
Due to #17556.
|
|
|
|
| |
Due to #17555.
|
|
|
|
|
| |
Due to #17554. It's very surprising that this only occurs on ARMv7 but
this is the only place I've seen this failure thusfar.
|