- ghc-devs - Haskell.org

Re: [commit: ghc] master: Fix a couple of inaccurate stack checks (3bebf3c)
by Joachim Breitner 07 Nov '14

07 Nov '14

Hi Simon, with Am Mittwoch, den 05.11.2014, 18:15 +0000 schrieb git(a)git.haskell.org: > commit 3bebf3c2d92e6defc6d17ffa237cc4a9cad71dcf > Author: Simon Marlow <marlowsd(a)gmail.com> > Date: Tue Nov 4 21:31:00 2014 +0000 > > Fix a couple of inaccurate stack checks I observe a 5% runtime performance regression in nofib’s "integer" benchmark: http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2&base=2%2B68&ben=nofib%2… (The graph looks weird because codespeed doesn’t get the order of commits right.) Expected? Or worth looking into? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 1

Problems compiling with llvm-3.5.0-2 on ARM
by Jarl Gunnar Flaten 07 Nov '14

07 Nov '14

Hello, (cf. reddit thread <http://www.reddit.com/r/haskell/comments/2kpsz5/ghc_problem_new_llvm_schedu…> ) I am trying to compile a simple "hello world" program (test.hs). When compiling I am notified: > [1 of 1] Compiling Main ( test.hs, test.o ) > You are using a new version of LLVM that hasn't been tested yet! > We will try though... > Linking test ... But it seems to finish compiling fine, without further errors. However, running the program (./test): > test: schedule: re-entered unsafely. > Perhaps a 'foreign import unsafe' should be 'safe'? Isn't working. I'm not familiar enough with neither LLVM nor Haskell to troubleshoot from either of these; I don't even know if the messages are even related. Any ideas for solutions? Any commands or tests I can perform to give you more information? Thanks, Jarl Gunnar T. Flaten

4 4

How do I write multi-file test that are expected to fail?
by Jan Stolarek 07 Nov '14

07 Nov '14

I want to write a test where I import several modules into module Foo and expect that compilation of Foo fails. How do I do that? If I write: test('T6018fail', normal, compile_fail, ['']) I get en error: T6018fail.hs:5:1: Failed to load interface for `T6018Afail' Use -v to se a list of the files searched for. If I use multimod_compile instead of compile_fail then I get an error because compilation is expected to succeed. Help? Janek

2 3

Update Trac link 'Patches for review'
by Thomas Miedema 07 Nov '14

07 Nov '14

Dear Trac admins, on the left panel of the Trac wiki there is a link <https://ghc.haskell.org/trac/ghc/query?status=patch&ol=id&col=summary&col=o…> called 'Patches for review'. This shows a mix of tickets that have patches attached, and tickets that are being reviewed on Phabricator. Can someone change that link to only show the tickets that have patches attached, such that those are more easily found? You can do this by appending "&differential=" to the url. The list of open Phabricator reviews <https://phabricator.haskell.org/differential/> can be discovered on the Phabricator homepage, but I'm afraid the tickets <https://ghc.haskell.org/trac/ghc/query?status=patch&differential=&col=id&co…> that have patches attached are now sometimes overlooked. Thanks, Thomas

2 1

ANN: Updating flag description in the User's Guide
by Jan Stolarek 07 Nov '14

07 Nov '14

Devs, I have some important information for everyone. TL;DR1 As a rule of thumb, whenever you modify DynFlags or StaticFlags please make absolutely sure that your changes are described in the User's Guide. See Note [Updating flag description in the User's Guide] in DynFlags. TL;DR2 Your help is needed to update the User's Guide. I've spent last two days on updating the flag descriptions in the User's Guide (#9358). Saying that things were a complete mess would be an understatement. We had lots of flags that were not documented in the user's guide, we had documentation for flags that no longer exist, lots of flags were incorrectly labeled as static, etc. It seems that we don't have a habit of updating User's Guide when we change the code responsible for flags. I updated huge chunks of the documentation and things are in a better shape now. But if we forget to update documentation when we make changes then in 2 or 3 years things will most likely be as bad as they were before my clean-up. I added a Note and lots of references to it to remind us about that. If things go well we might even have a Herald rule to remind about updating User's Guide whenever DynFlags and StaticFlags are modified by a commit/revision [1]. However, the task of updating flag descriptions in the User's Guide is not finished. My main focus were the -f*/-fno-* optimisation flags described primarily in sections 4.10 and 4.19.15 (note that HEAD has different section numbers than 7.8.3). I updated what I could but there are still some descriptions missing - I'm not familiar with some of flags that we have. Here's where your help is required. These flags are currently completely missing from the User's Guide: -fbuilding-cabal-package -fflat-cache -fhpc-no-auto -fkill-absence -fkill-one-shot -fsimple-list-literals -fspecialise-aggressively -fuse-rpaths -fspec-constr-recursive -ffloat-lam-args -ffloat-all-lams If you can provide description for any of these flags please edit flags.xml and using.xml. I suspect that -fkill-absence might be related to demand analysis - CCing Nicolas Frisby. Following flags are listed in Flag Reference section (4.19) with a brief one sentence description but they don't have a detailed description in section 4.10 (using.xml): -fcall-arity (CCing Joachim) -funfolding-fun-discount -funfolding-dict-discount -funfolding-keeness-factor -frule-check (see #9776) Following flags have a detailed description but it is confusing: -fdo-eta-reduction -fdo-lambda-eta-expansion Follwoing flags have a description but it is too brief. We should have more details: -fdicts-cheap -fdicts-strict -fdmd-tx-dict-sel (Nicolas, can you update that?) -fmax-inline-memcpy-insns -fmax-inline-memset-insns -fmax-worker-args -fno-opt-coercion -fno-pre-inlining -fsimplifier-phases -fspec-constr-threshold -fspec-constr-count -fstrictness-before These flags were deliberately omitted from the User's Guide because they are deprectaed and will be removed: -fext-core -frewrite-rules For these flags Flag Reference section provides the description of their -fno-* version: -fembed-manifest -fgen-manifest -fghci-history -fghci-sandbox -fpre-inlining -fprint-bind-contents -fprof-count-entries -fshared-implib This seems to go against our convention of describing the flags. Should we revert to desribing their normal version (ie. ones that enable something, not disable)? As part of my work I also removed -ddump-core-pipeline and -ddump-simpl-phases, which weren;t very useful. And I cleaned up DynFlags by putting some of the long lists of flags into alphabetical order. This change is a bit invasive - I'm sorry if it causes merge conflicts, but I believe that in the long run this is beneficial. As I already said I focused primarily on -f* flags. But we should also make sure that documentation of remaining flags is up to date, especially the -d* ones. I don't have more time to put into this so I'm asking for a collective effort to update the User's Guide, especially that we are moving closer to 7.10 release. Janek [1] https://phabricator.haskell.org/T52

4 6

STM and GC write barrier
by Ryan Yates 06 Nov '14

06 Nov '14

Hi All, I'm starting to get to the bottom of something that has been puzzling me for a while. Recently commit 6d784c43592290ec16db8b7f0f2a012dff3ed497 [1] introduced the GC write barrier for TVars. Not fully understanding things and reading the commit message to be saying that this was an optimization, I implemented my hardware transactional memory support without the write barrier (avoiding the extra work inside a transaction). This resulted in occasional crashes where a TVar which was point to a valid heap object when it was committed, pointed to garbage later. My understanding was that the TVar ended up in a later generation then the value that it came to point to and without getting added to the mut list, the value was collected. Adding the write barrier to all TVars written in my hardware transaction made the problem go away. While this all makes sense to me, what doesn't make as much sense is how STM prior to the commit above was not susceptible to the same problem. Is there some machinery to avoid this issue that I'm still missing? Ryan [1]: https://github.com/ghc/ghc/commit/6d784c43592290ec16db8b7f0f2a012dff3ed497

2 2

Resurrecting ticky code
by Mateusz Lenik 06 Nov '14

06 Nov '14

Hi *, Recently I started working on resurrecting ticky code[1] and got to the point where I can compile and run bumpHistogram as well as accompanying code in RTS. Work in progress version can be found at [2], but there are few things remaining to get it working: * missing calls to tickyReturnNewCon, tickyUnboxedTupleReturn and tickyVectoredReturn need to be added. Unfortunately I'm not familiar with the code enough to find the right place to insert them. * magic eight needs to be replaced by a constant both Haskell and C files. Preprocessor macro seems to be the simplest choice here, however I don't find it the cleanest way to do it. I would be very grateful if someone could take a look and point me into the right direction. Best, Mateusz 1: https://ghc.haskell.org/trac/ghc/ticket/8308 2: https://github.com/mlen/ghc/compare/ticky -- Mateusz Lenik GPG: B865 E86A D36C 11A5 C1F8 C1D9 AAD4 CEC9 6B94 92C4

3 4

Re: [commit: ghc] master: Remove -ddump-simpl-phases flag (ad8457f)
by Johan Tibell 06 Nov '14

06 Nov '14

I think this flag is useful for debugging e.g. why something didn't optimize the way you thought. On Nov 6, 2014 1:05 PM, <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : > http://ghc.haskell.org/trac/ghc/changeset/ad8457f93807e3b7a9a24867ed69dc936… > > >--------------------------------------------------------------- > > commit ad8457f93807e3b7a9a24867ed69dc93662a29e3 > Author: Jan Stolarek <jan.stolarek(a)p.lodz.pl> > Date: Wed Nov 5 13:37:25 2014 +0100 > > Remove -ddump-simpl-phases flag > > > >--------------------------------------------------------------- > > ad8457f93807e3b7a9a24867ed69dc93662a29e3 > compiler/main/DynFlags.hs | 15 +++------------ > compiler/simplCore/CoreMonad.lhs | 40 > ++++++---------------------------------- > compiler/simplCore/SimplCore.lhs | 9 +++++---- > docs/users_guide/debugging.xml | 11 ----------- > docs/users_guide/flags.xml | 6 ------ > 5 files changed, 14 insertions(+), 67 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder > --ignore-space-at-eol --cc ad8457f93807e3b7a9a24867ed69dc93662a29e3 > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 1

loadInterfaceForModule
by Edward Z. Yang 06 Nov '14

06 Nov '14

Hello Gergely, I was cleaning up LoadIface and I noticed in commit 69fa2e558d56178d33950df815c3233606b0d44e Author: Austin Seipp <austin(a)well-typed.com> Date: Fri Nov 1 22:15:53 2013 -0500 Add support for module reification (#1480) Authored-by: Gergely Risko <gergely(a)risko.hu> Signed-off-by: Austin Seipp <austin(a)well-typed.com> You added a function loadInterfaceForModule which has the exact same type as loadModuleInterface, except when debugging is on it has an extra check to ensure you don't try to load the the current module (this seems like a general invariant that would be good to enforce). Was there any particular reason you created an extra function for this, or can we just use the existing function? Edward

2 1

Building head with head
by Moritz Angermann 06 Nov '14

06 Nov '14

Hi, today I tried to build head with head on os x. The result was: Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal ... "touch" utils/ghc-cabal/dist/build/tmp/ghc-cabal "cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal inplace/bin/ghc-cabal "inplace/bin/ghc-cabal" configure libraries/binary dist-boot "" --with-ghc="/usr/local/bin/ghc" --with-ghc-pkg="/usr/local/bin/ghc-pkg" --package-db=/Users/angerman/code/ghc/libraries/bootstrapping.conf --disable-library-for-ghci --enable-library-vanilla --disable-library-profiling --disable-shared --configure-option=CFLAGS=" -m64 -fno-stack-protector " --configure-option=LDFLAGS=" -m64 " --configure-option=CPPFLAGS=" -m64 " --gcc-options=" -m64 -fno-stack-protector -m64 " --constraint "binary == 0.7.1.0" --constraint "Cabal == 1.21.1.0" --constraint "hpc == 0.6.0.2" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.10.0.2" --constraint "transformers == 0.4.1.0" --constraint "terminfo == 0.4.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-alex="/Users/angerman/.cabal/bin/alex" --with-happy="/Users/angerman/.cabal/bin/happy" "inplace/bin/ghc-cabal" configure utils/hsc2hs dist "" --with-ghc="/usr/local/bin/ghc" --with-ghc-pkg="/usr/local/bin/ghc-pkg" --package-db=/Users/angerman/code/ghc/libraries/bootstrapping.conf --disable-library-for-ghci --disable-library-vanilla --disable-library-profiling --disable-shared --configure-option=CFLAGS=" -m64 -fno-stack-protector " --configure-option=LDFLAGS=" -m64 " --configure-option=CPPFLAGS=" -m64 " --gcc-options=" -m64 -fno-stack-protector -m64 " --constraint "binary == 0.7.1.0" --constraint "Cabal == 1.21.1.0" --constraint "hpc == 0.6.0.2" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.10.0.2" --constraint "transformers == 0.4.1.0" --constraint "terminfo == 0.4.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-alex="/Users/angerman/.cabal/bin/alex" --with-happy="/Users/angerman/.cabal/bin/happy" Configuring hsc2hs-0.67... Configuring binary-0.7.1.0... ghc-cabal: '/usr/local/bin/ghc-pkg' exited with an error: ghc-pkg: ghc no longer supports single-file style package databases (/Users/angerman/code/ghc/libraries/bootstrapping.conf) use 'ghc-pkg init' to create the database with the correct format. make[1]: *** [utils/hsc2hs/dist/package-data.mk] Error 1 make[1]: *** Waiting for unfinished jobs.... ghc-cabal: '/usr/local/bin/ghc-pkg' exited with an error: ghc-pkg: ghc no longer supports single-file style package databases (/Users/angerman/code/ghc/libraries/bootstrapping.conf) use 'ghc-pkg init' to create the database with the correct format. make[1]: *** [libraries/binary/dist-boot/package-data.mk] Error 1 Does anyone know what needs to be done to make this work? Best, Moritz

2 1