- ghc-devs - Haskell.org

RE: Which of these commits to merge into ghc-7.10?
by Simon Peyton Jones 30 Dec '14

30 Dec '14

| As I'm currently merging some commits into the ghc-7.10 branch, which | of the following commits do you deem suitable for 7.10? | | - | http://git.haskell.org/ghc.git/commitdiff/a6f0f5ab45b2643b561e0a0a54a4 | f14745ab2152 See https://ghc.haskell.org/trac/ghc/ticket/3064#comment:21 | http://git.haskell.org/ghc.git/commitdiff/3e96d89b1d37a989b92a11587de2 | 9e347ef19328 Yes, this can go in | http://git.haskell.org/ghc.git/commitdiff/679a661890c9e5a218d8328658ca | e2b71d367024 This is ok too; should be no change in functionality. | http://git.haskell.org/ghc.git/commitdiff/c3394e0d2cce4bbaa034dc77473a | dd151781ef93 Not so sure here... I may not have gotten the change in the test harness right. Simon

1 0

Re: master: Eliminate so-called "silent superclass parameters" (a6f0f5a)
by Joachim Breitner 29 Dec '14

29 Dec '14

Hi Am Montag, den 29.12.2014, 18:40 +0100 schrieb Joachim Breitner: > Am Dienstag, den 23.12.2014, 16:29 +0000 schrieb git(a)git.haskell.org: > > commit a6f0f5ab45b2643b561e0a0a54a4f14745ab2152 > > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > > Date: Tue Dec 23 15:39:50 2014 +0000 > > > > Eliminate so-called "silent superclass parameters" > > you may or may not have noticed that ghcspeed stopped producing results > since this commits. > > The reason is that running nofib fails: reproduced locally, filed as: https://ghc.haskell.org/trac/ghc/ticket/9938 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

1 0

Fwd: [Haskell-beginners] ghc prelude home
by Carter Schonwald 29 Dec '14

29 Dec '14

seems we need to update the various ghc pages to point to 7.8.4? also maybe provide links to how folks can install cabal-install, though I guess the new haskell.org page will accomplish that too ---------- Forwarded message ---------- From: Christian Maeder <Christian.Maeder(a)dfki.de> Date: Mon, Dec 29, 2014 at 8:53 AM Subject: Re: [Haskell-beginners] ghc prelude home To: gale(a)sefer.org, The Haskell-Beginners Mailing List - Discussion of primarily beginner-level topics related to Haskell <beginners(a)haskell.org>, Antoine Latter <aslatter(a)gmail.com>, GHC Users Mailing List < glasgow-haskell-users(a)haskell.org> Cc: Doug McIlroy <doug(a)cs.dartmouth.edu> 23 December 2014 GHC 7.8.4 Released! https://www.haskell.org/ghc/ So 7.8.4 is out! Only the download subpage https://www.haskell.org/ghc/download is not updated yet. Also http://downloads.haskell.org/~ghc/latest/ still refers to http://downloads.haskell.org/~ghc/7.8.3/ (and has a funny 7.8.4 subdirectory). I send this also to glasgow-haskell-users to reach someone who can fix this. Cheers Christian Am 28.12.2014 um 22:28 schrieb Yitzchak Gale: > Yes, sorry, neither 7.8.4 nor 7.10.1 is actually out yet. > They are both release candidates, and will be out soon. > > Thanks, > Yitz > > On Sun, Dec 28, 2014 at 9:50 PM, Antoine Latter <aslatter(a)gmail.com> > wrote: > >> I don't think GHC 7.10 is out yet: https://www.haskell.org/ghc/download >> >> Although that page doesn't have 7.8.4 on it. >> > _______________________________________________ > Beginners mailing list > Beginners(a)haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

GHC ARM64 calling convention
by Erik de Castro Lopo 28 Dec '14

28 Dec '14

Hi Luke, I found your llvm git tree which contains a patch [0] implementing the GHC calling convention for GHC. I also notice that: a) It has not been submitted upstream. b) It can be cherry picked and applied on top of current llvm HEAD. c) It can be applied to the llvm 3.5 tree and most importantly of all d) It actually works. With this patch applied to the llvm 3.5 tree, I was able to build an x86_64-linux to aarch64-linux cross-compiler which was able to build a simple "hello world" program that actually ran correctly. Are you in the process of trying to get this patch into LLVM? Do you need any help? Cheers, Erik [0] https://github.com/lukexi/llvm/commit/2d351c3d095e2fe42bc287947404d884841a1… -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

2 2

GHC 7.10.x migration guide
by Herbert Valerio Riedel 27 Dec '14

27 Dec '14

Hello! I've started collecting the most common compile-errors (and their respective fixes) I have encountered while compiling Hackage packages with GHC 7.10 in https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10 Feel free to contribute to this migration guide. HTH, hvr

1 0

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