Re: Windows breakage -- again
2014-07-17 0:51 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:47 GMT+02:00 Niklas Larsson metanik...@gmail.com: I hope they can just be done away with at the source, that is to make gcc generate the assembly primitives. GHC should already be built with i686, but does that reach ghc-prim? This depends on GCC -- if no -march=XXX is explicitly set, I guess it will take its default, which may vary platform by platform. All right, I have finally got a Windows (x64) machine and installed the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as Niklas wrote earlier), where the default -march is i386. You should see this line when trying to compile Johan's test program with the -v flag set: COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' With the -march=i586 flag explicitly set in the command line, no __sync_fetch_and_add_n() calls are generated. [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
I just found exactly the same thing! Well, I used i686 instead. Sounds like it's worthwhile to see if this is limited to ghc-prim or if there's more stuff that's built with i386. 2014-07-17 8:21 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:51 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:47 GMT+02:00 Niklas Larsson metanik...@gmail.com: I hope they can just be done away with at the source, that is to make gcc generate the assembly primitives. GHC should already be built with i686, but does that reach ghc-prim? This depends on GCC -- if no -march=XXX is explicitly set, I guess it will take its default, which may vary platform by platform. All right, I have finally got a Windows (x64) machine and installed the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as Niklas wrote earlier), where the default -march is i386. You should see this line when trying to compile Johan's test program with the -v flag set: COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' With the -march=i586 flag explicitly set in the command line, no __sync_fetch_and_add_n() calls are generated. [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
A perhaps silly question, *should* ghc-prim be built with i386 or i686? On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson metanik...@gmail.com wrote: I just found exactly the same thing! Well, I used i686 instead. Sounds like it's worthwhile to see if this is limited to ghc-prim or if there's more stuff that's built with i386. 2014-07-17 8:21 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:51 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:47 GMT+02:00 Niklas Larsson metanik...@gmail.com: I hope they can just be done away with at the source, that is to make gcc generate the assembly primitives. GHC should already be built with i686, but does that reach ghc-prim? This depends on GCC -- if no -march=XXX is explicitly set, I guess it will take its default, which may vary platform by platform. All right, I have finally got a Windows (x64) machine and installed the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as Niklas wrote earlier), where the default -march is i386. You should see this line when trying to compile Johan's test program with the -v flag set: COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' With the -march=i586 flag explicitly set in the command line, no __sync_fetch_and_add_n() calls are generated. [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
i686 has been out for so long that worrying about i386 support is silly. MinGW-w64 uses i686 by default. Even i586 is *incredibly* conservative. On Jul 16, 2014 11:34 PM, Johan Tibell johan.tib...@gmail.com wrote: A perhaps silly question, *should* ghc-prim be built with i386 or i686? On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson metanik...@gmail.com wrote: I just found exactly the same thing! Well, I used i686 instead. Sounds like it's worthwhile to see if this is limited to ghc-prim or if there's more stuff that's built with i386. 2014-07-17 8:21 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:51 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:47 GMT+02:00 Niklas Larsson metanik...@gmail.com: I hope they can just be done away with at the source, that is to make gcc generate the assembly primitives. GHC should already be built with i686, but does that reach ghc-prim? This depends on GCC -- if no -march=XXX is explicitly set, I guess it will take its default, which may vary platform by platform. All right, I have finally got a Windows (x64) machine and installed the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as Niklas wrote earlier), where the default -march is i386. You should see this line when trying to compile Johan's test program with the -v flag set: COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' With the -march=i586 flag explicitly set in the command line, no __sync_fetch_and_add_n() calls are generated. [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
It certainly shouldn't be built with i386, because that is generating code for a processor that lacks all these fancy atomic instructions. The first of them appears on the 486. i686 should be safe, it goes all the way back to Pentium Pro. 2014-07-17 8:33 GMT+02:00 Johan Tibell johan.tib...@gmail.com: A perhaps silly question, *should* ghc-prim be built with i386 or i686? On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson metanik...@gmail.com wrote: I just found exactly the same thing! Well, I used i686 instead. Sounds like it's worthwhile to see if this is limited to ghc-prim or if there's more stuff that's built with i386. 2014-07-17 8:21 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:51 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:47 GMT+02:00 Niklas Larsson metanik...@gmail.com: I hope they can just be done away with at the source, that is to make gcc generate the assembly primitives. GHC should already be built with i686, but does that reach ghc-prim? This depends on GCC -- if no -march=XXX is explicitly set, I guess it will take its default, which may vary platform by platform. All right, I have finally got a Windows (x64) machine and installed the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as Niklas wrote earlier), where the default -march is i386. You should see this line when trying to compile Johan's test program with the -v flag set: COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' With the -march=i586 flag explicitly set in the command line, no __sync_fetch_and_add_n() calls are generated. [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
Alright, then which Make file do we need to fix to make sure GCC is called correctly? Also, I remember reading that some time during the 4.x GCC series GCC switched to auto-detecting the arch to be that of the machine being used. Could someone try to just switch GCC to a newer version and see if it automatically stops trying to use i386, leading to Simon's problem? On Thu, Jul 17, 2014 at 8:37 AM, Niklas Larsson metanik...@gmail.com wrote: It certainly shouldn't be built with i386, because that is generating code for a processor that lacks all these fancy atomic instructions. The first of them appears on the 486. i686 should be safe, it goes all the way back to Pentium Pro. 2014-07-17 8:33 GMT+02:00 Johan Tibell johan.tib...@gmail.com: A perhaps silly question, *should* ghc-prim be built with i386 or i686? On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson metanik...@gmail.com wrote: I just found exactly the same thing! Well, I used i686 instead. Sounds like it's worthwhile to see if this is limited to ghc-prim or if there's more stuff that's built with i386. 2014-07-17 8:21 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:51 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:47 GMT+02:00 Niklas Larsson metanik...@gmail.com: I hope they can just be done away with at the source, that is to make gcc generate the assembly primitives. GHC should already be built with i686, but does that reach ghc-prim? This depends on GCC -- if no -march=XXX is explicitly set, I guess it will take its default, which may vary platform by platform. All right, I have finally got a Windows (x64) machine and installed the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as Niklas wrote earlier), where the default -march is i386. You should see this line when trying to compile Johan's test program with the -v flag set: COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' With the -march=i586 flag explicitly set in the command line, no __sync_fetch_and_add_n() calls are generated. [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: RFC: style cleanup guidelines for GHC, and related bikeshedding
| I used to be a 80 column guy, but moved away from that the last years. | But you are right, there must be an upper limit and, if 80 is a | problem for code reviews, then it's a reasonable choice. As laptop screens have successively more horizontal pixels and fewer vertical pixels, longer lines use screen real estate better. 80 columns now seems a bit narrow to me. 100 would be better. But I'm not going to die for this Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Updating Haddock submodule
| Is | https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules | #MakingchangestoGHCsubmodules | what you are looking for? Yes, it's the right kind of thing. I failed to find that, apologies. But - the page is advertised as work in progress - it checks out 'master'. Is that always right? perhaps not (see my comments) - it assumes you have anticipated the need for change before you do them Much more likely is my situation in which I altered my tree and then thought oh now I have to commit - it's at the bottom of a long page, most of which is irrelevant if you use ./sync-all (I think??) More generally I think I just need a bit more hand-holding for this process. Examples of expected output at the various stages would be useful. (I didn't include those in my writeup, but I should have.) | Basically in step 12, you do your GHC hacking. Git should also show you | a one line change with a commit reference which is your updated | Haddock. | You should commit that as well. There's an example of the need for an example. How does it display that one line change? What command makes it do so. | Not sure why you have step 14, it seems to me that you should be good | after 13. At step 14 you will already be pointing to the appropriate | commit, it will just happen to be the same as the master branch at that | point too so I think you're done. OK. But the current page clearly states that submodules should be in a detatched-head state, and it plainly isn't at that moment. Perhaps that's fine, but an unequivaocal statement that it's fine would be super helpful. I'm *not* complaining -- just trying to articulate explicitly what would be helpful to me (or other ill-informed people) next time. Thanks SImon | | -- | Mateusz K. | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RFC: style cleanup guidelines for GHC, and related bikeshedding
On Thu, Jul 17, 2014 at 8:40 AM, Simon Peyton Jones simo...@microsoft.com wrote: | I used to be a 80 column guy, but moved away from that the last years. | But you are right, there must be an upper limit and, if 80 is a | problem for code reviews, then it's a reasonable choice. As laptop screens have successively more horizontal pixels and fewer vertical pixels, longer lines use screen real estate better. 80 columns now seems a bit narrow to me. 100 would be better. But I'm not going to die for this Here we go! * Wider screens let you have several Emacs buffers next to each other. At 80 chars you can have about 2 buffers next to each other on a 13 screen. * The average line length is about 30-35 characters in Python. If it's anything similar in Haskell shorter line length are more efficient, looking how much of the lines times columns space is filled with characters. * The eye has trouble traveling back to the next line if lines get too long (at least when reading prose). Research says around 60-70 characters is optimal, if I recall correctly. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
The build is broken? (Haddock parse error)
Hello there,
I have just found the builds are failing due to this (see [1] for the full log):
/usr/home/ghc-builder/work/builder/tempbuild/build/inplace/bin/haddock
--odir=compiler/stage2/doc/html/ghc --no-tmp-comp-dir
--dump-interface=compiler/stage2/doc/html/ghc/ghc.haddock --html
--hoogle --title=ghc-7.9.20140717: The GHC API
--prologue=compiler/stage2/haddock-prologue.txt
--read-interface=../Cabal-1.20.0.1,../Cabal-1.20.0.1/src/%{MODULE/./-}.html\#%{NAME},libraries/Cabal/Cabal/dist-install/doc/html/Cabal/Cabal.haddock
--read-interface=../array-0.5.0.0,../array-0.5.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/array/dist-install/doc/html/array/array.haddock
--read-interface=../base-4.7.1.0,../base-4.7.1.0/src/%{MODULE/./-}.html\#%{NAME},libraries/base/dist-install/doc/html/base/base.haddock
--read-interface=../bin-package-db-0.0.0.0,../bin-package-db-0.0.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/bin-package-db/dist-install/doc/html/bin-package-db/bin-package-db.haddock
--read-interface=../bytestring-0.10.4.0,../bytestring-0.10.4.0/src/%{MODULE/./-}.html\#%{NAME},libraries/bytestring/dist-install/doc/html/bytestring/bytestring.haddock
--read-interface=../containers-0.5.5.1,../containers-0.5.5.1/src/%{MODULE/./-}.html\#%{NAME},libraries/containers/dist-install/doc/html/containers/containers.haddock
--read-interface=../directory-1.2.1.0,../directory-1.2.1.0/src/%{MODULE/./-}.html\#%{NAME},libraries/directory/dist-install/doc/html/directory/directory.haddock
--read-interface=../filepath-1.3.0.2,../filepath-1.3.0.2/src/%{MODULE/./-}.html\#%{NAME},libraries/filepath/dist-install/doc/html/filepath/filepath.haddock
--read-interface=../hoopl-3.10.0.1,../hoopl-3.10.0.1/src/%{MODULE/./-}.html\#%{NAME},libraries/hoopl/dist-install/doc/html/hoopl/hoopl.haddock
--read-interface=../hpc-0.6.0.1,../hpc-0.6.0.1/src/%{MODULE/./-}.html\#%{NAME},libraries/hpc/dist-install/doc/html/hpc/hpc.haddock
--read-interface=../process-1.2.0.0,../process-1.2.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/process/dist-install/doc/html/process/process.haddock
--read-interface=../template-haskell-2.10.0.0,../template-haskell-2.10.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/template-haskell/dist-install/doc/html/template-haskell/template-haskell.haddock
--read-interface=../time-1.4.2,../time-1.4.2/src/%{MODULE/./-}.html\#%{NAME},libraries/time/dist-install/doc/html/time/time.haddock
--read-interface=../transformers-0.4.1.0,../transformers-0.4.1.0/src/%{MODULE/./-}.html\#%{NAME},libraries/transformers/dist-install/doc/html/transformers/transformers.haddock
--read-interface=../unix-2.7.0.2,../unix-2.7.0.2/src/%{MODULE/./-}.html\#%{NAME},libraries/unix/dist-install/doc/html/unix/unix.haddock
--optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o
--optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic
--optghc=-H32m --optghc=-O --optghc=-package-name
--optghc=ghc-7.9.20140717 --optghc=-hide-all-packages --optghc=-i
--optghc=-icompiler/basicTypes --optghc=-icompiler/cmm
--optghc=-icompiler/codeGen --optghc=-icompiler/coreSyn
--optghc=-icompiler/deSugar --optghc=-icompiler/ghci
--optghc=-icompiler/hsSyn --optghc=-icompiler/iface
--optghc=-icompiler/llvmGen --optghc=-icompiler/main
--optghc=-icompiler/nativeGen --optghc=-icompiler/parser
--optghc=-icompiler/prelude --optghc=-icompiler/profiling
--optghc=-icompiler/rename --optghc=-icompiler/simplCore
--optghc=-icompiler/simplStg --optghc=-icompiler/specialise
--optghc=-icompiler/stgSyn --optghc=-icompiler/stranal
--optghc=-icompiler/typecheck --optghc=-icompiler/types
--optghc=-icompiler/utils --optghc=-icompiler/vectorise
--optghc=-icompiler/stage2/build
--optghc=-icompiler/stage2/build/autogen
--optghc=-Icompiler/stage2/build
--optghc=-Icompiler/stage2/build/autogen --optghc=-Icompiler/.
--optghc=-Icompiler/parser --optghc=-Icompiler/utils
--optghc=-Icompiler/../rts/dist/build --optghc=-Icompiler/stage2
--optghc=-optP-DGHCI --optghc=-optP-include
--optghc=-optPcompiler/stage2/build/autogen/cabal_macros.h
--optghc=-package --optghc=Cabal-1.20.0.1 --optghc=-package
--optghc=array-0.5.0.0 --optghc=-package --optghc=base-4.7.1.0
--optghc=-package --optghc=bin-package-db-0.0.0.0 --optghc=-package
--optghc=bytestring-0.10.4.0 --optghc=-package
--optghc=containers-0.5.5.1 --optghc=-package
--optghc=directory-1.2.1.0 --optghc=-package --optghc=filepath-1.3.0.2
--optghc=-package --optghc=hoopl-3.10.0.1 --optghc=-package
--optghc=hpc-0.6.0.1 --optghc=-package --optghc=process-1.2.0.0
--optghc=-package --optghc=template-haskell-2.10.0.0 --optghc=-package
--optghc=time-1.4.2 --optghc=-package --optghc=transformers-0.4.1.0
--optghc=-package --optghc=unix-2.7.0.2 --optghc=-Wall
--optghc=-fno-warn-name-shadowing --optghc=-XHaskell2010
--optghc=-optc-DTHREADED_RTS --optghc=-DGHCI_TABLES_NEXT_TO_CODE
--optghc=-DSTAGE=2 --optghc=-Rghc-timing --optghc=-O2
--optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir
--optghc=compiler/stage2/build --optghc=-hidir
Re: a little phrustrated
I've used Phabricator for the first time yesterday and have also experienced most of the problems mentioned by Richard. The most painful ones were: 1. Complaining about any untracked or uncommited changes in the source tree. This is mostly annoying. How can I tell arcanist to ignore such changes? Rant: I really don't like tools that try to be smarter than me and prohibit from doing what I want them to do. 2. Linters. I vote to disable the tab linter - we already have mechanisms to prevent introducing tabs in the source code. I'd also vote to disable whitespace linter unless we can tweak it to complain only about whitespaces introduced by commits in question. I've also run into issues with updating my revision. `arc diff` did not seem to work. Sadly, I don't remember the details - I'll write them down if it happens again. Janek Dnia środa, 16 lipca 2014, Richard Eisenberg napisał: Hi all, I'm trying to use Phab for the first time this morning, and hitting a fair number of obstacles. I'm writing up my experiences here in order to figure out which of these are my fault, which can be fixed, and which are just things to live with; and also to help others who may go down the same path. If relevant, my diff is at https://phabricator.haskell.org/D73 1) I had some untracked files in a submodule repo. I couldn't find a way to get `arc diff` to ignore these, as they appeared to git to be a change in a tracked file (that is, a change to a submodule, which is considered tracked). `git stash` offered no help, so I had to delete the untracked files. This didn't cause real pain (the files were there in error), but it seems a weakness of the system if I can't make progress otherwise. 2) I develop and build in the same tree. This means that I often have a few untracked files in the outer, ghc.git repo that someone hasn't yet added to .gitignore. Thus, I need to say `--allow-untracked` to get `arc diff` to work. I will likely always need `--allow-untracked`, so I looked for a way to get this to be configured automatically. I found https://secure.phabricator.com/book/phabricator/article/arcanist/#configura tion , but the details there are sparse. Any advice? 3) The linter picks up and complains about tabs in any of my touched files. I can then write an excuse for every `arc diff` I do, or de-tab the files. In one case, I changed roughly one line in the file (MkCore.lhs) and didn't think it right to de-tab the whole file. Even if I did de-tab the whole file, then my eventual `arc land` would squash the whitespace commit in with my substantive commits, which we expressly don't want. I can imagine a fair amount of git fiddling which would push the whitespace commit to master and then rebase my substantive work on top so that the final, landed, squashed patch would avoid the whitespace changes, but this is painful. And advice on this? Just ignore the lint errors and write silly excuses? Or, is there a way Phab/arc can be smart enough to keep whitespace-only commits (perhaps tagged with the words whitespace only in the commit message) separate from other commits when squashing in `arc land`? 4) For better or worse, we don't currently require every file to be tab-free, just some of them. Could this be reflected in Phab's lint settings to avoid the problem in (3)? (Of course, a way to de-tab and keep the history nice would be much better!) 5) In writing my revision description, I had to add reviewers. I assumed these should be comma-separated. This worked and I have updated the Wiki. Please advise if I am wrong. 6) When I looked at my posted revision, it said that the revision was closed... and that I had done it! slyfox on IRC informed me that this was likely because I had pushed my commits to a wip/... branch. Is using wip branches with Phab not recommended? Or, can Phab be configured not to close revisions if the commit appears only in wip/... branches? 7) How can I re-open my revision? 8) Some time after posting, phaskell tells me that my build failed. OK. This is despite the fact that Travis was able to build the same commit (https://travis-ci.org/ghc/ghc/builds/30066130). I go to find out why it failed, and am directed to build log F3870 (https://phabricator.haskell.org/file/info/PHID-FILE-hz2r4sjamkkrbf7nsz6b/) . I can't view the file online, but instead have to download and then ungzip it. Is it possible to view this file directly? Or not have it be compressed? 9) When I do view the build log, I get no answers. The end of the file comes abruptly in the middle of some haddock output, and the closest thing that looks like an error is about a missing link in a haddock tag `$kind_subtyping` in Type.lhs. I didn't touch this file, and I imagine the missing link has been there for some time, so I'm dubious that this is the real problem. Are these log files cut off? 10) More of a question than a phrustration: is there a way to link directly to
Re: The build is broken? (Haddock parse error)
On 07/17/2014 09:05 AM, Páli Gábor János wrote:
Hello there,
I have just found the builds are failing due to this (see [1] for the full
log):
/usr/home/ghc-builder/work/builder/tempbuild/build/inplace/bin/haddock
--odir=compiler/stage2/doc/html/ghc --no-tmp-comp-dir
--dump-interface=compiler/stage2/doc/html/ghc/ghc.haddock --html
--hoogle --title=ghc-7.9.20140717: The GHC API
--prologue=compiler/stage2/haddock-prologue.txt
--read-interface=../Cabal-1.20.0.1,../Cabal-1.20.0.1/src/%{MODULE/./-}.html\#%{NAME},libraries/Cabal/Cabal/dist-install/doc/html/Cabal/Cabal.haddock
--read-interface=../array-0.5.0.0,../array-0.5.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/array/dist-install/doc/html/array/array.haddock
--read-interface=../base-4.7.1.0,../base-4.7.1.0/src/%{MODULE/./-}.html\#%{NAME},libraries/base/dist-install/doc/html/base/base.haddock
--read-interface=../bin-package-db-0.0.0.0,../bin-package-db-0.0.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/bin-package-db/dist-install/doc/html/bin-package-db/bin-package-db.haddock
--read-interface=../bytestring-0.10.4.0,../bytestring-0.10.4.0/src/%{MODULE/./-}.html\#%{NAME},libraries/bytestring/dist-install/doc/html/bytestring/bytestring.haddock
--read-interface=../containers-0.5.5.1,../containers-0.5.5.1/src/%{MODULE/./-}.html\#%{NAME},libraries/containers/dist-install/doc/html/containers/containers.haddock
--read-interface=../directory-1.2.1.0,../directory-1.2.1.0/src/%{MODULE/./-}.html\#%{NAME},libraries/directory/dist-install/doc/html/directory/directory.haddock
--read-interface=../filepath-1.3.0.2,../filepath-1.3.0.2/src/%{MODULE/./-}.html\#%{NAME},libraries/filepath/dist-install/doc/html/filepath/filepath.haddock
--read-interface=../hoopl-3.10.0.1,../hoopl-3.10.0.1/src/%{MODULE/./-}.html\#%{NAME},libraries/hoopl/dist-install/doc/html/hoopl/hoopl.haddock
--read-interface=../hpc-0.6.0.1,../hpc-0.6.0.1/src/%{MODULE/./-}.html\#%{NAME},libraries/hpc/dist-install/doc/html/hpc/hpc.haddock
--read-interface=../process-1.2.0.0,../process-1.2.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/process/dist-install/doc/html/process/process.haddock
--read-interface=../template-haskell-2.10.0.0,../template-haskell-2.10.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/template-haskell/dist-install/doc/html/template-haskell/template-haskell.haddock
--read-interface=../time-1.4.2,../time-1.4.2/src/%{MODULE/./-}.html\#%{NAME},libraries/time/dist-install/doc/html/time/time.haddock
--read-interface=../transformers-0.4.1.0,../transformers-0.4.1.0/src/%{MODULE/./-}.html\#%{NAME},libraries/transformers/dist-install/doc/html/transformers/transformers.haddock
--read-interface=../unix-2.7.0.2,../unix-2.7.0.2/src/%{MODULE/./-}.html\#%{NAME},libraries/unix/dist-install/doc/html/unix/unix.haddock
--optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o
--optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic
--optghc=-H32m --optghc=-O --optghc=-package-name
--optghc=ghc-7.9.20140717 --optghc=-hide-all-packages --optghc=-i
--optghc=-icompiler/basicTypes --optghc=-icompiler/cmm
--optghc=-icompiler/codeGen --optghc=-icompiler/coreSyn
--optghc=-icompiler/deSugar --optghc=-icompiler/ghci
--optghc=-icompiler/hsSyn --optghc=-icompiler/iface
--optghc=-icompiler/llvmGen --optghc=-icompiler/main
--optghc=-icompiler/nativeGen --optghc=-icompiler/parser
--optghc=-icompiler/prelude --optghc=-icompiler/profiling
--optghc=-icompiler/rename --optghc=-icompiler/simplCore
--optghc=-icompiler/simplStg --optghc=-icompiler/specialise
--optghc=-icompiler/stgSyn --optghc=-icompiler/stranal
--optghc=-icompiler/typecheck --optghc=-icompiler/types
--optghc=-icompiler/utils --optghc=-icompiler/vectorise
--optghc=-icompiler/stage2/build
--optghc=-icompiler/stage2/build/autogen
--optghc=-Icompiler/stage2/build
--optghc=-Icompiler/stage2/build/autogen --optghc=-Icompiler/.
--optghc=-Icompiler/parser --optghc=-Icompiler/utils
--optghc=-Icompiler/../rts/dist/build --optghc=-Icompiler/stage2
--optghc=-optP-DGHCI --optghc=-optP-include
--optghc=-optPcompiler/stage2/build/autogen/cabal_macros.h
--optghc=-package --optghc=Cabal-1.20.0.1 --optghc=-package
--optghc=array-0.5.0.0 --optghc=-package --optghc=base-4.7.1.0
--optghc=-package --optghc=bin-package-db-0.0.0.0 --optghc=-package
--optghc=bytestring-0.10.4.0 --optghc=-package
--optghc=containers-0.5.5.1 --optghc=-package
--optghc=directory-1.2.1.0 --optghc=-package --optghc=filepath-1.3.0.2
--optghc=-package --optghc=hoopl-3.10.0.1 --optghc=-package
--optghc=hpc-0.6.0.1 --optghc=-package --optghc=process-1.2.0.0
--optghc=-package --optghc=template-haskell-2.10.0.0 --optghc=-package
--optghc=time-1.4.2 --optghc=-package --optghc=transformers-0.4.1.0
--optghc=-package --optghc=unix-2.7.0.2 --optghc=-Wall
--optghc=-fno-warn-name-shadowing --optghc=-XHaskell2010
--optghc=-optc-DTHREADED_RTS --optghc=-DGHCI_TABLES_NEXT_TO_CODE
--optghc=-DSTAGE=2 --optghc=-Rghc-timing --optghc=-O2
Re: Updating Haddock submodule
On 2014-07-17 at 08:54:32 +0200, Simon Peyton Jones wrote: [...] - it's at the bottom of a long page, most of which is irrelevant if you use ./sync-all (I think??) Fwiw, the page was written to be a `./sync-all`-agnostic on purpose (in fact, ./sync-all isn't mentioned only once for pre-submodule trees) [...] I'm *not* complaining -- just trying to articulate explicitly what would be helpful to me (or other ill-informed people) next time. Maybe we need different two different presentations. One concise reference-like wiki page for Git-gnostic devs, and one for `./sync-all`-accustomed devs (or maybe even a rosetta-stone like translation between 'sync-all' invocations, and what the respective Git-only commands look like) Fwiw, I have started experimenting with a `runghc`-based ./sync-all replacement[1] (which uses only the packages bundled with GHC), but I don't have time to work on it for the next couple of weeks. Cheers, hvr [1]: Currently, it's more of a ghc.git advisor, checking the current state of your Git repo, and telling you what commands you should invoke next, but it's in its really earliest stages. If anyone wants to pick it up, and work on it, lemme know. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: The build is broken? (Haddock parse error)
| parse error on input ‘-- *kind* and role of its argument.
| Luckily,
| laziness should’
|
| [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-
| head/322/10.html
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs
|
|
| ‘-- *’ is Haddock syntax for headers and because GHC doesn't expect a
| Haddock comment there, it chucks a parse error. I think just adding a
| leading space or turning it into {- -} style comment would work.
|
| In all honesty, GHC should just warn and treat as regular comments at
| these cases rather than failing.
I agree. I've been bitten by this several times. But don't you mean Haddock
should just warn...?
S
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RFC: style cleanup guidelines for GHC, and related bikeshedding
Johan Tibell johan.tib...@gmail.com: On Thu, Jul 17, 2014 at 8:40 AM, Simon Peyton Jones simo...@microsoft.com wrote: | I used to be a 80 column guy, but moved away from that the last years. | But you are right, there must be an upper limit and, if 80 is a | problem for code reviews, then it's a reasonable choice. As laptop screens have successively more horizontal pixels and fewer vertical pixels, longer lines use screen real estate better. 80 columns now seems a bit narrow to me. 100 would be better. But I'm not going to die for this Here we go! * Wider screens let you have several Emacs buffers next to each other. At 80 chars you can have about 2 buffers next to each other on a 13 screen. I think that was SimonM's premise for code reviews, that you want lines short enough to have two versions besides each other. * The average line length is about 30-35 characters in Python. If it's anything similar in Haskell shorter line length are more efficient, looking how much of the lines times columns space is filled with characters. The problem is that indentation and long identifiers push you towards longer lines. * The eye has trouble traveling back to the next line if lines get too long (at least when reading prose). Research says around 60-70 characters is optimal, if I recall correctly. I think we read code differently to prose (and prose is not much indented), so I don't think these numbers transfer. Manuel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Updating Haddock submodule
| Maybe we need different two different presentations. One concise | reference-like wiki page for Git-gnostic devs, and one for `./sync- | all`-accustomed devs (or maybe even a rosetta-stone like translation | between 'sync-all' invocations, and what the respective Git-only | commands look like) Maybe so. But we *certainly* need the one for people who are not Git-gnostic. WE provide sync-all, and advise its use for most folk, precisely because it automates a number of tricky corners. So our primary Git-un-gnostic documentation should be directed at that workflow. By all means there can be more implementation detail behind it, for Git gurus. I'm begging for it. Begging! Humbly! Simon | -Original Message- | From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com] | Sent: 17 July 2014 09:20 | To: Simon Peyton Jones | Cc: Mateusz Kowalczyk; ghc-devs@haskell.org | Subject: Re: Updating Haddock submodule | | On 2014-07-17 at 08:54:32 +0200, Simon Peyton Jones wrote: | | [...] | | - it's at the bottom of a long page, most of which is irrelevant if | you use ./sync-all (I think??) | | Fwiw, the page was written to be a `./sync-all`-agnostic on purpose (in | fact, ./sync-all isn't mentioned only once for pre-submodule trees) | | [...] | | I'm *not* complaining -- just trying to articulate explicitly what | would be helpful to me (or other ill-informed people) next time. | | Maybe we need different two different presentations. One concise | reference-like wiki page for Git-gnostic devs, and one for `./sync- | all`-accustomed devs (or maybe even a rosetta-stone like translation | between 'sync-all' invocations, and what the respective Git-only | commands look like) | | Fwiw, I have started experimenting with a `runghc`-based ./sync-all | replacement[1] (which uses only the packages bundled with GHC), but I | don't have time to work on it for the next couple of weeks. | | | Cheers, | hvr | | [1]: Currently, it's more of a ghc.git advisor, checking the current | state of your Git repo, and telling you what commands you should | invoke next, but it's in its really earliest stages. If anyone | wants to pick it up, and work on it, lemme know. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: The build is broken? (Haddock parse error)
On Thu, Jul 17, 2014 at 08:21:43AM +, Simon Peyton Jones wrote:
| parse error on input ‘-- *kind* and role of its argument.
| Luckily,
| laziness should’
|
| [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-
| head/322/10.html
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs
|
|
| ‘-- *’ is Haddock syntax for headers and because GHC doesn't expect a
| Haddock comment there, it chucks a parse error. I think just adding a
| leading space or turning it into {- -} style comment would work.
|
| In all honesty, GHC should just warn and treat as regular comments at
| these cases rather than failing.
I agree. I've been bitten by this several times. But don't you mean
Haddock should just warn...?
The corresponding code is in GHC (only used with Opt_Haddock). So we
need to change this in GHC.
Cheers,
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RFC: style cleanup guidelines for GHC, and related bikeshedding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17/07/14 08:57, Johan Tibell wrote: * Wider screens let you have several Emacs buffers next to each other. At 80 chars you can have about 2 buffers next to each other on a 13 screen. This is my main grief with 100 char lines (which is the Android standard, by the way). I like to have 6 or 8 files open side by side (including diffs and other meta-code). * The eye has trouble traveling back to the next line if lines get too long (at least when reading prose). Research says around 60-70 characters is optimal, if I recall correctly. 66 as far as I remember, but that number is for prose and thus not *very* relevant, as Manuel points out. But I do think it's a problem in code too, regardless of the exact number. Being at 80+ is also often an indication that you're in dire need of refactoring. So while we're all chiming in, my preferences in order: 78 72 80 less than 72 more than 80 - -- Alexander alexan...@plaimi.net https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlPHkAIACgkQRtClrXBQc7VVpwD+K2Q8NYplnmJdNYTulHx4hQBP GVeBJjYQifYrr6MoQq8BAJNP3IUyq+pg+VsGqJg4tCkrv6nmfM1teExzE2avz0/u =76Tq -END PGP SIGNATURE- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Beta Performance dashboard
This is totally brilliant: thank you Joachim! Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Joachim Breitner | Sent: 16 July 2014 09:02 | To: ghc-devs@haskell.org | Subject: Beta Performance dashboard | | Hi, | | I guess it’s time to talk about this, especially as Richard just | brought it up again... | | I felt that we were seriously lacking in our grip on performance | issues. | We don’t even know whether 6.8.3 was better or worse than 6.8.3 or | 7.6.4 in terms of nofib, not to speak of the effect of each single | commit. | | I want to change that, so I set up a benchmark monitoring dashboard. | You can currently reach it at: | | http://ghcspeed-nomeata.rhcloud.com/ | | What does it do? | | | It monitors the repository (master branch only) and builds each commit, | complete with the test suite and nofib. The log is saved and analyzed, | and some numbers are extracted: | * The build time | * The test suite summary numbers | * Runtime (if 1s), allocations and binary sizes of the nofib |benchmarks | | These are uploaded to the website above, which is powered by codespeed, | a general performance dashboard, implemented in Python using Django. | | Under _Changes_, it provides a report for each commit (changes wrt. to | the previous version, and wrt. to 10 revisions earlier, the so-called | “trend”). A summary of these reports is visible on the front-page. | | The _Timeline_ is a graph for each individual performance number. If | there are bumps, you can hopefully find them there! You can also | compare to 7.8.3, which is available as a “baseline”. | | _Comparison_ will be more useful if we have more tagged revision, or if | were benchmarking various options (e.g. -fllvm): Here you can do bar- | chart comparisons. | | Why codespeed? | ~~ | | For a long time I searched for a suitable software product, and one | criterion is that it should be open source, rather simple to set up and | mostly decoupled from other tools, i.e. something that I throw numbers | at and which then displays them nicely. While I don’t think codespeed | is the best performance dashboard out there (I find | http://goperfd.appspot.com/perf a bit better; I wonder how well | codespeed scales to even larger numbers of benchmarks and I wish it | were more git-aware), it was the easiest to get started with. And | thanks to the loose coupling of (1) running the tests to acquire a log, | (2) parsing the log to get numbers and (3) putting them on a server, we | can hopefully replace it when we come along something better. I was | hoping for the Phabricator guys to have something in their tool suite, | but doesn’t look like it. | | How does it work (currently)? | ~ | | My office PC is underused (I work on my laptop), so its currently | dedicated to it. I have a simple shell script that monitors the repo | for new versions. It builds the newest revision and works itself back | to the commit where everything was turned into submodules: | https://github.com/nomeata/codespeed/blob/ghc/tools/ghc/watch.sh | | It calls a script that does the actual building: | https://github.com/nomeata/codespeed/blob/ghc/tools/ghc/run-speed.sh | This produces a log file which should contain all the required numbers | somewhere. | | A second script extracts these numbers (with help of nofib-analyze) and | converts them into codespeed compatible JSON files: | https://github.com/nomeata/codespeed/blob/ghc/tools/ghc/log2json.pl | | Finally, a simple invocation to curl uploads them to codespeed: | https://github.com/nomeata/codespeed/blob/ghc/tools/ghc/upload.sh | | So if you want additional benchmarks to be tracked, make sure they are | present in the logs and adjust log2json.pl. codespeed will | automatically pick up new benchmarks in these logs. Reimplementations | in Haskell are also welcome :-) | | The testsuite is run with VERBOSE=4, so the performance numbers are | also shown for failing test cases. So once a test case goes over the | limit, you can grep through previous logs try to find the real culprit. | I uploaded the logs (so far) to https://github.com/nomeata/ghc-speed- | logs | (but this is not automated yet, ping me if you need an update on this). | | What next? | ~~ | | Clearly, the current setup is only good enough to evaluate the system. | Eventually, I might want to use my office PC again, and the free | hosting on openshift is not very powerful. | | So if we want to keep this setup and make it “official”, we need find a | permanent solution.¹ This involves: | | * A dedicated machine to run the benchmarks. This probably shouldn’t | be |a VM, if we want to keep the noise in the runtime down. | * A machine to run the codespeed server. Can be a VM, or even run on |any of the system that we have right now. Just needs a database |(postgresql preferably) and a webserver
Re: The build is broken? (Haddock parse error)
Oops. I was relying on Travis's validation, which skips haddocking.
This is most likely why Phab's build failed.
Thanks for fixing it!
Richard
On Jul 17, 2014, at 4:44 AM, Simon Hengel s...@typeful.net wrote:
On Thu, Jul 17, 2014 at 08:21:43AM +, Simon Peyton Jones wrote:
| parse error on input ‘-- *kind* and role of its argument.
| Luckily,
| laziness should’
|
| [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-
| head/322/10.html
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs
|
|
| ‘-- *’ is Haddock syntax for headers and because GHC doesn't expect a
| Haddock comment there, it chucks a parse error. I think just adding a
| leading space or turning it into {- -} style comment would work.
|
| In all honesty, GHC should just warn and treat as regular comments at
| these cases rather than failing.
I agree. I've been bitten by this several times. But don't you mean
Haddock should just warn...?
The corresponding code is in GHC (only used with Opt_Haddock). So we
need to change this in GHC.
Cheers,
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
gcc has -march=native which uses the current CPU's architecture, but I think it would be a really bad idea to turn that on by default, because it would mean that we have to be really careful which machine we build the distributions on. On my Linux box, gcc -v says it was configured with --with-arch-32=i686, which means that -march=i686 is the default for 32-bit code. We shouldn't go any later than that IMO. Anyway, this is all beside the point, if we aren't able to run the code generated by gcc (in whatever mode) then there's a bug somewhere. Cheers, Simon On 17/07/2014 07:39, Johan Tibell wrote: Alright, then which Make file do we need to fix to make sure GCC is called correctly? Also, I remember reading that some time during the 4.x GCC series GCC switched to auto-detecting the arch to be that of the machine being used. Could someone try to just switch GCC to a newer version and see if it automatically stops trying to use i386, leading to Simon's problem? On Thu, Jul 17, 2014 at 8:37 AM, Niklas Larsson metanik...@gmail.com wrote: It certainly shouldn't be built with i386, because that is generating code for a processor that lacks all these fancy atomic instructions. The first of them appears on the 486. i686 should be safe, it goes all the way back to Pentium Pro. 2014-07-17 8:33 GMT+02:00 Johan Tibell johan.tib...@gmail.com: A perhaps silly question, *should* ghc-prim be built with i386 or i686? On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson metanik...@gmail.com wrote: I just found exactly the same thing! Well, I used i686 instead. Sounds like it's worthwhile to see if this is limited to ghc-prim or if there's more stuff that's built with i386. 2014-07-17 8:21 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:51 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:47 GMT+02:00 Niklas Larsson metanik...@gmail.com: I hope they can just be done away with at the source, that is to make gcc generate the assembly primitives. GHC should already be built with i686, but does that reach ghc-prim? This depends on GCC -- if no -march=XXX is explicitly set, I guess it will take its default, which may vary platform by platform. All right, I have finally got a Windows (x64) machine and installed the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as Niklas wrote earlier), where the default -march is i386. You should see this line when trying to compile Johan's test program with the -v flag set: COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' With the -march=i586 flag explicitly set in the command line, no __sync_fetch_and_add_n() calls are generated. [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC contribution guidelines and infrastructure talk on 6th September at HIW?
Hi, On Saturday 6th September is the Haskell Implementers Workshop. There has been plenty of discussion over the last 12 months about making contributions to GHC less formidable. Is this story going to be told at HIW? A talk about revised contribution guidelines and helpful tool support might engage those sat on, or peering over, the fence. This might include: * Phabricator code review demonstration. * Continuous integration infrastructure. * Trac demonstration, e.g. how to contribute to design discussions. * Wiki navigation, and important new pages born in recent months. * GHC coding guidelines, e.g. using notes and haddock documentation. * Git policies, e.g. use of submodules. * What GHC needs.. Windows testers? * Old contribution guidelines that no longer apply. Is HIW on 6th September a good place to give a GHC contributions and infrastructure talk? -- Rob ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC contribution guidelines and infrastructure talk on 6th September at HIW?
wearing my i'm on the HIW PC hat, i'm going to speculatively say, Yes!, though i'm ccing Jost into this dialogue :) On Thu, Jul 17, 2014 at 2:18 PM, Rob Stewart robstewar...@gmail.com wrote: Hi, On Saturday 6th September is the Haskell Implementers Workshop. There has been plenty of discussion over the last 12 months about making contributions to GHC less formidable. Is this story going to be told at HIW? A talk about revised contribution guidelines and helpful tool support might engage those sat on, or peering over, the fence. This might include: * Phabricator code review demonstration. * Continuous integration infrastructure. * Trac demonstration, e.g. how to contribute to design discussions. * Wiki navigation, and important new pages born in recent months. * GHC coding guidelines, e.g. using notes and haddock documentation. * Git policies, e.g. use of submodules. * What GHC needs.. Windows testers? * Old contribution guidelines that no longer apply. Is HIW on 6th September a good place to give a GHC contributions and infrastructure talk? -- Rob ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
| On my Linux box, gcc -v says it was configured with --with-arch-32=i686, which means that -march=i686 is the default for 32-bit code. We shouldn't go any later than that IMO. | | Anyway, this is all beside the point, if we aren't able to run the code generated by gcc (in whatever mode) then there's a bug somewhere. I've looked at it more now. The bug is that the mingw32 build is generating code for i386, which lacks these assembler primitives. The failure to link is just because gcc is sticking in these undefined symbols on the off-chance that you want to provide them yourself, they aren't included in gcc. Stick a -march=i686 in there and it works. I don't think it's reasonable to cater for processors that doesn't have support for CAS. So I'm testing a patch that just adds a -march=i686 flag for 32-bit mingw in aclocal.m4. Niklas 2014-07-17 20:06 GMT+02:00 Simon Marlow marlo...@gmail.com: gcc has -march=native which uses the current CPU's architecture, but I think it would be a really bad idea to turn that on by default, because it would mean that we have to be really careful which machine we build the distributions on. On my Linux box, gcc -v says it was configured with --with-arch-32=i686, which means that -march=i686 is the default for 32-bit code. We shouldn't go any later than that IMO. Anyway, this is all beside the point, if we aren't able to run the code generated by gcc (in whatever mode) then there's a bug somewhere. Cheers, Simon On 17/07/2014 07:39, Johan Tibell wrote: Alright, then which Make file do we need to fix to make sure GCC is called correctly? Also, I remember reading that some time during the 4.x GCC series GCC switched to auto-detecting the arch to be that of the machine being used. Could someone try to just switch GCC to a newer version and see if it automatically stops trying to use i386, leading to Simon's problem? On Thu, Jul 17, 2014 at 8:37 AM, Niklas Larsson metanik...@gmail.com wrote: It certainly shouldn't be built with i386, because that is generating code for a processor that lacks all these fancy atomic instructions. The first of them appears on the 486. i686 should be safe, it goes all the way back to Pentium Pro. 2014-07-17 8:33 GMT+02:00 Johan Tibell johan.tib...@gmail.com: A perhaps silly question, *should* ghc-prim be built with i386 or i686? On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson metanik...@gmail.com wrote: I just found exactly the same thing! Well, I used i686 instead. Sounds like it's worthwhile to see if this is limited to ghc-prim or if there's more stuff that's built with i386. 2014-07-17 8:21 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:51 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:47 GMT+02:00 Niklas Larsson metanik...@gmail.com: I hope they can just be done away with at the source, that is to make gcc generate the assembly primitives. GHC should already be built with i686, but does that reach ghc-prim? This depends on GCC -- if no -march=XXX is explicitly set, I guess it will take its default, which may vary platform by platform. All right, I have finally got a Windows (x64) machine and installed the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as Niklas wrote earlier), where the default -march is i386. You should see this line when trying to compile Johan's test program with the -v flag set: COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' With the -march=i586 flag explicitly set in the command line, no __sync_fetch_and_add_n() calls are generated. [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/ Windows/MSYS2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
Can someone see if adding Cc-options: -march=i686 To ghc-prim.cabal resolves the issue? On Jul 17, 2014 9:06 PM, Simon Marlow marlo...@gmail.com wrote: gcc has -march=native which uses the current CPU's architecture, but I think it would be a really bad idea to turn that on by default, because it would mean that we have to be really careful which machine we build the distributions on. On my Linux box, gcc -v says it was configured with --with-arch-32=i686, which means that -march=i686 is the default for 32-bit code. We shouldn't go any later than that IMO. Anyway, this is all beside the point, if we aren't able to run the code generated by gcc (in whatever mode) then there's a bug somewhere. Cheers, Simon On 17/07/2014 07:39, Johan Tibell wrote: Alright, then which Make file do we need to fix to make sure GCC is called correctly? Also, I remember reading that some time during the 4.x GCC series GCC switched to auto-detecting the arch to be that of the machine being used. Could someone try to just switch GCC to a newer version and see if it automatically stops trying to use i386, leading to Simon's problem? On Thu, Jul 17, 2014 at 8:37 AM, Niklas Larsson metanik...@gmail.com wrote: It certainly shouldn't be built with i386, because that is generating code for a processor that lacks all these fancy atomic instructions. The first of them appears on the 486. i686 should be safe, it goes all the way back to Pentium Pro. 2014-07-17 8:33 GMT+02:00 Johan Tibell johan.tib...@gmail.com: A perhaps silly question, *should* ghc-prim be built with i386 or i686? On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson metanik...@gmail.com wrote: I just found exactly the same thing! Well, I used i686 instead. Sounds like it's worthwhile to see if this is limited to ghc-prim or if there's more stuff that's built with i386. 2014-07-17 8:21 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:51 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:47 GMT+02:00 Niklas Larsson metanik...@gmail.com: I hope they can just be done away with at the source, that is to make gcc generate the assembly primitives. GHC should already be built with i686, but does that reach ghc-prim? This depends on GCC -- if no -march=XXX is explicitly set, I guess it will take its default, which may vary platform by platform. All right, I have finally got a Windows (x64) machine and installed the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as Niklas wrote earlier), where the default -march is i386. You should see this line when trying to compile Johan's test program with the -v flag set: COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' With the -march=i586 flag explicitly set in the command line, no __sync_fetch_and_add_n() calls are generated. [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/ Windows/MSYS2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
Now I have an extremely simple patch that I have confirmed is working. As it is in the autoconfig stuff, one needs to run: autoreconf make distclean ./boot and so on As apparently everything has been built with i386 before, I'm curious about if there's a performance increase when going i686. I'll have to measure that, but not tonight. Niklas 2014-07-17 22:05 GMT+02:00 Johan Tibell johan.tib...@gmail.com: Can someone see if adding Cc-options: -march=i686 To ghc-prim.cabal resolves the issue? On Jul 17, 2014 9:06 PM, Simon Marlow marlo...@gmail.com wrote: gcc has -march=native which uses the current CPU's architecture, but I think it would be a really bad idea to turn that on by default, because it would mean that we have to be really careful which machine we build the distributions on. On my Linux box, gcc -v says it was configured with --with-arch-32=i686, which means that -march=i686 is the default for 32-bit code. We shouldn't go any later than that IMO. Anyway, this is all beside the point, if we aren't able to run the code generated by gcc (in whatever mode) then there's a bug somewhere. Cheers, Simon On 17/07/2014 07:39, Johan Tibell wrote: Alright, then which Make file do we need to fix to make sure GCC is called correctly? Also, I remember reading that some time during the 4.x GCC series GCC switched to auto-detecting the arch to be that of the machine being used. Could someone try to just switch GCC to a newer version and see if it automatically stops trying to use i386, leading to Simon's problem? On Thu, Jul 17, 2014 at 8:37 AM, Niklas Larsson metanik...@gmail.com wrote: It certainly shouldn't be built with i386, because that is generating code for a processor that lacks all these fancy atomic instructions. The first of them appears on the 486. i686 should be safe, it goes all the way back to Pentium Pro. 2014-07-17 8:33 GMT+02:00 Johan Tibell johan.tib...@gmail.com: A perhaps silly question, *should* ghc-prim be built with i386 or i686? On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson metanik...@gmail.com wrote: I just found exactly the same thing! Well, I used i686 instead. Sounds like it's worthwhile to see if this is limited to ghc-prim or if there's more stuff that's built with i386. 2014-07-17 8:21 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:51 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 0:47 GMT+02:00 Niklas Larsson metanik...@gmail.com: I hope they can just be done away with at the source, that is to make gcc generate the assembly primitives. GHC should already be built with i686, but does that reach ghc-prim? This depends on GCC -- if no -march=XXX is explicitly set, I guess it will take its default, which may vary platform by platform. All right, I have finally got a Windows (x64) machine and installed the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as Niklas wrote earlier), where the default -march is i386. You should see this line when trying to compile Johan's test program with the -v flag set: COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' With the -march=i586 flag explicitly set in the command line, no __sync_fetch_and_add_n() calls are generated. [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/ Windows/MSYS2 0001-Set-i686-as-the-minimum-architecture-on-32-bit-mingw.patch Description: Binary data ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
2014-07-17 22:05 GMT+02:00 Niklas Larsson metanik...@gmail.com: The bug is that the mingw32 build is generating code for i386, which lacks these assembler primitives. I think this might be a feature instead. As I wrote earlier, on FreeBSD/i386, arch is set to i486 in GCC's configure script [1]. Hence, whatever version I install from the Ports Collection, it will target i486 by default. [1] https://github.com/mirrors/gcc/blob/master/gcc/config.gcc#L2899 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
2014-07-17 22:05 GMT+02:00 Johan Tibell johan.tib...@gmail.com: Can someone see if adding Cc-options: -march=i686 To ghc-prim.cabal resolves the issue? Yes, I can confirm that it works. However, it shall be prefixed with a conditional such as (os(windows) arch(i386)) as x86_64 does not support -march=i686. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
Yes, ultimately the problem is that the mingw-gcc that is in the tarball git has a too low target. But that is a rather larger fix than setting the arch targetted in configure. 2014-07-17 22:50 GMT+02:00 Páli Gábor János pali.ga...@gmail.com: 2014-07-17 22:05 GMT+02:00 Niklas Larsson metanik...@gmail.com: The bug is that the mingw32 build is generating code for i386, which lacks these assembler primitives. I think this might be a feature instead. As I wrote earlier, on FreeBSD/i386, arch is set to i486 in GCC's configure script [1]. Hence, whatever version I install from the Ports Collection, it will target i486 by default. [1] https://github.com/mirrors/gcc/blob/master/gcc/config.gcc#L2899 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
