- ghc-devs - Haskell.org

GHC cross compilation survey
by Moritz Angermann 10 May '17

10 May '17

Dear friends, as some of you might have noticed, together with obsidian.systems, I’m trying to make cross compiling GHC a bit easier. To that extend, I’d like to invite you to fill out a short survey[1], so we understand the needs of the community better. Please follow the attached link and fill out the survey! Cheers, Moritz [1]: https://medium.com/@zw3rk/hello-world-a-cross-compilation-survey-890cb95029…

1 1

Hadrian status
by Ben Gamari 09 May '17

09 May '17

Hi Andrey, Given that 8.2.1 is finally starting to come together, now is probably a good time to start reflecting on what will come in 8.4. I think it would be great if we could finally get Hadrian into the tree for the 8.4 release. It would be even better if we could flip over to Hadrian as the primary build system. However, if we are to do this then I think we should leave plenty of time to iron out the inevitable bugs that will arise. Have you given much thought to the schedule post-8.2? Do you think a complete switch-over will be feasible? Cheers, - Ben

1 0

Perf test failing: Trac #13668
by Simon Peyton Jones 09 May '17

09 May '17

Test perf/compiler/T9675 is failing (dramatically) for me. See https://ghc.haskell.org/trac/ghc/ticket/13668 Is it not failing for anyone else? Why does https://perf.haskell.org/ghc/ not show it up? Could someone (Reid?) track down which patch made it go bad? Simon

3 2

GHC API user: How to stop simplifier from turning recursive let-bindings into mutually recursive functions
by Christiaan Baaij 08 May '17

08 May '17

Hello GHC Devs, First some context: I'm using the GHC API to convert Haskell to digital circuit descriptions (clash compiler). When viewed as a structural description of a circuit, recursive let-bindings can be turned into feedback loops. In general, when viewed as a structural description of a circuit, recursive functions describe infinite hierarchy, i.e. they are not realisable as circuit. So now my problem: the simplifier turns recursive let-bindings to recursive functions; i.e. it is turning something which I can translate to a circuit to something which I cannot translate to a circuit. Next follows a reduced test case which exemplifies this behaviour: ``` import Control.Applicative topEntity :: [((),())] topEntity = (,) <$> outport1 <*> outport2 where (outport1, outResp1) = gpio (decodeReq 1 req) (outport2, outResp2) = gpio (decodeReq 2 req) ramResp = ram (decodeReq 0 req) req = core $ (<|>) <$> ramResp <*> ((<|>) <$> outResp1 <*> outResp2) {-# INLINE req #-} core :: [Maybe ()] -> [()] core = fmap (maybe () id) {-# NOINLINE core #-} ram :: [()] -> [Maybe ()] ram = fmap pure {-# NOINLINE ram #-} decodeReq :: Integer -> [()] -> [()] decodeReq 0 = fmap (const ()) decodeReq 1 = id decodeReq _ = fmap id {-# NOINLINE decodeReq #-} gpio :: [()] -> ([()],[Maybe ()]) gpio i = (i,pure <$> i) {-# NOINLINE gpio #-} ``` Now, when we look at the output of the desugarer (-ddump-ds), we can see that the core-level binder of `topEntity` basically follows the Haskell code. However, when we look at the simplifier output, with nearly all transformations disabled (-O0 -ddump-ds), you will see that parts of `topEntity` are split into 3 different top-level, mutually recursive, functions. So my question are: - Which part of the simplifier is turning these local recursive let-binders into global recursive functions? - Is there some way to disable this transformation? - If not, how much effort do you think it would be to put this behaviour behind a dynflag? So that I, as a GHC API user, can disable it for my use-case. I'm willing to implements this dynflag myself. Kind regards, Christiaan

2 2

Re: [GHC] #13646: strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused-pattern-binds
by Ben Gamari 05 May '17

05 May '17

GHC <ghc-devs(a)haskell.org> writes: > #13646: strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused- > pattern-binds > -------------------------------------+------------------------------------- > Reporter: exphp | Owner: (none) > Type: bug | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 8.0.2 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > Yes I see the point. Perhaps we should suppress this warning if the > pattern has an outmost bang. > > Does anyone object? Sounds reasonable to me.

1 0

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