- ghc-devs - Haskell.org

New perf.haskell.org/ghc builder up
by Joachim Breitner 02 Dec '16

02 Dec '16

Hi, Brynmar, via Richard, has sponsored a new machine to build GHC commits for https://perf.haskell.org/ghc/ and I have set it up now. Since the numbers will be incomparable with the previous ones, I started the benchmarking from scratch, starting with 853cdaea7f8724cd071f4fa7ad6c5377a2a8a6e4 which was the last commit benchmarked before. The machine is churning through all commits of the last month at a speed of one commit per hour, so eventually https://perf.haskell.org/ghc/ will give information about up-to-date commits again. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

Re: [GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P`
by George Colpitts 01 Dec '16

01 Dec '16

I can confirm that what Ben says is true for me using XCode 8.1 On Thu, Dec 1, 2016 at 6:21 PM GHC <ghc-devs(a)haskell.org> wrote: > #11744: Latest Xcode update violates POSIX compliance of `nm -P` > ---------------------------------+-------------------------------------- > Reporter: hvr | Owner: > Type: bug | Status: new > Priority: highest | Milestone: > Component: Build System | Version: > Resolution: | Keywords: > Operating System: MacOS X | Architecture: x86_64 (amd64) > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): phab:D2113 > Wiki Page: | > ---------------------------------+-------------------------------------- > > Comment (by bgamari): > > It actually appears that the latest XCode release (8.1) fixes this. It > shouldn't be necessary to use `nm-classic` with, > {{{ > $ nm --version > Apple LLVM version 8.0.0 (clang-800.0.38) > Optimized build. > Default target: x86_64-apple-darwin16.0.0 > Host CPU: haswell > }}} > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11744#comment:20> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

testsuite broken
by Simon Peyton Jones 01 Dec '16

01 Dec '16

Yikes. I can’t run the testsuite on Linux (debian ? I think…). See below. I installed python3 by saying apt-get install python3 And indeed python3 --version Python 3.2.3 This is bad. Can anyone help? Simon PYTHON="python3" "python3" ../../driver/runtests.py -e ghc_compiler_always_flags="'-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -dno-debug-output'" -e config.compiler_debugged=True -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=False -e config.unregisterised=False -e config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=False -e darwin=False -e config.in_tree_compiler=True --threads=33 -e config.cleanup=True -e config.local=False --rootdir=. --configfile=../../config/ghc -e 'config.confdir="../../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-4/testsuite"' --config 'compiler="/5playpen/simonpj/HEAD-4/inplace/test spaces/ghc-stage1"' --config 'ghc_pkg="/5playpen/simonpj/HEAD-4/inplace/test spaces/ghc-pkg"' --config 'haddock="/5playpen/simonpj/HEAD-4/inplace/test spaces/haddock"' --config 'hp2ps="/5playpen/simonpj/HEAD-4/inplace/test spaces/hp2ps"' --config 'hpc="/5playpen/simonpj/HEAD-4/inplace/test spaces/hpc"' --config 'gs="gs"' --config 'timeout_prog="../../timeout/install-inplace/bin/timeout"' -e "config.stage=1" --summary-file "../../../testsuite_summary_stage1.txt" --no-print-summary 1 \ \ \ \ \ \ -e config.speed="2" \ Traceback (most recent call last): File "../../driver/runtests.py", line 210, in <module> from testlib import * File "/home/simonpj/code/HEAD-4/testsuite/driver/testlib.py", line 1286 f.write(u':set prog ' + name + u'\n') ^ SyntaxError: invalid syntax

3 3

Compiling on OpenBSD-current
by Adam Steen 01 Dec '16

01 Dec '16

Hi When Compiling on OpenBSD-Current I get the follow error, what do i need to do to fix this? Cheers Adam ===--- building phase 0 gmake --no-print-directory -f ghc.mk phase=0 phase_0_builds gmake[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 gmake --no-print-directory -f ghc.mk phase=1 phase_1_builds "/usr/local/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/hsc2hs/autogen -Iutils/hsc2hs/dist/build/hsc2hs/autogen -optP-include -optPutils/hsc2hs/dist/build/hsc2hs/autogen/cabal_macros.h -package-id base-4.9.0.0 -package-id containers-0.5.7.1 -package-id directory-1.2.6.2 -package-id filepath-1.4.1.0 -package-id process-1.4.2.0 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -optl-z -optlwxneeded -static -O0 -H64m -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/hsc2hs/autogen -Iutils/hsc2hs/dist/build/hsc2hs/autogen -optP-include -optPutils/hsc2hs/dist/build/hsc2hs/autogen/cabal_macros.h -package-id base-4.9.0.0 -package-id containers-0.5.7.1 -package-id directory-1.2.6.2 -package-id filepath-1.4.1.0 -package-id process-1.4.2.0 -XHaskell2010 -no-user-package-db -rtsopts utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Paths_hsc2hs.o <no location info>: error: Warning: Couldn't figure out linker information! Make sure you're using GNU ld, GNU gold or the built in OS X linker, etc. cc: wxneeded: No such file or directory `cc' failed in phase `Linker'. (Exit code: 1) compiler/ghc.mk:580: compiler/stage1/build/.depend-v.haskell: No such file or directory gmake[1]: *** [utils/hsc2hs/ghc.mk:15: utils/hsc2hs/dist/build/tmp/hsc2hs] Error 1 gmake: *** [Makefile:125: all] Error 2

4 3

Windows build
by Simon Peyton Jones 30 Nov '16

30 Nov '16

Thanks for all the work you've been doing on the Windows build. As requested by Tamar I removed ghc-tarballs, and reconfigured. Then I built from scratch. I get the following testsuite failures Simon Unexpected failures: ghci/prog003/prog003.run prog003 [bad exit code] (ghci) plugins/plugins05.run plugins05 [exit code non-0] (normal) plugins/plugins01.run plugins01 [bad exit code] (normal) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/T11244.run T11244 [bad stderr] (normal) plugins/T12567a.run T12567a [bad exit code] (normal) rts/testmblockalloc.run testmblockalloc [bad exit code] (normal) simplCore/should_compile/T7702.run T7702 [exit code non-0] (normal) Unexpected stat failures: perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) Framework failures: ghci/scripts/ghci062.run ghci062 [ghci-ext] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test spaces/./ghci/scripts/ghci062.run') plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T10294a.run T10294a [normal] (pre_cmd failed: 2) plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) th/TH_repPrim.run TH_repPrim [ext-interp] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test spaces/./th/TH_repPrim.run') th/TH_repPatSig.run TH_repPatSig [ext-interp] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test spaces/./th/TH_repPatSig.run')

2 1

Separating typechecking and type error reporting in two passes?
by Joachim Breitner 30 Nov '16

30 Nov '16

Hi, the following is a rough idea that I came up with while pondering #12864, which is about better (and fewer!) error messages when the user forgot an argument to a function, or swapped their order. The current scheme of type checking and error reporting is the following (please correct me if I am wrong, I have actually done little in this area so far): The typechecker traverses the syntax tree from top to bottom. Along the way, it keeps track of the current context in terms of SDoc fragments of the form “In the second argument of…”. It generates constraints (e.g. the argument type of a function is the type of the actual argument), which it either solves, or propagate outwards as “wanted constraints”, which refer to their context, and refer to a “hole” in the program where, if this constraint gets solved later, some form of evidence gets filled in. At the end, if there are any wanted constraints left, they are reported as type errors, together with the context they are mentioned. But with -fdefer-type-errors, they are not reported, but the evidence holes are filled in with essentially calls to `error` that print the error message at runtime. The problem I see with this approach is that the type checker has to remember interesting bits about context that might possibly eventually be relevant when reporting the error. In particular, it makes it harder to report multiple related error messages at once. So I am wondering if this approach would be better: The type checker does *not* bother keeping track of context: It traverses the syntax tree, creates constraints, and unsolvable constraints get filled with “error evidence”. Basically as if -fdefer-type-errors is one. Then a second pass is done over the syntax tree. This pass does keep track of the context. Whenever it finds some error evidence, it reports it. I see the following advantages: * The type checker code gets a bit simpler and tidier. * As most compiled programs are type correct [citation needed], the type checker, but not the error reporting, is compiler-performance- critical. This might make type checking a (possibly insignificant) tad faster. * The error reporting pass can “look around” more. For example, before recursing into a pair `(e1,e2)`, it could check for the special case of `(e1 ▷ TyError Int Bool, e1 ▷ TyError Bool Int)` and report this as one error “Tuple with swapped arguments” instead of two errors. The #12864 is a more elaborate application of this. * There could even be an intermediate pass over the syntax tree between typechecking and error reporting that “transform” or “optimizes” the AST by moving type errors around, by coalescing error or other things, all with the aim of giving easier to understand error messages. * (This is getting into the area of wild dreams:) Library authors could somehow express custom error messages for certain patterns of the form If the AST now contains an application of `Library.foo` where the first argument is a type error `TyError Int Bool`, then give this particular domain-specific error message. I don’t see any disadvantages now, but there probably are some, and I would be grateful about feedback from those who actually have worked with this part of GHC before. Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

5 7

Testsuite and Python 3
by Ben Gamari 30 Nov '16

30 Nov '16

Hello everyone, Note that yesterday I flipped the switch in the build system to use the Python 3 interpreter by default when invoking the testsuite driver. The motivation for this is the fact that Python 2.7 is quite buggy on Windows, which resulted in spurious testsuite failures (see #12554). The question remains, however, of how much we care to preserve compatibility with Python 2. From what little I've seen so far I think it would be easier for everyone involved if we just let Python 2 pass into the sunset. Afterall, Python 3 is no less available than 2 at this point. Thoughts? Cheers, - Ben

2 1

Windows toolchain update
by lonetiger＠gmail.com 30 Nov '16

30 Nov '16

Hi Windows devs, The Windows GCC has been updated to 6.2.0 and binutils to 2.27. At some point please rebuild using these binaries. Do throw away your old toolchain cache before getting the new one: rm -rf ghc-tarballs && ./configure --enable-tarballs-autodownload The plan is to ship these versions with GHC 8.2, though binutils will likely Get another minor bump. Thanks, Tamar

1 0

Status of "Improved LLVM backend"
by Michal Terepeta 30 Nov '16

30 Nov '16

Hi all, I was wondering what’s the current status of the “Improved LLVM backend” project ( https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend ). The page mentions a few main problems, but some seem to be already fixed: 1) Using/supporting only one version of LLVM. This has been done AFAIK. 2) Prebuilt binaries to be shipped together with GHC. I can't find anything about this. Is there a ticket? Has there been any progress on this? 3) Adding support for split-objs I found a ticket about it: https://ghc.haskell.org/trac/ghc/ticket/8300 which was closed as WONTFIX in favor of split-sections. So I guess this can also be considered as done. 4) Figuring out what LLVM optimizations are useful. Again, I can seem to find anything here. Has anyone looked at this? I only found an issue about this: https://ghc.haskell.org/trac/ghc/ticket/11295 The page also mentions that the generated IR could be improved in many cases, but it doesn't link to any tickets or discussions. Is there something I could read to better understand what are the main problems? The only thing I can recall is that proc point splitting is likely to cause issues for LLVM's ability to optimize the code. (but I only found a couple of email threads about this but couldn't find any follow-ups) Thanks, Michal

2 5

[ANNOUNCE] GHC 8.0.2 release candidate 1
by Ben Gamari 29 Nov '16

29 Nov '16

Hello everyone, The GHC team is happy to (finally!) announce the first candiate of the 8.0.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at http://downloads.haskell.org/~ghc/8.0.2-rc1/ This is the first of what will hopefully be only two release candidates leading up the final 8.0.2 release. This release will fix a number bugs found in 8.0.1 including, * Interface file build determinism (#4012). * Compatibility with macOS Sierra and GCC compilers which compile position-independent executables by default * Runtime linker fixes on Windows (see #12797) * A compiler bug which resulted in undefined reference errors while compiling some packages (see #12076) * Compatability with systems which use the gold linker * A number of memory consistency bugs in the runtime system * A number of efficiency issues in the threaded runtime which manifest on larger core counts and large numbers of bound threads. * A typechecker bug which caused some programs using -XDefaultSignatures to be incorrectly accepted. * More than two-hundred other bugs. See Trac [1] for a complete listing. Unfortunately there is one known bug (#12757) which can result in runtime crashes which is still lurking in -rc1. This will be fixed in -rc2, which will be released in about a week. As always, let us know if you encounter trouble. Thanks to everyone who has contributed so far! Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.0.2&col=id…

6 11