- Oct 26, 2015
-
-
Ben Gamari authored
Otherwise we get a C-- lint error due to mismatched RHS and variable types.
-
- Oct 22, 2015
-
-
-
Ben Gamari authored
Some day I'll learn to validate before pushing.
-
Previous suggestion would clear executable bit, meaning directory couldn't be entered. Fixes #11003. Test Plan: Read message. Reviewers: austin, thomie, dfeuer Reviewed By: thomie, dfeuer Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1350 GHC Trac Issues: #11003
-
Simon Peyton Jones authored
-
Previously, foldr1 would be defiend recursively and thus not inline. This is bad, for example, when maximumBy has a strict comparison function: Before the BBP, it was implemented via foldl1, which inlined and yielded good code. With BBP, it goes via foldr1, so we better inline this as well. Fixes #10830. Differential Revision: https://phabricator.haskell.org/D1205
-
-
Make Linker.hs try asking gcc for lib%s.dll as well, also changed tryGcc to pass -L to all components by using -B instead. These two fix shortnames linking on windows. re-enabled tests: ghcilink003, ghcilink006 and T3333 Added two tests: load_short_name and enabled T1407 on windows. Reviewed By: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1310 GHC Trac Issues: #9878, #1407, #1883, #5289
-
For example ``` pattern head `Cons` tail = head : tail ``` Reviewed By: goldfire, austin Differential Revision: https://phabricator.haskell.org/D1295 GHC Trac Issues: #10747
-
The implementation of `mask` and `uninterruptibleMask` assumed so far that the restore argument would be called in a context with the same masking state as that set by `mask` or `uninterruptibleMask`. This patch has the restore argument restore the masking, whatever the current masking state is. Test Plan: validate Reviewers: simonmar, hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie, qnikst Differential Revision: https://phabricator.haskell.org/D1327 GHC Trac Issues: #10149
-
Among doing other things, Phab:D201 (bc2289e1) tried to improve the error messages thrown by the parser. For example a missing else clause now prints "parse error in if statement: else clause empty" instead of "parse error (possibly incorrect indentation or mismatched brackets)". Some error messages got much worse however (see tests), and the result seems to be a net negative. Although not entirely satisfactory, this commits therefore reverts those parser changes. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1309 GHC Trac Issues: #10498
-
-
Arm has two instruction sets, Arm and Thumb, and an execution mode for each. Executing Arm code in Thumb mode or vice-versa will likely result in an Illegal instruction exception. Furthermore, Haskell code compiled via LLVM was generating Arm instructions while C code compiled via GCC was generating Thumb code by default. When these two object code types were being linked by the system linker, all was fine, because the system linker knows how to jump and call from one instruction set to the other. The first problem was with GHCi's object code loader which did not know about Thumb vs Arm. When loading an object file `StgCRun` would jump into the loaded object which could change the mode causing a crash after it returned. This was fixed by forcing all C code to generate Arm instructions by passing `-marm` to GCC. The second problem was the `mkJumpToAddr` function which was generating Thumb instructions. Changing that to generate Arm instructions instead results in a working GHCi on Arm. Test Plan: validate on x86_64 and arm Reviewers: bgamari, austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1323 GHC Trac Issues: #10375
-
Simon Peyton Jones authored
A missing 'closeOverKinds' triggered Trac #10934. Happily the fix is simple. Merge to 7.10.3
-
Richard Eisenberg authored
This makes two real changes: - Equalities like (a ~R [a]) really *are* insoluble. Previously, GHC refused to give up when an occurs check bit on a representational equality. But for datatypes, it really should bail. - Now, GHC will sometimes report an occurs check error (in cases above) for representational equalities. Previously, it never did. This "fixes" #10715, where by "fix", I mean clarifies the error message. It's unclear how to do more to fix that ticket. Test cases: typecheck/should_fail/T10715{,b}
-
Richard Eisenberg authored
This change means that the intricate reasoning in TcErrors around getting messages just right for nominal equalities is skipped for representational equalities.
-
Richard Eisenberg authored
-
The Windows Linker has 3 main parts that this patch changes. 1) Identification and classification of sections 2) Adding of symbols to the symbols tables 3) Reallocation of sections 1. Previously section identification used to be done on a whitelisted basis. It was also exclusively being done based on the names of the sections. This meant that there was a bit of a cat and mouse game between `GCC` and `GHC`. Every time `GCC` added new sections there was a good chance `GHC` would break. Luckily this hasn't happened much in the past because the `GCC` versions `GHC` used were largely unchanged. The new code instead treats all new section as `CODE` or `DATA` sections, and changes the classifications based on the `Characteristics` flag in the PE header. By doing so we no longer have the fragility of changing section names. The one exception to this is the `.ctors` section, which has no differentiating flag in the PE header, but we know we need to treat it as initialization data. The check to see if the sections are aligned by `4` has been removed. The reason is that debug sections often time are `1 aligned` but do have relocation symbols. In order to support relocations of `.debug` sections this check needs to be gone. Crucially this assumption doesn't seem to be in the rest of the code. We only check if there are at least 4 bytes to realign further down the road. 2. The second loop is iterating of all the symbols in the file and trying to add them to the symbols table. Because the classification of the sections we did previously are (currently) not available in this phase we still have to exclude the sections by hand. If they don't we will load in symbols from sections we've explicitly ignored the in # 1. This whole part should rewritten to avoid this. But didn't want to do it in this commit. 3. Finally the sections are relocated. But for some reason the PE files contain a Linux relocation constant in them `0x0011` This constant as far as I can tell does not come from GHC (or I couldn't find where it's being set). I believe this is probably a bug in GAS. But because the constant is in the output we have to handle it. I am thus mapping it to the constant I think it should be `0x0003`. Finally, static linking *should* work, but won't. At least not if you want to statically link `libgcc` with exceptions support. Doing so would require you to link `libgcc` and `libstd++` but also `libmingwex`. The problem is that `libmingwex` also defines a lot of symbols that the RTS automatically injects into the symbol table. Presumably because they're symbols that it needs. like `coshf`. The these symbols are not in a section that is declared with weak symbols support. So if we ever want to get this working, we should either a) Ask mingw to declare the section as such, or b) treat all a imported symbols as being weak. Though this doesn't seem like it's a good idea.. Test Plan: Running ./validate for both x86 and x86_64 Also running the specific test case for #10672 make TESTS="T10672_x86 T10672_x64" Reviewed By: ezyang, thomie, austin Differential Revision: https://phabricator.haskell.org/D1244 GHC Trac Issues: #9907, #10672, #10563
-
Andrew Farmer authored
HERMIT users depend on RULES to specify equational properties. 6.10.2 performed both inlining and simplification in both sides of the rules, meaning they can't really be used for this. This breaks most HERMIT use cases. A separate commit already disabled this for the LHS of rules. This does so for the RHS. See Trac #10829 for nofib results. Reviewed By: austin, bgamari, simonpj Differential Revision: https://phabricator.haskell.org/D1246 GHC Trac Issues: #10829
-
Ben Gamari authored
-
This patch does a few things - Moved GHC x86 to MinGW-w64 (Using Awson's patch) - Moves Both GHCs to MSYS2 toolchains - Completely removes the dependencies on the git tarball repo - Downloads only the required tarball for the architecture for which we are building - Downloads the perl tarball is missing as well - Fixed a few bugs in the linker to fix tests on Windows The links currently point to repo.msys2.org and GitHub, it might be more desirable to mirror them on http://downloads.haskell.org/~ghc/mingw/ as with the previous patch attempt. For more details on what the MSYS2 packages I include see #10726 (Awson's comment). but it should contain all we need and no python or fortran, which makes the uncompressed tar a 1-2 hundreds mb smaller. The `GCC 5.2.0` in the package supports `libgcc` as a shared library, this is a problem since when compiling with -shared the produced dll now has a dependency on `libgcc_s_sjlj-1.dll`. To solve this the flag `-static-libgcc` is now being used for all GCC calls on windows. Test Plan: ./validate was ran both on x86 and x86_64 windows and compared against the baseline. A few test were failing due to Ld no longer being noisy. These were updated. The changes to the configure script *should* be validated by the build bots for the other platforms before landing Reviewers: simonmar, awson, bgamari, austin, thomie Reviewed By: thomie Subscribers: #ghc_windows_task_force, thomie, awson Differential Revision: https://phabricator.haskell.org/D1123 GHC Trac Issues: #10726, #9014, #9218, #10435 -
This fixes more testsuite failures on Windows. Signed-off-by:Austin Seipp <austin@well-typed.com>
-
This fixes the FreeBSD build.
-
Currently checking out the source on windows requires two git checkouts. One for the GHC sources and one for the GHC-tarballs. This patch will make configure issue an error if compiling under windows and the GHC-tarballs folder is missing. On failure the user is told which command they need to run to get the tarballs or if they want configure to handle it for them configure provide the `--enable-tarballs-autodownload` flag. Test Plan: 1. make sure ghc-tarballs folder is not present 2. run ./configure which should fail giving an error that tarballs is missing and how to get it 3. run ./configure --enable-tarballs-autodownload and the tarballs should be downloaded and configure finishes 4. rerun the command in 3, no new download should be done. 5. run configure without --enable-tarballs-autodownload, configure should finish correctly. Reviewers: bgamari, austin, thomie Reviewed By: thomie Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1108 GHC Trac Issues: #10705
-
Ben Gamari authored
Fixes #10571.
-
Ben Gamari authored
Apparently some Clang 3.6 expects these to be sorted. Patch due to Peter Wortmann. Fixes #10687.
-
Ben Gamari authored
This was likely due to an incorrectly merged conflict during cherry-picking.
-
Back port of Peter Trommler's patch from master (19dae027cb) to the 7.10 branch. Peter's commit does not apply to the 7.10 branch because PowerPC64 was added to master after the 7.10 branch was started. Comments from the original commit: Implement access to spill slots at offsets larger than 16 bits. Also allocation and deallocation of spill slots was restricted to 16 bit offsets. Now 32 bit offsets are supported on all PowerPC platforms. The implementation of 32 bit offsets requires more than one instruction but the native code generator wants one instruction. So we implement pseudo-instructions that are pretty printed into multiple assembly instructions. With pseudo-instructions for spill slot allocation and deallocation we can also implement handling of the back chain pointer according to the ELF ABIs.
-
Richard Eisenberg authored
This fixes #10810 by cleaning up pretty-printing of constructor declarations. This change also removes a (in my opinion) deeply bogus orphan instance OutputableBndr [Located name], making HsDecls now a non-orphan module. Yay all around. Test case: th/T10810
-
Some headers used `new` as parameter name, which is reserved word in C++. This patch changes these names to `new_`. Test Plan: validate Reviewers: austin, ezyang, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1107 GHC Trac Issues: #10700
-
-
Ben Gamari authored
-
-
Here we fix a few mis-optimizations that could occur in code with floating point comparisons with -0.0. These issues arose from our insistence on rewriting equalities into case analyses and the simplifier's ignorance of floating-point semantics. For instance, in Trac #10215 (and the similar issue Trac #9238) we turned `ds == 0.0` into a case analysis, ``` case ds of __DEFAULT -> ... 0.0 -> ... ``` Where the second alternative matches where `ds` is +0.0 and *also* -0.0. However, the simplifier doesn't realize this and will introduce a local inlining of `ds = -- +0.0` as it believes this is the only value that matches this pattern. Instead of teaching the simplifier about floating-point semantics we simply prohibit case analysis on floating-point scrutinees and keep this logic in the comparison primops, where it belongs. We do several things here, - Add test cases from relevant tickets - Clean up a bit of documentation - Desugar literal matches against floats into applications of the appropriate equality primitive instead of case analysis - Add a CoreLint to ensure we don't pattern match on floats in Core Test Plan: validate with included testcases Reviewers: goldfire, simonpj, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1061 GHC Trac Issues: #10215, #9238
-
Christiaan Baaij authored
This fixes the GHC side of trac #10568. So `cabal install --ghc-options="-framework GLUT" GLUT` creates a correctly linked GLUT.dylib. We still need to explictly pass `--ghc-options="-framework GLUT"` because the Cabal side #10568 is not fixed. Update: the Cabal side of #10568 is fixed by [Cabal#2747](https://github.com/haskell/cabal/pull/2747) Test Plan: validate Reviewers: austin, rwbarton, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D1115 GHC Trac Issues: #10568
-
Summary: See Note [MallocPtr finalizers] Test Plan: validate; new test T10904 Reviewers: ezyang, bgamari, austin, hvr, rwbarton Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1275
-
Richard Eisenberg authored
This fixes #10855.
-
which might help, as it has helped with lots of other TH-related test cases in the past.
-
Edward Z. Yang authored
Test Plan: validate Reviewers: goldfire, austin, simonpj, bgamari Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1026 GHC Trac Issues: #10596
-
Alexander found a interesting case: 1. We have a queue of two waiters in a blocked_queue 2. first file descriptor changes state to RUNNABLE, second changes to INVALID 3. awaitEvent function dequeued RUNNABLE thread to a run queue and attempted to dequeue INVALID descriptor to a run queue. Unqueueing INVALID fails thusly: #3 0x000000000045cf1c in barf (s=0x4c1cb0 "removeThreadFromDeQueue: not found") at rts/RtsMessages.c:42 #4 0x000000000046848b in removeThreadFromDeQueue (...) at rts/Threads.c:249 #5 0x000000000049a120 in removeFromQueues (...) at rts/RaiseAsync.c:719 #6 0x0000000000499502 in throwToSingleThreaded__ (...) at rts/RaiseAsync.c:67 #7 0x0000000000499555 in throwToSingleThreaded (..) at rts/RaiseAsync.c:75 #8 0x000000000047c27d in awaitEvent (wait=rtsFalse) at rts/posix/Select.c:415 The problem here is a throwToSingleThreaded function that tries to unqueue a TSO from blocked_queue, but awaitEvent function leaves blocked_queue in a inconsistent state while traverses over blocked_queue: case RTS_FD_IS_READY: IF_DEBUG(scheduler, debugBelch("Waking up blocked thread %lu\n", (unsigned long)tso->id)); tso->why_blocked = NotBlocked; tso->_link = END_TSO_QUEUE; // Here we break the queue head pushOnRunQueue(&MainCapability,tso); break; Signed-off-by:Sergei Trofimovich <siarheit@google.com> Test Plan: tested on a sample from T10590 Reviewers: austin, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: qnikst, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1024 GHC Trac Issues: #10590, #4934
-
