- User Since
- Sep 11 2014, 7:17 AM (227 w, 2 d)
Dec 19 2018
Right. As part of D4762. That didn’t cover ghci though it seems ;)
Dec 6 2018
Tamar, could you please have a look wrt. to libffi and windows?
Dec 4 2018
The ghci ffi guard breaks the build. Without it, this builds for me on macOS in ~40min for the default build.
Dec 3 2018
Seems to build a ghc on macOS.
As determined on IRC today, the proper solution here is to likely teach hadrian about extra-libraries as specified in cabal files.
We currently hardcode some of the in hadrian, but should rather read them from the cabal files and fix the cabal files where
they are missing.
Dec 2 2018
So we are looking for libffi as a dependency of ghci, that makes some sense as ghci does reference quite a bit of libffi symbols.
For completeness sake: here's the dead_strip_dylib documentation:
-dead_strip_dylibs Remove dylibs that are unreachable by the entry point or exported symbols. That is, suppresses the generation of load command commands for dylibs which supplied no symbols during the link. This option should not be used when linking against a dylib which is required at runtime for some indi- rect reason such as the dylib has an important initializer.
The question (to me) is: why doesn't ghc reference libffi if it needs it? Or are we bundling libffi just for convenience?
It doesn't build for me; bails out with some rather weird linker errors.
I wouldn't put it past my system to be screwing me over here. I'll have to try in a clean room install again.
Nov 28 2018
Nov 22 2018
Oct 23 2018
Oct 11 2018
Oct 1 2018
Sep 26 2018
Didn't manage to try it, but LGTM source wise.
Sep 16 2018
Two minor issues, I'd appreciate to see addressed otherwise LGTM.
Jul 30 2018
Jul 28 2018
Jul 27 2018
Assuming it passes CI. LGTM! Thanks!
Jul 26 2018
Jul 16 2018
I have a concern about the LLVM implementation. using *usub*, while the primop name suggests it should be *uadd*.
Jun 20 2018
@last_g if you do not intend to address LLVM in any way in this patch, does this mean it will potentially render the llvm backend broken? I'm not asking for the same functionality in the LLVM backend, just that we ensure not to break -fllvm.
Jun 14 2018
Jun 13 2018
Howdy @Phyx, I actually did try my luck on GHC 7.3; but this ended up being really messy. And then I have no idea how to build gcc/mingw on windows properly.
Jun 1 2018
May 31 2018
May 26 2018
Note that while we have the fix in LLVM, the result only works with the llvm-ng backend, not with the stock llvm backend due to the excessive use of aliases in the stock backend, which confuses LLVM's entry-point logic.
May 23 2018
As @simonmar noted, the LLVM part is missing, I don't see any fundamental reasons why the LLVM backend could not support the same.
Similar to the -ffunction-sections question:
- has this been tested on macOS with -dead_strip, which uses the .subsections_via_symbols directive?
- The lack of symbols as @simonmar noted, is concerning to me as well, and I'm in the same boat, not making the connect with D4713 yet. Could you provide the same Perf-list without the D4713 interaction?
May 20 2018
May 16 2018
LGTM. Maybe see the comments.
May 12 2018
Apr 3 2018
Apr 2 2018
Apr 1 2018
Related: D4553 tries to address (3).
Mar 31 2018
Mar 25 2018
Mar 19 2018
Mar 6 2018
Mar 5 2018
@trofi you might want to still try --via-asm with https://github.com/haskell/hsc2hs/pull/8. It might be faster, as we do not need to do the binary search for constants.
Ideally we'd also extend it to compute all constants in one go, instead of computing each on their own.
Ok, let's do this in 8.6.
Mar 4 2018
won't make it in 8.4 anymore.
Mar 3 2018
Mar 2 2018
... and the windows build is green!
- Adds hvr's fix
- Windows, are we friends now?
Mar 1 2018
- add .buildinfo from dist/build into bindist-list
Feb 28 2018
- fix .buildinfo lookup for bindist
- in-place is the worst
Feb 27 2018
for the record:
make: *** [utils/check-ppr/dist-install/build/Main.dyn_o] Segmentation fault: 11 make: *** Waiting for unfinished jobs.... make: *** [utils/check-api-annotations/dist-install/build/Main.dyn_o] Segmentation fault: 11 make: *** [utils/ghctags/dist-install/build/Main.dyn_o] Segmentation fault: 11 make: *** [all] Error 2
This does however cause my stage2 ghc to segfault, and I have no idea why...
Feb 23 2018
- drop flavour change
Feb 22 2018
- drop hsc2hs related changes. (end up in a different diff: D4439)
Feb 21 2018
Feb 15 2018
- rebase onto master
Aside from stat failures; this builds and validates for me locally.
- fix Makefile
- adds .gitignore
Feb 14 2018
Feb 13 2018
- rebase onto master
- adds configure
Feb 12 2018
I have a working version with the configure script in a local branch.
Feb 11 2018
Feb 7 2018
Feb 6 2018
Feb 5 2018
Sorry to be a bit late to the party 🎉
@bgamari yey, everything is green... except for Linux which fails with Haddock 🗡
Feb 4 2018
Lovely, haddock is failing... what the hell?
Jan 31 2018
@harpocrates, I’m terribly sorry for letting this languish. I’m currently bed bound, but will try to give this a try next week. Feel free to ping me next week!
Jan 21 2018
... and optllvm starts failing ;-)
Unexpected failures: /tmp/ghctest-qmrjo3ke/test spaces/./llvm/should_compile/T5681.run T5681 [exit code non-0] (optllvm) /tmp/ghctest-qmrjo3ke/test spaces/./llvm/should_compile/T7571.run T7571 [exit code non-0] (optllvm) /tmp/ghctest-qmrjo3ke/test spaces/./llvm/should_compile/T8131b.run T8131b [exit code non-0] (optllvm) /tmp/ghctest-qmrjo3ke/test spaces/./llvm/should_compile/T11649.run T11649 [exit code non-0] (optllvm)