November 2014 - ghc-devs

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 05 Nov '14

05 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

"precedence when printing context" patch breaks ghc-7.8 branch
by Jost Berthold 05 Nov '14

05 Nov '14

Hi, A build of the ghc-7.8 branch in its current state failed for me today in compiler/types/TypeRep.lhs I am at commit 7b1d4c4 ("release note blurb..."), there was only one more since ("revert 'revert'..."). It seems as though the merge of commit d71f316ef ("...precedence when printing contexts..") does not fit into ghc-7.8 (that patch works on HEAD, of course). Error message is: compiler/types/TypeRep.lhs:540:35: Not in scope: data constructor `TyOpPrec' (a constructor introduced by that patch) I have no idea how to fix this (GHC itself suggests "TopPrec", but that actually reverts the fix :-) ) Cheers, Jost Berthold

2 2

Removing -ddump-simpl-phases and -ddump-core-pipeline flags?
by Jan Stolarek 05 Nov '14

05 Nov '14

As part of #9358 I'm considering removing these two flags: -ddump-simpl-phases: dumps simplifier statistics for phases of the simplifier but it works only when used together with -ddump-simpl-stats. User can limit which statistics are displayed by passing in either the simplifier phase number (0,1,2), phase name (final, main, post-worker-wrapper, Gentle) or both (separated with ":"). So for example -ddump-simpl-phases=0:main,1 dumps statistics for all pases labeled as phase 1 and only those pases of phase 0 that are named "main". Has anyone ever used that flag? Do we consider it useful? -ddump-core-pipeline: this seems like a partially implemented stub. The name is very misleading because it is related to plugins. The only thing that it seems to do at the moment is that when -ddump-to-file is set then -ddump-core-pipeline will result in dumping plugin passes to file. Janek

3 2

Tests with compilation errors
by Gintautas Miliauskas 05 Nov '14

05 Nov '14

Going through some validate.sh results, I found compilation errors due to missing libraries, like this one: =====> stm052(normal) 4088 of 4108 [0, 21, 0] cd ../../libraries/stm/tests && 'C:/msys64/home/Gintas/ghc/bindisttest/install dir/bin/ghc.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopt s -fno-warn-tabs -fno-ghci-history -o stm052 stm052.hs -package stm >stm052.comp.stderr 2>&1 Compile failed (status 256) errors were: stm052.hs:10:8: Could not find module ‘System.Random’ Use -v to see a list of the files searched for. I was surprised to see that these are not listed in the test summary at the end of the test run, but only counted towards the "X had missing libraries" row. That setup makes it really easy to miss them, and I can't think of a good reason to sweep such tests under the rug; a broken test is a failing test. How about at least listing such failed tests in the list of failed tests of the end? At least in this case the error does not seem to be due to some missing external dependencies (which probably would not be a great idea anyway...). The test does pass if I remove the "-no-user-package-db" argument. What was the intention here? Does packaging work somehow differently on Linux? (I'm currently testing on Windows.) On a related note, how about separating test failures from failing performance tests ("stat too good" / "stat not good enough")? The latter are important, but they seem to be much more prone to fail without good reason. Perhaps do some color coding of the test runner output? That would also help. -- Gintautas Miliauskas

4 6

GHC AST Annotations (again)
by Alan & Kim Zimmerman 05 Nov '14

05 Nov '14

Hi all Hopefully I will be able to stop harassing everyone on this topic soon. The final versions of the patches for this are ready for review. It has been split into three parts D412 Extends the HsLit values to have an extra field for the original source text, which can differ from the literal value. D426 adds various extra locations in the HsSyn AST to allow the additions of API annotations everywhere needed. D438 modifies the Lexer/Parser to produce API annotations and comments as part of the ParsedSource result. Please review if you are interested. Links https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations https://ghc.haskell.org/trac/ghc/ticket/9628 https://phabricator.haskell.org/D412 https://phabricator.haskell.org/D426 https://phabricator.haskell.org/D438 Regards Alan

1 1

"Hidden" LLVM flags
by Jan Stolarek 05 Nov '14

05 Nov '14

DynFlags list some LLVM flags as "hidden": ( "llvm-tbaa", Opt_LlvmTBAA, nop), -- hidden flag ( "llvm-pass-vectors-in-regs", Opt_LlvmPassVectorsInRegisters, nop), -- hidden flag Do I undertsand correctly that "hidden" means "not documented in the User's Guide"? Is there a good reason for this? I'd like to document them as part of #9358, especially that -fllvm-tbaa is enabled by default for all optimisation levels. Janek

1 1