July 2014 - ghc-devs - Haskell.org

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

17 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 17 Jul '14

17 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 17 Jul '14

17 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 16 Jul '14

16 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 16 Jul '14

16 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 16 Jul '14

16 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

HEAD build fails on compiling haddoc
by Karel Gardas 15 Jul '14

15 Jul '14

Hello, I'm trying to compile HEAD on amd64-solaris2 platform, but the build fails with: "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/haddock-library/vendor/attoparsec-0.10.4.0 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.20.0.1 -package array-0.5.0.0 -package base-4.7.1.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-1.3.0.2 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package ghc-7.9.20140715 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/src/Haddock/GhcUtils.hs -o utils/haddock/dist/build/Haddock/GhcUtils.dyn_o utils/haddock/src/Haddock/GhcUtils.hs:105:21: Not in scope: data constructor ‘TyFamInstEqn’ Perhaps you meant ‘TyFamInstD’ (imported from GHC) utils/haddock/src/Haddock/GhcUtils.hs:105:36: ‘tfie_rhs’ is not a (visible) constructor field name gmake[1]: *** [utils/haddock/dist/build/Haddock/GhcUtils.dyn_o] Error 1 gmake: *** [all] Error 2 is this just issue on my system or general issue which waits for someone to resolve it? Since I built HEAD successfully just two days ago, this patch may looks suspiciously: commit 9b8ba62991ae22420a0c4486127a3b22ee7f22bd Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Tue Jul 15 07:43:55 2014 +0100 Entirely re-jig the handling of default type-family instances (fixes Trac #9063) In looking at Trac #9063 I decided to re-design the default instances for associated type synonyms. Previously it was all jolly complicated, to support generality that no one wanted, and was arguably undesirable. Specifically * The default instance for an associated type can have only type variables on the LHS. (Not type patterns.) * There can be at most one default instances declaration for each associated type. To achieve this I had to do a surprisingly large amount of refactoring of HsSyn, specifically to parameterise HsDecls.TyFamEqn over the type of the LHS patterns. That change in HsDecls has a (trivial) knock-on effect in Haddock, so this commit does a submodule update too. The net result is good though. The code is simpler; the language specification is simpler. Happy days. Trac #9263 and #9264 are thereby fixed as well. but I'm not expert so no offense! And if this is a mistake on my side, then I'm really sorry for false alarm. Thanks! Karel

2 2