- ghc-devs - Haskell.org

Weird problem involving untouchable type variables
by Wolfgang Jeltsch 05 May '17

05 May '17

Hi! My inquiry on the users mailing list about untouchable types did not get a reply. Maybe it is better to ask my question here. Today I encountered for the first time the notion of an untouchable type variable. I have no clue what this is supposed to mean. The error message that talked about a type variable being untouchable is unfounded in my opinion. A minimal example that exposes my problem is the following: > {-# LANGUAGE Rank2Types, TypeFamilies #-} > > import GHC.Exts (Constraint) > > type family F a b :: Constraint > > data T b c = T > > f :: (forall b . F a b => T b c) -> a > f _ = undefined This results in the following error message from GHC 8.0.1: > Untouchable.hs:9:6: error: > • Couldn't match type ‘c0’ with ‘c’ > ‘c0’ is untouchable > inside the constraints: F a b > bound by the type signature for: > f :: F a b => T b c0 > at Untouchable.hs:9:6-37 > ‘c’ is a rigid type variable bound by > the type signature for: > f :: forall a c. (forall b. F a b => T b c) -> a > at Untouchable.hs:9:6 > Expected type: T b c0 > Actual type: T b c > • In the ambiguity check for ‘f’ > To defer the ambiguity check to use sites, enable AllowAmbiguousTypes > In the type signature: > f :: (forall b. F a b => T b c) -> a I have no idea what the problem is. The type of f looks fine to me. The type variable c should be universally quantified at the outermost level. Apparently, c is not related to the type family F at all. Why does the type checker even introduce a type variable c0? All the best, Wolfgang

2 1

Trac maintenance
by Ben Gamari 04 May '17

04 May '17

Hello everyone, It has been brought to my attention that Trac has been exhibiting some odd behavior (in particular giving a strange error in place of a proper 404 message). If there's no objection I'll bring down Trac for a few minutes in about an hour in order to debug the issue. Cheers, - Ben

1 0

[ANNOUNCE] GHC tarballs for Windows 10 Creators Update
by Ben Gamari 02 May '17

02 May '17

Hello GHC users, Over the next few weeks Microsoft will be pushing out an update (the so-called Creators Update) to Windows 10 which will break the GCC toolchain shipped with all GHC releases prior to the yet-to-be-released 8.2.1 (see Trac [1] for details). Over the last few weeks our resident Windows expert Tamar and I have been working on preparing a set of patched Windows tarballs with retrofitted GCC toolchains covering GHC 7.2.1 through 8.0.2. These tarballs are now available on downloads.haskell.org. The new tarballs are distinguished from the original releases with a `-win10` suffix. For instance, the 64-bit 8.0.2 binary distribution can be found at, https://downloads.haskell.org/~ghc/8.0.2/ghc-8.0.2-x86_64-unknown-mingw32-w… Other than an updated mingw/bin/gcc.exe, these are identical to the original releases. More details about the patched toolchain can be found in Tamar's ghc-compat repository [2]. As always, let me know if you encounter trouble. Finally, we should all thank Tamar for his work on this; without his effort GHC-on-Windows would be in a sad state indeed. Thanks Tamar! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/ticket/13411 [2] https://github.com/Mistuke/ghc-compat

5 6

forkprocess01
by Simon Peyton Jones 02 May '17

02 May '17

I got this on Linux in libraries/unix/tests Wrong exit code for forkprocess01(threaded1_ls)(expected 0 , actual 134 ) Stderr ( forkprocess01 ): forkprocess01: internal error: multiple ACQUIRE_LOCK: rts/Task.c 226 (GHC version 8.3.20170428 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted when validaiting. It worked fine when I said "make TEST=forkprocess01" (see below). I have no idea if this matters. Simon make TEST=forkprocess01 PYTHON="python3" "python3" ../../../testsuite/driver/runtests.py -e ghc_compiler_always_flags="'-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output'" -e config.compiler_debugged=False -e ghc_with_native_codegen=1 -e config.have_vanilla=True -e config.have_dynamic=True -e config.have_profiling=False -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=1 -e config.have_interp=True -e config.unregisterised=False -e config.ghc_dynamic_by_default=False -e config.ghc_dynamic=True -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=False -e darwin=False -e config.in_tree_compiler=True -e config.cleanup=True -e config.local=True --rootdir=. --configfile=../../../testsuite/config/ghc -e 'config.confdir="../../../testsuite/config"' -e 'config.platform="x86_64-unknown-linux"' -e 'config.os="linux"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=""' -e 'config.top="/5playpen/simonpj/HEAD-6/testsuite"' --config 'compiler="/5playpen/simonpj/HEAD-6/inplace/test spaces/ghc-stage2"' --config 'ghc_pkg="/5playpen/simonpj/HEAD-6/inplace/test spaces/ghc-pkg"' --config 'haddock=' --config 'hp2ps="/5playpen/simonpj/HEAD-6/inplace/test spaces/hp2ps"' --config 'hpc="/5playpen/simonpj/HEAD-6/inplace/test spaces/hpc"' --config 'gs="gs"' --config 'timeout_prog="../../../testsuite/timeout/install-inplace/bin/timeout"' -e "config.stage=2" \ --only=forkprocess01 \ \ \ \ \ \ Timeout is 300 Found 2 .T files... Beginning test run at Tue May 2 10:11:39 2017 BST ====> Scanning ./all.T ====> Scanning ./libposix/all.T =====> forkprocess01(normal) 1 of 1 [0, 0, 0] cd "./forkprocess01.run" && "/5playpen/simonpj/HEAD-6/inplace/test spaces/ghc-stage2" -o forkprocess01 forkprocess01.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix cd "./forkprocess01.run" && ./forkprocess01 =====> forkprocess01(threaded1_ls) 1 of 1 [0, 0, 0] cd "./forkprocess01.run" && "/5playpen/simonpj/HEAD-6/inplace/test spaces/ghc-stage2" -o forkprocess01 forkprocess01.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug -package unix cd "./forkprocess01.run" && ./forkprocess01 +RTS -ls -RTS SUMMARY for test run started at Tue May 2 10:11:39 2017 BST 0:00:03 spent to go through 1 total tests, which gave rise to 8 test cases, of which 6 were skipped 0 had missing libraries 2 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 0 unexpected failures 0 unexpected stat failures simonpj@cam-05-unx:~/5builds/HEAD-6/libraries/unix/tests$

1 0

validation failure on Mac
by Richard Eisenberg 02 May '17

02 May '17

Hi devs, Trying to validate with tonight's HEAD (+ my local changes) on a Mac yields libraries/time/lib/Data/Time/Clock/Internal/SystemTime.hs:22:7: error: error: 'HAVE_CLOCK_GETTIME' is not defined, evaluates to 0 [-Werror,-Wundef] | 22 | #elif HAVE_CLOCK_GETTIME | ^ #elif HAVE_CLOCK_GETTIME ^ libraries/time/lib/Data/Time/Clock/Internal/SystemTime.hs:70:7: error: error: 'HAVE_CLOCK_GETTIME' is not defined, evaluates to 0 [-Werror,-Wundef] | 70 | #elif HAVE_CLOCK_GETTIME | ^ #elif HAVE_CLOCK_GETTIME Is this related to the recent change from #ifdef to #if? Thanks, Richard

3 3

make install fails on master on macOS Sierra
by Mitsutoshi Aoe 28 Apr '17

28 Apr '17

Hi ghc devs, I'm trying to build recent master (579bb766) on macOS Sierra but make install fails as follows: "/usr/local/ghc/ghc-HEAD/lib/ghc-8.3.20170426/bin/ghc-pkg" --force --global-package-db "/usr/local/ghc/ghc-HEAD/lib/ghc-8.3.20170426/package.conf.d" update rts/dist/package.conf.install Reading package info from "rts/dist/package.conf.install" ... done. : Warning: Unrecognized field exposed-modules on line 708 : Warning: Unrecognized field key on line 703 : Warning: Unrecognized field id on line 702 : Warning: Unrecognized field version on line 701 : Warning: Unrecognized field name on line 700 : invalid package identifier: : missing id field make[1]: *** [install_packages] Error 1 make: *** [install] Error 2 The package.conf.install in question is available here: https://gist.github.com/maoe/2cff85004ef8765937023425c53f2cc7. And my build.mk is here: https://gist.github.com/maoe/caee7b2dfd921def4e95580c202cd664 I can't reproduce this error on Linux. Does anyone know how to fix it? Regards, Mitsutoshi

2 4

Pushing to nofib
by Simon Peyton Jones 28 Apr '17

28 Apr '17

How can I push to the nofib repository? I get this: simonpj@cam-05-unx:~/code/HEAD-4/nofib$ git push fatal: remote error: access denied or repository not exported: /nofib.git Thanks Simon

2 3

NCG lowering of sqrt
by Kavon Farvardin 28 Apr '17

28 Apr '17

Given a Cmm expression such as (_c8Gq::F64) = call MO_F64_Sqrt(_s8oX::F64); // CmmUnsafeForeignCall the native code generator produces an actual call to the sqrt C function, which has the side-effect of causing all floating-point registers to be dumped as they are caller-saved. In the nbody benchmark, this is particularly bad for a rather hot piece of code (see below). Ideally the NCG would recognize this foreign call and instead use the `sqrtsd` SSE instruction when targeting x86-64. Does anyone know if the NCG can produce this instruction? I think it would be beneficial, as the below would turn into one or two instructions. Other math functions such as sin/cos require x87 FPU instructions, which as far as I know we're not using. ;;;;;;;;;;; ; NCG generates this in parts of the nbody benchmark ; to compute the sqrt ; subq $8,%rsp movsd %xmm9,176(%rsp) ; all floating-point registers movsd %xmm1,184(%rsp) ; are caller-saved in SysV ABI movsd %xmm2,192(%rsp) movsd %xmm3,200(%rsp) movq %rdi,208(%rsp) movq %rcx,216(%rsp) movq %rsi,224(%rsp) movsd %xmm4,232(%rsp) movsd %xmm5,240(%rsp) movsd %xmm6,248(%rsp) movsd %xmm7,256(%rsp) movsd %xmm8,264(%rsp) movsd %xmm11,272(%rsp) call _sqrt ;; the loads ;; below are interleaved ;; with computations addq $8,%rsp movsd 264(%rsp),%xmm1 movsd 240(%rsp),%xmm2 movsd 224(%rsp),%xmm2 movsd 232(%rsp),%xmm4 movq 200(%rsp),%rax movsd 248(%rsp),%xmm4 movsd 256(%rsp),%xmm4 movq 216(%rsp),%rcx movsd 192(%rsp),%xmm2 ~kavon

3 2

Constraint solver iterations
by amindfv＠gmail.com 27 Apr '17

27 Apr '17

To build the 'vivid' package (on Hackage) with recent versions of GHC (I believe the problem is with 8.0+, didn't see it before then), I need to compile with -fconstraint-solver-iterations=0. (0 meaning unbounded) However, I noticed today that the GHC docs say "Typically one iteration suffices; so please yell if you find you need to set it higher than the default." The code (in Vivid.SynthDef.FromUA) uses a large amount of type family recursion. Is this not a case where I should be yelling? If I should be, I can provide a smaller repro case. If this is expected, are there techniques for rewriting the code in a way that'll fit under the default number of iterations? I've tried rewriting, making the number of iterations logarithmic instead of linear (e.g. by appending lists instead of cons-ing), but still hit the problem (even with an increased but bounded number of iteration steps). Thanks! Tom

2 1

Re: Re: Re-compiling wired-in packages
by Shao Cheng 25 Apr '17

25 Apr '17

Hi, > I did just that recently, see > https://github.com/nomeata/veggies > for how I did it, in particular boot.sh. Thank you for your work! I looked at boot.sh, and tried the "ghc Setup.hs && ./Cabal" approach. It works for ghc-prim & integer-simple, but not base. Since porting gmp to my target platform is hard, I chose integer-simple, and "./Cabal build" produces the following error message for base: Preprocessing library for base-4.10.0.0.. Building library for base-4.10.0.0.. [ 1 of 238] Compiling GHC.IO[boot] ( GHC/IO.hs-boot, dist/build/GHC/IO.o-boot ) [ 2 of 238] Compiling GHC.Stack.Types ( GHC/Stack/Types.hs, dist/build/GHC/Stack/Types.o ) GHC/Stack/Types.hs:57:1: error: Bad interface file: /home/shaocheng/hana/lib/x86_64-linux-ghc-8.3.20170423/integer-simple-0.1.1.1-FieYyHVQ4yaKr3TU2vSN3a/GHC/Integer.hi Something is amiss; requested module integer-simple-0.1.1.1:GHC.Integer differs from name found in the interface file integer-simple:GHC.Integer (if these names look the same, try again with -dppr-debug) | 57 | import GHC.Integer () | ^^^^^^^^^^^^^^^^^^^^^ The compilation for integer-simple didn't produce error, and it is properly registered by ghc-pkg, so I've no idea why there's a bad interface file. Do you have any ideas on possible causes? Thanks a lot. Greetings, Shao Cheng

2 1