- ghc-devs - Haskell.org

primitive using PrimWrappers rather than PrimOpWrappers?
by Carter Schonwald 19 Sep '13

19 Sep '13

hey all, i just rebased my prefetch patch onto HEAD, and now i'm working on getting ghc to build looks like Data.Primitive.Types is trying to import PrimWrappers rather than PrimOpWrappers? i patched that up in my local build, but that seems to be missing, unless i'm overlooking somthing and i'm botching the submodules?

3 5

HEADS UP: New primops in HEAD
by Jan Stolarek 19 Sep '13

19 Sep '13

New comparison primops are now in HEAD. This change breaks backwards compatibility for comparison primops. What you need to do after pulling the latest HEAD is: 1) Upgrade to latest versions of Alex and Happy (cabal update && cabal install alex happy). 2) Rebase your branches on top of HEAD, if these branches were in a repository affected by primop change. Repositories that will were affected: GHC, testsuite, array, base, dph, ghc-prim, integer-gmp, integer-simple, primitive, template-haskell. 3) Blow away your build. Be sure to run ./configure to pick up new versions of Alex and Happy Janek

2 3

Overly verbose output from testsuite
by Jan Stolarek 18 Sep '13

18 Sep '13

I am getting very lengthy output at the end of testsuite run: =====> posix014(normal) 3788 of 3795 [0, 1, 0] cd ../../libraries/unix/tests/libposix && '/5playpen/t-jastol/ghc-validate-2/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-us er-package-db -rtsopts -fno-ghci-history -o posix014 posix014.hs >posix014.comp.stderr 2>&1 cd ../../libraries/unix/tests && ./signals004 </dev/null >signals004.run.stdout 2>signals004.run.stderr cd ../../libraries/unix/tests && ./processGroup001 </dev/null >processGroup001.run.stdout 2>processGroup001.run.stderr cd ../../libraries/unix/tests && ./T3816 </dev/null >T3816.run.stdout 2>T3816.run.stderr cd ../../libraries/unix/tests && ./T1185 </dev/null >T1185.run.stdout 2>T1185.run.stderr cd ../../libraries/unix/tests && ./executeFile001 </dev/null >executeFile001.run.stdout 2>executeFile001.run.stderr cd ../../libraries/unix/tests && ./fileStatusByteString </dev/null >fileStatusByteString.run.stdout 2>fileStatusByteString.run.stderr cd ../../libraries/unix/tests && ./processGroup002 </dev/null >processGroup002.run.stdout 2>processGroup002.run.stderr cd ../../libraries/unix/tests/libposix && ./posix002 </dev/null >posix002.run.stdout 2>posix002.run.stderr cd ../../libraries/unix/tests && ./fileStatus </dev/null >fileStatus.run.stdout 2>fileStatus.run.stderr cd ../../libraries/unix/tests && ./T8108 </dev/null >T8108.run.stdout 2>T8108.run.stderr cd ../../libraries/unix/tests/libposix && ./posix003 </dev/null >posix003.run.stdout 2>posix003.run.stderr cd ../../libraries/unix/tests/libposix && ./posix005 </dev/null >posix005.run.stdout 2>posix005.run.stderr cd ../../libraries/unix/tests/libposix && ./posix004 </dev/null >posix004.run.stdout 2>posix004.run.stderr cd ../../libraries/unix/tests/libposix && ./posix009 </dev/null >posix009.run.stdout 2>posix009.run.stderr cd ../../libraries/unix/tests/libposix && ./posix006 </dev/null >posix006.run.stdout 2>posix006.run.stderr cd ../../libraries/unix/tests/libposix && ./posix010 </dev/null >posix010.run.stdout 2>posix010.run.stderr cd ../../libraries/unix/tests/libposix && ./posix014 </dev/null >posix014.run.stdout 2>posix014.run.stderr Timeout happened...killing process... Wrong exit code (expected 0 , actual 99 ) Stdout: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 6 1 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 11 4 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 20 1 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 28 .... 667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 Stderr: =====> T7815(threaded1) 3795 of 3795 [0, 1, 0] cd ./rts && '/5playpen/t-jastol/ghc-validate-2/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-gh ci-history -o T7815 T7815.hs -threaded -debug >T7815.comp.stderr 2>&1 cd ./rts && ./T7815 50000 +RTS -N2 -RTS </dev/null >T7815.run.stdout 2>T7815.run.stderr I don't know which test causes this, but this wasn't happening 2 or 3 days ago. Anyone knows how to silence this output? It is quite annoying. Janek

3 2

potential for controlling memory alignment?
by Nicolas Frisby 18 Sep '13

18 Sep '13

On my laptop, a program showed a consistent slowdown with -fdicts-strict I didn't find any obvious causes in the Core differences, so I turned to Intel's Performance Counter Monitor for measurements. After trying a few counters, I eventuall saw that there are about an order of magnitude more misaligned memory loads with -fdicts-strict than without, so I think that may be a significant part of the slowdown. I'm not sure if these are code or data reads. Can anyone suggest how to validate this hypothesis about misaligned reads? A subsequent commit has changed the behavior I was seeing, so I'm not interested in alternatives means to determine if -fdicts-strict is somehow at fault — I'm just asking specifically about data/code memory alignment in GHC and how to diagnose/experiment with it. Thanks.

3 3

Suggestion for resolving the Cabal/GHC dependency problems
by Duncan Coutts 18 Sep '13

18 Sep '13

All, I was discussing this with Yuri earlier and I had an idea that I think may resolve our problems. Firstly, what are the problems: 1. ghc devs and users grumble because the ghc library depends on Cabal, making it hard to use the ghc lib with a later Cabal. 2. ghc devs grumble generally that Cabal seems quite big but they only need small parts of it 3. Cabal devs complain that they cannot add useful dependencies (like a parser with error messages) because ghc depends on Cabal. Secondly, let us recall why it is that ghc does use Cabal, and where: 1. it's used by ghc-pkg to read/write the external representation of installed package files (external rep is defined by Cabal spec, and implemented in the Cabal lib) 2. it's used by ghc to read the ghc package database files/dirs. These databases use the same external representation, and ghc & ghc-pkg use the InstalledPackageInfo type internally (InstalledPackageInfo is defined in the Cabal lib). 3. it's used by the ghc build system to help with building all the libraries that ship with ghc. I believe that this part uses more of the build system part of Cabal, not just the types and external formats. 4. ghc comes with Cabal pre-installed so that users can run Setup.hs scripts to install other packages. This was part of the original Cabal design: that all compilers would use the installed package info format defined by Cabal, and all compilers would ship Cabal to users so the Setup.hs mechanism will work. Now, as far as I know, nobody is suggesting that ghc stop shipping Cabal, nor that it stop using it as part of the build system. The problems all centre around use number 2, where the ghc library package depends on Cabal. Number 1 isn't really a problem because ghc-pkg is an executable. So my suggestion is quite simple, eliminate the dependency in case 2 above, but keep it in the other three cases. Specifically: * ghc will use a new internal type to represent info coming from the ghc-pkg databases, ie not InstalledPackageInfo. This can be smaller as ghc doesn't care about the metadata. * The InstalledPackageInfo and the current need for ghc to read its external representation is the main reason the ghc lib depends on Cabal. Other dependencies should be minor and easy to remove. * ghc and ghc-pkg will agree on a new on-disk representation of the installed package info. * ghc-pkg will continue to depend on Cabal, it will continue to use the types and parsers defined by Cabal to read/write the InstalledPackageInfo. It will translate from InstalledPackageInfo into the on-disk representation that ghc & ghc-pkg share. So what might the on-disk representation for the ghc-pkg databases look like? Currently they use the external format of InstalledPackageInfo because this is convenient using Cabal. One simple option is just to store both formats for all packages. Another option would be that ghc never reads package dbs where the cache is out of date. Then it only ever reads the cache and never has to look at the other files. In principle the cache should never be out of date: there are two options for updating the db, calling ghc-pkg, or putting the file directly and calling ghc-pkg recache (distros often use the latter as it is simpler for them). In either case the db cache will be up to date. (In fact calling it a cache is not really correct.) So this is a better solution than the one previously proposed to split out some small part of Cabal, because in this proposal, ghc doesn't depend on Cabal at all, not even some smaller common lib. It's also better from the point of view of the Cabal folks because it does not involve splitting Cabal in unnatural ways. The Cabal folks do want to split the Cabal lib, but not in a way that is especially helpful to ghc. This suggestion is orthogonal to any Cabal lib splits. Further, if only ghc-pkg and the ghc build system depend on Cabal, then it is easier for Cabal to add more dependencies, since they do not have to be installed with ghc (due to the ghc lib depending on them). In particular the Cabal folks would like to use a proper parser and have suggested adding dependencies on parsec, mtl and transformers. If only ghc-pkg depends on Cabal, then these dependencies only need to be used at build time, and do not have to be installed (which also means they don't have to be kept quite so up to date). Note that this would not address SPJ's complaint that the start of building ghc involves building 60+ modules of Cabal. The ghc-cabal tool still uses Cabal and I am not suggesting changing that now. It's plausible that when the Cabal lib is split that the ghc-cabal tool could depend on just the smaller of the two (someone would need to look at how much functionality from the "Simple" build system it uses). I don't see that this is a big priority however. Duncan

4 4

AMP failure
by Simon Peyton-Jones 18 Sep '13

18 Sep '13

I think my tree is up to date but I’m getting this. Any ideas? simon "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name xhtml-3000.2.1 -hide-all-packages -i -ilibraries/xhtml/. -ilibraries/xhtml/dist-install/build -ilibraries/xhtml/dist-install/build/autogen -Ilibraries/xhtml/dist-install/build -Ilibraries/xhtml/dist-install/build/autogen -Ilibraries/xhtml/. -optP-include -optPlibraries/xhtml/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -Wall -XHaskell98 -XCPP -O2 -O -dcore-lint -fno-warn-amp -fno-warn-deprecated-flags -Wwarn -ticky -no-user-package-db -rtsopts -odir libraries/xhtml/dist-install/build -hidir libraries/xhtml/dist-install/build -stubdir libraries/xhtml/dist-install/build -split-objs -dynamic-too -c libraries/xhtml/./Text/XHtml/Frameset/Elements.hs -o libraries/xhtml/dist-install/build/Text/XHtml/Frameset/Elements.o -dyno libraries/xhtml/dist-install/build/Text/XHtml/Frameset/Elements.dyn_o "inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Werror -Wall -H64m -O0 -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist-install/build -iutils/hsc2hs/dist-install/build/autogen -Iutils/hsc2hs/dist-install/build -Iutils/hsc2hs/dist-install/build/autogen -optP-include -optPutils/hsc2hs/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.3.1 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist-install/build -hidir utils/hsc2hs/dist-install/build -stubdir utils/hsc2hs/dist-install/build -c utils/hsc2hs/./HSCParser.hs -o utils/hsc2hs/dist-install/build/HSCParser.dyn_o utils/hsc2hs/HSCParser.hs:24:10: Warning: ‛Parser’ is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. utils/hsc2hs/HSCParser.hs:36:10: Warning: ‛Parser’ is an instance of MonadPlus but not Alternative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. <no location info>: Failing due to -Werror. make[1]: *** [utils/hsc2hs/dist-install/build/HSCParser.dyn_o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 simonpj@cam-05-unx:~/5builds/HEAD$ Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

3 3

Performance failures
by Jan Stolarek 18 Sep '13

18 Sep '13

I've been getting failures from a few performance test: - haddock.base (stat too good - allocation has decreased). I see that allocation was bumped yesterday by Joachim due to changes in printf implementation. For me this causes a failure. Actual bytes allocated: 6294339840 - T5837. Stat too low - allocation increased. This one is failing on my machine since the AMP patch (BTW. - it only fails durng ./validate, never when run separately). Actual bytes allocated: 90587232. I've adjusted the numbers so that tests pass on my machine, but I expect they might start failing on other systems. If they do, please report in this thread and post numbers that you are getting - we'll try to work out a reasonable average. Janek

1 0

[PATCH 1/2] System.IO.Unsafe: fix doc typo: 'System.IO.IO' to 'System.IO'
by slyich＠gmail.com 18 Sep '13

18 Sep '13

From: Sergei Trofimovich <slyfox(a)gentoo.org> Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- System/IO/Unsafe.hs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/System/IO/Unsafe.hs b/System/IO/Unsafe.hs index eb6eef6..1971e9f 100644 --- a/System/IO/Unsafe.hs +++ b/System/IO/Unsafe.hs @@ -16,7 +16,7 @@ ----------------------------------------------------------------------------- module System.IO.Unsafe ( - -- * Unsafe 'System.IO.IO' operations + -- * Unsafe 'System.IO' operations unsafePerformIO, unsafeDupablePerformIO, unsafeInterleaveIO, -- 1.8.3.2

3 3

Safe Haskell and abstraction
by Richard Eisenberg 17 Sep '13

17 Sep '13

Hi David, Joachim, Simon, and I have been trying to figure out how roles and newtype coercions fit in with Safe Haskell. (See, for example http://www.haskell.org/pipermail/ghc-devs/2013-September/002526.html, which I will try to summarize here.) It all boils down to this: Does Safe Haskell strive to guarantee that a datatype whose constructors are not visible is actually abstract? With roles implemented, GeneralizedNewtypeDeriving (GND) and the newtype coercions (implemented through a Coercible "class") are fully type-safe. However, there are various ways of using these features to end-run abstraction. I infer from #5498 that Safe Haskell *does* strive to maintain abstraction barriers, and then we need to think hard about how to fit GND and Coercible into Safe Haskell. Bug #5498 demonstrates how GND breaks abstraction (this behavior is unchanged with roles), and here is an example of how Coercible can, too: > module A (Abstract) where > data Abstract a = MkAbs a > > abstractInt :: Int -> Abstract Int > abstractInt = MkAbs > ------ > module B where > import A > import GHC.Prim -- or wherever Coercible lives > > newtype Age = MkAge Int > notSoAbstract :: Abstract Age > notSoAbstract = coerce (abstractInt 5) Does this behavior eliminate the use of `coerce` within Safe Haskell? Does #5498 eliminate GND from Safe Haskell? And, do the fixes proposed in the email thread linked above fix these problems? To wit, under Safe Haskell, we propose that coercions and GND work only when all constructors of the relevant datatype (and, recursively, all constructors of datatypes mentioned in the top-level datatype, going all the way down) are visible. Thanks, Richard

1 0

[FYI] LLVM: function prefix data (a.k.a. tables-next-to-code) committed
by Gabor Greif 17 Sep '13

17 Sep '13

This looks pretty exiting for LLVM IR-generation: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130909/188042… GHC 7.10 might generate LLVM IR including embedded tables without resorting to linker tricks/postprocessing when targeting LLVM 3.4! The relevant LLVM bug is http://llvm.org/bugs/show_bug.cgi?id=14080 and GHC Trac: http://ghc.haskell.org/trac/ghc/ticket/4213 Cheers, Gabor

4 4