- 26 Feb, 2017 23 commits
-
-
rwbarton authored
The script I used is included as testsuite/driver/kill_extra_files.py, though at this point it is for mostly historical interest. Some of the tests in libraries/hpc relied on extra_files.py, so this commit includes an update to that submodule. One test in libraries/process also relies on extra_files.py, but we cannot update that submodule so easily, so for now we special-case it in the test driver.
-
rwbarton authored
Some of the *.T files were in libraries/hpc, so this contains an update to that submodule.
-
rwbarton authored
-
rwbarton authored
Summary: My script won't understand this. Test Plan: validate Reviewers: austin, bgamari, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3210
-
rwbarton authored
-
Joachim Breitner authored
This commit fixes several bugs related to case expressions involving numeric literals which are not in the range of values of their (fixed-width, integral) type. There is a new invariant on Literal: The argument of a MachInt[64] or MachWord[64] must lie within the range of the corresponding primitive type Int[64]# or Word[64]#, as defined by the target machine. This invariant is enforced in mkMachInt[64]/mkMachWord[64] by wrapping the argument to the target type's range if necessary. Test Plan: Test Plan: make slowtest TEST="T9533 T9533b T9533c T10245 T10246" Trac issues: #9533, #10245, #10246, #13171 Reviewers: simonmar, simonpj, austin, bgamari, nomeata Reviewed By: bgamari Subscribers: thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D810
-
Andrzej Rybczak authored
Trac issues: #13194 Reviewers: austin, hvr, erikd, bgamari, dfeuer, duncan Subscribers: DemiMarie, dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D3090
-
Ben Gamari authored
Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3184
-
Ben Gamari authored
Bumps binary submodule.
-
Ben Gamari authored
While working through the FunCo patch I encountered some lint issues which suggested that `Constraint` wasn't being considered equal to `TYPE 'LiftedRep`. Consequently I introduced this axiom and associated messy ball of logic to explicitly coerce `Constraint`. However, as @goldfire points out on D3208 this really shouldn't be necessary. Indeed, I tried ripping out the axiom and things appear to just work. I suspect the issue motivating the axiom was a bug elsewhere in the FunCo branch that I fixed during development. Test Plan: Validate Reviewers: simonpj, goldfire, austin Reviewed By: goldfire Subscribers: thomie, goldfire Differential Revision: https://phabricator.haskell.org/D3218
-
Ben Gamari authored
The build system uses the CrossCompiling variable to decide whether or not we should build various packages that must be built using the compiler. Consequently, it is important that we persist its value in the binary distribution so we know during `make install` not to go looking for files that would have been built for these packages. Failing to do this causes #13325. Test Plan: Cross compile, `make binary-dist`, and try installing the binary distribution on the target Reviewers: hvr, austin, trofi, rwbarton Reviewed By: trofi, rwbarton Subscribers: carter, trofi, rwbarton, erikd, thomie, snowleopard, davean Differential Revision: https://phabricator.haskell.org/D3187
-
Simon Peyton Jones authored
This too is prepartory for my early-inlining patch. It turned out that early inlining exposed a bug in the way that static pointers were being floated. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3205
-
Simon Peyton Jones authored
Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3200
-
Adam Gundry authored
Test Plan: n/a Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3144
-
Ben Gamari authored
Test Plan: Run test of `openTempFile` under `strace` to verify reasonably random filenames Reviewers: austin, hvr, trofi, rwbarton Reviewed By: trofi, rwbarton Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3188
-
Ben Gamari authored
Test Plan: Validate Reviewers: rwbarton, austin Reviewed By: rwbarton Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3215
-
Ben Gamari authored
Although I'm really not convinced that measuring peak_megabytes_allocated of this test is reasonable.
-
Ben Gamari authored
-
Tamar Christina authored
The GCC Bindists that we use compile with `pthread` enabled by default. This means that on every link the dll is passed as a dependency by the driver. Lots of packages depend on it but the runtime linker doesn't provide it by default making compiled code work but not interpreted. Following D3028 `pthreads` would be provided by default ONLY when linked dynamicly, which we don't support yet (See D2592). Until this is the case we need to manually provide `libpthreads`. Test Plan: ./validate Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3155
-
Tamar Christina authored
We have a unfortunate workaround in place for the fact that most packages out there use POSIX names for symbols even on Windows. This means that we have to recognize e.g. both `_ungetch` and `ungetch`. The former is the actual symbol name on windows and the latter is the POSIX variant. The problem is that on normal windows programs `ungetch` should not be in the global namespace. To work around this, we now mark the deprecated symbols as weak symbols in the global namespace. This provides the flexibility we need: * If you use the symbol without defining it, we assume you meant to use the POSIX variant. * If you actually define the symbol, we'll hence forth use that definition and assume you didn't mean to use POSIX code. This is how MingW64's wrapper also works. This requires D3028. Fixes #13210. Test Plan: ./validate Reviewers: austin, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3154
-
Tamar Christina authored
When the `GCC` driver envokes the pipeline a `SPEC` is used to determine how to configure the compiler and which libraries to pass along. For Windows/mingw, this specfile is https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/mingw32.h This has a lot of interesting things that we need to emulate in order to be able to link as many things out of the box as GCC. In particular this is why you never need to specify `-lgcc_s` when compiling, but you do when using `GHCi`. Unfortunately due to time constraints I can't set up the framework required in `GHC` to do this before the feature freeze. So I suggest this alternate implementation: When we load a dll, also bring it's dependencies into scope of the interpeter. This has pros and cons. Pro is, we'll fix many packages on hackage which specify just `-lstdc++`. Since this points to `libstdc++-6.dll` which will bring `libgcc` into scope. The downside is, we'll be more lenient than GCC, in that the interpreter will link much easier since it has implicit dependencies in scope. Whereas for compilation to work you will have to specify it as an argument to GHC. This will make the Windows runtime linker more consistent with the unix ones. The difference in semantics came about because of the differences between `dlsym` and `GetProcAddress`. The former seems to search the given library and all it's dependencies, while the latter only searches the export table of the library. So we need some extra manual work to search the dependencies which this patch provides. Test Plan: ``` ./validate ``` ``` $ echo :q | inplace/bin/ghc-stage2.exe --interactive +RTS -Dl -RTS -lstdc++ 2>&1 | grep "Loading dependency" ``` ``` $ echo :q | ../inplace/bin/ghc-stage2.exe --interactive -lstdc++ +RTS -Dl -RTS 2>&1 | grep "Loading dependency" Loading dependency *.exe -> GDI32.dll. Loading dependency GDI32.dll -> ntdll.dll. Loading dependency *.exe -> KERNEL32.dll. Loading dependency KERNEL32.dll -> KERNELBASE.dll. Loading dependency *.exe -> msvcrt.dll. Loading dependency *.exe -> SHELL32.dll. Loading dependency SHELL32.dll -> USER32.dll. Loading dependency USER32.dll -> win32u.dll. Loading dependency *.exe -> WINMM.dll. Loading dependency WINMM.dll -> WINMMBASE.dll. Loading dependency *.exe -> WSOCK32.dll. Loading dependency WSOCK32.dll -> WS2_32.dll. Loading dependency WS2_32.dll -> RPCRT4.dll. Loading dependency libstdc++-6.dll -> libwinpthread-1.dll. Loading dependency libstdc++-6.dll -> libgcc_s_seh-1.dll. ``` Trac tickets: #13093, #13189 Reviewers: simonmar, rwbarton, austin, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, RyanGlScott, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3028
-
Alan Zimmerman authored
-
Edward Z. Yang authored
Summary: The plan is to release a separate library, 'compact', which gives a friendly user-facing interface. This library is just enough so that we can make sure the functionality is working in GHC. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, dfeuer, austin, simonmar, hvr Subscribers: thomie, erikd, snowleopard Differential Revision: https://phabricator.haskell.org/D3206
-
- 25 Feb, 2017 3 commits
-
-
Alan Zimmerman authored
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
- 24 Feb, 2017 6 commits
-
-
Edward Z. Yang authored
Summary: The previous implementation tried to be "efficient" by storing field names once in IfaceConDecls, and only just enough information for us to reconstruct the FieldLabel. But this came at a bit of code complexity cost. This patch undos the optimization, instead storing a full FieldLabel at each data constructor. Consequently, this fixes bugs #12699 and #13250. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: adamgundry, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3174
-
David Feuer authored
`Applicative` as a superclass of `Monad` is non-standard. Fixes #13196. [skip ci] Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3185
-
Matthew Pickering authored
[skip ci]
-
Alan Zimmerman authored
-
Alan Zimmerman authored
-
Simon Peyton Jones authored
There are two things here * Use exprIsLiteral_maybe to "look through" a variable bound to a literal string. * Add CONLIKE to the NOINLINE pragma for unpackCString# and unpackCStringUtf8# See Trac #13317, Trac #10844, and Note [exprIsConApp_maybe on literal strings] in CoreSubst I did a nofib run and got essentially zero change except for one 2.2% improvement in allocation for 'pretty'.
-
- 23 Feb, 2017 8 commits
-
-
Ryan Scott authored
`(:~~:)`, the hetergeneous version of `(:~:)`, should have class instances similar to those of `(:~:)`, especially since their implementations aren't particularly tricky or surprising. This adds them. Reviewers: bgamari, austin, hvr, goldfire Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3181
-
Tamar Christina authored
GHC and ghc-pkg make some pretty hard assumptions about where they're running on Windows. They assume that they are always running from `foo/bin/ghc.exe` and that to find the `lib` folder they can drop `bin/ghc.exe` from the base path and append `lib`. This is already false for the testsuite, which when testing thenbindist has one test which puts the binaries in `inplace/test spaces`. For some reason before this was either being skipped or mysteriously passing. But as of `2017.02.11` our luck ran out. the testsuite triggers a failure such as those in #13310 Let's soften the assumption and just check that `../lib` exists instead. 80 chars Test Plan: ./validate Reviewers: austin, erikd, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3158
-
Dmitry Ivanov authored
Parse `foo, bar, baz` into `And [foo, bar, baz]` instead of `And [foo, And [bar, baz]]`. Fixes #11024. Test Plan: read and think Reviewers: austin, bgamari, mpickering Reviewed By: bgamari, mpickering Subscribers: ezyang, thomie, alanz Differential Revision: https://phabricator.haskell.org/D3139
-
Edward Z. Yang authored
Summary: Fixes #13323. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3175
-
Simon Peyton Jones authored
Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3179
-
rwbarton authored
I don't see any reason for the (filesize*2), and experimentally allocations do go down slightly after this change. Test Plan: validate Reviewers: simonmar, austin, bgamari, trofi Reviewed By: bgamari, trofi Subscribers: trofi, thomie Differential Revision: https://phabricator.haskell.org/D3164
-
Chris Martin authored
I discovered this feature via Stack Overflow. https://stackoverflow.com/questions/42310399 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3150
-
Andreas Klebinger authored
getArgs didn't match the treatmeant of -- in the RTS leading to inconsistencies between behavior on Windows and other platforms. See #13287. Reviewers: austin, hvr, bgamari, erikd, simonmar, rwbarton Reviewed By: bgamari, rwbarton Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3147
-