| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a module uses a class, then it can instantiate the class and
thereby use its default methods, so we must include the default
methods when calculating the fingerprint for the class.
Test Plan:
New unit test: driver/T15970
Before:
```
=====> T15970(normal) 1 of 1 [0, 0, 0]
cd "T15970.run" && $MAKE -s --no-print-directory T15970
Wrong exit code for T15970()(expected 0 , actual 2 )
Stdout ( T15970 ):
Makefile:13: recipe for target 'T15970' failed
Stderr ( T15970 ):
C.o:function Main_zdfTypeClassMyDataType1_info: error: undefined
reference to 'A_toTypedData2_closure'
C.o:function Main_main1_info: error: undefined reference to
'A_toTypedData2_closure'
C.o(.data+0x298): error: undefined reference to 'A_toTypedData2_closure'
C.o(.data+0x480): error: undefined reference to 'A_toTypedData2_closure'
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
```
After: test passes.
Reviewers: bgamari, simonpj, erikd, watashi, afarmer
Subscribers: rwbarton, carter
GHC Trac Issues: #15970
Differential Revision: https://phabricator.haskell.org/D5394
(cherry picked from commit 288f681e06accbae690c46eb8a6e997fa9e5f56a)
|
|
|
|
| |
(cherry picked from commit 1c0c5e844226f3d77af31d97b21ffb8b14b55740)
|
|
|
|
|
|
|
|
| |
As documented in #15382, this is known to fail in prof_hc_hb on i386.
Concerningly, I have also seen this test non-deterministically fail in
prof_hc_hb on amd64. We should really investigate this.
(cherry picked from commit 8fd3f9a67f9c7b447a5bfcb3aefd8986794918ce)
|
| |
|
|
|
|
|
|
| |
As noted in #16085 this test is fragile in unregisterised compilers.
(cherry picked from commit 7bfc1e81377d1e37069cf52bd090530124dcd871)
|
|
|
|
| |
These are just too fragile on ghc-8.6 which lacks #12758.
|
|
|
|
|
| |
This is awfully ugly but is nevertheless significantly less error-prone
than cherry-picking all of the relevant commits manually.
|
|
|
|
|
|
| |
This ended up breaking GHCi due to alignment issues. See #16071.
This reverts commit ed86e3b531322f74d2c2d00d7ff8662b08fabde6.
|
|
|
|
|
|
| |
Fixes #16023.
(cherry picked from commit e709c8f8d45c699840f5bab7c9ff71373a53b8b0)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Do full build on Windows.
Reviewers: AndreasK, Phyx
Reviewed By: AndreasK
Subscribers: rwbarton, erikd, carter
GHC Trac Issues: #15934
Differential Revision: https://phabricator.haskell.org/D5383
(cherry picked from commit 1ef90f990da90036d481c830d8832e21b8f1571b)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes a corner case in which we have seen the symbol multiple times in
different static libraries, but due to a depencency we end up loading the
symbol from a library other than the first one.
Previously the runtime linker would only track symbols from the first
library and did not store the full link map. In this case it was unable
to find the address for the symbols in the second library during delay
loading.
This change stores the address of all symbols seen so a full link map
is generated, such that when we make a different decision later than what
was expected we're able to still correctly load the library.
Test Plan: ./validate, new testcase T15894
Reviewers: angerman, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, carter
GHC Trac Issues: #15894
Differential Revision: https://phabricator.haskell.org/D5353
(cherry picked from commit a8b7cef4d45a5003bf7584e06912f0f632116c71)
|
|
|
|
|
| |
This fixes #15866, the original fix for which didn't merge cleanly to
the stable branch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Retainer profiling contained a recursion that under
certain circumstances could lead to the stack overflow
in C code.
The idea of the improvement is to keep an explicit stack for the
object, more precise to reuse existing stack, but allow new type of
objects to be stored there.
There is no reliable reproducer that is not a big program
but in some cases foldr (+) 0 [1..10000000] can work.
Reviewers: bgamari, simonmar, erikd, osa1
Reviewed By: bgamari, osa1
Subscribers: osa1, rwbarton, carter
GHC Trac Issues: #14758
Differential Revision: https://phabricator.haskell.org/D5351
(cherry picked from commit 5f1d949ab9e09b8d95319633854b7959df06eb58)
|
|
|
|
|
|
|
|
|
|
|
|
| |
We thought that visible dependent quantification was impossible
in terms, but Iceland Jack discovered otherwise in #15859. This fixes an
ASSERT failure that arose.
test case: dependent/should_fail/T15859
(cherry picked from commit 72b82343b79365dc74ffafb345dd33499a7fd394)
(cherry picked from commit 5693ddd071033516a1804420a903cb7e3677682b)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed in #15715, the POSIX specification specifies that
attempting to open a FIFO in write-only mode when the FIFO has no
readers will fail with -ENOENT.
[skip ci]
Test Plan: Read it
Reviewers: hvr
Subscribers: rwbarton, carter
GHC Trac Issues: #15715
Differential Revision: https://phabricator.haskell.org/D5295
(cherry picked from commit 4ba3fa31ddfa12b428bd67216a2d4118dc9e8311)
|
|
|
|
| |
This reverts commit cbde2726f10b8f4c19483bbb755ad42356098c51.
|
|
|
|
|
|
| |
Fixes #15105
(cherry picked from commit 254890855ee04762cc0392da19e0c42fc039a718)
|
|
|
|
|
|
| |
Eliminates a bit of repetition.
(cherry picked from commit b2f6f896a0bae0e68ec629bd6817a2cb2533a12c)
|
|
|
|
| |
(cherry picked from commit 9e0a23b95c285c4019fd2d36102374ee582f1dcb)
|
|
|
|
|
|
| |
Fixes #15404.
(cherry picked from commit 3584bd4255eb59be043252c9b4ef16bcbd835c9b)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The logic in `Note [recursive SRTs]` was correct. However, my
implementation of it wasn't: I got the associativity of
`Set.difference` wrong, which led to an extremely subtle and difficult
to find bug.
Fortunately now we have a test case. I was able to cut down the code
to something manageable, and I've added it to the test suite.
Test Plan:
Before (using my stage 1 compiler without the fix):
```
====> T15892(normal) 1 of 1 [0, 0, 0]
cd "T15892.run" && "/home/smarlow/ghc/inplace/bin/ghc-stage1" -o T15892
T15892.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts
-fno-warn-missed-specialisations -fshow-warning-groups
-fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat
-dno-debug-output -O
cd "T15892.run" && ./T15892 +RTS -G1 -A32k -RTS
Wrong exit code for T15892(normal)(expected 0 , actual 134 )
Stderr ( T15892 ):
T15892: internal error: evacuate: strange closure type 0
(GHC version 8.7.20181113 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
*** unexpected failure for T15892(normal)
=====> T15892(g1) 1 of 1 [0, 1, 0]
cd "T15892.run" && "/home/smarlow/ghc/inplace/bin/ghc-stage1" -o T15892
T15892.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts
-fno-warn-missed-specialisations -fshow-warning-groups
-fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat
-dno-debug-output -O
cd "T15892.run" && ./T15892 +RTS -G1 -RTS +RTS -G1 -A32k -RTS
Wrong exit code for T15892(g1)(expected 0 , actual 134 )
Stderr ( T15892 ):
T15892: internal error: evacuate: strange closure type 0
(GHC version 8.7.20181113 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
```
After (using my stage 2 compiler with the fix):
```
=====> T15892(normal) 1 of 1 [0, 0, 0]
cd "T15892.run" && "/home/smarlow/ghc/inplace/test spaces/ghc-stage2"
-o T15892 T15892.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts
-fno-warn-missed-specialisations -fshow-warning-groups
-fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat
-dno-debug-output
cd "T15892.run" && ./T15892 +RTS -G1 -A32k -RTS
=====> T15892(g1) 1 of 1 [0, 0, 0]
cd "T15892.run" && "/home/smarlow/ghc/inplace/test spaces/ghc-stage2"
-o T15892 T15892.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts
-fno-warn-missed-specialisations -fshow-warning-groups
-fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat
-dno-debug-output
cd "T15892.run" && ./T15892 +RTS -G1 -RTS +RTS -G1 -A32k -RTS
```
Reviewers: bgamari, osa1, erikd
Reviewed By: osa1
Subscribers: rwbarton, carter
GHC Trac Issues: #15892
Differential Revision: https://phabricator.haskell.org/D5334
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, tdammers
Reviewed By: tdammers
Subscribers: monoidal, rwbarton, carter
GHC Trac Issues: #15633
Differential Revision: https://phabricator.haskell.org/D5348
(cherry picked from commit 599eaada382d04722219bfc319bde94591be3fb1)
|
|
|
|
|
|
| |
Previously we should just blinding dereference a NULL pointer.
(cherry picked from commit 86f6890e3689f2f75ecca8172eda0338fe3e9769)
|
|
|
|
|
|
| |
We now generally use split-sections instead.
(cherry picked from commit f5fbecc85967218fd8ba6512f10eea2daf2812ac)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See #15906 for the problem. To fix we simply call `allocate()` instead of
`ALLOC_PRIM()`. `allocate()` does not trigger GC when the nursery is full,
instead it extends it.
Test Plan:
This validates. memo001 now passes with `-debug` compile parameter. I'll add
another test that runs memo001 with `-debug` once I figure out how to use
stdout files for multiple tests.
Reviewers: simonmar, bgamari, erikd
Reviewed By: simonmar
Subscribers: rwbarton, carter
GHC Trac Issues: #15906
Differential Revision: https://phabricator.haskell.org/D5342
(cherry picked from commit 691aa715cf43bf9d88ee32bca37e471bae35adfb)
|
|
|
|
| |
This fixes #15875.
|
|
|
|
|
| |
Previously the version number was set by hand. This seems like
unnecessary busywork for what is mostly an internal library.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
newFamInst lints its types. This is good. But it's not so good
when there have been errors and thus recovery tycons are about.
So we now don't.
Fixes #15796.
Test case: typecheck/should_fail/T15796
(cherry picked from commit 1f72a1c81368e34387aac38c0b1c59521cec58ec)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In type-incorrect code, we can sometimes let a coercion
hole make it through the zonker. If this coercion hole then
ends up in the environment (e.g., in the type of a data
constructor), then it causes trouble later.
This patch avoids trouble by substituting the coercion hole
for its representative CoVar. Really, any coercion would do,
but the CoVar was very handy.
test case: polykinds/T15787
(cherry picked from commit 4427315a65b25db22e1754d41b43dd4b782b022f)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An unfortunate consequence of commit
b9483981d128f55d8dae3f434f49fa6b5b30c779 (`Remove HsEqTy and XEqTy`)
is infix uses of `~` in TH quotes now desugar differently than
before. In particular, we have that:
```haskell
a ~ (Int -> Int)
```
Now desugars to:
```haskell
HsOpTy a (~) (HsOpTy Int (->) Int)
```
Which GHC interprets as being:
```haskell
a ~ Int -> Int
```
Or, equivalently:
```haskell
(a ~ Int) -> Int
```
Which is different than what was intended! This is the cause
of #15815.
All of this has revealed that we likely need to renovate the way we
desugar infix type operators to be more consistent with the treatment
for infix expressions (see
https://ghc.haskell.org/trac/ghc/ticket/15815#comment:5 for more on
this.) Doing so would constitute a breaking change, however, so we
will likely want to wait until another major GHC release to do this.
In the meantime, this patch offers a non-invasive change to the way
that infix uses of `~` are desugared. This makes the program
in #15815 compile again by inserting extra `HsParTy`s around the
arguments to `~` if they are lacking them.
Test Plan: make test TEST=T15815
Reviewers: int-index, goldfire, bgamari
Reviewed By: int-index
Subscribers: int-e, rwbarton, carter
GHC Trac Issues: #15815
Differential Revision: https://phabricator.haskell.org/D5274
(cherry picked from commit b8a797ecc34a309bd78f5a290e3554642a3a478a)
|
|
|
|
|
|
|
| |
This reverts commit 73273be476a8cc6c13368660b042b3b0614fd928.
Unfortunately we were unable to come to a fix that didn't sacrifice the
ability to bootstrap GHC using the LLVM backend. Reverting for 8.6.2.
|
|
|
|
| |
This reverts commit 2e23e1c7de01c92b038e55ce53d11bf9db993dd4.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We suppress some Given errors; see Note [Given errors]
in TcErrors. But we must be careful not to suppress
Wanted errors because of the presence of these Given
errors -- else we might allow compilation to bogusly
proceed
The rubber hits the road in TcRnTypes.insolubleCt,
where we don't want to treat Givens as insoluble,
nor (and this is the new bit) Deriveds that arise
from Givens. See Note [Given insolubles] in TcRnTypes.
This fixes #15767.
(cherry picked from commit 6b1102e2cfcffb265fd33cf8a99ab5e6b3f14906)
Ben notes:
I have folded some test output changes in `TEST="T12529 T12921 mc13
mc14"` into this patch that were not in the original.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch fixes #15805, where we found that
`TcType.anyRewritableTyVar` has one wrong case.
Besides the fix, it also:
- removed some unnecessary `ASSERT2(tcIsTcTyVar...)` in `TcType`, as now we have
`tcIsTcTyVar = isTyVar`.
- fixed some comments
Test Plan: ./validate
Reviewers: goldfire, simonpj, bgamari
Reviewed By: simonpj
Subscribers: rwbarton, carter
GHC Trac Issues: #15805
Differential Revision: https://phabricator.haskell.org/D5263
(cherry picked from commit a7f64c6cbfc5562adff207945576d1c9db2a58d9)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
on windows, plugins are loaded via .a files,
but those paths were not being searched when loading plugins
Test Plan: ./validate
Reviewers: Phyx, bgamari
Reviewed By: Phyx
Subscribers: RyanGlScott, rwbarton, carter
GHC Trac Issues: #15700
Differential Revision: https://phabricator.haskell.org/D5253
(cherry picked from commit 70298db16c3f0ea4adb603ccb2b5e93eb9c7a556)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Although these functions were marked as CONSTANT_FOLDED, they did
not have a corresponding builtinRule in PrelRules. The idea was
probably to add them eventually, but this hasn't manifested so
far.
The plan is to eventually add builtin rules for these functions
over Natural, so as a reminder we simply comment out the
CONSTANT_FOLDED annotation instead of removing it completely.
Reviewers: hvr, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, carter
Differential Revision: https://phabricator.haskell.org/D5267
(cherry picked from commit 3ec6fe8827956cc36b58cdf0bb1f5752eaa2a8ea)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Ticket #15271 reports a case where 1e1000000000 is incorrectly
converted to 0.0. After some investigation, I discovered the number is
converted to rational correctly, but converting the ratio into a double
introduced an error.
Tracking down to how the conversion is done, I found the rts float
implementation uses `ldexp`, whose signature is
`double ldexp (double x, int exp);`
The callsite passes an `I_` to the second argument, which is
platform-dependent. On machines where `I_` is 64 bits and `int` is 32 bits, we
observe integer overflow behaviour.
Here is a mapping from rational to exponent with observations
1e646457008 -> 2147483645 (result = infinity, positive in int32)
1e646457009 -> 2147483648 (result = 0.0, overflow to negative in int32)
1e1000000000 -> 3321928042 (result = infinity, overflow to positive in int32)
1e1555550000 -> 5167425196 (result = 0.0, overflow to negative in int32)
We fix this issue by comparing STG_INT_MIN/MAX and INT_MIN/MAX and bound the
value appropriately.
Test Plan: New test cases
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, carter
GHC Trac Issues: #15271
Differential Revision: https://phabricator.haskell.org/D5271
(cherry picked from commit 311a63979cfa2c1e81be54b82205e681f6ec4f14)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch fixes #15806, where we found that the `:k` command in GHCi
misses a validity checking for the type.
Missing validity checking causes `:k` to accept types that are not validated.
For example, `:k (Maybe (forall a. a -> a))` (incorrectly) returns `*`, while
impredictivity of type instantiation shouldn't be allowed.
Test Plan: ./validate
Reviewers: simonpj, goldfire, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, carter
GHC Trac Issues: #15806
Differential Revision: https://phabricator.haskell.org/D5265
(cherry picked from commit 12cb5cf50b8b35394e2e2d57e1ac693c76f90833)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fixes #14784. Note that C++11 is quite conservative; we could likely accept
C++03 as well.
Test Plan:
```
$ cat >hi.c <<EOF
#include <Rts.h>
EOF
$ g++ -std=c++11 hi.c
```
Reviewers: simonmar, hvr
Subscribers: rwbarton, carter
GHC Trac Issues: #14784
Differential Revision: https://phabricator.haskell.org/D5244
(cherry picked from commit d3a1022fabb0ad337003fac774c6929f402ecb8b)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Encountered assembly error due to undefined label `.LcaDcU_info_end` for
following code generated by `pprFrameProc`:
```
.Lsat_sa8fp{v}_info_fde_end:
.long .Lblock{v caDcU}_info_fde_end-.Lblock{v caDcU}_info_fde
.Lblock{v caDcU}_info_fde:
.long _nbHlD-.Lsection_frame
.quad block{v caDcU}_info-1
.quad .Lblock{v caDcU}_info_end-block{v caDcU}_info+1
.byte 1
```
This diff fixed the error.
Test Plan:
./validate
Also the case where we used to have assembly error is now fixed.
Unfortunately, I have limited insight here and cannot get a small enough repro
or test case for this.
Ben says:
> I think I see: Previously we only produced end symbols for the info
> tables of top-level procedures. However, blocks within a procedure may
> also have info tables, we will dutifully generate debug information for
> and consequently we get undefined symbols.
Reviewers: simonmar, scpmw, last_g, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, carter
Differential Revision: https://phabricator.haskell.org/D5246
(cherry picked from commit cf961dcf5ebc26cbd960196ba387736334088303)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now calculate the SSE register padding needed to fix the calling
convention in LLVM in a robust way: grouping them by whether
registers in that class overlap (with the same class overlapping
itself).
My prior patch assumed that no matter the platform, physical
register Fx aliases with Dx, etc, for our calling convention.
This is unfortunately not the case for any platform except x86-64.
Test Plan:
Only know how to test on x86-64, but it should be tested on ARM with:
`make test WAYS=llvm && make test WAYS=optllvm`
Reviewers: bgamari, angerman
Reviewed By: bgamari
Subscribers: rwbarton, carter
GHC Trac Issues: #15780, #14251, #15747
Differential Revision: https://phabricator.haskell.org/D5254
(cherry picked from commit c36a2b596a6ba9d7a0a80df01b3c041720c727ca)
|