November 2016 - ghc-devs

OSX build failing
by Matthew Pickering 14 Nov '16

14 Nov '16

Hi all, The OSX build is broken due to 55d535da10dd63bbaf03fb176ced7179087cd0d4 Should I revert the patch or is there a fix coming? Matt ===== commit 55d535da10dd63bbaf03fb176ced7179087cd0d4 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Wed Nov 9 09:20:02 2016 +0000 Remove CONSTR_STATIC Summary: We currently have two info tables for a constructor * XXX_con_info: the info table for a heap-resident instance of the constructor, It has type CONSTR, or one of the specialised types like CONSTR_1_0 * XXX_static_info: the info table for a static instance of this constructor, which has type CONSTR_STATIC or CONSTR_STATIC_NOCAF. I'm getting rid of the latter, and using the `con_info` info table for both static and dynamic constructors. For rationale and more details see Note [static constructors] in SMRep.hs. I also removed these macros: `isSTATIC()`, `ip_STATIC()`, `closure_STATIC()`, since they relied on the CONSTR/CONSTR_STATIC distinction, and anyway HEAP_ALLOCED() does the same job. Test Plan: validate Reviewers: bgamari, simonpj, austin, gcampax, hvr, niteria, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2690 https://phabricator.haskell.org/rGHC

1 1

Non-working "-no-pie" test?
by Gabor Greif 14 Nov '16

14 Nov '16

Hi all, The test for checking "-no-pie" support of GCC doesn't seem to work. See below: $ gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ echo 'int main() { return 0; }' > conftest.c $ if gcc -o conftest -no-pie conftest.c > /dev/null 2>&1 ; then echo YEP ; else echo NOPE ; fi YEP $ if gcc -o conftest -no-pie conftest.c ; then echo YEP ; else echo NOPE ; fi gcc: unrecognized option '-no-pie' YEP $ if gcc -o conftest -no-pie conftest.c > /dev/null ; then echo YEP ; else echo NOPE ; fi gcc: unrecognized option '-no-pie' YEP Is the test supposed to check that there is nothing output into stdout? If so, it seems to fail. It leads to lots of failures when "make test", because gcc gets chatty. Cheers, Gabor PS: I have bash 4.1.

2 1

T12041 failing?
by Simon Marlow 14 Nov '16

14 Nov '16

I just saw the error below in a validate with -DDEBUG. Anyone know about this? --- /tmp/ghctest-uhJ8rt/test spaces/./indexed-types/should_fail/T12041.run/T12041.stderr.normalised 2016-11-09 12:13:38.206501840 +0000 +++ /tmp/ghctest-uhJ8rt/test spaces/./indexed-types/should_fail/T12041.run/T12041.comp.stderr.normalised 2016-11-09 12:13:38.206501840 +0000 @@ -1,7 +1,17 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.1.20161109 for x86_64-unknown-linux): + ASSERT failed! + i_axb + Call stack: + CallStack (from HasCallStack): + prettyCurrentCallStack, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + callStackDoc, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + assertPprPanic, called at compiler/typecheck/TcType.hs:<line>:<column> in <package-id>:TcType + Call stack: + CallStack (from HasCallStack): + prettyCurrentCallStack, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + callStackDoc, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + pprPanic, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + assertPprPanic, called at compiler/typecheck/TcType.hs:<line>:<column> in <package-id>:TcType -T12041.hs:12:15: - Expected kind â€˜i -> Constraintâ€™, - but â€˜(~) Intâ€™ has kind â€˜* -> Constraintâ€™ - In the type â€˜(~) Intâ€™ - In the type instance declaration for â€˜Obâ€™ - In the instance declaration for â€˜Category Iâ€™ +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T12041(normal)

2 2

build fail with latest 8.1 sources
by John Leo 13 Nov '16

13 Nov '16

Hi everyone, I'm trying to build the latest 8.1 sources on a Mac running El Capitan. I'm getting an error I'd never seen before and wonder if anyone has any pointers of how I might fix things. I blew away my GHC, re-cloned from github, reconfigured and I still get the same error. The following are the relevant output lines; the problem is that the template-haskell version doesn't seem to match. I'm not sure whether this is coming from the template-haskell in 8.1 or in 8.0.1 (which I'm using to build 8.1), but checking the latter I have version 2.11.0.0 which I assume should be sufficient. John -------------------- Configuring ghc-pkg-6.9... Configuring ghc-8.1... ghc-cabal: Encountered missing dependencies: template-haskell ==2.11.* && ==2.12.0.0 make[1]: *** [compiler/stage1/package-data.mk] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 ---------------- internal-229:~/haskell/ghc> cabal update (git)-[master] Downloading the latest package list from hackage.haskell.org Skipping download: local and remote files match. internal-229:~/haskell/ghc> cabal install template-haskell (git)-[master] Resolving dependencies... All the requested packages are already installed: template-haskell-2.11.0.0 Use --reinstall if you want to reinstall anyway.

3 5

Windows build broken -- again
by Simon Peyton Jones 13 Nov '16

13 Nov '16

Sigh. The Simon PJ Windows Buildbot reports "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-DWINVER=0x06000100 -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wnoncanonical-monad-instances -c rts/CheckUnload.c -o rts/dist/build/CheckUnload.o In file included from rts\CheckUnload.c:16:0: error: rts\LinkerInternals.h:284:15: error: error: unknown type name 'UChar' STATIC_INLINE UChar * ^ rts\LinkerInternals.h: In function 'myindex': rts\LinkerInternals.h:288:11: error: error: 'UChar' undeclared (first use in this function) ((UChar*)base) + scale * index; ^ rts\LinkerInternals.h:288:11: error: note: each undeclared identifier is reported only once for each function it appears in rts\LinkerInternals.h:288:17: error: error: expected expression before ')' token ((UChar*)base) + scale * index; ^ rts\LinkerInternals.h:285:28: error: error: unused parameter 'base' [-Werror=unused-parameter] myindex ( int scale, void* base, int index ) ^ rts\LinkerInternals.h: At top level: rts\LinkerInternals.h:292:5: error: error: unknown type name 'UChar' UChar* name, ^ rts\LinkerInternals.h:293:5: error: error: unknown type name 'UChar' UChar* strtab); ^ cc1.exe: all warnings being treated as errors `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) make[1]: *** [rts/ghc.mk:255: rts/dist/build/CheckUnload.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:127: all] Error 2 /c/code/HEAD-1$

3 2

GHC pretty printer philosophy
by Alan & Kim Zimmerman 13 Nov '16

13 Nov '16

I am currently working on #3384, with the intent of ensuring that parse (ppr (parse source)) == parse source I have hit the issue where foo :: (Int) has the parens reflected in the original parsed AST, but the types pretty printer goes to a lot of trouble to remove any parens not required to interpret the meaning of the type. So the question is, should the default ppr faithfully reproduce the source that was parsed to generate the given AST, or simplify it? >From a round-tripping perspective I prefer the former, but there are other use cases where the current behaviour is preferred. If the original is preferred, it can perhaps be enabled via a flag to the pretty printer, but before doing that I want to see if it actually matters. Alan

2 2

data families syntax
by Harendra Kumar 13 Nov '16

13 Nov '16

I am curious about why the data families syntax was chosen to be the way it is. For example a list can be defined as follows: data family List a data instance List Char = Empty | Cons Char (List Char) data instance List () = Count Int Instead why not define it as: data List :: * -> * data List Char = Empty | Cons Char (List Char) data List () = Count Int The latter form looks more intuitive and easy to remember to me since it is very similar to the way value level functions are defined (signature & pattern matching defs). Here we are just defining a type level function instead. -harendra

1 1

New home for the perf.haskell.org builder wanted
by Joachim Breitner 11 Nov '16

11 Nov '16

Hi, although I have moved away from Karlsruhe three months ago, so far it is still my office PC driving https://perf.haskell.org/ghc/ But a new person is now using my desk and wants to use this machine, so I should really really move this away from there now. Sebastian Graf has been working on turning gipeda, the Frontend perf.haskell.org, into a more general service open to open source Haskell projects, and this is close, but not close enough to simply stop running the performance tests until he is good to go. He currently has a machine given from haskell.org to run this on, but it is a virtual machine and the measurements are too flaky for real use. So basically, I need a decent non-virtualized (or virtualized, but exclusive) machine to move my performance build runner to, as quickly as possible. The current specs are * 8 core Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz * 16 GB RAM but it does not matter too much, a slightly weaker machine would be able to keep up as well. I also do not necessarily need root access (but it would be beyond the point if the machine would do other stuff that incurs a heavy load). The same machine could then be used by Sebastian for his more general setup, once that is ready to go. Does anyone have something handy? 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

3 5

177 unexpected test failures on a new system -- is this yet another linker issue?
by Ömer Sinan Ağacan 11 Nov '16

11 Nov '16

I'm trying to validate on a new system (not sure if related, but it has gcc 6.2.1 and ld 2.27.0), and I'm having 177 unexpected failures, most (maybe even all) of them are similar to this one: =====> T5976(ext-interp) 1 of 1 [0, 0, 0] cd "./th/T5976.run" && "/home/omer/haskell/ghc/inplace/test spaces/ghc-stage2" -c T5976.hs -dcore-dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0 Actual stderr output differs from expected: --- ./th/T5976.run/T5976.stderr.normalised 2016-11-10 23:01:39.351997560 -0500 +++ ./th/T5976.run/T5976.comp.stderr.normalised 2016-11-10 23:01:39.351997560 -0500 @@ -1,7 +1,4 @@ - -T5976.hs:1:1: - Exception when trying to run compile-time code: - bar -CallStack (from HasCallStack): - error, called at T5976.hs:<line>:<column> in <package-id>:Main - Code: error ((++) "foo " error "bar") +ghc-iserv.bin: internal loadArchive: GNU-variant filename offset not found while reading filename f + (GHC version 8.1.20161107 for x86_64_unknown_linux) + Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug +ghc: ghc-iserv terminated (-6) *** unexpected failure for T5976(ext-interp) Does anyone know what is this about?

4 8

Breakage due to CallStack refactoring
by Ben Gamari 11 Nov '16

11 Nov '16

Hi Simon, In 317236db308d you performed some refactoring of CallStack defaulting and noted that there was no change in visisble behavior. However, it isn't seem that this is true. The following two tests [1] now fail as callstacks are no longer produced in their output, TEST="assert T10845" Presumably this isn't expected. Cheers, - Ben [1] https://phabricator.haskell.org/harbormaster/build/14964/?l=100

2 1