- ghc-devs - Haskell.org

Re: Windows breakage -- again
by Niklas Larsson 18 Jul '14

18 Jul '14

I get the same failure when I try to build HEAD. Turns out the error occurs on the 32-bit Windows build, and my successful build was a 64-bit build. My 64-bit build still succeeds. Also, gcc is 4.5.2 on 32-bit, not 4.6.3 as on 64-bit. Niklas 2014-07-16 14:48 GMT+02:00 Niklas Larsson <metaniklas(a)gmail.com>: > I have built ghc on windows after that was added with no issue. > > I can take a look this evening and see how HEAD works for me. > > The standard gcc in the tarballs is 4.6.3, which is getting long in the > tooth, there is an issue on trac to upgrade it. > > -- Niklas > > ------------------------------ > Från: Johan Tibell <johan.tibell(a)gmail.com> > Skickat: ‎2014-‎07-‎16 09:57 > Till: Simon Peyton Jones <simonpj(a)microsoft.com> > Kopia: ghc-devs(a)haskell.org > Ämne: Re: Windows breakage -- again > > You can rollback the commit (git revert 4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) > and push that to the repo if you wish. I will try to re-add the primop > again after I figure out what's wrong. > > > On Wed, Jul 16, 2014 at 9:37 AM, Johan Tibell <johan.tibell(a)gmail.com> > wrote: > >> I added some primops about a month ago >> (4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) that call __sync_fetch_and_add, >> a gcc/llvm builtin. I'm a bit surprised to see this error. The GCC manual >> [1] says: >> >> > " Not all operations are supported by all target processors. If a >> particular operation cannot be implemented on the target processor, a >> warning will be generated and a call an external function will be >> generated. The external function will carry the same name as the builtin, >> with an additional suffix `_n' where n is the size of the data type." >> >> I'm a bit surprised by this error for two reasons: >> >> * A call to that symbol should only be generated if the CPU doesn't >> support the atomic instructions. What CPU model does Windows report that >> you have? >> >> * gcc should define such a symbol. For me the following test program >> compiles: >> >> #include <stdint.h> >> >> uint8_t test(uint8_t* ptr, uint8_t val) { >> return __sync_fetch_and_add_1(ptr, val); >> } >> >> int main(void) { >> uint8_t n; >> return test(&n, 1); >> } >> >> Does that compile for you? Which version of GCC do we end up using on >> Windows? >> >> The reported symbol (___sync_fetch_and_add_1) has three leading >> underscores, that looks weird. Can you compile just >> libraries/ghc-prim/cbits/atomic.c and see if it's indeed GCC that generates >> a reference to that symbol? >> >> 1. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html >> >> >> On Wed, Jul 16, 2014 at 12:29 AM, Simon Peyton Jones < >> simonpj(a)microsoft.com> wrote: >> >>> Aargh! The Windows build has broken – again. I can’t build GHC on >>> my laptop any more. >>> >>> A clean ‘sh validate’ finishes as below. What on earth is >>> `___sync_fetch_and_add_1'? >>> >>> Can anyone help? Thanks! >>> >>> Simon >>> >>> "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m >>> -O -Werror -Wall -H64m -O0 -package-name vector-0.10.9.1 >>> -hide-all-packages -i -ilibraries/vector/. >>> -ilibraries/vector/dist-install/build >>> -ilibraries/vector/dist-install/build/autogen >>> -Ilibraries/vector/dist-install/build >>> -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include >>> -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include >>> -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package >>> base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package >>> primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O >>> -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts >>> -Wwarn -odir libraries/vector/dist-install/build -hidir >>> libraries/vector/dist-install/build -stubdir >>> libraries/vector/dist-install/build -c >>> libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o >>> libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o >>> >>> Loading package ghc-prim ... linking ... ghc-stage2.exe: unable to load >>> package `ghc-prim' >>> >>> ghc-stage2.exe: >>> C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.3.1.0.o: >>> unknown symbol `___sync_fetch_and_add_1' >>> >>> libraries/vector/ghc.mk:5: recipe for target >>> 'libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o' >>> failed >>> >>> make[1]: *** >>> [libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o] >>> Error 1 >>> >>> >>> >>> I >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> >> >

7 21

The build is broken? (Haddock parse error)
by Páli Gábor János 17 Jul '14

17 Jul '14

Hello there, I have just found the builds are failing due to this (see [1] for the full log): "/usr/home/ghc-builder/work/builder/tempbuild/build/inplace/bin/haddock" --odir="compiler/stage2/doc/html/ghc" --no-tmp-comp-dir --dump-interface=compiler/stage2/doc/html/ghc/ghc.haddock --html --hoogle --title="ghc-7.9.20140717: The GHC API" --prologue="compiler/stage2/haddock-prologue.txt" --read-interface=../Cabal-1.20.0.1,../Cabal-1.20.0.1/src/%{MODULE/./-}.html\#%{NAME},libraries/Cabal/Cabal/dist-install/doc/html/Cabal/Cabal.haddock --read-interface=../array-0.5.0.0,../array-0.5.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/array/dist-install/doc/html/array/array.haddock --read-interface=../base-4.7.1.0,../base-4.7.1.0/src/%{MODULE/./-}.html\#%{NAME},libraries/base/dist-install/doc/html/base/base.haddock --read-interface=../bin-package-db-0.0.0.0,../bin-package-db-0.0.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/bin-package-db/dist-install/doc/html/bin-package-db/bin-package-db.haddock --read-interface=../bytestring-0.10.4.0,../bytestring-0.10.4.0/src/%{MODULE/./-}.html\#%{NAME},libraries/bytestring/dist-install/doc/html/bytestring/bytestring.haddock --read-interface=../containers-0.5.5.1,../containers-0.5.5.1/src/%{MODULE/./-}.html\#%{NAME},libraries/containers/dist-install/doc/html/containers/containers.haddock --read-interface=../directory-1.2.1.0,../directory-1.2.1.0/src/%{MODULE/./-}.html\#%{NAME},libraries/directory/dist-install/doc/html/directory/directory.haddock --read-interface=../filepath-1.3.0.2,../filepath-1.3.0.2/src/%{MODULE/./-}.html\#%{NAME},libraries/filepath/dist-install/doc/html/filepath/filepath.haddock --read-interface=../hoopl-3.10.0.1,../hoopl-3.10.0.1/src/%{MODULE/./-}.html\#%{NAME},libraries/hoopl/dist-install/doc/html/hoopl/hoopl.haddock --read-interface=../hpc-0.6.0.1,../hpc-0.6.0.1/src/%{MODULE/./-}.html\#%{NAME},libraries/hpc/dist-install/doc/html/hpc/hpc.haddock --read-interface=../process-1.2.0.0,../process-1.2.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/process/dist-install/doc/html/process/process.haddock --read-interface=../template-haskell-2.10.0.0,../template-haskell-2.10.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/template-haskell/dist-install/doc/html/template-haskell/template-haskell.haddock --read-interface=../time-1.4.2,../time-1.4.2/src/%{MODULE/./-}.html\#%{NAME},libraries/time/dist-install/doc/html/time/time.haddock --read-interface=../transformers-0.4.1.0,../transformers-0.4.1.0/src/%{MODULE/./-}.html\#%{NAME},libraries/transformers/dist-install/doc/html/transformers/transformers.haddock --read-interface=../unix-2.7.0.2,../unix-2.7.0.2/src/%{MODULE/./-}.html\#%{NAME},libraries/unix/dist-install/doc/html/unix/unix.haddock --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-H32m --optghc=-O --optghc=-package-name --optghc=ghc-7.9.20140717 --optghc=-hide-all-packages --optghc=-i --optghc=-icompiler/basicTypes --optghc=-icompiler/cmm --optghc=-icompiler/codeGen --optghc=-icompiler/coreSyn --optghc=-icompiler/deSugar --optghc=-icompiler/ghci --optghc=-icompiler/hsSyn --optghc=-icompiler/iface --optghc=-icompiler/llvmGen --optghc=-icompiler/main --optghc=-icompiler/nativeGen --optghc=-icompiler/parser --optghc=-icompiler/prelude --optghc=-icompiler/profiling --optghc=-icompiler/rename --optghc=-icompiler/simplCore --optghc=-icompiler/simplStg --optghc=-icompiler/specialise --optghc=-icompiler/stgSyn --optghc=-icompiler/stranal --optghc=-icompiler/typecheck --optghc=-icompiler/types --optghc=-icompiler/utils --optghc=-icompiler/vectorise --optghc=-icompiler/stage2/build --optghc=-icompiler/stage2/build/autogen --optghc=-Icompiler/stage2/build --optghc=-Icompiler/stage2/build/autogen --optghc=-Icompiler/. --optghc=-Icompiler/parser --optghc=-Icompiler/utils --optghc=-Icompiler/../rts/dist/build --optghc=-Icompiler/stage2 --optghc=-optP-DGHCI --optghc=-optP-include --optghc=-optPcompiler/stage2/build/autogen/cabal_macros.h --optghc=-package --optghc=Cabal-1.20.0.1 --optghc=-package --optghc=array-0.5.0.0 --optghc=-package --optghc=base-4.7.1.0 --optghc=-package --optghc=bin-package-db-0.0.0.0 --optghc=-package --optghc=bytestring-0.10.4.0 --optghc=-package --optghc=containers-0.5.5.1 --optghc=-package --optghc=directory-1.2.1.0 --optghc=-package --optghc=filepath-1.3.0.2 --optghc=-package --optghc=hoopl-3.10.0.1 --optghc=-package --optghc=hpc-0.6.0.1 --optghc=-package --optghc=process-1.2.0.0 --optghc=-package --optghc=template-haskell-2.10.0.0 --optghc=-package --optghc=time-1.4.2 --optghc=-package --optghc=transformers-0.4.1.0 --optghc=-package --optghc=unix-2.7.0.2 --optghc=-Wall --optghc=-fno-warn-name-shadowing --optghc=-XHaskell2010 --optghc=-optc-DTHREADED_RTS --optghc=-DGHCI_TABLES_NEXT_TO_CODE --optghc=-DSTAGE=2 --optghc=-Rghc-timing --optghc=-O2 --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=compiler/stage2/build --optghc=-hidir --optghc=compiler/stage2/build --optghc=-stubdir --optghc=compiler/stage2/build --source-module=src/%{MODULE/./-}.html --source-entity=src/%{MODULE/./-}.html#%{NAME} --optghc=-DSTAGE=2 compiler/basicTypes/Avail.hs compiler/basicTypes/BasicTypes.lhs compiler/basicTypes/ConLike.lhs compiler/basicTypes/DataCon.lhs compiler/basicTypes/PatSyn.lhs compiler/basicTypes/Demand.lhs compiler/utils/Exception.hs compiler/main/GhcMonad.hs compiler/main/Hooks.lhs compiler/basicTypes/Id.lhs compiler/basicTypes/IdInfo.lhs compiler/basicTypes/Literal.lhs compiler/llvmGen/Llvm.hs compiler/llvmGen/Llvm/AbsSyn.hs compiler/llvmGen/Llvm/MetaData.hs compiler/llvmGen/Llvm/PpLlvm.hs compiler/llvmGen/Llvm/Types.hs compiler/llvmGen/LlvmCodeGen.hs compiler/llvmGen/LlvmCodeGen/Base.hs compiler/llvmGen/LlvmCodeGen/CodeGen.hs compiler/llvmGen/LlvmCodeGen/Data.hs compiler/llvmGen/LlvmCodeGen/Ppr.hs compiler/llvmGen/LlvmCodeGen/Regs.hs compiler/llvmGen/LlvmMangler.hs compiler/basicTypes/MkId.lhs compiler/basicTypes/Module.lhs compiler/basicTypes/Name.lhs compiler/basicTypes/NameEnv.lhs compiler/basicTypes/NameSet.lhs compiler/basicTypes/OccName.lhs compiler/basicTypes/RdrName.lhs compiler/basicTypes/SrcLoc.lhs compiler/basicTypes/UniqSupply.lhs compiler/basicTypes/Unique.lhs compiler/basicTypes/Var.lhs compiler/basicTypes/VarEnv.lhs compiler/basicTypes/VarSet.lhs compiler/utils/UnVarGraph.hs compiler/cmm/BlockId.hs compiler/cmm/CLabel.hs compiler/cmm/Cmm.hs compiler/cmm/CmmBuildInfoTables.hs compiler/cmm/CmmPipeline.hs compiler/cmm/CmmCallConv.hs compiler/cmm/CmmCommonBlockElim.hs compiler/cmm/CmmContFlowOpt.hs compiler/cmm/CmmExpr.hs compiler/cmm/CmmInfo.hs compiler/stage2/build/CmmLex.hs compiler/cmm/CmmLint.hs compiler/cmm/CmmLive.hs compiler/cmm/CmmMachOp.hs compiler/cmm/CmmNode.hs compiler/cmm/CmmOpt.hs compiler/stage2/build/CmmParse.hs compiler/cmm/CmmProcPoint.hs compiler/cmm/CmmSink.hs compiler/cmm/CmmType.hs compiler/cmm/CmmUtils.hs compiler/cmm/CmmLayoutStack.hs compiler/cmm/MkGraph.hs compiler/nativeGen/PprBase.hs compiler/cmm/PprC.hs compiler/cmm/PprCmm.hs compiler/cmm/PprCmmDecl.hs compiler/cmm/PprCmmExpr.hs compiler/cmm/Bitmap.hs compiler/codeGen/CodeGen/Platform.hs compiler/codeGen/CodeGen/Platform/ARM.hs compiler/codeGen/CodeGen/Platform/NoRegs.hs compiler/codeGen/CodeGen/Platform/PPC.hs compiler/codeGen/CodeGen/Platform/PPC_Darwin.hs compiler/codeGen/CodeGen/Platform/SPARC.hs compiler/codeGen/CodeGen/Platform/X86.hs compiler/codeGen/CodeGen/Platform/X86_64.hs compiler/codeGen/CgUtils.hs compiler/codeGen/StgCmm.hs compiler/codeGen/StgCmmBind.hs compiler/codeGen/StgCmmClosure.hs compiler/codeGen/StgCmmCon.hs compiler/codeGen/StgCmmEnv.hs compiler/codeGen/StgCmmExpr.hs compiler/codeGen/StgCmmForeign.hs compiler/codeGen/StgCmmHeap.hs compiler/codeGen/StgCmmHpc.hs compiler/codeGen/StgCmmArgRep.hs compiler/codeGen/StgCmmLayout.hs compiler/codeGen/StgCmmMonad.hs compiler/codeGen/StgCmmPrim.hs compiler/codeGen/StgCmmProf.hs compiler/codeGen/StgCmmTicky.hs compiler/codeGen/StgCmmUtils.hs compiler/codeGen/StgCmmExtCode.hs compiler/cmm/SMRep.lhs compiler/coreSyn/CoreArity.lhs compiler/coreSyn/CoreFVs.lhs compiler/coreSyn/CoreLint.lhs compiler/coreSyn/CorePrep.lhs compiler/coreSyn/CoreSubst.lhs compiler/coreSyn/CoreSyn.lhs compiler/coreSyn/TrieMap.lhs compiler/coreSyn/CoreTidy.lhs compiler/coreSyn/CoreUnfold.lhs compiler/coreSyn/CoreUtils.lhs compiler/coreSyn/MkCore.lhs compiler/coreSyn/PprCore.lhs compiler/deSugar/Check.lhs compiler/deSugar/Coverage.lhs compiler/deSugar/Desugar.lhs compiler/deSugar/DsArrows.lhs compiler/deSugar/DsBinds.lhs compiler/deSugar/DsCCall.lhs compiler/deSugar/DsExpr.lhs compiler/deSugar/DsForeign.lhs compiler/deSugar/DsGRHSs.lhs compiler/deSugar/DsListComp.lhs compiler/deSugar/DsMonad.lhs compiler/deSugar/DsUtils.lhs compiler/deSugar/Match.lhs compiler/deSugar/MatchCon.lhs compiler/deSugar/MatchLit.lhs compiler/hsSyn/HsBinds.lhs compiler/hsSyn/HsDecls.lhs compiler/hsSyn/HsDoc.hs compiler/hsSyn/HsExpr.lhs compiler/hsSyn/HsImpExp.lhs compiler/hsSyn/HsLit.lhs compiler/hsSyn/HsPat.lhs compiler/hsSyn/HsSyn.lhs compiler/hsSyn/HsTypes.lhs compiler/hsSyn/HsUtils.lhs compiler/iface/BinIface.hs compiler/iface/BuildTyCl.lhs compiler/iface/IfaceEnv.lhs compiler/iface/IfaceSyn.lhs compiler/iface/IfaceType.lhs compiler/iface/LoadIface.lhs compiler/iface/MkIface.lhs compiler/iface/TcIface.lhs compiler/iface/FlagChecker.hs compiler/main/Annotations.hs compiler/main/BreakArray.hs compiler/main/CmdLineParser.hs compiler/main/CodeOutput.lhs compiler/stage2/build/Config.hs compiler/main/Constants.lhs compiler/main/DriverMkDepend.hs compiler/main/DriverPhases.hs compiler/main/PipelineMonad.hs compiler/main/DriverPipeline.hs compiler/main/DynFlags.hs compiler/main/ErrUtils.lhs compiler/main/Finder.lhs compiler/main/GHC.hs compiler/main/GhcMake.hs compiler/main/GhcPlugins.hs compiler/main/DynamicLoading.hs compiler/main/HeaderInfo.hs compiler/main/HscMain.hs compiler/main/HscStats.hs compiler/main/HscTypes.lhs compiler/main/InteractiveEval.hs compiler/main/InteractiveEvalTypes.hs compiler/main/PackageConfig.hs compiler/main/Packages.lhs compiler/main/PlatformConstants.hs compiler/main/PprTyThing.hs compiler/main/StaticFlags.hs compiler/main/SysTools.lhs compiler/main/TidyPgm.lhs compiler/parser/Ctype.lhs compiler/parser/HaddockUtils.hs compiler/stage2/build/Lexer.hs compiler/types/OptCoercion.lhs compiler/stage2/build/Parser.hs compiler/parser/RdrHsSyn.lhs compiler/prelude/ForeignCall.lhs compiler/prelude/PrelInfo.lhs compiler/prelude/PrelNames.lhs compiler/prelude/PrelRules.lhs compiler/prelude/PrimOp.lhs compiler/prelude/TysPrim.lhs compiler/prelude/TysWiredIn.lhs compiler/profiling/CostCentre.lhs compiler/profiling/ProfInit.hs compiler/profiling/SCCfinal.lhs compiler/rename/RnBinds.lhs compiler/rename/RnEnv.lhs compiler/rename/RnExpr.lhs compiler/rename/RnHsDoc.hs compiler/rename/RnNames.lhs compiler/rename/RnPat.lhs compiler/rename/RnSource.lhs compiler/rename/RnSplice.lhs compiler/rename/RnTypes.lhs compiler/simplCore/CoreMonad.lhs compiler/simplCore/CSE.lhs compiler/simplCore/FloatIn.lhs compiler/simplCore/FloatOut.lhs compiler/simplCore/LiberateCase.lhs compiler/simplCore/OccurAnal.lhs compiler/simplCore/SAT.lhs compiler/simplCore/SetLevels.lhs compiler/simplCore/SimplCore.lhs compiler/simplCore/SimplEnv.lhs compiler/simplCore/SimplMonad.lhs compiler/simplCore/SimplUtils.lhs compiler/simplCore/Simplify.lhs compiler/simplStg/SimplStg.lhs compiler/simplStg/StgStats.lhs compiler/simplStg/UnariseStg.lhs compiler/specialise/Rules.lhs compiler/specialise/SpecConstr.lhs compiler/specialise/Specialise.lhs compiler/stgSyn/CoreToStg.lhs compiler/stgSyn/StgLint.lhs compiler/stgSyn/StgSyn.lhs compiler/simplCore/CallArity.hs compiler/stranal/DmdAnal.lhs compiler/stranal/WorkWrap.lhs compiler/stranal/WwLib.lhs compiler/typecheck/FamInst.lhs compiler/typecheck/Inst.lhs compiler/typecheck/TcAnnotations.lhs compiler/typecheck/TcArrows.lhs compiler/typecheck/TcBinds.lhs compiler/typecheck/TcClassDcl.lhs compiler/typecheck/TcDefaults.lhs compiler/typecheck/TcDeriv.lhs compiler/typecheck/TcEnv.lhs compiler/typecheck/TcExpr.lhs compiler/typecheck/TcForeign.lhs compiler/typecheck/TcGenDeriv.lhs compiler/typecheck/TcGenGenerics.lhs compiler/typecheck/TcHsSyn.lhs compiler/typecheck/TcHsType.lhs compiler/typecheck/TcInstDcls.lhs compiler/typecheck/TcMType.lhs compiler/typecheck/TcValidity.lhs compiler/typecheck/TcMatches.lhs compiler/typecheck/TcPat.lhs compiler/typecheck/TcPatSyn.lhs compiler/typecheck/TcRnDriver.lhs compiler/typecheck/TcRnMonad.lhs compiler/typecheck/TcRnTypes.lhs compiler/typecheck/TcRules.lhs compiler/typecheck/TcSimplify.lhs compiler/typecheck/TcErrors.lhs compiler/typecheck/TcTyClsDecls.lhs compiler/typecheck/TcTyDecls.lhs compiler/typecheck/TcType.lhs compiler/typecheck/TcEvidence.lhs compiler/typecheck/TcUnify.lhs compiler/typecheck/TcInteract.lhs compiler/typecheck/TcCanonical.lhs compiler/typecheck/TcSMonad.lhs compiler/typecheck/TcTypeNats.hs compiler/typecheck/TcSplice.lhs compiler/types/Class.lhs compiler/types/Coercion.lhs compiler/types/FamInstEnv.lhs compiler/typecheck/FunDeps.lhs compiler/types/InstEnv.lhs compiler/types/TyCon.lhs compiler/types/CoAxiom.lhs compiler/types/Kind.lhs compiler/types/Type.lhs compiler/types/TypeRep.lhs compiler/types/Unify.lhs compiler/utils/Bag.lhs compiler/utils/Binary.hs compiler/utils/BooleanFormula.hs compiler/utils/BufWrite.hs compiler/utils/Digraph.lhs compiler/utils/Encoding.hs compiler/utils/FastBool.lhs compiler/utils/FastFunctions.lhs compiler/utils/FastMutInt.lhs compiler/utils/FastString.lhs compiler/utils/FastTypes.lhs compiler/stage2/build/Fingerprint.hs compiler/utils/FiniteMap.lhs compiler/utils/GraphBase.hs compiler/utils/GraphColor.hs compiler/utils/GraphOps.hs compiler/utils/GraphPpr.hs compiler/utils/IOEnv.hs compiler/utils/ListSetOps.lhs compiler/utils/Maybes.lhs compiler/utils/MonadUtils.hs compiler/utils/OrdList.lhs compiler/utils/Outputable.lhs compiler/utils/Pair.lhs compiler/utils/Panic.lhs compiler/utils/Pretty.lhs compiler/utils/Serialized.hs compiler/utils/State.hs compiler/utils/Stream.hs compiler/utils/StringBuffer.lhs compiler/utils/UniqFM.lhs compiler/utils/UniqSet.lhs compiler/utils/Util.lhs compiler/utils/ExtsCompat46.hs compiler/vectorise/Vectorise/Builtins/Base.hs compiler/vectorise/Vectorise/Builtins/Initialise.hs compiler/vectorise/Vectorise/Builtins.hs compiler/vectorise/Vectorise/Monad/Base.hs compiler/vectorise/Vectorise/Monad/Naming.hs compiler/vectorise/Vectorise/Monad/Local.hs compiler/vectorise/Vectorise/Monad/Global.hs compiler/vectorise/Vectorise/Monad/InstEnv.hs compiler/vectorise/Vectorise/Monad.hs compiler/vectorise/Vectorise/Utils/Base.hs compiler/vectorise/Vectorise/Utils/Closure.hs compiler/vectorise/Vectorise/Utils/Hoisting.hs compiler/vectorise/Vectorise/Utils/PADict.hs compiler/vectorise/Vectorise/Utils/Poly.hs compiler/vectorise/Vectorise/Utils.hs compiler/vectorise/Vectorise/Generic/Description.hs compiler/vectorise/Vectorise/Generic/PAMethods.hs compiler/vectorise/Vectorise/Generic/PADict.hs compiler/vectorise/Vectorise/Generic/PData.hs compiler/vectorise/Vectorise/Type/Env.hs compiler/vectorise/Vectorise/Type/Type.hs compiler/vectorise/Vectorise/Type/TyConDecl.hs compiler/vectorise/Vectorise/Type/Classify.hs compiler/vectorise/Vectorise/Convert.hs compiler/vectorise/Vectorise/Vect.hs compiler/vectorise/Vectorise/Var.hs compiler/vectorise/Vectorise/Env.hs compiler/vectorise/Vectorise/Exp.hs compiler/vectorise/Vectorise.hs compiler/cmm/Hoopl/Dataflow.hs compiler/cmm/Hoopl.hs compiler/nativeGen/AsmCodeGen.lhs compiler/nativeGen/TargetReg.hs compiler/nativeGen/NCGMonad.hs compiler/nativeGen/Instruction.hs compiler/nativeGen/Size.hs compiler/nativeGen/Reg.hs compiler/nativeGen/RegClass.hs compiler/nativeGen/PIC.hs compiler/utils/Platform.hs compiler/nativeGen/CPrim.hs compiler/nativeGen/X86/Regs.hs compiler/nativeGen/X86/RegInfo.hs compiler/nativeGen/X86/Instr.hs compiler/nativeGen/X86/Cond.hs compiler/nativeGen/X86/Ppr.hs compiler/nativeGen/X86/CodeGen.hs compiler/nativeGen/PPC/Regs.hs compiler/nativeGen/PPC/RegInfo.hs compiler/nativeGen/PPC/Instr.hs compiler/nativeGen/PPC/Cond.hs compiler/nativeGen/PPC/Ppr.hs compiler/nativeGen/PPC/CodeGen.hs compiler/nativeGen/SPARC/Base.hs compiler/nativeGen/SPARC/Regs.hs compiler/nativeGen/SPARC/Imm.hs compiler/nativeGen/SPARC/AddrMode.hs compiler/nativeGen/SPARC/Cond.hs compiler/nativeGen/SPARC/Instr.hs compiler/nativeGen/SPARC/Stack.hs compiler/nativeGen/SPARC/ShortcutJump.hs compiler/nativeGen/SPARC/Ppr.hs compiler/nativeGen/SPARC/CodeGen.hs compiler/nativeGen/SPARC/CodeGen/Amode.hs compiler/nativeGen/SPARC/CodeGen/Base.hs compiler/nativeGen/SPARC/CodeGen/CondCode.hs compiler/nativeGen/SPARC/CodeGen/Gen32.hs compiler/nativeGen/SPARC/CodeGen/Gen64.hs compiler/nativeGen/SPARC/CodeGen/Sanity.hs compiler/nativeGen/SPARC/CodeGen/Expand.hs compiler/nativeGen/RegAlloc/Liveness.hs compiler/nativeGen/RegAlloc/Graph/Main.hs compiler/nativeGen/RegAlloc/Graph/Stats.hs compiler/nativeGen/RegAlloc/Graph/ArchBase.hs compiler/nativeGen/RegAlloc/Graph/ArchX86.hs compiler/nativeGen/RegAlloc/Graph/Coalesce.hs compiler/nativeGen/RegAlloc/Graph/Spill.hs compiler/nativeGen/RegAlloc/Graph/SpillClean.hs compiler/nativeGen/RegAlloc/Graph/SpillCost.hs compiler/nativeGen/RegAlloc/Graph/TrivColorable.hs compiler/nativeGen/RegAlloc/Linear/Main.hs compiler/nativeGen/RegAlloc/Linear/JoinToTargets.hs compiler/nativeGen/RegAlloc/Linear/State.hs compiler/nativeGen/RegAlloc/Linear/Stats.hs compiler/nativeGen/RegAlloc/Linear/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/StackMap.hs compiler/nativeGen/RegAlloc/Linear/Base.hs compiler/nativeGen/RegAlloc/Linear/X86/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/X86_64/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/PPC/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/SPARC/FreeRegs.hs compiler/deSugar/DsMeta.hs compiler/hsSyn/Convert.lhs compiler/ghci/ByteCodeAsm.lhs compiler/ghci/ByteCodeGen.lhs compiler/ghci/ByteCodeInstr.lhs compiler/ghci/ByteCodeItbls.lhs compiler/ghci/ByteCodeLink.lhs compiler/ghci/Debugger.hs compiler/stage2/build/LibFFI.hs compiler/ghci/Linker.lhs compiler/ghci/ObjLink.lhs compiler/ghci/RtClosureInspect.hs compiler/ghci/DebuggerUtils.hs +RTS -tcompiler/stage2/doc/html/ghc/ghc.haddock.t --machine-readable compiler/types/Coercion.lhs:1892:3: parse error on input ‘-- *kind* and role of its argument. Luckily, laziness should’ [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-head/322/10.html

5 4

RFC: style cleanup & guidelines for GHC, and related bikeshedding
by Austin Seipp 17 Jul '14

17 Jul '14

Hi *, First off, WARNING: BIKESHEDDING AHEAD. With that out of the way - today on IRC, there was some discussion about some stylistic/consistency issues in GHC, and being spurred by Johans recent proposal for top-level documentation, I figured perhaps we should beat the drum on this issue as well. The TL;DR is that GHC has a lot of inconsistent style issues, including things like: - Mixing literate haskell with non-literate haskell files - Legacy code with tabs and spaces intermixed - Related to the last one, trailing whitespace - Mixing styles of do notation in different parts of the compiler (braces vs no braces) - Probably things like indentation mismatches even in the same code - Probably many other things I've missed, obvious or not. These issues by themselves aren't too bad, but together they make the coding style for GHC very inconsistent, and this hurts maintainability a bit I feel. Furthermore, some of these issues block related improvements - for example, https://ghc.haskell.org/trac/ghc/ticket/9230 which is probably quite reasonable will likely be a bit annoying to implement until GHC itself is de-tabbed - we use -Werror during ./validate. This particular issue is what started the discussion. Also, with developers now using arcanist and phabricator, they have linting enabled for new patches, but they will often warn about surrounding issues, mostly tabs and trailing spaces. This is a bit annoying for submitters, and would be fixed by enforcing it. First attack plan ~~~~~~~~~~~~~~~ So, to start, I'd like to propose that we make some guidelines for these kinds of things, and also a plan to fix some of them. To start: #1) We should really consider going ahead and detabbing the remaining files that have them. We already enforce this on new commits with git hooks, but by doing this, we can make -fwarn-tabs a default flag and then validate with -Werror in the development process. #2) Similarly, we should kill all the trailing whitespace. (I think this is less controversial than #1) #3) We should most certainly move the remaining files from literate haskell to non-literate haskell. Most of the files in the compiler are already in this form, and the literate haskell documentation can't be used to generate PDFs or anything similar. I suggest we get rid of it. More Haskell users use non-literate files anyway. This is probably the least controversial. Merge issues ~~~~~~~~~~~~~~~~~ The reason we haven't done the above three things historically is that it makes merge conflicts nastier. A useful approximation suggested on IRC might be to detab and remove whitespace for files older than a certain date (say, 6 months). However, in general I'm thinking perhaps it's best to go ahead and bite the bullet. maybe. I'd like to know what other people think! If we have a vote and most people are in favor of doing this, maybe we should really do it. I'd especially like to hear about this if you have an outstanding branch. Some numbers on these issues ~~~~~~~~~~~~~~~~~~~~~~~~ Here are some quick numbers on where most of the tabs reside, as well as the breakdown of literate files vs non-literate files. NOTE: these tests occurred in the 'compiler' subdirectory of the GHC repository, which is where most of the relevant code is. LITERATE vs NON-LITERATE: $ find . -type f -iname '*.hs' | wc -l 206 $ find . -type f -iname '*.lhs' | wc -l 194 Non-literate wins by a slim margin! But having the compiler divided in half is really not a good thing IMO... NUMBER OF TABS PER SUBDIRECTORY: NOTE: this counts the number of lines which have tabs in them. It does not count the total number of tab occurrences. $ for x in `echo */`; do echo -n "$x:\t\t"; find $x -type f -regex '.*\.$lhs\|hs$' | xargs grep -P '\t' | wc -l; done basicTypes/: 919 cbits/: 0 cmm/: 38 codeGen/: 0 coreSyn/: 843 deSugar/: 545 ghci/: 90 hsSyn/: 120 iface/: 213 llvmGen/: 0 main/: 8 nativeGen/: 1213 parser/: 19 prelude/: 182 profiling/: 39 rename/: 188 simplCore/: 754 simplStg/: 0 specialise/: 0 stgSyn/: 0 stranal/: 336 typecheck/: 1171 types/: 301 utils/: 220 vectorise/: 0 >From these numbers, we can see a few useful things at least, primarily that there are definitely some places where removing tabs should be easy. For example, parser/, profiling/, main/, and cmm/ can all be de-tabbed without much of a problem, I think. nativeGen is very often not touched, so even though it has a *huge* amount of tabs, it can likely be de-tabbed as well with minimal impact. Other style issues ~~~~~~~~~~~~~~~~~ We should also discuss some related issues, like what general block-width to use for indentations, naming conventions, and other stuff. However, I leave this all to you, and perhaps it is best we split that part off into a separate thread. Some things I'd like you all to consider: - Block width for indentation - Naming conventions (we use camelCase and_underscores_sometimes which isReally_confusing) - Import/export styles (I think we have some sloppiness here too) - Other things worth arguing forever about. Thoughts on the above issues? -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

12 19

Updating Haddock submodule
by Simon Peyton Jones 17 Jul '14

17 Jul '14

Herbert, Austin I've just made a change to GHC that has a (trivial) knock-on effect in Haddock, so I had to update the submodule. Here is what I did, after consulting Austin. Can I humbly implore you both (or someone) to write down the workflow so that git-naïve people like me can do this with confidence, rather than (as now) in fear? Below is my draft of the workflow. It seems pretty complicated, and there are three places (in red) where I am unsure what to do. Please in writing the workflow, document every step as I have done below. Thanks! Simon 1. Starting point: · all changes made in GHC and in utils/haddock. · validate works 2. cd utils/haddock 3. git stash Keep my changes out of the way 4. git branch -av Keep the output 5. git checkout master Why 'master'? Because I know from talking to Austin that the ghc repo tracks Haddock's master branch. There is no way to get this information without talking to Someone Who Knows. There should be a wiki page that documents it. 6. Check that in the output of step 4, the current branch (which should be detatched-head) is the same commit as origin/master. I have no idea what to do if this isn't the case. 7. git pull Now Haddock's 'master' is up to date 8. git stash pop Apply the changes to the Haddock master branch 9. git add/commit to record and commit the patch as usual 10. git push Phew! At this stage we have updated Haddock. I think. 11. cd ../.. Back into main ghc repo 12. git add/commit to record patch as usual, but · include utils/haddock in the "files" you add. This will update the submodule pointer in the ghc repo · include the word "submodule" in the commit message 13. git push At this stage we have updated GHC too 14. ???? to get utils/haddock back into the detached-head state. How do I do this? git submodule update doesn't

6 8

7.8.3 source tarball imminent
by Austin Seipp 16 Jul '14

16 Jul '14

Hello *, The 7.8.3 source tarball is imminent. I'll be creating it as soon as my build is done. I expect it will take an hour or so to finish. Note that I have not yet pushed the tag (which will mark the official release version), but everything should be just fine. I'm simply a bit paranoid and running everything through its steps again before handing it out. Gabor, Luke, Mark, Karel - you know what to do when it's here. As usual, I'll be taking care of Windows and the matrix of Linux builds. Mark has stepped up to build the OS X release, for which I'm quite grateful. Sorry for the wait everyone, but it's here, and it's looking good.... -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

7 9

updated OS X 7.8.3 bindist
by Mark Lentczner 16 Jul '14

16 Jul '14

The release 7.8.3 bindist for OS X was flawed: It was not build SplitObjs. That is my fault for not catching it before releasing it. You may demand a beer from me at ICFP as restitution.... I have built a new 7.8.3 bindist for OS X, and tested in 10.9, 10.7, and 10.6(!). It is SplitObjs, and still performs better than the gcc based build. Find it here: ghc-7.8.3-x86_64-apple-darwin-r2.tar.bz2 <http://www.ozonehouse.com/mark/platform/ghc-7.8.3-x86_64-apple-darwin-r2.ta…> shasum -a 256: 7f056a48de5158a950e49f208d1e79c6721c2a908db55f7691f7695171c63306 Updated blurb for the release page: This is a bindist for Mac OS X, 10.6 or later. The package requires the command line tools package of Xcode 4 or XCode 5 to be installed. You can find Xcode at http://developer.apple.com/. If you are installing on a gcc based system (gcc --version doesn't not include the word "clang"), then then when installing this, use the command make install CC_CLANG_BACKEND=0). - Mark

1 1

Travis now tests ghc directly
by Joachim Breitner 16 Jul '14

16 Jul '14

Hi, I just added a .travis.yml file to GHC master. This means that every push will be validated automatic and for free by travis; you can check the build status at https://travis-ci.org/ghc/ghc/builds It is not a full validation. In particular, * it skips DPH * it does not build dynamic libraries and no dynamic executables * does not build haddock or generate documentation * only runs fast tests, and no performance tests This way we stay under the 50 minuite limit. Failures are reported to me, and I’ll manually report relevant breakage to you. It is also configured to mail to ghc-builds(a)haskell.org, but I don’t see these messages there. Maybe some mailing list admin needs to whitelist mails from Travis CI <notifications(a)travis-ci.org>? I’ve also added a link to it from http://ghc.haskell.org/trac/ghc/, including a nice icon showing the current build status. If you have that .travis.yml file in your branch, travis will also test these. My unofficial ghc-complete repository is therefore obsolete, I stopped updating it. Greetings, Joachim -- 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

5 7

7.8.1 plan
by Austin Seipp 16 Jul '14

16 Jul '14

Hello all, As I'm sure you're all aware, it's the final countdown. The (final) source distribution will be up within a few hours, and then we'll continue on from there. Yay! I will post an update when that is, so Gabor/Luke/Karel can make binaries from the sources as I do so. Second, there are just two things I want to note: - For people following the Windows debacle in #8834, there has been a bug fixed, but one may still remain. The TL;DR of this is that we currently have a committed workaround in place we'll keep using, but Simon has made some good steps towards finding the bug. - Lots of people, I'm sure, are wondering what's going on with Safe Haskell and the GND story. The TL;DR of this one is that "everything will be the same as in 7.6" - GND is considered an Unsafe feature, and Data.Coerce is behind Unsafe bars. From a safety point of view, nothing should change for library authors I cherry picked these changes into 7.8 last night. In the mean time, the 7.8 branch is effectively closed. If you have something to commit, and I *really* mean something, you can let me know. But your deadline is hours, not days! I'm doing a final review of all the trees before pushing the library tags, and after that I'll begin rolling the sdist. Anyway, the time is finally here, so let's get it over with! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

16 41

Re: Windows breakage -- again
by Johan Tibell 16 Jul '14

16 Jul '14

I'll be out until Tuesday. I would much appreciate if someone with a Windows setup could help me debug this. These symbols are supposed to be defined by GCC somewhere (as GCC is outputting these when it cannot convert __sync_fetch_and_add into assembly instructions.) On Wed, Jul 16, 2014 at 9:08 PM, Niklas Larsson <metaniklas(a)gmail.com> wrote: > Oh, wait, it isn't the system linker that is complaining, it's the ghc rts > linker. Maybe we just have to tell it to leave those symbols alone. > > Niklas > > > 2014-07-16 20:57 GMT+02:00 Niklas Larsson <metaniklas(a)gmail.com>: > > I get the same failure when I try to build HEAD. Turns out the error >> occurs on the 32-bit Windows build, and my successful build was a 64-bit >> build. My 64-bit build still succeeds. >> >> Also, gcc is 4.5.2 on 32-bit, not 4.6.3 as on 64-bit. >> >> Niklas >> >> >> >> 2014-07-16 14:48 GMT+02:00 Niklas Larsson <metaniklas(a)gmail.com>: >> >> I have built ghc on windows after that was added with no issue. >>> >>> I can take a look this evening and see how HEAD works for me. >>> >>> The standard gcc in the tarballs is 4.6.3, which is getting long in the >>> tooth, there is an issue on trac to upgrade it. >>> >>> -- Niklas >>> >>> ------------------------------ >>> Från: Johan Tibell <johan.tibell(a)gmail.com> >>> Skickat: ‎2014-‎07-‎16 09:57 >>> Till: Simon Peyton Jones <simonpj(a)microsoft.com> >>> Kopia: ghc-devs(a)haskell.org >>> Ämne: Re: Windows breakage -- again >>> >>> You can rollback the commit (git revert 4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) >>> and push that to the repo if you wish. I will try to re-add the primop >>> again after I figure out what's wrong. >>> >>> >>> On Wed, Jul 16, 2014 at 9:37 AM, Johan Tibell <johan.tibell(a)gmail.com> >>> wrote: >>> >>>> I added some primops about a month ago >>>> (4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) that call __sync_fetch_and_add, >>>> a gcc/llvm builtin. I'm a bit surprised to see this error. The GCC manual >>>> [1] says: >>>> >>>> > " Not all operations are supported by all target processors. If a >>>> particular operation cannot be implemented on the target processor, a >>>> warning will be generated and a call an external function will be >>>> generated. The external function will carry the same name as the builtin, >>>> with an additional suffix `_n' where n is the size of the data type." >>>> >>>> I'm a bit surprised by this error for two reasons: >>>> >>>> * A call to that symbol should only be generated if the CPU doesn't >>>> support the atomic instructions. What CPU model does Windows report that >>>> you have? >>>> >>>> * gcc should define such a symbol. For me the following test program >>>> compiles: >>>> >>>> #include <stdint.h> >>>> >>>> uint8_t test(uint8_t* ptr, uint8_t val) { >>>> return __sync_fetch_and_add_1(ptr, val); >>>> } >>>> >>>> int main(void) { >>>> uint8_t n; >>>> return test(&n, 1); >>>> } >>>> >>>> Does that compile for you? Which version of GCC do we end up using on >>>> Windows? >>>> >>>> The reported symbol (___sync_fetch_and_add_1) has three leading >>>> underscores, that looks weird. Can you compile just >>>> libraries/ghc-prim/cbits/atomic.c and see if it's indeed GCC that generates >>>> a reference to that symbol? >>>> >>>> 1. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html >>>> >>>> >>>> On Wed, Jul 16, 2014 at 12:29 AM, Simon Peyton Jones < >>>> simonpj(a)microsoft.com> wrote: >>>> >>>>> Aargh! The Windows build has broken – again. I can’t build GHC on >>>>> my laptop any more. >>>>> >>>>> A clean ‘sh validate’ finishes as below. What on earth is >>>>> `___sync_fetch_and_add_1'? >>>>> >>>>> Can anyone help? Thanks! >>>>> >>>>> Simon >>>>> >>>>> "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf o -hcsuf hc -static >>>>> -H32m -O -Werror -Wall -H64m -O0 -package-name vector-0.10.9.1 >>>>> -hide-all-packages -i -ilibraries/vector/. >>>>> -ilibraries/vector/dist-install/build >>>>> -ilibraries/vector/dist-install/build/autogen >>>>> -Ilibraries/vector/dist-install/build >>>>> -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include >>>>> -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include >>>>> -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package >>>>> base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package >>>>> primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O >>>>> -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts >>>>> -Wwarn -odir libraries/vector/dist-install/build -hidir >>>>> libraries/vector/dist-install/build -stubdir >>>>> libraries/vector/dist-install/build -c >>>>> libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o >>>>> libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o >>>>> >>>>> Loading package ghc-prim ... linking ... ghc-stage2.exe: unable to >>>>> load package `ghc-prim' >>>>> >>>>> ghc-stage2.exe: >>>>> C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.3.1.0.o: >>>>> unknown symbol `___sync_fetch_and_add_1' >>>>> >>>>> libraries/vector/ghc.mk:5: recipe for target >>>>> 'libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o' >>>>> failed >>>>> >>>>> make[1]: *** >>>>> [libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o] >>>>> Error 1 >>>>> >>>>> >>>>> >>>>> I >>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs(a)haskell.org >>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>> >>>>> >>>> >>> >> >

1 0

Windows breakage -- again
by Simon Peyton Jones 16 Jul '14

16 Jul '14

Aargh! The Windows build has broken - again. I can't build GHC on my laptop any more. A clean 'sh validate' finishes as below. What on earth is `___sync_fetch_and_add_1'? Can anyone help? Thanks! Simon "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name vector-0.10.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist-install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist-install/build -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o Loading package ghc-prim ... linking ... ghc-stage2.exe: unable to load package `ghc-prim' ghc-stage2.exe: C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.3.1.0.o: unknown symbol `___sync_fetch_and_add_1' libraries/vector/ghc.mk:5: recipe for target 'libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o' failed make[1]: *** [libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o] Error 1 I

3 6