- ghc-devs - Haskell.org

Windows build broken again: urgent
by Simon Peyton Jones 01 Dec '14

01 Dec '14

Alas. Alack. The Windows build is broken again. This time it's pretty fundamental: the stage2 compiler seg-faults every time it invokes the linker: * On GHCi startup * On every Template Haskell splice I don't know when this started, but I did a successful build at 23.10 on 24 November, so it's during the last week. I would gladly do any experiments if someone tells me what to do. It would be really good to fix this. At the moment I'm pretty much stalled on laptop work. Simon

1 0

Re: [commit: ghc] master: compiler: fix trac issue #8815 (780b061)
by Joachim Breitner 30 Nov '14

30 Nov '14

Hi, just a quick note: This commit message is rather unhelpful. In this case it is not a big deal (the patch is quite self-explanatory), but I recommend you to manually clean up arc-generated commit messages before pushing. Also remember when creating a Phab DR that whatever you put in the summary will be part of the default commit message. Greetings, Joachim (who does more complaining than actual contributing these days...) Am Sonntag, den 30.11.2014, 19:17 +0000 schrieb git(a)git.haskell.org: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/780b061ce2aea4722d1a5d0e46fd4ed8e… > > >--------------------------------------------------------------- > > commit 780b061ce2aea4722d1a5d0e46fd4ed8ee2641d6 > Author: Sivaram Balakrishnan <sivaram1992(a)gmail.com> > Date: Sun Nov 30 13:05:56 2014 -0600 > > compiler: fix trac issue #8815 > > Summary: This patch changes the error message as suggested in trac issue #8815 comments. > > Reviewers: jstolarek, austin > > Reviewed By: jstolarek, austin > > Subscribers: jstolarek, thomie, carter > > Differential Revision: https://phabricator.haskell.org/D533 > > GHC Trac Issues: #8815 > > > >--------------------------------------------------------------- > > 780b061ce2aea4722d1a5d0e46fd4ed8ee2641d6 > compiler/typecheck/TcPat.lhs | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/compiler/typecheck/TcPat.lhs b/compiler/typecheck/TcPat.lhs > index 3b7b5df..58e8bae 100644 > --- a/compiler/typecheck/TcPat.lhs > +++ b/compiler/typecheck/TcPat.lhs > @@ -796,7 +796,8 @@ tcDataConPat penv (L con_span con_name) data_con pat_ty arg_pats thing_inside > ; gadts_on <- xoptM Opt_GADTs > ; families_on <- xoptM Opt_TypeFamilies > ; checkTc (no_equalities || gadts_on || families_on) > - (ptext (sLit "A pattern match on a GADT requires GADTs or TypeFamilies")) > + (text "A pattern match on a GADT requires the" <+> > + text "GADTs or TypeFamilies language extension") > -- Trac #2905 decided that a *pattern-match* of a GADT > -- should require the GADT language flag. > -- Re TypeFamilies see also #7156 > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

Partial type signatures validate failures
by Edward Z. Yang 29 Nov '14

29 Nov '14

I get these fails: TEST="overloadedlistsfail03 overloadedlistsfail05 sigof02dt sigof02dmt annfail07 FD3 T5689 T7696 T5978 FDsFromGivens tcfail178 tcfail014 T8603 tcfail143 tcfail200 T9612 tcfail159 T7368 T5570 T6069 T5691 T7368a T8262 T7851 T8392a T5246 tcfail123 tcfail122 tcfail090 mc24 mc25 mc22 mc23 T3950 tcfail165 T8142 T5462Yes1 T5462Yes2 T3169 SimpleFail5b T3330c T5439 T7729 T7354a T7354 T7729a T7786" Mostly stderr changes. Edward

1 0

Proposal: Improving the LLVM backend by packaging it
by Austin Seipp 28 Nov '14

28 Nov '14

Hi *, A few days ago a discussion on IRC occurred about the LLVM backend, its current status, and what we could do to make it a rock solid part of GHC for all our users. Needless to say, the situation right now isn't so hot: we have no commitment to version support, two major versions are busted, others are seriously buggy, and yet there are lots of things we could improve on. So I give you a proposal, from a few of us to you all, about improving it: https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend I won't repeat what's on the wiki page too much, but the TL;DR version is: we should start packaging a version of LLVM, and shipping it with e.g. binary distributions of GHC. It's just a lot better for everyone. I know we're normally fairly hesitant about things like this (shipping external dependencies), but I think it's the only sane thing to do here, and the situation is fairly unique in that it's not actually very complicated to implement or support, I think. We'd like to do this for 7.12. I've also wrangled some people to help. Those people know who they are (because they're CC'd), and I will now badger them into submission until it is fixed for 7.12. Please let me know what you think. PS. Joachim, I would be particularly interested in upstream needs for Debian, as I know of their standard packaging policy to not duplicate things. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

8 20

let app invariant failure, HALP Re: how to write a ghc primop that acts on an unevaluated argument?
by Carter Schonwald 27 Nov '14

27 Nov '14

ok, i'm getting a let/app invariant failure when i build my test case with O1 or O2 but not without http://lpaste.net/114881 any help would be appreciated on how to address that On Sun, Nov 23, 2014 at 4:13 PM, Carter Schonwald < carter.schonwald(a)gmail.com> wrote: > yup, i have that! > > wrapFetch prefetchValue0# (error "this shouldn't get evaluated") > > in the test suite! > > in contrast > wrapFetch prefetchValue0# $! (error "this shouldn't get evaluated") > does explode > > shall I add a "should fail" test with the latter? (it doesn't seem > worthwhile) > > On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett <ekmett(a)gmail.com> wrote: > >> Maybe test for laziness in the argument by just putting something in that >> goes boom when forced, e.g. 'undefined'? >> >> >> On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald < >> carter.schonwald(a)gmail.com> wrote: >> >>> Hey All, >>> as part of trying to get some fixups for how prefetch works into 7.10, >>> i'm adding a "prefetchValue" primop that prefetchs the memory location >>> of a lifted heap value >>> >>> namely >>> >>> several operations of the following form >>> >>> primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp >>> a -> State# s -> State# s >>> with strictness = { \ _arity -> mkClosedStrictSig [botDmd, topDmd] >>> topRes } >>> >>> I'd like some feedback on the strictness information design by someone >>> who's familiar with how that piece of GHC. the idea being that >>> prefetchValue is lazy in its polymorphic argument (it doesn't force it, it >>> just does a prefetch on the heap location, which may or may not be >>> evaluated). >>> >>> https://phabricator.haskell.org/D350 >>> >>> is the code in question. And i *believe* i'm testing for being lazy in >>> that argument correctly. >>> >>> thoughts? >>> >>> many thanks! >>> -Carter >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> >> >

2 9

superfluous ghc --make log?
by Tuncer Ayaz 27 Nov '14

27 Nov '14

This is a very minor "issue", but I've been wondering if there's a rationale behind ghc --make pretty much printing the same thing thrice. Say you're building Cabal, you'll see (line wrapped for email): [ 1 of 75] Compiling Distribution.Compat.CreatePipe ( Distribution/Compat/CreatePipe.hs, Distribution/Compat/CreatePipe.o ) So, why not print [ 1 of 75] Compiling Distribution.Compat.CreatePipe instead? I'm assuming there's a good reason for the current behavior, but if there's none, are there any objections to changing what's printed? Of course, the old behavior could be re-enabled via -v.

2 1

Uploading a patch (without arcanist)
by Tuncer Ayaz 26 Nov '14

26 Nov '14

When trying to upload a diff with Differential's web interface, all I see is the following error message: --------snip-------- Unhandled Exception ("PhabricatorApplicationTransactionNoEffectException") Transactions have no effect: - This Revision already has that view policy. --------snip-------- Any idea what I might have done wrong?

2 1

T5462Yes1
by Simon Peyton Jones 26 Nov '14

26 Nov '14

I'm getting this on Linux: Unexpected failures: generics T5462Yes1 [exit code non-0] (normal) Linking T5462Yes1 ... gcc: error: GEq/GEq1A.o: No such file or directory gcc: error: GFunctor/GFunctor.o: No such file or directory *** unexpected failure for T5462Yes1(normal) But it doesn't happen if I say "make TEST=T5462Yes1". Could this be a multi-thread file deletion thing? make TEST=T5462Yes1 runs the test 8 different ways Simon

2 4

ghc HEAD can't validate with xcode 6 clang on OS X
by Carter Schonwald 26 Nov '14

26 Nov '14

Hey all, on OS X 10.9 if i do git clone --recursive git://git.haskell.org/ghc.git ghc-valifail cd ghc-valifail perl boot ./configure --with-gcc=clang # the with gcc bit isnt needed, but making it clearly pick up clang is the point ./validate --fast then within a minute or two i get error: unknown warning option '-Werror=unused-but-set-variable'; did you mean '-Werror=unused-const-variable'? [-Werror,-Wunknown-warning-option] which makes me think that the clang warning flags have changed in that release (which corresponds with clang Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)). SO maybe clang 3.5 / 3.6 will also fail when used in validate builds? s/hpc/dist-boot/build/autogen/cabal_macros.h libraries/hpc/./Trace/Hpc/Reflect.hsc -o libraries/hpc/dist-boot/build/Trace/Hpc/Reflect.hs error: unknown warning option '-Werror=unused-but-set-variable'; did you mean '-Werror=unused-const-variable'? [-Werror,-Wunknown-warning-option] compiling compiler/stage1/build/Fingerprint_hsc_make.c failed (exit code 1) command was: clang -c compiler/stage1/build/Fingerprint_hsc_make.c -o compiler/stage1/build/Fingerprint_hsc_make.o -Werror -Wall -m64 -fno-stack-protector -m64 -Dx86_64_HOST_ARCH=1 -Ddarwin_HOST_OS=1 -D__GLASGOW_HASKELL__=708 -m64 -fno-stack-protector -error: unknown warning option '-Werror=unused-but-set-variable'; did you mean '-Werror=unused-const-variable'? [-Werror,-Wunknown-warning-option] Werror -Wall -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -isystem/usr/local/lib/ghc-7.8.3/process-1.2.0.0/include -isystem/usr/local/lib/ghc-7.8.3/directory-1.2.1.0/include -isystem/usr/local/lib/ghc-7.8.3/unix-2.7.0.1/include -isystem/usr/local/lib/ghc-7.8.3/time-1.4.2/include -isystem/usr/loccalo/mlpiibl/ignhgc -l7i.b8r.a3r/ibeyst/ehsptc/dist-boot/build/Trace/Hpc/Reflect_hsc_make.c fring-0.10.4.0/include -isystemailed (exit c/usr/local/liode 1) commab/ghc-7.8.3/band was: clanse-4.7.0.1/ing -c librariclude -isystees/hpc/dist-m/usr/localboot/build/T/lib/ghc-7.8race/Hpc/Ref.3/inlteecgte_rh-sgcm_pm-a0k.e5.1.0/include -isys.c -o libraries/hpc/dist-boott/bueiml/du/sTrr/acel/Hopcca/l/lib/ghc-7.8.3/include -Werror=unused-but-sReet-variabflel e-Wcnto_-hesrcr_omra=kien.loi n-eW e-rIrcoorm p-iWlaelrl/ s-tma6g4e 1-/fbnuoi-lsdt/aacukt-opgreont e-citnocrl u-dme6 4c o-mDpxi8l6e_r6/4s_tHaOgSeT1_/AbRuCiHl=d1/ a-uDtdoagrewni/nc_aHbOaSlT__mOaSc=r1o s-.Dh_ _-GIL/AUSsGeOrWs_/HcAaSrKtEeLrL/_D_e=s7k0t8o p-/mr6e4p o-Sfcnor-asttcahcekr-/pgrhoct-evcatloirf a-iWle/rirnoprl a-cWea/llli b-/Iilnicblrudaer/i es/hpc/. -isystem/usr/local/lib/ghc-7.8.3/directory-1.2.1.0/include -isystem/usr/local/lib/ghc-7.8.3/unix-2.7.0.1/include -isystem/usr/local/lib/ghc-7.8.3/time-1.4.2/include -isystem/usr/local/lib/ghc-7.8.3/bytestring-0.10.4.0/include -isystem/usr/local/lib/ghc-7.8.3/base-4.7.0.1/include -isystem/usr/local/lib/ghc-7.8.3/integer-gmp-0.5.1.0/include -isystem/usr/local/lib/ghc-7.8.3/include -Werror=unused-but-set-variable -Wno-error=inline -Ilibraries/hpc/dist-boot/build/autogen -include libraries/hpc/dist-boot/build/amake[1]: *** [compiler/stage1/build/Fingerprint.hs] Error 1 make[1]: *** Waiting for unfinished jobs.... utogen/cabal_macros.h -I/Users/carter/Desktop/repoScratcher/ghc-valifail/inplace/lib/include/ make[1]: *** [libraries/hpc/dist-boot/build/Trace/Hpc/Reflect.hs] Error 1 make: *** [all] Error 2

2 1

More flexible literate Haskell extensions (Trac #9789), summary on wiki
by Merijn Verstraaten 25 Nov '14

25 Nov '14

As requested on my ticket I summarised the entire proposal on the wiki here: https://ghc.haskell.org/trac/ghc/wiki/FlexibleLiterateExtension I don't expect a lot of disagreement on discussion, aside from minor bike shedding on the flavour of the extension. I've started implementing this already. I'm open to bikesheds on exact extension, as it shouldn't affect the implementation. Unless there's any vehement objections, I'll produce a diff on fabricator asap. Cheers, Merijn

8 11