December 2014 - ghc-devs

Status and future of the LLVM backend
by Ben Gamari 27 Dec '14

27 Dec '14

I've written down some thoughts on the current status and future direction of the LLVM backend here [1]. Have a look when you get a chance. To summarize, * it seems like LLVM 3.4 chokes on the code produced by my 3.5 rework when the `$def` symbols are marked as internal * ARM is broken (again) due to a bug in the GHC calling convention implementation; an LLVM fix is waiting to be merged * I have code reworking TNTC for LLVM 3.6; unfortunately LLVM 3.6 support will likely need to wait until 7.12 * Austin's LLVM packaging proposal seems very much like the right way forward * Anticipating this proposal, I have started collecting [2] optimization passes Cheers, - Ben [1]: http://smart-cactus.org/~ben/posts/2014-11-28-state-of-llvm-backend.html [2]: https://github.com/bgamari/ghc-llvm-analyses

4 25

Failing tests: literals T5681 annotations
by Joachim Breitner 26 Dec '14

26 Dec '14

Hi, the CI weather is bad these days. Maybe a broken-window-effect? I currently observe Unexpected results from: TEST="literals T5681 annotations" Details: Compile failed (status 256) errors were: /tmp/ghc13786_0/ghc13786_5.s: Assembler messages: /tmp/ghc13786_0/ghc13786_5.s:26:0: Error: can't resolve `.rodata' {.rodata section} - `Main_zdwwork_info$def' {.text section} /tmp/ghc13786_0/ghc13786_5.s:46:0: Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def' {.text section} /tmp/ghc13786_0/ghc13786_5.s:66:0: Error: can't resolve `.rodata' {.rodata section} - `Main_main1_info$def' {.text section} /tmp/ghc13786_0/ghc13786_5.s:86:0: Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def' {.text section} /tmp/ghc13786_0/ghc13786_5.s:106:0: Error: can't resolve `.rodata' {.rodata section} - `Main_main2_info$def' {.text section} /tmp/ghc13786_0/ghc13786_5.s:126:0: Error: can't resolve `.rodata' {.rodata section} - `ZCMain_main_info$def' {.text section} *** unexpected failure for T5681(optllvm) =====> T8131(optllvm) 1496 of 4230 [0, 1, 0] Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: /usr/bin/ld: reopening annotations.o: No such file or directory /usr/bin/ld:annotations.o: bfd_stat failed: No such file or directory /usr/bin/ld: reopening annotations.o: No such file or directory /usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.22 internal error, aborting at ../../bfd/merge.c line 873 in _bfd_merged_section_offset /usr/bin/ld: Please report this bug. collect2: ld returned 1 exit status make[3]: *** [annotations] Error 1 *** unexpected failure for annotations(normal) Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: /usr/bin/ld: reopening literals.o: No such file or directory /usr/bin/ld:literals.o: bfd_stat failed: No such file or directory /usr/bin/ld: reopening literals.o: No such file or directory /usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.22 internal error, aborting at ../../bfd/merge.c line 873 in _bfd_merged_section_offset /usr/bin/ld: Please report this bug. collect2: ld returned 1 exit status make[3]: *** [literals] Error 1 *** unexpected failure for literals(normal) Does anyone feel responsible? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 4

ghc-7.10.1-rc1 build GC log messages
by Tuncer Ayaz 25 Dec '14

25 Dec '14

Building ghc-7.10.1-rc1, I see the following new messages: HC [stage 1] compiler/stage2/build/Dwarf.p_o <<ghc: 607994600 bytes, 145 GCs, 14478288/51516200 avg/max bytes residency (8 samples), 103M in use, 0.00 INIT (0.00 elapsed), 0.88 MUT (1.10 elapsed), 0.76 GC (0.77 elapsed) :ghc>> Is this a debug log or normal from now on during a ghc build? I don't mind, but I just wanted to make sure it's not a mistakenly enabled debug flag somewhere.

2 2

Linker problem with HPC and TemplateHaskell
by David Turner 24 Dec '14

24 Dec '14

Hi, I'm getting the following error message when compiling a Yesod application (which uses Template Haskell rather a lot) with -fhpc: /usr/bin/ld: ./Foundation.dyn_o: relocation R_X86_64_PC32 against undefined symbol `_hpc_tickboxes_Settings_hpc' can not be used when making a shared object; recompile with -fPIC Steps to reproduce: 1. Run 'yesod init' to make a new scaffold. Call it 'testsite' and select 'simple' for no database. 2. Run: cd testsite sed Settings.hs -i -e 's/staticRoot conf.*/staticRoot conf = "foo"/' # GHC doesn't like this line ghc --make app/main.hs -XTemplateHaskell -XCPP -XOverloadedStrings -XMultiParamTypeClasses -XTypeFamilies -fhpc -O1 Running the ghc line again completes successfully. It seems that there is a missing ./Settings.dyn_o in the gcc command line that ghc calls, the first time through. It's there the second time so the link succeeds. No idea what that might mean. It's not a problem at -O0. I'm using 7.8.3 so this might be fixed now. Not sure what else might help! Any advice gratefully received. Cheers, David

2 3

API Annotatons in a FunBind
by Alan & Kim Zimmerman 23 Dec '14

23 Dec '14

After individual FunBinds have been parsed, they are combined in getMonoBind. In the process, all the original FunBind fun_id's bar one are discarded, including its location. This causes a problem for source-to-source conversions of functions such as the following (&&& ) [] [] = [] xs &&& [] = xs ( &&& ) [] ys = ys Where there are compound RdrNames, and each has different spacing. I am proposing to add a (Maybe (Located id)) to the Match datatype to deal with this. data Match id body = Match Maybe (Located id) -- fun_id in subsequent function equations [LPat id] -- The patterns (Maybe (LHsType id)) -- A type signature for the result of the match -- Nothing after typechecking (GRHSs id body) Is this a problem? Alan

2 6

HEADS UP: Tickets have been triaged a bit
by Austin Seipp 23 Dec '14

23 Dec '14

Hi *, As many of you will probably notice, I have bulk modified a lot of Trac tickets and moved their milestone out. You might be wondering why; the reasoning is that since 7.10.1 RC1 is out (see other email), we need to start prioritizing what gets done. So, I moved all tickets that were a) set to 7.10.1 milestone, b) not closed, and c) had below 'high priority', to the 7.12.1 milestone. There are some tickets in 'normal' that probably should be moved back. If you're CC'd on a ticket and think it should be fixed for 7.10.1, please: - Set the milestone back to 7.10.1 - And if you can, take ownership! GHC HQ will probably only have time to organize efforts to take on the most high priority tickets - so any help you can offer is always appreciated. You can see the current list of tickets here. We'll put notes on the page at the top as time goes on to keep people up to date. https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Phabricator builds with haddock changes fail
by Alan & Kim Zimmerman 23 Dec '14

23 Dec '14

It seems that phabricator is not picking up haddock commits for builds. I rebased my D538 diff, with matching haddock submodule Subproject commit 54c5e7cd0b5844712301cacc826a6b112dbc1090 However, the build fails with an error in haddock which is explictly patched in the haddock repo. Up until last week this process worked fine, and was recently recommended on this mailing list. Has something changed now that it is a RC? Failing build: https://phabricator.haskell.org/harbormaster/build/2762/ Changed line in haddock branch https://github.com/haskell/haddock/commit/54c5e7cd0b5844712301cacc826a6b112… Regards Alan

1 0

GHC 7.10.1 / cabal-install 1.22 Ubuntu-PPA pre-RC snapshots available!
by Herbert Valerio Riedel 23 Dec '14

23 Dec '14

To early adopters & multi-ghc-travis users, I've uploaded pre-RC snapshots for GHC 7.10.1 and cabal-install 1.22 to my GHC PPA[1], so you can start extending your .travis.yml files w/ CABALVER=1.22 GHCVER=7.10.1 There are no official RCs yet for GHC 7.10/cabal-install 1.22, these are merely snapshots from the respective Git branches which I'll keep updating regularly (every 1-3 days) till the final proper release for GHC 7.10.1 and cabal-install 1.22.0.0 occur, at which point those packages (`ghc-7.10-*` & `cabal-install-1.22`) will install the final release versions. The usual official release-candidates (including respective announcements) for GHC & cabal will follow soon. So please, help us finding issues/bugs with these pre-RC snapshots of GHC & cabal-install. Obviously, it's desirable to become aware of any serious issues ASAP, as opposed to shortly before the planned final release date... As these are Git snapshots, when reporting bugs/issues, please also provide the snapshot's Git commit id (which uniquely identifies the GHC source-tree state), which can be queried via a new GHC CLI option, e.g.: $ ghc --print-project-git-commit-id a8c556dfca3eca5277615cc2bf9d6c8f1f143c9a Here's an example build using 7.10.1 to show those packages actually work: https://travis-ci.org/haskell/unix/builds/44919992 [1]: https://github.com/hvr/multi-ghc-travis https://launchpad.net/~hvr/+archive/ubuntu/ghc Cheers, hvr PS: If you happen to run into compile errors for Hackage packages which claim to work with GHC 7.10.1 (e.g. by allowing `base-4.8`), I'd be interested to hear about it.

1 0

stg_init_finish
by Ben Gamari 22 Dec '14

22 Dec '14

Hi Simon, A few of us are puzzling over a cross-compilation bug, #9920. stg_init_finish appears to be loading a zero Sp from the saved thread state. None of us have been able to figure out how execution makes it to stg_init_finish. The only references to the symbol are its definition in StgStartup.cmm and a header declaration in MiscClosures.h. Could you perhaps shed some light on how execution is supposed to flow during RTS initialization? Cheers, - Ben

1 0

Triggering a Harbourmaster build on a given commit
by Dr. ERDI Gergo 22 Dec '14

22 Dec '14

Hi, Given a concrete commit on a non-master branch (e.g. https://phabricator.haskell.org/rGHC20acaa7785d910d36d46c4eae9e9cce4000635d1) how do I manually trigger a Harbourmaster build + validation? Thanks, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo(a)erdi.hu =-------' A man's best friend is his dogma.

3 4