- ghc-devs - Haskell.org

The build is broken (Solaris/x86, FreeBSD/{i386,amd64})
by Páli Gábor János 15 Apr '14

15 Apr '14

The failing command: "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-1.3.0.2 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package ghc-7.9.20140414 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/src/Haddock/Interface/Create.hs -o utils/haddock/dist/build/Haddock/Interface/Create.dyn_o utils/haddock/src/Haddock/Interface/Create.hs:367:44: Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' with '(a1, Located (HsBind id))' Expected type: TyClDecl Name -> Bag (a1, Located (HsBind id)) Actual type: TyClDecl Name -> LHsBinds Name Relevant bindings include defs :: [Located (HsDecl id)] (bound at utils/haddock/src/Haddock/Interface/Create.hs:367:5) In the second argument of '(.)', namely 'tcdMeths' In the second argument of '(.)', namely 'bagToList . tcdMeths' utils/haddock/src/Haddock/Interface/Create.hs:393:22: Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' with '(a0, Located (HsBind Name))' Expected type: HsValBindsLR Name Name -> [(a0, Located (HsBind Name))] Actual type: HsValBindsLR Name Name -> [LHsBindLR Name Name] In the first argument of '(.)', namely 'valbinds' In the second argument of '(.)', namely 'valbinds . hs_valds' gmake[1]: *** [utils/haddock/dist/build/Haddock/Interface/Create.dyn_o] Error 1 gmake: *** [all] Error 2 Please consult the details at http://haskell.inf.elte.hu/builders/solaris-x86-head/28/10.html

7 6

Help with coercion & roles?
by Conal Elliott 14 Apr '14

14 Apr '14

I’m working on a GHC plugin (as part of my Haskell-to-hardware work) and running into trouble with coercions & roles. Error message from Core Lint: Warning: In the expression: LambdaCCC.Lambda.lamvP# @ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) @ (Simple.HasIf GHC.Types.Bool) "tpl"# ((LambdaCCC.Lambda.varP# @ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) "tpl"#) `cast` (<LambdaCCC.Lambda.EP>_N (Sym (Simple.NTCo:HasIf[0] <GHC.Types.Bool>_N)) ∷ LambdaCCC.Lambda.EP (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) ~# LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) Role incompatibility: expected nominal, got representationalin <LambdaCCC.Lambda.EP>_N (Sym (Simple.NTCo:HasIf[0] <GHC.Types.Bool>_N)) Do you see anything inconsistent/incompatible in the coercions or roles above? I constructed the nominal EP Refl coercion, and applied it (AppCo) an existing coercion of a simpler type. Thanks, -- Conal

3 7

Re: [commit: ghc] master: Fix linked list manipulation code (buggy on consecutive deletion) (e3938f3)
by Simon Marlow 14 Apr '14

14 Apr '14

Thanks Edward. Austin, can you cherry-pick this for 7.8.3 please? Cheers, Simon On 13/04/2014 07:37, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/e3938f3adac0093b23694fd347774244c… > >> --------------------------------------------------------------- > > commit e3938f3adac0093b23694fd347774244ce121478 > Author: Edward Z. Yang <ezyang(a)cs.stanford.edu> > Date: Sat Apr 12 23:02:13 2014 -0700 > > Fix linked list manipulation code (buggy on consecutive deletion) > > Signed-off-by: Edward Z. Yang <ezyang(a)cs.stanford.edu> > > >> --------------------------------------------------------------- > > e3938f3adac0093b23694fd347774244ce121478 > rts/CheckUnload.c | 3 ++- > rts/Linker.c | 6 ++++-- > 2 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/rts/CheckUnload.c b/rts/CheckUnload.c > index f1f454c..98f184b 100644 > --- a/rts/CheckUnload.c > +++ b/rts/CheckUnload.c > @@ -298,7 +298,7 @@ void checkUnload (StgClosure *static_objects) > // marked as unreferenced can be physically unloaded, because we > // have no references to it. > prev = NULL; > - for (oc = unloaded_objects; oc; prev = oc, oc = next) { > + for (oc = unloaded_objects; oc; oc = next) { > next = oc->next; > if (oc->referenced == 0) { > if (prev == NULL) { > @@ -312,6 +312,7 @@ void checkUnload (StgClosure *static_objects) > } else { > IF_DEBUG(linker, debugBelch("Object file still in use: %" > PATH_FMT "\n", oc->fileName)); > + prev = oc; > } > } > > diff --git a/rts/Linker.c b/rts/Linker.c > index af26d74..ab235e9 100644 > --- a/rts/Linker.c > +++ b/rts/Linker.c > @@ -3016,8 +3016,8 @@ unloadObj( pathchar *path ) > IF_DEBUG(linker, debugBelch("unloadObj: %" PATH_FMT "\n", path)); > > prev = NULL; > - for (oc = objects; oc; prev = oc, oc = next) { > - next = oc->next; > + for (oc = objects; oc; oc = next) { > + next = oc->next; // oc might be freed > > if (!pathcmp(oc->fileName,path)) { > > @@ -3075,6 +3075,8 @@ unloadObj( pathchar *path ) > /* This could be a member of an archive so continue > * unloading other members. */ > unloadedAnyObj = HS_BOOL_TRUE; > + } else { > + prev = oc; > } > } > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0

Has the behavior of -fno-ghci-sandbox changed with ghc-7.8.2?
by Dominick Samperi 13 Apr '14

13 Apr '14

I ticket #8371 I reported a problem using embedded R with ghci (no problem when application is compiled with ghc). The work-around was to use the option -fno-ghci-sandbox with ghci, as this prevented ghci from starting a new thread (R is not thread-safe). This worked fine with pre-release ghci 7.7 (built from source using BuildFlavour = quick), but now I get a segfault on startup using ghci 7.8.2, suggesting that the behavior of -fno-ghci-sandbox may have changed, perhaps because of the way the Linux binary distribution was built. Has the behavior of -fno-ghci-sandbox changed, or could it have been changed because of the way the Linux binary distribution was built? BTW, I would have posted this as a follow-up to the ticket but I forgot my password. How does one reset the password on the ticket tracker site? Thanks, Dominick

1 1

Validation failures on master
by Dr. ERDI Gergo 12 Apr '14

12 Apr '14

The ultimate case of 'the pot calling the kettle black'[*]: I'm seeing validation errors on 'master' 7233638: Unexpected passes: arrows/should_fail arrowfail001 (normal) lib/integer integerConstantFolding (normal) [*] just to be clear, I mean me being the pot in this case:)

1 0

Defined but not used in TcPatSyn
by Joachim Breitner 12 Apr '14

12 Apr '14

Hi, someone introduced a validate error recently: compiler/typecheck/TcPatSyn.lhs:324:19: Warning: Defined but not used: `lit' compiler/typecheck/TcPatSyn.lhs:325:17: Warning: Defined but not used: `n' Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

3 4

RFC: provide patch-level information at __GLASGOW_HASKELL__
by Herbert Valerio Riedel 11 Apr '14

11 Apr '14

Hello, I know this has come up various times. So this is mostly an attempt to see what the current position is on this topic: The current scheme is documented as ,---- | The value of __GLASGOW_HASKELL__ for a major release x.y.z is the | integer xyy (if y is a single digit, then a leading zero is added, so | for example in version 6.8.2 of GHC we would have | __GLASGOW_HASKELL__==608). `---- This has lead to confusion in the past, e.g. the following two values __GLASGOW_HASKELL__ == 702 __GLASGOW_HASKELL__ == 704 were sometimes confused (by me at least) to mean 7.0.2 and 7.0.4 respectively. And sometimes when writing conditionals, it also happened that '__GLASGOW_HASKELL__ >= 722' was written to mean >= 7.2.2. Moreover, when GHC 7.2.2 came out, it would have been useful to be able to discriminate 7.2.1 vs 7.2.2 easily, as some SafeHaskell properties changed between 7.2.1 and 7.2.2. Therefore, I'd propose to extend this constant by a patch-level digit for future GHC versions (starting with 7.10.1), i.e. __GLASGOW_HASKELL__ == 7090 -- 7.9 branch __GLASGOW_HASKELL__ == 7100 -- 7.10.1 release candidates __GLASGOW_HASKELL__ == 7101 -- 7.10.1 __GLASGOW_HASKELL__ == 7102 -- 7.10.2 __GLASGOW_HASKELL__ == 7121 -- 7.12.2 NB: this ensures that __GLASGOW_HASKELL__ retains its ordering relation. There's just a steeper jump from 7.8.1 to 7.10.1, but existing code using conditionals such as #if (__GLASGOW_HASKELL__ >= 708) && (__GLASGOW_HASKELL__ < 709) for currently existing GHC versions will continue to work as expected. Alternative ideas: - Define a __GLASGOW_HASKELL_PATCHLEVEL__ containing only the patch-level number. (c.f. GNU GCC's __GNUC_PATCHLEVEL__ constant) This one might have the least impact, as its existence can be ignored safely, and we could even use this starting with GHC 7.8.2 with low risk of affecting users. - define a __MIN_VERSION_GHC__(x,y,z) macro in the style of Cabal's MIN_VERSION_<pkgname>() macros While this has the most structure, this has also the issue of backward compatibility, as for earlier GHC versions you'd have to check for the existence of the macro before using it to avoid compile-time errors. Cheers, hvr

7 7

Breaking bug in 7.8.1
by Simon Peyton Jones 11 Apr '14

11 Apr '14

Austin, Simon (and others) As you'll see from https://ghc.haskell.org/trac/ghc/ticket/8978, I succeeded in introducing a new bug into 7.8.1 post RC2, when fixing #8913. And it seems to matter. (Because of the windows seg-fault saga, RC2 was active for a long time, and none of our regression tests showed up this bug.) It looks to me that we have little choice but to push out 7.8.2, more or less immediately, and advise everyone to ignore 7.8.1. Do you agree? Sorry about this. Simon

3 4

GHC HQ on Launchpad
by Edward Z. Yang 11 Apr '14

11 Apr '14

Hello all, I've created a GHC team on Launchpad to manage the code imports and build recipes https://launchpad.net/~ghc Why? I recently was playing around with Launchpad's build recipes service, and realized that this could be another helpful source of builds for GHC (resulting in proper Ubuntu packages which then can be directly installed by installing a PPA). If you're not interested, you can just ignore (or remove yourself) from the group. Conversely, if I didn't find your Launchpad identifier, please ask to be added. Cheers, Edward

6 5

Compiling GHC with Clang
by Herbert Valerio Riedel 11 Apr '14

11 Apr '14

Hello *, I've been trying to compile GHC with Clang instead of GCC on Ubuntu, by configuring the build with CC=/usr/bin/clang ./configure --with-gcc=/usr/bin/clang but then, 'make' runs into ,---- | "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -package-name ghc-7.8.0.20140401 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.2.0.0 -package template-haskell-2.9.0.0 -package time-1.4.2 -package transformers-0.3.0.0 -package unix-2.7.0.1 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -XNondecreasingIndentation -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O0 -fasm -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/stage2/build/Lexer.hs -o compiler/stage2/build/Lexer.o -dyno compiler/stage2/build/Lexer.dyn_o | | compiler/stage2/build/Lexer.hs:2426:41: | Couldn't match expected type ‘[Char]’ with actual type ‘Int#’ | In the first argument of ‘(>=)’, namely ‘offset’ | In the expression: (offset >= "0#") | | compiler/stage2/build/Lexer.hs:2426:41: | Couldn't match expected type ‘Int#’ with actual type ‘Bool’ | In the expression: (offset >= "0#") | In the first argument of ‘(&&)’, namely | ‘(tagToEnum# (offset >= "0#"))’ | In the expression: | (tagToEnum# (offset >= "0#")) && (tagToEnum# (check == "ord_c")) | | compiler/stage2/build/Lexer.hs:2426:73: | Couldn't match expected type ‘[Char]’ with actual type ‘Int#’ | In the first argument of ‘(==)’, namely ‘check’ | In the expression: (check == "ord_c") | | compiler/stage2/build/Lexer.hs:2426:73: | Couldn't match expected type ‘Int#’ with actual type ‘Bool’ | In the expression: (check == "ord_c") | In the second argument of ‘(&&)’, namely | ‘(tagToEnum# (check == "ord_c"))’ | In the expression: | (tagToEnum# (offset >= "0#")) && (tagToEnum# (check == "ord_c")) | make[1]: *** [compiler/stage2/build/Lexer.o] Error 1 | make: *** [all] Error 2 `---- the versions of happy & alex were: ,---- | $ happy --version | Happy Version 1.19.3 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow | | $ alex --version | Alex version 3.1.3, (c) 2003 Chris Dornan and Simon Marlow `---- ...anyone know why this happens when using Clang instead of GCC, or better yet, what I need to do in order to build GHC with Clang on Linux?

3 9