January 2015 - ghc-tickets

[GHC] #8229: Linking in Windows is slow
by GHC 04 Sep '15

04 Sep '15

#8229: Linking in Windows is slow -------------------------+------------------------------------------------- Reporter: | Owner: ezyang | Status: new Type: bug | Milestone: 7.8.1 Priority: | Version: 7.7 normal | Operating System: Windows Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- It takes a long time to link ghc-stage2 on Windows; several minutes on what should be a pretty beefy machine. Here is the linker command: {{{ "C:\Users\ezyang\Dev\ghc-validate\inplace\lib/../mingw/bin/gcc.exe" "-U__i686" "-fno-stack-prot ector" "-DTABLES_NEXT_TO_CODE" "-o" "compiler/stage2/build/libHSghc-7.7.20130904-ghc7.7.2013090 4.dll" "-shared" "-Wl,--out- implib=compiler/stage2/build/libHSghc-7.7.20130904-ghc7.7.20130904. dll.a" "-Wl,--enable-auto-import" "compiler\stage2\build\GhcMonad.dyn_o" "compiler\stage2\build \Llvm.dyn_o" "compiler\stage2\build\Llvm\AbsSyn.dyn_o" "compiler\stage2\build\Llvm\MetaData.dyn _o" "compiler\stage2\build\Llvm\PpLlvm.dyn_o" "compiler\stage2\build\Llvm\Types.dyn_o" "compile r\stage2\build\LlvmCodeGen.dyn_o" "compiler\stage2\build\LlvmCodeGen\Base.dyn_o" "compiler\stag e2\build\LlvmCodeGen\CodeGen.dyn_o" "compiler\stage2\build\LlvmCodeGen\Data.dyn_o" "compiler\st age2\build\LlvmCodeGen\Ppr.dyn_o" "compiler\stage2\build\LlvmCodeGen\Regs.dyn_o" "compiler\stag e2\build\LlvmMangler.dyn_o" "compiler\stage2\build\CmmBuildInfoTables.dyn_o" "compiler\stage2\b uild\CmmPipeline.dyn_o" "compiler\stage2\build\CmmCommonBlockElim.dyn_o" "compiler\stage2\build \CmmContFlowOpt.dyn_o" "compiler\stage2\build\CmmLex.dyn_o" "compiler\stage2\build\CmmLint.dyn_ o" "compiler\stage2\build\CmmLive.dyn_o" "compiler\stage2\build\CmmOpt.dyn_o" "compiler\stage2\ build\CmmParse.dyn_o" "compiler\stage2\build\CmmProcPoint.dyn_o" "compiler\stage2\build\CmmRewr iteAssignments.dyn_o" "compiler\stage2\build\CmmSink.dyn_o" "compiler\stage2\build\CmmLayoutSta ck.dyn_o" "compiler\stage2\build\PprBase.dyn_o" "compiler\stage2\build\PprC.dyn_o" "compiler\st age2\build\CgUtils.dyn_o" "compiler\stage2\build\StgCmm.dyn_o" "compiler\stage2\build\StgCmmBin d.dyn_o" "compiler\stage2\build\StgCmmCon.dyn_o" "compiler\stage2\build\StgCmmExpr.dyn_o" "comp iler\stage2\build\StgCmmForeign.dyn_o" "compiler\stage2\build\StgCmmHeap.dyn_o" "compiler\stage 2\build\StgCmmHpc.dyn_o" "compiler\stage2\build\StgCmmPrim.dyn_o" "compiler\stage2\build\StgCmm ExtCode.dyn_o" "compiler\stage2\build\CoreLint.dyn_o" "compiler\stage2\build\CorePrep.dyn_o" "c ompiler\stage2\build\ExternalCore.dyn_o" "compiler\stage2\build\MkExternalCore.dyn_o" "compiler \stage2\build\PprExternalCore.dyn_o" "compiler\stage2\build\Check.dyn_o" "compiler\stage2\build \Coverage.dyn_o" "compiler\stage2\build\Desugar.dyn_o" "compiler\stage2\build\DsArrows.dyn_o" " compiler\stage2\build\DsBinds.dyn_o" "compiler\stage2\build\DsCCall.dyn_o" "compiler\stage2\bui ld\DsExpr.dyn_o" "compiler\stage2\build\DsForeign.dyn_o" "compiler\stage2\build\DsGRHSs.dyn_o" "compiler\stage2\build\DsListComp.dyn_o" "compiler\stage2\build\DsMonad.dyn_o" "compiler\stage2 \build\DsUtils.dyn_o" "compiler\stage2\build\Match.dyn_o" "compiler\stage2\build\MatchCon.dyn_o " "compiler\stage2\build\MatchLit.dyn_o" "compiler\stage2\build\BinIface.dyn_o" "compiler\stage 2\build\BuildTyCl.dyn_o" "compiler\stage2\build\IfaceEnv.dyn_o" "compiler\stage2\build\LoadIfac e.dyn_o" "compiler\stage2\build\MkIface.dyn_o" "compiler\stage2\build\TcIface.dyn_o" "compiler\ stage2\build\FlagChecker.dyn_o" "compiler\stage2\build\CodeOutput.dyn_o" "compiler\stage2\build \DriverMkDepend.dyn_o" "compiler\stage2\build\DriverPipeline.dyn_o" "compiler\stage2\build\Find er.dyn_o" "compiler\stage2\build\GHC.dyn_o" "compiler\stage2\build\GhcMake.dyn_o" "compiler\sta ge2\build\GhcPlugins.dyn_o" "compiler\stage2\build\DynamicLoading.dyn_o" "compiler\stage2\build \HeaderInfo.dyn_o" "compiler\stage2\build\HscMain.dyn_o" "compiler\stage2\build\HscStats.dyn_o" "compiler\stage2\build\InteractiveEval.dyn_o" "compiler\stage2\build\PprTyThing.dyn_o" "compil er\stage2\build\SysTools.dyn_o" "compiler\stage2\build\TidyPgm.dyn_o" "compiler\stage2\build\Ct ype.dyn_o" "compiler\stage2\build\HaddockUtils.dyn_o" "compiler\stage2\build\LexCore.dyn_o" "co mpiler\stage2\build\Lexer.dyn_o" "compiler\stage2\build\Parser.dyn_o" "compiler\stage2\build\Pa rserCore.dyn_o" "compiler\stage2\build\ParserCoreUtils.dyn_o" "compiler\stage2\build\RdrHsSyn.d yn_o" "compiler\stage2\build\PrelInfo.dyn_o" "compiler\stage2\build\ProfInit.dyn_o" "compiler\s tage2\build\SCCfinal.dyn_o" "compiler\stage2\build\RnBinds.dyn_o" "compiler\stage2\build\RnEnv. dyn_o" "compiler\stage2\build\RnExpr.dyn_o" "compiler\stage2\build\RnHsDoc.dyn_o" "compiler\sta ge2\build\RnNames.dyn_o" "compiler\stage2\build\RnPat.dyn_o" "compiler\stage2\build\RnSource.dy n_o" "compiler\stage2\build\RnTypes.dyn_o" "compiler\stage2\build\CoreMonad.dyn_o" "compiler\st age2\build\CSE.dyn_o" "compiler\stage2\build\FloatIn.dyn_o" "compiler\stage2\build\FloatOut.dyn _o" "compiler\stage2\build\LiberateCase.dyn_o" "compiler\stage2\build\SAT.dyn_o" "compiler\stag e2\build\SetLevels.dyn_o" "compiler\stage2\build\SimplCore.dyn_o" "compiler\stage2\build\SimplE nv.dyn_o" "compiler\stage2\build\SimplMonad.dyn_o" "compiler\stage2\build\SimplUtils.dyn_o" "co mpiler\stage2\build\Simplify.dyn_o" "compiler\stage2\build\SimplStg.dyn_o" "compiler\stage2\bui ld\StgStats.dyn_o" "compiler\stage2\build\UnariseStg.dyn_o" "compiler\stage2\build\SpecConstr.d yn_o" "compiler\stage2\build\Specialise.dyn_o" "compiler\stage2\build\CoreToStg.dyn_o" "compile r\stage2\build\StgLint.dyn_o" "compiler\stage2\build\DmdAnal.dyn_o" "compiler\stage2\build\Work Wrap.dyn_o" "compiler\stage2\build\WwLib.dyn_o" "compiler\stage2\build\FamInst.dyn_o" "compiler \stage2\build\Inst.dyn_o" "compiler\stage2\build\TcAnnotations.dyn_o" "compiler\stage2\build\Tc Arrows.dyn_o" "compiler\stage2\build\TcBinds.dyn_o" "compiler\stage2\build\TcClassDcl.dyn_o" "c ompiler\stage2\build\TcDefaults.dyn_o" "compiler\stage2\build\TcDeriv.dyn_o" "compiler\stage2\b uild\TcEnv.dyn_o" "compiler\stage2\build\TcExpr.dyn_o" "compiler\stage2\build\TcForeign.dyn_o" "compiler\stage2\build\TcGenDeriv.dyn_o" "compiler\stage2\build\TcGenGenerics.dyn_o" "compiler\ stage2\build\TcHsSyn.dyn_o" "compiler\stage2\build\TcHsType.dyn_o" "compiler\stage2\build\TcIns tDcls.dyn_o" "compiler\stage2\build\TcMType.dyn_o" "compiler\stage2\build\TcValidity.dyn_o" "co mpiler\stage2\build\TcMatches.dyn_o" "compiler\stage2\build\TcPat.dyn_o" "compiler\stage2\build \TcRnDriver.dyn_o" "compiler\stage2\build\TcRnMonad.dyn_o" "compiler\stage2\build\TcRnTypes.dyn _o" "compiler\stage2\build\TcRules.dyn_o" "compiler\stage2\build\TcSimplify.dyn_o" "compiler\st age2\build\TcErrors.dyn_o" "compiler\stage2\build\TcTyClsDecls.dyn_o" "compiler\stage2\build\Tc TyDecls.dyn_o" "compiler\stage2\build\TcUnify.dyn_o" "compiler\stage2\build\TcInteract.dyn_o" " compiler\stage2\build\TcCanonical.dyn_o" "compiler\stage2\build\TcSMonad.dyn_o" "compiler\stage 2\build\FunDeps.dyn_o" "compiler\stage2\build\GraphBase.dyn_o" "compiler\stage2\build\GraphColo r.dyn_o" "compiler\stage2\build\GraphOps.dyn_o" "compiler\stage2\build\GraphPpr.dyn_o" "compile r\stage2\build\IOEnv.dyn_o" "compiler\stage2\build\State.dyn_o" "compiler\stage2\build\Vectoris e\Builtins\Base.dyn_o" "compiler\stage2\build\Vectorise\Builtins\Initialise.dyn_o" "compiler\st age2\build\Vectorise\Builtins.dyn_o" "compiler\stage2\build\Vectorise\Monad\Base.dyn_o" "compil er\stage2\build\Vectorise\Monad\Naming.dyn_o" "compiler\stage2\build\Vectorise\Monad\Local.dyn_ o" "compiler\stage2\build\Vectorise\Monad\Global.dyn_o" "compiler\stage2\build\Vectorise\Monad\ InstEnv.dyn_o" "compiler\stage2\build\Vectorise\Monad.dyn_o" "compiler\stage2\build\Vectorise\U tils\Base.dyn_o" "compiler\stage2\build\Vectorise\Utils\Closure.dyn_o" "compiler\stage2\build\V ectorise\Utils\Hoisting.dyn_o" "compiler\stage2\build\Vectorise\Utils\PADict.dyn_o" "compiler\s tage2\build\Vectorise\Utils\Poly.dyn_o" "compiler\stage2\build\Vectorise\Utils.dyn_o" "compiler \stage2\build\Vectorise\Generic\Description.dyn_o" "compiler\stage2\build\Vectorise\Generic\PAM ethods.dyn_o" "compiler\stage2\build\Vectorise\Generic\PADict.dyn_o" "compiler\stage2\build\Vec torise\Generic\PData.dyn_o" "compiler\stage2\build\Vectorise\Type\Env.dyn_o" "compiler\stage2\b uild\Vectorise\Type\Type.dyn_o" "compiler\stage2\build\Vectorise\Type\TyConDecl.dyn_o" "compile r\stage2\build\Vectorise\Type\Classify.dyn_o" "compiler\stage2\build\Vectorise\Convert.dyn_o" " compiler\stage2\build\Vectorise\Vect.dyn_o" "compiler\stage2\build\Vectorise\Var.dyn_o" "compil er\stage2\build\Vectorise\Env.dyn_o" "compiler\stage2\build\Vectorise\Exp.dyn_o" "compiler\stag e2\build\Vectorise.dyn_o" "compiler\stage2\build\AsmCodeGen.dyn_o" "compiler\stage2\build\Targe tReg.dyn_o" "compiler\stage2\build\NCGMonad.dyn_o" "compiler\stage2\build\Instruction.dyn_o" "c ompiler\stage2\build\Size.dyn_o" "compiler\stage2\build\PIC.dyn_o" "compiler\stage2\build\CPrim .dyn_o" "compiler\stage2\build\X86\Regs.dyn_o" "compiler\stage2\build\X86\RegInfo.dyn_o" "compi ler\stage2\build\X86\Instr.dyn_o" "compiler\stage2\build\X86\Cond.dyn_o" "compiler\stage2\build \X86\Ppr.dyn_o" "compiler\stage2\build\X86\CodeGen.dyn_o" "compiler\stage2\build\PPC\Regs.dyn_o " "compiler\stage2\build\PPC\RegInfo.dyn_o" "compiler\stage2\build\PPC\Instr.dyn_o" "compiler\s tage2\build\PPC\Cond.dyn_o" "compiler\stage2\build\PPC\Ppr.dyn_o" "compiler\stage2\build\PPC\Co deGen.dyn_o" "compiler\stage2\build\SPARC\Base.dyn_o" "compiler\stage2\build\SPARC\Regs.dyn_o" "compiler\stage2\build\SPARC\Imm.dyn_o" "compiler\stage2\build\SPARC\AddrMode.dyn_o" "compiler\ stage2\build\SPARC\Cond.dyn_o" "compiler\stage2\build\SPARC\Instr.dyn_o" "compiler\stage2\build \SPARC\Stack.dyn_o" "compiler\stage2\build\SPARC\ShortcutJump.dyn_o" "compiler\stage2\build\SPA RC\Ppr.dyn_o" "compiler\stage2\build\SPARC\CodeGen.dyn_o" "compiler\stage2\build\SPARC\CodeGen\ Amode.dyn_o" "compiler\stage2\build\SPARC\CodeGen\Base.dyn_o" "compiler\stage2\build\SPARC\Code Gen\CondCode.dyn_o" "compiler\stage2\build\SPARC\CodeGen\Gen32.dyn_o" "compiler\stage2\build\SP ARC\CodeGen\Gen64.dyn_o" "compiler\stage2\build\SPARC\CodeGen\Sanity.dyn_o" "compiler\stage2\bu ild\SPARC\CodeGen\Expand.dyn_o" "compiler\stage2\build\RegAlloc\Liveness.dyn_o" "compiler\stage 2\build\RegAlloc\Graph\Main.dyn_o" "compiler\stage2\build\RegAlloc\Graph\Stats.dyn_o" "compiler \stage2\build\RegAlloc\Graph\ArchBase.dyn_o" "compiler\stage2\build\RegAlloc\Graph\ArchX86.dyn_ o" "compiler\stage2\build\RegAlloc\Graph\Coalesce.dyn_o" "compiler\stage2\build\RegAlloc\Graph\ Spill.dyn_o" "compiler\stage2\build\RegAlloc\Graph\SpillClean.dyn_o" "compiler\stage2\build\Reg Alloc\Graph\SpillCost.dyn_o" "compiler\stage2\build\RegAlloc\Graph\TrivColorable.dyn_o" "compil er\stage2\build\RegAlloc\Linear\Main.dyn_o" "compiler\stage2\build\RegAlloc\Linear\JoinToTarget s.dyn_o" "compiler\stage2\build\RegAlloc\Linear\State.dyn_o" "compiler\stage2\build\RegAlloc\Li near\Stats.dyn_o" "compiler\stage2\build\RegAlloc\Linear\FreeRegs.dyn_o" "compiler\stage2\build \RegAlloc\Linear\StackMap.dyn_o" "compiler\stage2\build\RegAlloc\Linear\Base.dyn_o" "compiler\s tage2\build\RegAlloc\Linear\X86\FreeRegs.dyn_o" "compiler\stage2\build\RegAlloc\Linear\X86_64\F reeRegs.dyn_o" "compiler\stage2\build\RegAlloc\Linear\PPC\FreeRegs.dyn_o" "compiler\stage2\buil d\RegAlloc\Linear\SPARC\FreeRegs.dyn_o" "compiler\stage2\build\DsMeta.dyn_o" "compiler\stage2\b uild\TcSplice.dyn_o" "compiler\stage2\build\Convert.dyn_o" "compiler\stage2\build\ByteCodeGen.d yn_o" "compiler\stage2\build\Debugger.dyn_o" "compiler\stage2\build\LibFFI.dyn_o" "compiler\sta ge2\build\Linker.dyn_o" "compiler\stage2\build\RtClosureInspect.dyn_o" "compiler\stage2\build\D ebuggerUtils.dyn_o" "compiler\stage2\build\parser\cutils.dyn_o" "compiler\stage2\build\ghci\kee pCAFsForGHCi.dyn_o" "compiler\stage2\build\cbits\genSym.dyn_o" "-lHSghc-7.7.20130904-0-ghc7.7.2 0130904.dll" "-Lcompiler/stage2/build" "-Lc:\Users\ezyang\Dev\ghc- validate\libraries\transforme rs\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc-validate\libraries \template-haskell\dist-inst all\build" "-Lc:\Users\ezyang\Dev\ghc-validate\libraries\hpc\dist- install\build" "-Lc:\Users\ez yang\Dev\ghc-validate\libraries\hoopl\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc-validate\l ibraries\bin-package-db\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc- validate\libraries\binar y\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc- validate\libraries\Cabal\Cabal\dist-install\bu ild" "-Lc:\Users\ezyang\Dev\ghc-validate\libraries\process\dist- install\build" "-Lc:\Users\ezya ng\Dev\ghc-validate\libraries\pretty\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc-validate\li braries\directory\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc- validate\libraries\time\dist-i nstall\build" "-Lc:\Users\ezyang\Dev\ghc-validate\libraries\old-locale \dist-install\build" "-Lc :\Users\ezyang\Dev\ghc-validate\libraries\filepath\dist-install\build" "-Lc:\Users\ezyang\Dev\g hc-validate\libraries\Win32\dist-install\build" "-Lc:\Users\ezyang\Dev \ghc-validate\libraries\c ontainers\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc- validate\libraries\bytestring\dist-ins tall\build" "-Lc:\Users\ezyang\Dev\ghc-validate\libraries\deepseq\dist- install\build" "-Lc:\Use rs\ezyang\Dev\ghc-validate\libraries\array\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc-valid ate\libraries\base\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc- validate\libraries\integer-gm p\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc-validate\libraries\ghc- prim\dist-install\build " "-Lc:/Users/ezyang/Dev/ghc-validate/rts/dist/build" "-lHStransformers-0.3.0.0-ghc7.7.20130904 " "-lHStemplate-haskell-2.9.0.0-ghc7.7.20130904" "-lHShpc-0.6.0.1-ghc7.7.20130904" "-lHShoopl-3 .10.0.0-ghc7.7.20130904" "-lHSbin-package-db-0.0.0.0-ghc7.7.20130904" "-lHSbinary-0.7.1.0-ghc7. 7.20130904" "-lHSCabal-1.18.0-ghc7.7.20130904" "-lHSprocess-1.2.0.0-ghc7.7.20130904" "-lHSprett y-1.1.1.0-ghc7.7.20130904" "-lHSdirectory-1.2.0.1-ghc7.7.20130904" "-lHStime-1.4.1-ghc7.7.20130 904" "-lHSold-locale-1.0.0.5-ghc7.7.20130904" "-lHSfilepath-1.3.0.2-ghc7.7.20130904" "-lHSWin32 -2.3.0.0-ghc7.7.20130904" "-lHScontainers-0.5.2.1-ghc7.7.20130904" "-lHSbytestring-0.10.3.0-ghc 7.7.20130904" "-lHSdeepseq-1.3.0.2-ghc7.7.20130904" "-lHSarray-0.4.0.2-ghc7.7.20130904" "-lHSba se-4.7.0.0-ghc7.7.20130904" "-lHSinteger-gmp-0.5.1.0-ghc7.7.20130904" "-lHSghc-prim-0.3.1.0-ghc 7.7.20130904" "-lHSrts_thr-ghc7.7.20130904" "-lffi-6" "-lkernel32" "-luser32" "-lgdi32" "-lwinm m" "-ladvapi32" "-lshell32" "-lshfolder" "-lwsock32" "-luser32" "-lshell32" "-lm" "-lwsock32" " -lgdi32" "-lwinmm" "-lmingwex" "-Wl,-u,_ghczmprim_GHCziTypes_Izh_static_info" "-Wl,-u,_ghczmpri m_GHCziTypes_Czh_static_info" "-Wl,-u,_ghczmprim_GHCziTypes_Fzh_static_info" "-Wl,-u,_ghczmprim _GHCziTypes_Dzh_static_info" "-Wl,-u,_base_GHCziPtr_Ptr_static_info" "-Wl,-u,_ghczmprim_GHCziTy pes_Wzh_static_info" "-Wl,-u,_base_GHCziInt_I8zh_static_info" "-Wl,-u,_base_GHCziInt_I16zh_stat ic_info" "-Wl,-u,_base_GHCziInt_I32zh_static_info" "-Wl,-u,_base_GHCziInt_I64zh_static_info" "- Wl,-u,_base_GHCziWord_W8zh_static_info" "-Wl,-u,_base_GHCziWord_W16zh_static_info" "-Wl,-u,_bas e_GHCziWord_W32zh_static_info" "-Wl,-u,_base_GHCziWord_W64zh_static_info" "-Wl,-u,_base_GHCziSt able_StablePtr_static_info" "-Wl,-u,_ghczmprim_GHCziTypes_Izh_con_info" "-Wl,-u,_ghczmprim_GHCz iTypes_Czh_con_info" "-Wl,-u,_ghczmprim_GHCziTypes_Fzh_con_info" "-Wl,-u,_ghczmprim_GHCziTypes_ Dzh_con_info" "-Wl,-u,_base_GHCziPtr_Ptr_con_info" "-Wl,-u,_base_GHCziPtr_FunPtr_con_info" "-Wl ,-u,_base_GHCziStable_StablePtr_con_info" "-Wl,-u,_ghczmprim_GHCziTypes_False_closure" "-Wl,-u, _ghczmprim_GHCziTypes_True_closure" "-Wl,-u,_base_GHCziPack_unpackCString_closure" "-Wl,-u,_bas e_GHCziIOziException_stackOverflow_closure" "-Wl,-u,_base_GHCziIOziException_heapOverflow_closu re" "-Wl,-u,_base_ControlziExceptionziBase_nonTermination_closure" "-Wl,-u,_base_GHCziIOziExcep tion_blockedIndefinitelyOnMVar_closure" "-Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnS TM_closure" "-Wl,-u,_base_ControlziExceptionziBase_nestedAtomically_closure" "-Wl,-u,_base_GHCz iWeak_runFinalizzerBatch_closure" "-Wl,-u,_base_GHCziTopHandler_flushStdHandles_closure" "-Wl,- u,_base_GHCziTopHandler_runIO_closure" "-Wl,-u,_base_GHCziTopHandler_runNonIO_closure" "-Wl,-u, _base_GHCziConcziIO_ensureIOManagerIsRunning_closure" "-Wl,-u,_base_GHCziConcziIO_ioManagerCapa bilitiesChanged_closure" "-Wl,-u,_base_GHCziConcziSync_runSparks_closure" "-Wl,-u,_base_GHCziCo ncziSignal_runHandlers_closure" "-Wl,--hash-size=31" "-Wl,--reduce-memory- overheads" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8229> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8127: iOS patch no 19: Linking
by GHC 04 Sep '15

04 Sep '15

#8127: iOS patch no 19: Linking -------------------------------------+------------------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Other Architecture: arm | Type of failure: GHC doesn't work Difficulty: Moderate (less | at all than a day) | Test Case: Blocked By: | Blocking: 7724 Related Tickets: | -------------------------------------+------------------------------------- Fix linking for cross compiler to iOS. This patch does these things: 1. use libtool to link to a static library in place of an executable (because on iOS the final link must be done in Xcode), 2. for packages, keep only the HS package libraries and throw out other options (because libtool doesn't accept them), 3. fail if you try to link a dynamic library on iOS because it isn't supported (not really needed but there for completeness). Note that there is a minor risk here, because in the normal case, the order of options passed to the linker is slightly different: The options relating to each dependent package are separated into three different kinds, but they're still in the same relative order per package. This should be perfectly OK. The name of "libtool" is hard-coded and can't be set by options. Is this OK? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8127> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs
by GHC 04 Sep '15

04 Sep '15

#9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh spacekitteh | Status: new Type: task | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Operating System: Unknown/Multiple Libraries | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It is basically the same as the standard error function but outputs a stack trace if one is available. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9943> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10047: inconsistency in name binding between splice and quasiquotation
by GHC 04 Sep '15

04 Sep '15

#10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.4 Haskell | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Let me preface this by saying that this may not be a bug. If not then it would be nice if the documentation for Template Haskell could clarify what's going on here. My understanding of quasiquotation is that a quasiquote `[n|foo|]` is equivalent to a splice `$(quoteExp n "foo")`. However, that is not the case in all contexts. {{{ module Q where import Language.Haskell.TH import Language.Haskell.TH.Quote n = QuasiQuoter { quoteExp = dyn } }}} {{{ rwbarton@morphism:/tmp$ ghci -XTemplateHaskell -XQuasiQuotes Q GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Q ( Q.hs, interpreted ) Q.hs:6:5: Warning: Fields of ‘QuasiQuoter’ not initialised: quotePat, quoteType, quoteDec In the expression: QuasiQuoter {quoteExp = dyn} In an equation for ‘n’: n = QuasiQuoter {quoteExp = dyn} Ok, modules loaded: Q. *Q> :t [| $(dyn "foo") |] [| $(dyn "foo") |] :: ExpQ *Q> :t [| [n|foo|] |] Loading package pretty-1.1.1.1 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package template-haskell ... linking ... done. <interactive>:1:7: Not in scope: ‘foo’ In the Template Haskell quotation [| [n|foo|] |] }}} Why do these behave differently? (Lastly, the link to the paper "Why It's Nice to be Quoted: Quasiquoting for Haskell" in the User's Guide at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/template- haskell.html#th-quasiquotation is broken. Does this paper have a permanent home? In any case, I only skimmed it but it didn't seem to answer my question.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10047> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #9447: Add support for resizing `MutableByteArray#`s
by GHC 27 Aug '15

27 Aug '15

#9447: Add support for resizing `MutableByteArray#`s -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D133 -------------------------------------+------------------------------------- This is motivated by #9281 which changes how memory is allocated, and gives rise to the need to be able to efficiently shrink or grow `MutableByteArray#`s before they're frozen into `ByteArray#` while retaining their original byte content to avoid a major bottle-neck. This ticket is for tracking/documenting all changes related to this new facility. Here's the current road-map: 1. Implement {{{#!hs shrinkMutableByteArray# :: MutableByteArray# s -> Int# -> State# s -> State# s resizeMutableByteArray# :: MutableByteArray# s -> Int# -> State# s -> (# State# s, MutableByteArray# s #) }}} (see Phab:D133) 2. As suggested by Johan, {{{#!hs getSizeofMutableByteArray# :: MutableByteArray# s -> State# s -> (# State# s Int# #) }}} This is similar in spirit to `numCapabilities` and `getNumCapabilities`. Add a deprecate pragma (or equivalent) for `sizeofMutableByteArray#`. Add a note to `sizeofMutableByteArray#` stating that it's unsafe in the presence of calls to resize-operations on the same MBA. 3. Submit patches to upstream libraries replacing calls to `sizeofMutableByteArray#` with `getSizeofMutableByteArray#` 4. Investigate how to provide in-place (zero-copy) growing of MBAs (step 1. only implements in-place shrinking). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9447> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10032: --with-system-libffi not working on Solaris
by GHC 27 Aug '15

27 Aug '15

#10032: --with-system-libffi not working on Solaris -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.11 System | Operating System: Solaris Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hello, an attempt to configure ghc-7.10.1-rc2 with: {{{ $ ./configure --with-gmp-includes=/usr/include/gmp/ --with-gmp- libraries=/usr/lib/ --with-system-libffi --with-ffi- includes=/usr/lib/libffi-3.0.9/include/ --with-ffi-libraries=/usr/lib/ }}} results in kind of broken distribution, since gmake test_bindist fails with: {{{ bindisttest/"install dir"/bin/runghc bindisttest/HelloWorld > bindisttest/output diff -U 1 bindisttest/output bindisttest/expected_output No differences encountered bindisttest/"install dir"/bin/ghc --make bindisttest/HelloWorld [1 of 1] Compiling Main ( bindisttest/HelloWorld.lhs, bindisttest/HelloWorld.o ) Linking bindisttest/HelloWorld ... bindisttest/HelloWorld > bindisttest/output diff -U 1 bindisttest/output bindisttest/expected_output No differences encountered bindisttest/"install dir"/bin/ghc-pkg check --no-user-package-db There are problems in package rts-1.0: library-dirs: @FFILibDir@ is a relative path which makes no sense (as there is nothing for it to be relative to). You can make paths relative to the package database itself by using ${pkgroot}. include-dirs: @FFIIncludeDir@ is a relative path which makes no sense (as there is nothing for it to be relative to). You can make paths relative to the package database itself by using ${pkgroot}. The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. rts-1.0 ghc-7.10.0.20150123 haskeline-0.7.2.0 terminfo-0.4.0.1 xhtml-3000.2.1 transformers-0.4.2.0 hoopl-3.10.0.2 bin-package-db-0.0.0.0 Cabal-1.22.1.0 binary-0.7.3.0 template-haskell-2.10.0.0 pretty-1.1.2.0 hpc-0.6.0.2 process-1.2.2.0 directory-1.2.2.0 unix-2.7.1.0 time-1.5.0.1 containers-0.5.6.2 bytestring-0.10.6.0 deepseq-1.4.0.0 array-0.5.0.1 filepath-1.3.1.0 base-4.8.0.0 integer-gmp-1.0.0.0 ghc-prim-0.3.1.0 gmake[1]: *** [test_bindist] Error 1 gmake: *** [test_bindist] Error 2 }}} Honestly speaking I must add that even gmake binary-dist was not without issue since this expected ffi headers to be located in rts/dist/build directory but they were obviously not there. I've copied them manually and then binary-dist was able to run. I'm not sure if this is Solaris specific issue or if this also affects other Unix(-like) OSes. I mark that for 7.11 (HEAD) since I'm not sure I'll have a time to address this issue for 7.10.1-rc3/fcs. The workaround is easy, just let ghc use its own copy of ffi library and not the system provided one. In the long term however, having ghc using system provided one is better. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10032> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8096: Add fudge-factor for performance tests run on non-validate builds
by GHC 26 Aug '15

26 Aug '15

#8096: Add fudge-factor for performance tests run on non-validate builds ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Since I'm not going to get around to this immediately, Trac'ifying for posterity: These tests have been doing better than expected in the nightlies for some while. {{{ Unexpected failures: perf/compiler T3064 [stat too good] (normal) perf/compiler T3294 [stat too good] (normal) perf/compiler T5642 [stat too good] (normal) perf/haddock haddock.Cabal [stat too good] (normal) perf/haddock haddock.base [stat too good] (normal) }}} Unfortunately, fixing them is not a simple matter of shifting the ranges up, since the tests only exceed expectations on a /perf/ build, so on a normal build such as 'quick', these tests all pass normally. I could bump up the upper bounds so that the builder stops bleating about them; perhaps we could do something more complicated where the expected performance depends on what level of optimization GHC was built with (but I don't know how to implement this.) ---- The problem with just widening the bounds to cover 2 different types of build is that it increases the chance that performance changes won't actually be noticed by thge person responsible. Having different bounds for different build configurations is a pain, because (a) the testsuite has to work out which set of bounds to use, and (b) you now have even more wobbly values to keep up-to-date. I think perhaps the best thing would be to add some sort of (per-test?) fudge factor for non-validate builds. That way validate will still find performance regressions, like it does today, but other builds are less likely to give false positives. (Igloo) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8096> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9315: Weird change in allocation numbers of T9203
by GHC 26 Aug '15

26 Aug '15

#9315: Weird change in allocation numbers of T9203 ------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- While trying to improve our handle on allocation numbers, I’m stuck with the test case T9203. On some machines, it allocates roughly 95747304 bytes (this includes travis and my laptop), on others 42946176 bytes (e.g. on the machine where I monitor benchmark performance). All machines are 64 bit Linux machines. The output of `-ddump-simpl`, `-ddump-stg` and `-ddump-cmm` is identical (up to variable names). Even `-ddump-asm` looks the same, besides some jump target reordering. The binary runs too small to get a heap profile. I’m a bit stuck here: What can be the cause for these differences? (BTW, if have an up-to-date GHC tree, can you report the number you get? Run `make -C testsuite VERBOSE=4 TEST=9203` for that.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9315> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #9932: GHC fails to build when cross compiling for mingw with the message "Threads not supported"
by GHC 26 Aug '15

26 Aug '15

#9932: GHC fails to build when cross compiling for mingw with the message "Threads not supported" -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Keywords: Cross compiling | Operating System: Linux Architecture: x86 | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: 9542 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'm trying to build a mingw32 cross compiler. I configured with `./configure --target=x86_64-x64-mingw32`, then I built with `make -j 1`. The build then fails with the message ` # error "Threads not supported"` followed by some other errors. (The last part of the make log is attached) To bypass #9542, I deleted the following lines from utils/hsc2hs/Main.hs: {{{ #if defined(__GLASGOW_HASKELL__) && !defined(BUILD_NHC) #include "../../includes/ghcconfig.h" #endif }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9932> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9257: CC_CLANG_BACKEND not reconfigured during bindist install
by GHC 26 Aug '15

26 Aug '15

#9257: CC_CLANG_BACKEND not reconfigured during bindist install -------------------------------------+------------------------------------- Reporter: MtnViewMark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: clang | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Installing GHC Difficulty: Moderate (less | failed than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- 1) build GHC is built on a machine with clang -- project.mk ends up with the macro CC_CLANG_BACKEND=1 2) make binary-dist on that machine 3) bring that bindist to a machine that doesn't use clang 4) unpack the bindist, ./configure, make install This error ensues: cc1: error: unrecognized command line option "-Wno-invalid-pp-token" cc1: error: unrecognized command line option "-Wno-unicode" The problem rests in that there is on gcc invocation during that make install: /usr/bin/gcc -E ... rts/package.conf.in -o rts/dist/package.conf.install.raw This call is picking up arguments from RAWCPP_FLAGS, set in mk/config.mk, based on CC_CLANG_BACKEND, set in mk/project.mk... which was computed at build time. carter has hypothesized that adding the macro FP_CC_LLVM_BACKEND to distrib/configure.ac.in might fix this. In theory that will cause the config file that is bunded into the bindist to recompute the CC_CLANG_BACKEND flag at dist config time. However, this may not work because the only file that emits CC_CLANG_BACKEND is project.mk and that doesn't seem to get re-written during dist time config. -- so something else will be needed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9257> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3