- Dec 06, 2018
-
-
Ben Gamari authored
-
Ben Gamari authored
-
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 1ef90f99)
-
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 a8b7cef4)
-
Ben Gamari authored
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 5f1d949a)
-
- Nov 22, 2018
-
-
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 4ba3fa31)
-
Ben Gamari authored
This reverts commit cbde2726.
-
Fixes #15105 (cherry picked from commit 25489085)
-
Eliminates a bit of repetition. (cherry picked from commit b2f6f896)
-
(cherry picked from commit 9e0a23b9)
-
Fixes #15404. (cherry picked from commit 3584bd42)
-
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
-
Christiaan Baaij authored
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 599eaada)
-
Ben Gamari authored
Previously we should just blinding dereference a NULL pointer. (cherry picked from commit 86f6890e)
-
Ben Gamari authored
We now generally use split-sections instead. (cherry picked from commit f5fbecc8)
-
Ömer Sinan Ağacan authored
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 691aa715)
- Nov 08, 2018
-
-
Ben Gamari authored
This fixes #15875.
-
- Nov 06, 2018
-
-
Ben Gamari authored
Previously the version number was set by hand. This seems like unnecessary busywork for what is mostly an internal library.
-
- Nov 05, 2018
-
-
Ben Gamari authored
-
- Nov 02, 2018
-
-
Ben Gamari authored
-
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 1f72a1c8)
-
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 4427315a)
-
- Oct 31, 2018
-
-
Ben Gamari authored
-
- Oct 30, 2018
-
-
Ben Gamari authored
-
Ryan Scott authored
An unfortunate consequence of commit b9483981 (`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 b8a797ec)
-
Ben Gamari authored
This reverts commit 73273be4. 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.
-
Ben Gamari authored
This reverts commit 2e23e1c7.
-
Ben Gamari authored
-
Simon Peyton Jones authored
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 6b1102e2) Ben notes: I have folded some test output changes in `TEST="T12529 T12921 mc13 mc14"` into this patch that were not in the original.
-
- Oct 28, 2018
-
-
Ningning Xie authored
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 a7f64c6c)
-
Ben Gamari authored
-
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)
-
Christiaan Baaij authored
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)
-
Ningning Xie authored
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)
-