February 2014 - ghc-tickets

[GHC] #8596: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)"
by GHC 06 Sep '15

06 Sep '15

#8596: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)" ----------------------------+--------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------- I have a program (git-annex) which builds successfully on windows, but when I enable any of three optional features which pull in some additional libraries, it fails to link. I will attach the output of cabal build --ghc-options=-v for a failing and a successful build. I hypothesize this is due to a command line length limit. The final failing gcc link command is 43814 characters, vs 30765 in the configuration that succeeds. Right around the 32k boundry. Not sure what I can do to work around this, short of splitting up my program into standalone libraries which will link without referencing every individual module? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8596> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8614: Duplicate symbol error when loading text twice
by GHC 05 Sep '15

05 Sep '15

#8614: Duplicate symbol error when loading text twice ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We are developing some FFI binding to some Kinect Camera library, and came across the following: {{{ GHCi, version 7.6.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. Prelude> import Honi Prelude Honi> import Honi.Types Prelude Honi Honi.Types> initialize 2 Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package text-0.11.3.1 ... linking ... done. Loading package honi-0.1.0.0 ... can't load .so/.DLL for: libfreenect.so (libfreenect.so: cannot open shared object file: No such file or directory) Prelude Honi Honi.Types> Right [d] <- getDeviceList Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package text-0.11.3.1 ... GHCi runtime linker: fatal error: I found a duplicate definition for symbol __stginit_textzm0zi11zi3zi1_DataziText whilst processing object file /home/niklas/.cabal/lib/x86_64-linux- ghc-7.6.3/text-0.11.3.1/libHStext-0.11.3.1.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. }}} Apparently, ghci has no problem linking packages like array and deepseq twice, but when it comes across loading text another time, we get this duplicate symbol error. Does this make sense? Why does it not detect that text is already linked, like for the other packages? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8614> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8290: lookupSymbol API is unsafe
by GHC 05 Sep '15

05 Sep '15

#8290: lookupSymbol API is unsafe -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- lookupSymbol is one of those functions that looks nice and innocuous on the tin, until you realize actually it doesn't actually do what you want, and seduces you into writing code that doesn't work on Mac OS X. Case in point, this recent test suite commit: {{{ commit 29b0521cd9be39b4026103d184d1fec14ef3bc22 Author: Edward Z. Yang <ezyang(a)mit.edu> Date: Fri Sep 13 20:52:57 2013 -0700 Properly provide leading underscore when necessary. Signed-off-by: Edward Z. Yang <ezyang(a)mit.edu> }}} Yes, the API is "correct" in some sense, but from a portability sense, we really want the function to add the underscore itself. If we change this particular function, we will probably break most dynamic loading code (including GHC's). We could also add a safe variant of the function. We just need to decide something to do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8290> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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] #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] #8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8
by GHC 24 Aug '15

24 Aug '15

#8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8 -------------------------------------------+------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Changing type signature of comparison primops from `Bool` to `Int#` in GHC 7.8 (see #6135) caused a problem: type signatures of functions might be different for the bootstrapping compiler (if it is older than 7.8) than they are for the stage1 compiler. In order to solve this problem I introduced a compatibility module [[GhcFile(compiler/utils/ExtsCompat46)]] that provides different definition of primops for older versions of GHC (`__GLASGOW_HASKELL__ <= 706`) and different for newer versions (`__GLASGOW_HASKELL__ > 706`). However, once we set minimal version of GHC required for bootstrapping to be 7.8, we can (and should!) remove that compatibility module and go back to using GHC.Exts. This ticket is a reminder that we should do this after we release GHC 7.10 or 7.12. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8330> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8484: Compile-time panic
by GHC 20 Aug '15

20 Aug '15

#8484: Compile-time panic ----------------------------------+--------------------------------------- Reporter: Taymon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I attempted to build a program (using make) and got the following output: {{{ ghc -odir binaries -hidir binaries --make Main.hs -optl-w ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): While parsing "/home/taymonbeal/.ghc/x86_64-linux-7.6.3/package.conf.d/package.cache": too few bytes. Failed reading at byte position 8 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make: *** [build] Error 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8484> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8178: Need TypeRep for Symbol and numeric type literals; and Typeable instances
by GHC 08 Aug '15

08 Aug '15

#8178: Need TypeRep for Symbol and numeric type literals; and Typeable instances ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Nicolas Trangez points out that we don't have a `TypeRep` for types involving literal strings or numerics. E.g. what is `(typeRep (undefined :: Proxy "foo"))`? Here is Nicolas's example: {{{ {-# LANGUAGE DataKinds, KindSignatures, DeriveFunctor, DeriveDataTypeable #-} module Main where import Data.Typeable import GHC.TypeLits data NoSymbol n a b = NoSymbol a b deriving (Typeable) data WithSymbol (n :: Symbol) a b = WithSymbol a b deriving (Typeable) data Sym deriving (Typeable) main :: IO () main = do print $ typeOf (undefined :: NoSymbol Sym Int Int) let d = undefined :: WithSymbol "sym" Int Int {- print $ typeOf d No instance for (Typeable Symbol "sym") arising from a use of ‛typeOf’ -} return () }}} Just as types contain literal strings and natural numbers, so too must `TypeRep`, in some way. Once we have a suitable `TypeRep` we can make built-in instance for `Typeable` that return the appropriate representation. At the moment we have (in `Data.Typeable.Internals`): {{{ data TypeRep = TypeRep {-# UNPACK #-} !Fingerprint TyCon [TypeRep] data TyCon = TyCon { tyConHash :: {-# UNPACK #-} !Fingerprint, tyConPackage :: String, tyConModule :: String, tyConName :: String } }}} with instances for Eq and Ord. Perhaps we need {{{ data TypeRep = TcApp {-# UNPACK #-} !Fingerprint TyCon [TypeRep] | TcSym String | TcNat Integer }}} or something like that? I'm not certain. I think Iavor is going to think about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8178> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8488: Annotations should not distinguish type and value
by GHC 31 Jul '15

31 Jul '15

#8488: Annotations should not distinguish type and value ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In `HsDecls` we have {{{ data AnnDecl name = HsAnnotation (AnnProvenance name) (Located (HsExpr name)) data AnnProvenance name = ValueAnnProvenance name | TypeAnnProvenance name | ModuleAnnProvenance }}} And there's now a similar 3-way distinction in Template Haskell `Syntax`: {{{ data AnnTarget = ModuleAnnotation | TypeAnnotation Name | ValueAnnotation Name }}} But there's really no need to distinguish between `TypeAnnProvenance` and `ValueAnnProvenance` (and similarly in the TH vesrion) because the namespace on the `Name` makes that distinction. So the current story is redundant, and hence has silly case where you have a `ValueAnnProvenance` on a type constructor. Better to collapse the two. I'm making this a ticket so that people can comment. I hope that Gergely may be able to do it as part of his TH/annotation work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8488> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5