- ghc-devs - Haskell.org

7.8.1 plan
by Austin Seipp 16 Jul '14

16 Jul '14

Hello all, As I'm sure you're all aware, it's the final countdown. The (final) source distribution will be up within a few hours, and then we'll continue on from there. Yay! I will post an update when that is, so Gabor/Luke/Karel can make binaries from the sources as I do so. Second, there are just two things I want to note: - For people following the Windows debacle in #8834, there has been a bug fixed, but one may still remain. The TL;DR of this is that we currently have a committed workaround in place we'll keep using, but Simon has made some good steps towards finding the bug. - Lots of people, I'm sure, are wondering what's going on with Safe Haskell and the GND story. The TL;DR of this one is that "everything will be the same as in 7.6" - GND is considered an Unsafe feature, and Data.Coerce is behind Unsafe bars. From a safety point of view, nothing should change for library authors I cherry picked these changes into 7.8 last night. In the mean time, the 7.8 branch is effectively closed. If you have something to commit, and I *really* mean something, you can let me know. But your deadline is hours, not days! I'm doing a final review of all the trees before pushing the library tags, and after that I'll begin rolling the sdist. Anyway, the time is finally here, so let's get it over with! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

16 41

Re: Windows breakage -- again
by Johan Tibell 16 Jul '14

16 Jul '14

I'll be out until Tuesday. I would much appreciate if someone with a Windows setup could help me debug this. These symbols are supposed to be defined by GCC somewhere (as GCC is outputting these when it cannot convert __sync_fetch_and_add into assembly instructions.) On Wed, Jul 16, 2014 at 9:08 PM, Niklas Larsson <metaniklas(a)gmail.com> wrote: > Oh, wait, it isn't the system linker that is complaining, it's the ghc rts > linker. Maybe we just have to tell it to leave those symbols alone. > > Niklas > > > 2014-07-16 20:57 GMT+02:00 Niklas Larsson <metaniklas(a)gmail.com>: > > I get the same failure when I try to build HEAD. Turns out the error >> occurs on the 32-bit Windows build, and my successful build was a 64-bit >> build. My 64-bit build still succeeds. >> >> Also, gcc is 4.5.2 on 32-bit, not 4.6.3 as on 64-bit. >> >> Niklas >> >> >> >> 2014-07-16 14:48 GMT+02:00 Niklas Larsson <metaniklas(a)gmail.com>: >> >> I have built ghc on windows after that was added with no issue. >>> >>> I can take a look this evening and see how HEAD works for me. >>> >>> The standard gcc in the tarballs is 4.6.3, which is getting long in the >>> tooth, there is an issue on trac to upgrade it. >>> >>> -- Niklas >>> >>> ------------------------------ >>> Från: Johan Tibell <johan.tibell(a)gmail.com> >>> Skickat: ‎2014-‎07-‎16 09:57 >>> Till: Simon Peyton Jones <simonpj(a)microsoft.com> >>> Kopia: ghc-devs(a)haskell.org >>> Ämne: Re: Windows breakage -- again >>> >>> You can rollback the commit (git revert 4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) >>> and push that to the repo if you wish. I will try to re-add the primop >>> again after I figure out what's wrong. >>> >>> >>> On Wed, Jul 16, 2014 at 9:37 AM, Johan Tibell <johan.tibell(a)gmail.com> >>> wrote: >>> >>>> I added some primops about a month ago >>>> (4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) that call __sync_fetch_and_add, >>>> a gcc/llvm builtin. I'm a bit surprised to see this error. The GCC manual >>>> [1] says: >>>> >>>> > " Not all operations are supported by all target processors. If a >>>> particular operation cannot be implemented on the target processor, a >>>> warning will be generated and a call an external function will be >>>> generated. The external function will carry the same name as the builtin, >>>> with an additional suffix `_n' where n is the size of the data type." >>>> >>>> I'm a bit surprised by this error for two reasons: >>>> >>>> * A call to that symbol should only be generated if the CPU doesn't >>>> support the atomic instructions. What CPU model does Windows report that >>>> you have? >>>> >>>> * gcc should define such a symbol. For me the following test program >>>> compiles: >>>> >>>> #include <stdint.h> >>>> >>>> uint8_t test(uint8_t* ptr, uint8_t val) { >>>> return __sync_fetch_and_add_1(ptr, val); >>>> } >>>> >>>> int main(void) { >>>> uint8_t n; >>>> return test(&n, 1); >>>> } >>>> >>>> Does that compile for you? Which version of GCC do we end up using on >>>> Windows? >>>> >>>> The reported symbol (___sync_fetch_and_add_1) has three leading >>>> underscores, that looks weird. Can you compile just >>>> libraries/ghc-prim/cbits/atomic.c and see if it's indeed GCC that generates >>>> a reference to that symbol? >>>> >>>> 1. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html >>>> >>>> >>>> On Wed, Jul 16, 2014 at 12:29 AM, Simon Peyton Jones < >>>> simonpj(a)microsoft.com> wrote: >>>> >>>>> Aargh! The Windows build has broken – again. I can’t build GHC on >>>>> my laptop any more. >>>>> >>>>> A clean ‘sh validate’ finishes as below. What on earth is >>>>> `___sync_fetch_and_add_1'? >>>>> >>>>> Can anyone help? Thanks! >>>>> >>>>> Simon >>>>> >>>>> "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf o -hcsuf hc -static >>>>> -H32m -O -Werror -Wall -H64m -O0 -package-name vector-0.10.9.1 >>>>> -hide-all-packages -i -ilibraries/vector/. >>>>> -ilibraries/vector/dist-install/build >>>>> -ilibraries/vector/dist-install/build/autogen >>>>> -Ilibraries/vector/dist-install/build >>>>> -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include >>>>> -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include >>>>> -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package >>>>> base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package >>>>> primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O >>>>> -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts >>>>> -Wwarn -odir libraries/vector/dist-install/build -hidir >>>>> libraries/vector/dist-install/build -stubdir >>>>> libraries/vector/dist-install/build -c >>>>> libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o >>>>> libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o >>>>> >>>>> Loading package ghc-prim ... linking ... ghc-stage2.exe: unable to >>>>> load package `ghc-prim' >>>>> >>>>> ghc-stage2.exe: >>>>> C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.3.1.0.o: >>>>> unknown symbol `___sync_fetch_and_add_1' >>>>> >>>>> libraries/vector/ghc.mk:5: recipe for target >>>>> 'libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o' >>>>> failed >>>>> >>>>> make[1]: *** >>>>> [libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o] >>>>> Error 1 >>>>> >>>>> >>>>> >>>>> I >>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs(a)haskell.org >>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>> >>>>> >>>> >>> >> >

1 0

Windows breakage -- again
by Simon Peyton Jones 16 Jul '14

16 Jul '14

Aargh! The Windows build has broken - again. I can't build GHC on my laptop any more. A clean 'sh validate' finishes as below. What on earth is `___sync_fetch_and_add_1'? Can anyone help? Thanks! Simon "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name vector-0.10.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist-install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist-install/build -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o Loading package ghc-prim ... linking ... ghc-stage2.exe: unable to load package `ghc-prim' ghc-stage2.exe: C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.3.1.0.o: unknown symbol `___sync_fetch_and_add_1' libraries/vector/ghc.mk:5: recipe for target 'libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o' failed make[1]: *** [libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o] Error 1 I

3 6

another Phab question: Local commits
by Richard Eisenberg 16 Jul '14

16 Jul '14

Hi all, I wanted to make a comment in a Phab revision and refer to performance of a particular commit. So, I found the "Local commits" section of my page (https://phabricator.haskell.org/D73) But, those SHA's ("Commit" and "Tree") seem not to be related to others. The correct SHA, as I can see it, is the bit after "rGHC" in the "Description" field of "Diff 2". That SHA corresponds to the SHA I have on my own machine. What are the "Local commit" SHA's? Is there a way to refer to a particular commit in a Phab comment? And, while I'm at it, why do I have *2* Diffs here? I submitted only one git commit. One of the diffs (#2 a.k.a. #161 -- there seem to be two numbering schemes) is empty. Many thanks! Richard

1 0

SV: Windows breakage -- again
by Niklas Larsson 16 Jul '14

16 Jul '14

I have built ghc on windows after that was added with no issue. I can take a look this evening and see how HEAD works for me. The standard gcc in the tarballs is 4.6.3, which is getting long in the tooth, there is an issue on trac to upgrade it. -- Niklas ----- Ursprungligt meddelande ----- Från: "Johan Tibell" <johan.tibell(a)gmail.com> Skickat: ‎2014-‎07-‎16 09:57 Till: "Simon Peyton Jones" <simonpj(a)microsoft.com> Kopia: "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> Ämne: Re: Windows breakage -- again You can rollback the commit (git revert 4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) and push that to the repo if you wish. I will try to re-add the primop again after I figure out what's wrong. On Wed, Jul 16, 2014 at 9:37 AM, Johan Tibell <johan.tibell(a)gmail.com> wrote: I added some primops about a month ago (4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) that call __sync_fetch_and_add, a gcc/llvm builtin. I'm a bit surprised to see this error. The GCC manual [1] says: > " Not all operations are supported by all target processors. If a particular operation cannot be implemented on the target processor, a warning will be generated and a call an external function will be generated. The external function will carry the same name as the builtin, with an additional suffix `_n' where n is the size of the data type." I'm a bit surprised by this error for two reasons: * A call to that symbol should only be generated if the CPU doesn't support the atomic instructions. What CPU model does Windows report that you have? * gcc should define such a symbol. For me the following test program compiles: #include <stdint.h> uint8_t test(uint8_t* ptr, uint8_t val) { return __sync_fetch_and_add_1(ptr, val); } int main(void) { uint8_t n; return test(&n, 1); } Does that compile for you? Which version of GCC do we end up using on Windows? The reported symbol (___sync_fetch_and_add_1) has three leading underscores, that looks weird. Can you compile just libraries/ghc-prim/cbits/atomic.c and see if it's indeed GCC that generates a reference to that symbol? 1. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html On Wed, Jul 16, 2014 at 12:29 AM, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: Aargh! The Windows build has broken – again. I can’t build GHC on my laptop any more. A clean ‘sh validate’ finishes as below. What on earth is `___sync_fetch_and_add_1'? Can anyone help? Thanks! Simon "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name vector-0.10.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist-install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist-install/build -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o Loading package ghc-prim ... linking ... ghc-stage2.exe: unable to load package `ghc-prim' ghc-stage2.exe: C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.3.1.0.o: unknown symbol `___sync_fetch_and_add_1' libraries/vector/ghc.mk:5: recipe for target 'libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o' failed make[1]: *** [libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o] Error 1 I _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

2 1

performance monitoring idea
by Richard Eisenberg 16 Jul '14

16 Jul '14

Hi all, I'm deep into working on #9233 right now, which may stem from various inefficiencies due to roles. I'm making good progress, and I feel badly about introducing these problems. When I was coding this originally, I was thinking "Premature optimization is the root of all evil" and didn't pay too much attention to performance, thinking that a perf test would show me up if I erred. I was wrong. This all got me thinking: could we track some cumulative timing numbers for running the whole testsuite? As a first draft, it could just be the sum of the MUT statistic from +RTS -t. As part of our growing CI support (thanks, Joachim and others!!), we could track this number over time. When a commit slows GHC down, we would hopefully see it reflected here and then try to catch these bugs earlier, in an effort to defy Lennart's expectations of GHC slowing down every release. (Sorry, can't find reference to quote at the moment.) This idea seems easy enough to implement. It may not be terribly reliable, but it might just be reliable enough to help catch these problems before releases and to help to discover where they came from. What do we think? Richard

1 0

Re: Status of Haskell Platform 2014.2.0.0
by Johan Tibell 15 Jul '14

15 Jul '14

This was discussed earlier. We need to stick with the Cabal that ships with the GHC version we're using and thus we need to stick with cabal-install-1.18. On Tue, Jul 15, 2014 at 9:33 AM, Alois Cochard <alois.cochard(a)gmail.com> wrote: > Why not directly to 1.20.x? > On Jul 15, 2014 7:59 AM, "Andres Löh" <andres.loeh(a)googlemail.com> wrote: > >> Hi. >> >> > Check the version list in Release2014.hs >> >> Would it still be possible to bump cabal-install to 1.18.0.5? >> >> Cheers, >> Andres >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries > >

4 8

GhcLibHcOpts: -O or -O2?
by Joachim Breitner 15 Jul '14

15 Jul '14

Hi, I found that some performance tests cases fail in some setting, and not in another, and after a while I found the cause: The default settings (i.e. no mk/build.mk) have GhcLibHcOpts=-O2, while most development profiles (e.g. devel2) _and the validate settings_ have GhcLibHcOpts=-O1. It doesn’t make a lot of sense to have performance tests cases without fixing this parameter. And I think we really should be validating the settings that we actually used in the final build that we release. Hence three questions: 1. Are the default settings really the settings used when producing the final build? 2. Do we want to use GhcLibHcOpts=-O2 or GhcLibHcOpts=-O for releases? 3. Once 2. is answered, may I change the validate settings to that value, and update the performance tests to expect the number produced with that value? (This was first observed in https://ghc.haskell.org/trac/ghc/ticket/9315#comment:5 but I wanted to the wider audience of the mailing list for such a design decision.) Thanks, Joachim -- Joachim Breitner e-Mail: mail(a)joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata(a)joachim-breitner.de

1 0

ANN: New source documentation policy for GHC
by Johan Tibell 15 Jul '14

15 Jul '14

Hi all! After some discussion [1] we've decided to require Haddock comments for all top-level entities (i.e. functions, classes, and data types) in new [2] GHC code. If you're writing new code, please try to add at least a sentence of two documenting what the function does and why. When you're reviewing patches, please ask the author to add comments. This policy doesn't replace GHC's use of [Notes], which talk mostly about implementation details, but instead compliments it by making it clearer how to *use* the code. See the original thread [1] for some example comments. We will use Haddock for our comments, in order to make the generated Haddock docs more useful, but we don't require that you use any special markup in the comments themselves or required that you validate that your docs render nicely [3]. We're not adding any technical enforcement [4], to avoid extending the compile/validate cycle, instead rely on social enforcement; please encourage people to write comments and remind them during code review! Cheers, Johan 1. https://www.mail-archive.com/ghc-devs@haskell.org/msg05135.html 2. Documenting old code is of course also much appreciated! 3. This is a pragmatic trade-off to not add too much extra work for frequent contributions. It's easy for anyone to fix up bad markup, so allowing some bad markup to slip in temporarily isn't a big issue. 4. We might try to add lint warning to Phabricator, to serve as an extra reminder to patch authors.

2 2

Building GHC API Documentation?
by Andrew Gibiansky 15 Jul '14

15 Jul '14

Hello, I am trying to create my first patch, for #9294, where I want to export some extra things from Parser along with a bit of documentation. However, I cannot figure out how to regenerate the documentation for the GHC API (not for the libraries). I tried running `make html stage=0 FAST=YES` in `./compiler`, and got the following helpful message: make[2]: *** No rule to make target `html_compiler'. Stop. make[1]: *** [html_compiler] Error 2 make: *** [html] Error 2 So I'm a bit stumped. How do I regenerate Haddock documentation for the GHC API? Thanks! Andrew

3 5