From trac at galois.com  Tue Jan  1 09:06:31 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 09:00:36 2008
Subject: [GHC] #1985: IntSet.deleteMin doesn't agree with Set.deleteMin
In-Reply-To: <047.5a3c908303a81d833e8535fa59db8e2e@localhost>
References: <047.5a3c908303a81d833e8535fa59db8e2e@localhost>
Message-ID: <056.93959bc636abd47fdce80197551a685a@localhost>

#1985: IntSet.deleteMin doesn't agree with Set.deleteMin
-------------------------------+--------------------------------------------
 Reporter:  dbenbenn           |          Owner:             
     Type:  bug                |         Status:  new        
 Priority:  normal             |      Milestone:  6.10 branch
Component:  libraries (other)  |        Version:  6.8.1      
 Severity:  normal             |     Resolution:             
 Keywords:                     |     Difficulty:  Unknown    
 Testcase:                     |   Architecture:  Multiple   
       Os:  Multiple           |  
-------------------------------+--------------------------------------------
Changes (by igloo):

 * cc: jeanphilippe.bernardy (added)
  * milestone:  => 6.10 branch

Comment:

 Good spot! Jean-Philippe, does David's patch look right to you?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1985#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 09:12:41 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 09:06:47 2008
Subject: [GHC] #1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
In-Reply-To: <047.e1a81f31ca9bdca7e0fd42494374e2fa@localhost>
References: <047.e1a81f31ca9bdca7e0fd42494374e2fa@localhost>
Message-ID: <056.7828575d8bafc2018fb6c919476d6f22@localhost>

#1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
----------------------+-----------------------------------------------------
 Reporter:  wb.kloke  |          Owner:                
     Type:  bug       |         Status:  new           
 Priority:  normal    |      Milestone:                
Component:  Compiler  |        Version:  6.8.2         
 Severity:  normal    |     Resolution:                
 Keywords:            |     Difficulty:  Unknown       
 Testcase:            |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD   |  
----------------------+-----------------------------------------------------
Old description:

> I am trying to build a native amd64 compiler on FreeBSD. At the bootstrap
> stage I use the -i386
> compiler as ghc: This works to stage1. The stage1 compiler is usable in a
> limited way. But the stage2 compiler built with this fails very early
> (before even complaining about missing -B options, if started naked).
>
> Ex.:
> /home/wb.local/ghc-6.8.2 0$ compiler/stage2/ghc-6.8.2
> Segmentation fault: 11 (core dumped)
> wb@yorikke:ttyp2
> /home/wb.local/ghc-6.8.2 0$ compiler/stage1/ghc-6.8.2
> ghc-6.8.2: missing -B<dir> option
>

> The most reproducable misbehaviour of the stage1 compiler is the
> unability to run test arith003. The value minInt is converted to a
> nonprintable 1-char string in the int_ops part. Most other results,
> including the multiple precision tests, look better than the output from
> x86-64-openbsd (as published with the 6.6.1-testsuite). It looks as if
> there is a specific problem with bit pattern 0x8000000000000000L. If I
> change the source code to avoid this pattern (minInt -> minInt+1) the
> error does not occur.
>
> First lines of arith003 output:
>
> (+) 0 0 = 0
> (+) 0 1 = 1
> (+) 0 -1 = -1
> (+) 0 2 = 2
> (+) 0 -2 = -2
> (+) 0 -<FC>8 = -<FC>8
> (+) 0 9223372036854775807 = 9223372036854775807
> (+) 1 0 = 1
> (+) 1 1 = 2
> (+) 1 -1 = 0
> (+) 1 2 = 3
> (+) 1 -2 = -1
> (+) 1 -<FC>8 = -9223372036854775807
> (+) 1 9223372036854775807 = -<FC>8
> (+) -1 0 = -1
> (+) -1 1 = 0
> (+) -1 -1 = -2
> (+) -1 2 = 1
> (+) -1 -2 = -3
> (+) -1 -<FC>8 = 9223372036854775807
> (+) -1 9223372036854775807 = 9223372036854775806
> (+) 2 0 = 2
> (+) 2 1 = 3
> (+) 2 -1 = 1
> (+) 2 2 = 4
> (+) 2 -2 = 0
> (+) 2 -<FC>8 = -9223372036854775806
> (+) 2 9223372036854775807 = -9223372036854775807
> (+) -2 0 = -2
> (+) -2 1 = -1
> (+) -2 -1 = -3
> (+) -2 2 = 0
> (+) -2 -2 = -4
> (+) -2 -<FC>8 = 9223372036854775806
> (+) -2 9223372036854775807 = 9223372036854775805
> (+) -<FC>8 0 = -<FC>8
> (+) -<FC>8 1 = -9223372036854775807
> (+) -<FC>8 -1 = 9223372036854775807
> (+) -<FC>8 2 = -9223372036854775806
> (+) -<FC>8 -2 = 9223372036854775806
> (+) -<FC>8 -<FC>8 = 0
> (+) -<FC>8 9223372036854775807 = -1
> (+) 9223372036854775807 0 = 9223372036854775807
> (+) 9223372036854775807 1 = -<FC>8
> (+) 9223372036854775807 -1 = 9223372036854775806
> (+) 9223372036854775807 2 = -9223372036854775807
> (+) 9223372036854775807 -2 = 9223372036854775805
> (+) 9223372036854775807 -<FC>8 = -1
> (+) 9223372036854775807 9223372036854775807 = -2
> ...

New description:

 I am trying to build a native amd64 compiler on FreeBSD. At the bootstrap
 stage I use the -i386
 compiler as ghc: This works to stage1. The stage1 compiler is usable in a
 limited way. But the stage2 compiler built with this fails very early
 (before even complaining about missing -B options, if started naked).
 {{{
 Ex.:
 /home/wb.local/ghc-6.8.2 0$ compiler/stage2/ghc-6.8.2
 Segmentation fault: 11 (core dumped)
 wb@yorikke:ttyp2
 /home/wb.local/ghc-6.8.2 0$ compiler/stage1/ghc-6.8.2
 ghc-6.8.2: missing -B<dir> option
 }}}

 The most reproducable misbehaviour of the stage1 compiler is the unability
 to run test arith003. The value minInt is converted to a nonprintable
 1-char string in the int_ops part. Most other results, including the
 multiple precision tests, look better than the output from x86-64-openbsd
 (as published with the 6.6.1-testsuite). It looks as if there is a
 specific problem with bit pattern 0x8000000000000000L. If I change the
 source code to avoid this pattern (minInt -> minInt+1) the error does not
 occur.

 First lines of arith003 output:
 {{{
 (+) 0 0 = 0
 (+) 0 1 = 1
 (+) 0 -1 = -1
 (+) 0 2 = 2
 (+) 0 -2 = -2
 (+) 0 -<FC>8 = -<FC>8
 (+) 0 9223372036854775807 = 9223372036854775807
 (+) 1 0 = 1
 (+) 1 1 = 2
 (+) 1 -1 = 0
 (+) 1 2 = 3
 (+) 1 -2 = -1
 (+) 1 -<FC>8 = -9223372036854775807
 (+) 1 9223372036854775807 = -<FC>8
 (+) -1 0 = -1
 (+) -1 1 = 0
 (+) -1 -1 = -2
 (+) -1 2 = 1
 (+) -1 -2 = -3
 (+) -1 -<FC>8 = 9223372036854775807
 (+) -1 9223372036854775807 = 9223372036854775806
 (+) 2 0 = 2
 (+) 2 1 = 3
 (+) 2 -1 = 1
 (+) 2 2 = 4
 (+) 2 -2 = 0
 (+) 2 -<FC>8 = -9223372036854775806
 (+) 2 9223372036854775807 = -9223372036854775807
 (+) -2 0 = -2
 (+) -2 1 = -1
 (+) -2 -1 = -3
 (+) -2 2 = 0
 (+) -2 -2 = -4
 (+) -2 -<FC>8 = 9223372036854775806
 (+) -2 9223372036854775807 = 9223372036854775805
 (+) -<FC>8 0 = -<FC>8
 (+) -<FC>8 1 = -9223372036854775807
 (+) -<FC>8 -1 = 9223372036854775807
 (+) -<FC>8 2 = -9223372036854775806
 (+) -<FC>8 -2 = 9223372036854775806
 (+) -<FC>8 -<FC>8 = 0
 (+) -<FC>8 9223372036854775807 = -1
 (+) 9223372036854775807 0 = 9223372036854775807
 (+) 9223372036854775807 1 = -<FC>8
 (+) 9223372036854775807 -1 = 9223372036854775806
 (+) 9223372036854775807 2 = -9223372036854775807
 (+) 9223372036854775807 -2 = 9223372036854775805
 (+) 9223372036854775807 -<FC>8 = -1
 (+) 9223372036854775807 9223372036854775807 = -2
 ...
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1989#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 09:36:08 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 09:30:10 2008
Subject: [GHC] #1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
In-Reply-To: <047.e1a81f31ca9bdca7e0fd42494374e2fa@localhost>
References: <047.e1a81f31ca9bdca7e0fd42494374e2fa@localhost>
Message-ID: <056.e23c909558be83ef0d8fa824c7c28c12@localhost>

#1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
----------------------+-----------------------------------------------------
 Reporter:  wb.kloke  |          Owner:                
     Type:  bug       |         Status:  new           
 Priority:  normal    |      Milestone:  6.8.3         
Component:  Compiler  |        Version:  6.8.2         
 Severity:  normal    |     Resolution:                
 Keywords:            |     Difficulty:  Unknown       
 Testcase:            |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

  * milestone:  => 6.8.3

Comment:

 If you've built stage3 then that means the compiler itself is now
 basically working, right?

 For arith003, the maths looks OK, I assume the problem is with the
 printing code:
 {{{
 showSignedInt :: Int -> Int -> ShowS
 showSignedInt (I# p) (I# n) r
     | n <# 0# && p ># 6# = '(' : itos n (')' : r)
     | otherwise          = itos n r

 itos :: Int# -> String -> String
 itos n# cs
     | n# <# 0# =
     let I# minInt# = minInt in
     if n# ==# minInt#
         -- negateInt# minInt overflows, so we can't do that:
        then '-' : itos' (negateInt# (n# `quotInt#` 10#))
                              (itos' (negateInt# (n# `remInt#` 10#)) cs)
        else '-' : itos' (negateInt# n#) cs
     | otherwise = itos' n# cs
     where
     itos' :: Int# -> String -> String
     itos' n# cs
         | n# <# 10#  = C# (chr# (ord# '0'# +# n#)) : cs
         | otherwise = case chr# (ord# '0'# +# (n# `remInt#` 10#)) of { c#
 ->
               itos' (n# `quotInt#` 10#) (C# c# : cs) }
 }}}
 My suspicion is that the sign of one or both of these will be wrong:
 {{{
 Prelude> :set -fglasgow-exts
 Prelude> :m + GHC.Exts
 Prelude GHC.Exts> I# ((-9223372036854775808#) `remInt#` 10#)
 -8
 Prelude GHC.Exts> I# ((-9223372036854775808#) `quotInt#` 10#)
 -922337203685477580
 }}}
 Otherwise, reproducing the problem with the printing code in a module of
 its own, using `showSignedInt 0 minBound ""` (you'll need to import
 GHC.Exts, and possibly other modules, and the problem may be sensitive to
 commandline flags like `-fvia-C/-fasm`, `-O0/-O/-O2`) and then cutting it
 down to work out exactly which step gives the wrong answer may point in
 the direction of the problem.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1989#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 10:05:41 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 09:59:50 2008
Subject: [GHC] #1992: 6.8.2 intermittent build failure on multiple OS X
 versions
In-Reply-To: <044.6e3d43e6297883ec96aae365685c0c7d@localhost>
References: <044.6e3d43e6297883ec96aae365685c0c7d@localhost>
Message-ID: <053.0fd7bcb2f2e2fcd1787cf157cef776f9@localhost>

#1992: 6.8.2 intermittent build failure on multiple OS X versions
----------------------+-----------------------------------------------------
 Reporter:  guest     |          Owner:          
     Type:  bug       |         Status:  new     
 Priority:  normal    |      Milestone:  6.8.3   
Component:  Compiler  |        Version:  6.8.2   
 Severity:  normal    |     Resolution:          
 Keywords:            |     Difficulty:  Unknown 
 Testcase:            |   Architecture:  Multiple
       Os:  MacOS X   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

  * milestone:  => 6.8.3

Comment:

 Thanks for the report. Does running
 {{{
 ../compiler/stage1/ghc-inplace -M -optdep-f -optdep.depend-BASE  -osuf o
 -I../includes   -H16m -O -I/opt/local/include -I/usr/include
 -L/opt/local/lib -L/usr/lib -iutils -ibasicTypes -itypes -ihsSyn -iprelude
 -irename -itypecheck -ideSugar -icoreSyn -ivectorise -ispecialise
 -isimplCore -istranal -istgSyn -isimplStg -icodeGen -imain -iprofiling
 -iparser -icprAnalysis -indpFlatten -iiface -icmm -inativeGen -ighci -Wall
 -fno-warn-name-shadowing -fno-warn-orphans -Istage2 -package hpc -package
 bytestring -DGHCI -package template-haskell -DGHCI_TABLES_NEXT_TO_CODE
 -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno-generics -Rghc-
 timing -I. -Iparser -package unix -package Cabal -ignore-package lang
 -recomp -Rghc-timing -H16M '-#include "cutils.h"' -package-name ghc-6.8.2
 -fgenerics basicTypes/BasicTypes.lhs basicTypes/DataCon.lhs
 basicTypes/Demand.lhs basicTypes/Id.lhs basicTypes/IdInfo.lhs
 basicTypes/Literal.lhs basicTypes/MkId.lhs basicTypes/Module.lhs
 basicTypes/Name.lhs basicTypes/NameEnv.lhs basicTypes/NameSet.lhs
 basicTypes/NewDemand.lhs basicTypes/OccName.lhs basicTypes/RdrName.lhs
 basicTypes/SrcLoc.lhs basicTypes/UniqSupply.lhs basicTypes/Unique.lhs
 basicTypes/Var.lhs basicTypes/VarEnv.lhs basicTypes/VarSet.lhs
 cmm/CLabel.hs cmm/Cmm.hs cmm/CmmBrokenBlock.hs cmm/CmmCPS.hs
 cmm/CmmCPSGen.hs cmm/CmmCallConv.hs cmm/CmmInfo.hs cmm/CmmLex.hs
 cmm/CmmLint.hs cmm/CmmLive.hs cmm/CmmOpt.hs cmm/CmmParse.hs
 cmm/CmmProcPoint.hs cmm/CmmUtils.hs cmm/Dataflow.hs cmm/MachOp.hs
 cmm/PprC.hs cmm/PprCmm.hs codeGen/Bitmap.hs codeGen/CgBindery.lhs
 codeGen/CgCallConv.hs codeGen/CgCase.lhs codeGen/CgClosure.lhs
 codeGen/CgCon.lhs codeGen/CgExpr.lhs codeGen/CgForeignCall.hs
 codeGen/CgHeapery.lhs codeGen/CgHpc.hs codeGen/CgInfoTbls.hs
 codeGen/CgLetNoEscape.lhs codeGen/CgMonad.lhs codeGen/CgParallel.hs
 codeGen/CgPrimOp.hs codeGen/CgProf.hs codeGen/CgStackery.lhs
 codeGen/CgTailCall.lhs codeGen/CgTicky.hs codeGen/CgUtils.hs
 codeGen/ClosureInfo.lhs codeGen/CodeGen.lhs codeGen/SMRep.lhs
 coreSyn/CoreFVs.lhs coreSyn/CoreLint.lhs coreSyn/CorePrep.lhs
 coreSyn/CoreSubst.lhs coreSyn/CoreSyn.lhs coreSyn/CoreTidy.lhs
 coreSyn/CoreUnfold.lhs coreSyn/CoreUtils.lhs coreSyn/ExternalCore.lhs
 coreSyn/MkExternalCore.lhs coreSyn/PprCore.lhs coreSyn/PprExternalCore.lhs
 cprAnalysis/CprAnalyse.lhs deSugar/Check.lhs deSugar/Coverage.lhs
 deSugar/Desugar.lhs deSugar/DsArrows.lhs deSugar/DsBinds.lhs
 deSugar/DsCCall.lhs deSugar/DsExpr.lhs deSugar/DsForeign.lhs
 deSugar/DsGRHSs.lhs deSugar/DsListComp.lhs deSugar/DsMeta.hs
 deSugar/DsMonad.lhs deSugar/DsUtils.lhs deSugar/Match.lhs
 deSugar/MatchCon.lhs deSugar/MatchLit.lhs ghci/ByteCodeAsm.lhs
 ghci/ByteCodeFFI.lhs ghci/ByteCodeGen.lhs ghci/ByteCodeInstr.lhs
 ghci/ByteCodeItbls.lhs ghci/ByteCodeLink.lhs ghci/Debugger.hs
 ghci/GhciMonad.hs ghci/GhciTags.hs ghci/InteractiveUI.hs ghci/Linker.lhs
 ghci/ObjLink.lhs ghci/RtClosureInspect.hs hsSyn/Convert.lhs
 hsSyn/HsBinds.lhs hsSyn/HsDecls.lhs hsSyn/HsDoc.hs hsSyn/HsExpr.lhs
 hsSyn/HsImpExp.lhs hsSyn/HsLit.lhs hsSyn/HsPat.lhs hsSyn/HsSyn.lhs
 hsSyn/HsTypes.lhs hsSyn/HsUtils.lhs iface/BinIface.hs iface/BuildTyCl.lhs
 iface/IfaceEnv.lhs iface/IfaceSyn.lhs iface/IfaceType.lhs
 iface/LoadIface.lhs iface/MkIface.lhs iface/TcIface.lhs main/BreakArray.hs
 main/CmdLineParser.hs main/CodeOutput.lhs main/Config.hs
 main/Constants.lhs main/DriverMkDepend.hs main/DriverPhases.hs
 main/DriverPipeline.hs main/DynFlags.hs main/ErrUtils.lhs main/Finder.lhs
 main/GHC.hs main/HeaderInfo.hs main/HscMain.lhs main/HscStats.lhs
 main/HscTypes.lhs main/InteractiveEval.hs main/Main.hs
 main/PackageConfig.hs main/Packages.lhs main/ParsePkgConf.hs
 main/PprTyThing.hs main/StaticFlags.hs main/SysTools.lhs main/TidyPgm.lhs
 nativeGen/AsmCodeGen.lhs nativeGen/GraphBase.hs nativeGen/GraphColor.hs
 nativeGen/GraphOps.hs nativeGen/GraphPpr.hs nativeGen/MachCodeGen.hs
 nativeGen/MachInstrs.hs nativeGen/MachRegs.lhs nativeGen/NCGMonad.hs
 nativeGen/PositionIndependentCode.hs nativeGen/PprMach.hs
 nativeGen/RegAllocColor.hs nativeGen/RegAllocInfo.hs
 nativeGen/RegAllocLinear.hs nativeGen/RegAllocStats.hs
 nativeGen/RegArchBase.hs nativeGen/RegArchX86.hs nativeGen/RegCoalesce.hs
 nativeGen/RegLiveness.hs nativeGen/RegSpill.hs nativeGen/RegSpillClean.hs
 nativeGen/RegSpillCost.hs ndpFlatten/FlattenInfo.hs
 ndpFlatten/FlattenMonad.hs ndpFlatten/Flattening.hs
 ndpFlatten/NDPCoreUtils.hs ndpFlatten/PArrAnal.hs parser/Ctype.lhs
 parser/HaddockLex.hs parser/HaddockParse.hs parser/HaddockUtils.hs
 parser/LexCore.hs parser/Lexer.hs parser/Parser.hs parser/ParserCore.hs
 parser/ParserCoreUtils.hs parser/RdrHsSyn.lhs prelude/ForeignCall.lhs
 prelude/PrelInfo.lhs prelude/PrelNames.lhs prelude/PrelRules.lhs
 prelude/PrimOp.lhs prelude/TysPrim.lhs prelude/TysWiredIn.lhs
 profiling/CostCentre.lhs profiling/SCCfinal.lhs rename/RnBinds.lhs
 rename/RnEnv.lhs rename/RnExpr.lhs rename/RnHsDoc.hs rename/RnHsSyn.lhs
 rename/RnNames.lhs rename/RnSource.lhs rename/RnTypes.lhs
 simplCore/CSE.lhs simplCore/FloatIn.lhs simplCore/FloatOut.lhs
 simplCore/LiberateCase.lhs simplCore/OccurAnal.lhs simplCore/SAT.lhs
 simplCore/SATMonad.lhs simplCore/SetLevels.lhs simplCore/SimplCore.lhs
 simplCore/SimplEnv.lhs simplCore/SimplMonad.lhs simplCore/SimplUtils.lhs
 simplCore/Simplify.lhs simplStg/SRT.lhs simplStg/SimplStg.lhs
 simplStg/StgStats.lhs specialise/Rules.lhs specialise/SpecConstr.lhs
 specialise/Specialise.lhs stgSyn/CoreToStg.lhs stgSyn/StgLint.lhs
 stgSyn/StgSyn.lhs stranal/DmdAnal.lhs stranal/SaAbsInt.lhs
 stranal/SaLib.lhs stranal/StrictAnal.lhs stranal/WorkWrap.lhs
 stranal/WwLib.lhs typecheck/FamInst.lhs typecheck/Inst.lhs
 typecheck/TcArrows.lhs typecheck/TcBinds.lhs typecheck/TcClassDcl.lhs
 typecheck/TcDefaults.lhs typecheck/TcDeriv.lhs typecheck/TcEnv.lhs
 typecheck/TcExpr.lhs typecheck/TcForeign.lhs typecheck/TcGadt.lhs
 typecheck/TcGenDeriv.lhs typecheck/TcHsSyn.lhs typecheck/TcHsType.lhs
 typecheck/TcInstDcls.lhs typecheck/TcMType.lhs typecheck/TcMatches.lhs
 typecheck/TcPat.lhs typecheck/TcRnDriver.lhs typecheck/TcRnMonad.lhs
 typecheck/TcRnTypes.lhs typecheck/TcRules.lhs typecheck/TcSimplify.lhs
 typecheck/TcSplice.lhs typecheck/TcTyClsDecls.lhs typecheck/TcTyDecls.lhs
 typecheck/TcTyFuns.lhs typecheck/TcType.lhs typecheck/TcUnify.lhs
 types/Class.lhs types/Coercion.lhs types/FamInstEnv.lhs types/FunDeps.lhs
 types/Generics.lhs types/InstEnv.lhs types/TyCon.lhs types/Type.lhs
 types/TypeRep.lhs types/Unify.lhs utils/Bag.lhs utils/Binary.hs
 utils/BufWrite.hs utils/Digraph.lhs utils/Encoding.hs utils/FastMutInt.lhs
 utils/FastString.lhs utils/FastTypes.lhs utils/FiniteMap.lhs
 utils/IOEnv.hs utils/ListSetOps.lhs utils/Maybes.lhs utils/OrdList.lhs
 utils/Outputable.lhs utils/Panic.lhs utils/Pretty.lhs utils/State.hs
 utils/StringBuffer.lhs utils/UniqFM.lhs utils/UniqSet.lhs utils/Util.lhs
 vectorise/VectBuiltIn.hs vectorise/VectCore.hs vectorise/VectMonad.hs
 vectorise/VectType.hs vectorise/VectUtils.hs vectorise/Vectorise.hs
 }}}
 by hand in `compiler/` reproduce the problem? It sounds like printing info
 from the internals of openFile, as you suggest, or looking at the
 equivalent of strace's output (ktrace on OS X, if I remember correctly),
 should shed some light.

 It's curious that I haven't seen anyone else report this. What sort of
 filesystem are you working on?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1992#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 10:08:40 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 10:02:42 2008
Subject: [GHC] #1993: "RegAllocLinear.getStackSlotFor: out of stack
 slots" when compiling SHA1.hs in darcs
In-Reply-To: <047.e84806530b859709e5179210f10fbc2c@localhost>
References: <047.e84806530b859709e5179210f10fbc2c@localhost>
Message-ID: <056.66a1a36c86079a914149a06e35562fd0@localhost>

#1993: "RegAllocLinear.getStackSlotFor: out of stack slots" when compiling SHA1.hs
in darcs
----------------------+-----------------------------------------------------
 Reporter:  apstrand  |          Owner:         
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:         
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  x86    
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Old description:

> I got the following error when compiling darcs under win32/cygwin with
> ghc 6.8.2 and profiling turned on.
>
> $ make VERBOSE=1
> ghc -DPACKAGE_NAME=\"darcs\" -DPACKAGE_TARNAME=\"darcs\"
> -DPACKAGE_VERSION=\"2.0.0pre3\" -DPACKAGE_STRING=\"darcs\ 2.0.0pre3\"
> -DPACKAGE_BUGREPORT=\"bugs@darcs.net\" -DSTDC_HEADERS=1
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -Isrc/win32 -cpp
> -package regex-compat -package QuickCheck -package mtl -package parsec
> -package html -package containers -package pretty -O -funbox-strict-
> fields  -prof -auto-all -Wall -Werror -I. -I./src -i./src -isrc/win32
> -Isrc/win32 -DWIN32
> -DHAVE_MAPI -no-auto-all -funfolding-use-threshold20 -c src/SHA1.lhs
> ghc.exe: panic! (the 'impossible' happened)
>   (GHC version 6.8.2 for i386-unknown-mingw32):
>         RegAllocLinear.getStackSlotFor: out of stack slots
>
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>
> make: *** [src/SHA1.o] Error 1
>

> Context for the darcs version I tried to compile is attached.

New description:

 I got the following error when compiling darcs under win32/cygwin with ghc
 6.8.2 and profiling turned on.
 {{{
 $ make VERBOSE=1
 ghc -DPACKAGE_NAME=\"darcs\" -DPACKAGE_TARNAME=\"darcs\"
 -DPACKAGE_VERSION=\"2.0.0pre3\" -DPACKAGE_STRING=\"darcs\ 2.0.0pre3\"
 -DPACKAGE_BUGREPORT=\"bugs@darcs.net\" -DSTDC_HEADERS=1
 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -Isrc/win32 -cpp  -package regex-
 compat -package QuickCheck -package mtl -package parsec -package html
 -package containers -package pretty -O -funbox-strict-fields  -prof -auto-
 all -Wall -Werror -I. -I./src -i./src -isrc/win32 -Isrc/win32 -DWIN32
 -DHAVE_MAPI -no-auto-all -funfolding-use-threshold20 -c src/SHA1.lhs
 ghc.exe: panic! (the 'impossible' happened)
   (GHC version 6.8.2 for i386-unknown-mingw32):
         RegAllocLinear.getStackSlotFor: out of stack slots

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

 make: *** [src/SHA1.o] Error 1
 }}}

 Context for the darcs version I tried to compile is attached.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1993#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 10:59:27 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 10:53:30 2008
Subject: [GHC] #1993: "RegAllocLinear.getStackSlotFor: out of stack
 slots" when compiling SHA1.hs in darcs
In-Reply-To: <047.e84806530b859709e5179210f10fbc2c@localhost>
References: <047.e84806530b859709e5179210f10fbc2c@localhost>
Message-ID: <056.7628525568351a67c62205c662afaa6a@localhost>

#1993: "RegAllocLinear.getStackSlotFor: out of stack slots" when compiling SHA1.hs
in darcs
----------------------+-----------------------------------------------------
 Reporter:  apstrand  |          Owner:         
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:  6.8.3  
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  x86    
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

  * milestone:  => 6.8.3

Comment:

 I've added a standalone example:
 {{{
 $ ghc -O -funbox-strict-fields -prof -funfolding-use-threshold20 -c
 SHA1.lhs
 ghc.exe: panic! (the 'impossible' happened)
   (GHC version 6.8.2 for i386-unknown-mingw32):
         RegAllocLinear.getStackSlotFor: out of stack slots

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1993#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 11:41:55 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 11:36:31 2008
Subject: [GHC] #1999: panic with GADT etc.
In-Reply-To: <046.74c6dc616261a913ffd4180fb00731f0@localhost>
References: <046.74c6dc616261a913ffd4180fb00731f0@localhost>
Message-ID: <055.0ed2c0010def488e22c88748affab9ff@localhost>

#1999: panic with GADT etc.
----------------------+-----------------------------------------------------
 Reporter:  jeltsch   |          Owner:             
     Type:  bug       |         Status:  new        
 Priority:  normal    |      Milestone:  6.10 branch
Component:  Compiler  |        Version:  6.9        
 Severity:  normal    |     Resolution:             
 Keywords:            |     Difficulty:  Unknown    
 Testcase:            |   Architecture:  x86        
       Os:  Linux     |  
----------------------+-----------------------------------------------------
Changes (by igloo):

  * milestone:  => 6.10 branch

Comment:

 Thanks for the report! This works in 6.8.2.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1999#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 11:46:55 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 11:40:58 2008
Subject: [GHC] #2000: -funfolding-update-in-place badly documented
In-Reply-To: <045.ac76dc598481f3a493531a6d155a8b48@localhost>
References: <045.ac76dc598481f3a493531a6d155a8b48@localhost>
Message-ID: <054.e8dc6b8ae6eacfa820debc05de574e39@localhost>

#2000: -funfolding-update-in-place badly documented
----------------------+-----------------------------------------------------
 Reporter:  m4dc4p    |          Owner:  igloo  
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:  6.8.3  
Component:  Compiler  |        Version:  6.8.1  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  x86    
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

  * owner:  => igloo
  * milestone:  => 6.8.3

Comment:

 Thanks for the report, you are right. I'll fix the docs.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2000#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 11:53:06 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 11:47:08 2008
Subject: [GHC] #2001: panic when recompiling after ctrl-C leaves .o
 without .hi
In-Reply-To: <051.a9f35addcc3c7bb910990fccf4192860@localhost>
References: <051.a9f35addcc3c7bb910990fccf4192860@localhost>
Message-ID: <060.f7463048d08a12ee57f77c9255cbe356@localhost>

#2001: panic when recompiling after ctrl-C leaves .o without .hi
--------------------------+-------------------------------------------------
 Reporter:  Isaac Dupree  |          Owner:         
     Type:  bug           |         Status:  closed 
 Priority:  normal        |      Milestone:         
Component:  Compiler      |        Version:  6.8.2  
 Severity:  minor         |     Resolution:  wontfix
 Keywords:                |     Difficulty:  Unknown
 Testcase:                |   Architecture:  x86    
       Os:  Linux         |  
--------------------------+-------------------------------------------------
Changes (by igloo):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 GHC can't just recompile the other module as it's being used in one-file
 mode, so it doesn't know what command line flags should be used for the
 other module. Even if it did, I don't think it should recompile
 dependencies if you don't use `--make`.

 Thanks

 Ian

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2001#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 12:10:53 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 12:04:54 2008
Subject: [GHC] #2002: problems with very large (list) literals
In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost>
References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost>
Message-ID: <060.a49cf70449eea5b62f288add0d01e04d@localhost>

#2002: problems with very large (list) literals
--------------------------+-------------------------------------------------
 Reporter:  Isaac Dupree  |          Owner:         
     Type:  bug           |         Status:  new    
 Priority:  high          |      Milestone:  6.8.3  
Component:  Compiler      |        Version:  6.8.2  
 Severity:  normal        |     Resolution:         
 Keywords:                |     Difficulty:  Unknown
 Testcase:                |   Architecture:  x86    
       Os:  Linux         |  
--------------------------+-------------------------------------------------
Changes (by igloo):

  * priority:  normal => high
  * milestone:  => 6.8.3

Comment:

 It sounds like this could be a regression, so I've marked it as high
 priority.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2002#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 12:34:57 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 12:28:58 2008
Subject: [GHC] #2004: Pattern matching against GADTs without -XGADTs has
 odd behavior.
In-Reply-To: <044.b468022ed3fa4097df9a462be70e8e2e@localhost>
References: <044.b468022ed3fa4097df9a462be70e8e2e@localhost>
Message-ID: <053.1c263b9fb21d61d83605ff377583c4b9@localhost>

#2004: Pattern matching against GADTs without -XGADTs has odd behavior.
-------------------------------------+--------------------------------------
 Reporter:  guest                    |          Owner:  simonpj    
     Type:  bug                      |         Status:  new        
 Priority:  normal                   |      Milestone:  6.10 branch
Component:  Compiler (Type checker)  |        Version:  6.8.1      
 Severity:  normal                   |     Resolution:             
 Keywords:                           |     Difficulty:  Unknown    
 Testcase:                           |   Architecture:  Unknown    
       Os:  Unknown                  |  
-------------------------------------+--------------------------------------
Changes (by igloo):

  * owner:  => simonpj
  * milestone:  => 6.10 branch

Comment:

 Simon, is this the expected behaviour?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2004#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 13:50:42 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 13:44:44 2008
Subject: [GHC] #2006: unreachable GADT pattern clauses show up as
 warnings with -Wall
In-Reply-To: <044.a004885c928a62e2a73bf12df457c462@localhost>
References: <044.a004885c928a62e2a73bf12df457c462@localhost>
Message-ID: <053.ea686eb12159db53a8578bcea26b247e@localhost>

#2006: unreachable GADT pattern clauses show up as warnings with -Wall
----------------------+-----------------------------------------------------
 Reporter:  ryani     |          Owner:            
     Type:  bug       |         Status:  new       
 Priority:  normal    |      Milestone:  6.8 branch
Component:  Compiler  |        Version:  6.8.1     
 Severity:  normal    |     Resolution:            
 Keywords:            |     Difficulty:  Unknown   
 Testcase:            |   Architecture:  Unknown   
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

  * milestone:  => 6.8 branch

Comment:

 Thanks for the report.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2006#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 13:55:27 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 13:49:33 2008
Subject: [GHC] #2007: :main deals poorly with \escape characters
In-Reply-To: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
References: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
Message-ID: <060.d0fa383aad44d6d3c3844aa269dd0850@localhost>

#2007: :main deals poorly with \escape characters
--------------------------+-------------------------------------------------
 Reporter:  NeilMitchell  |          Owner:             
     Type:  bug           |         Status:  new        
 Priority:  normal        |      Milestone:  6.10 branch
Component:  GHCi          |        Version:  6.9        
 Severity:  normal        |     Resolution:             
 Keywords:                |     Difficulty:  Unknown    
 Testcase:                |   Architecture:  Unknown    
       Os:  Unknown       |  
--------------------------+-------------------------------------------------
Changes (by igloo):

  * milestone:  => 6.10 branch

Comment:

 I'd prefer that it worked more like a shell, i.e. in
 {{{
 :main foo bar
 :main "foo bar"
 :main "foo\nbar"
 }}}
 the first call has 2 arguments and the latter 2 have 1.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2007#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 14:21:23 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 14:15:25 2008
Subject: [GHC] #2010: out of stack slots
In-Reply-To: <051.e72c7b92923d8544c2af0d69efb8bb0f@localhost>
References: <051.e72c7b92923d8544c2af0d69efb8bb0f@localhost>
Message-ID: <060.629be9062ade8d2637ed3e4ba4789f59@localhost>

#2010: out of stack slots
--------------------------+-------------------------------------------------
 Reporter:  jim.stuttard  |          Owner:           
     Type:  bug           |         Status:  closed   
 Priority:  normal        |      Milestone:           
Component:  Compiler      |        Version:  6.8.2    
 Severity:  normal        |     Resolution:  duplicate
 Keywords:                |     Difficulty:  Unknown  
 Testcase:                |   Architecture:  x86      
       Os:  Unknown       |  
--------------------------+-------------------------------------------------
Changes (by igloo):

  * status:  new => closed
  * resolution:  => duplicate

Comment:

 Thanks for the report! I'm closing this ticket as it's a duplicate of
 #1993.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2010#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 14:23:07 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 14:17:08 2008
Subject: [GHC] #1986: runhaskell doesn't have a --version option
In-Reply-To: <042.44d90b1d57525d17b12ffab59d5bba78@localhost>
References: <042.44d90b1d57525d17b12ffab59d5bba78@localhost>
Message-ID: <051.79e58a1a7963c66398d70d2744e180ca@localhost>

#1986: runhaskell doesn't have a --version option
-----------------------------+----------------------------------------------
 Reporter:  tim              |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.10 branch
Component:  Compiler         |        Version:  6.9        
 Severity:  minor            |     Resolution:             
 Keywords:                   |     Difficulty:  Unknown    
 Testcase:                   |   Architecture:  Unknown    
       Os:  Unknown          |  
-----------------------------+----------------------------------------------
Changes (by igloo):

  * milestone:  => 6.10 branch

Comment:

 Thanks for the report. In an ideal world `runhaskell --help` would only
 mention the portable flags.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1986#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 14:28:34 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 14:23:10 2008
Subject: [GHC] #2005: localhost on mac causes getnameinfo error in
 safari.
In-Reply-To: <043.2e0e6309ca162e2f7e3751b621e7afca@localhost>
References: <043.2e0e6309ca162e2f7e3751b621e7afca@localhost>
Message-ID: <052.8e28d7859a87679065abb6efc28174ef@localhost>

#2005: localhost on mac causes getnameinfo error in safari.
------------------------------------+---------------------------------------
 Reporter:  alex                    |          Owner:            
     Type:  bug                     |         Status:  new       
 Priority:  normal                  |      Milestone:  6.8 branch
Component:  libraries/network       |        Version:  6.8.2     
 Severity:  normal                  |     Resolution:            
 Keywords:  network localhost ipv6  |     Difficulty:  Unknown   
 Testcase:                          |   Architecture:  x86       
       Os:  MacOS X                 |  
------------------------------------+---------------------------------------
Changes (by igloo):

 * cc: therp, allbery_b (removed)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2005#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 15:55:45 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 15:49:47 2008
Subject: [GHC] #2007: :main deals poorly with \escape characters
In-Reply-To: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
References: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
Message-ID: <060.eb2e0a2666e615e84834036aebb0d617@localhost>

#2007: :main deals poorly with \escape characters
--------------------------+-------------------------------------------------
 Reporter:  NeilMitchell  |          Owner:             
     Type:  bug           |         Status:  new        
 Priority:  normal        |      Milestone:  6.10 branch
Component:  GHCi          |        Version:  6.9        
 Severity:  normal        |     Resolution:             
 Keywords:                |     Difficulty:  Unknown    
 Testcase:                |   Architecture:  Unknown    
       Os:  Unknown       |  
--------------------------+-------------------------------------------------
Comment (by NeilMitchell):

 Using "quotes" to group arguments is definately a good idea. Treating \n
 as a newline rather than the literal slash followed by n follows the Linux
 behaviour, but would probably be a bit annoying for Windows users. Ideally
 the syntax for :main should be identical to the system shell - whatever
 that may be. Is it too frustrating to have the same command behave
 differently depending on your OS?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2007#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 16:54:11 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 16:48:13 2008
Subject: [GHC] #2007: :main deals poorly with \escape characters
In-Reply-To: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
References: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
Message-ID: <060.363f1fe0e1fedb781d618937a7147a8e@localhost>

#2007: :main deals poorly with \escape characters
--------------------------+-------------------------------------------------
 Reporter:  NeilMitchell  |          Owner:             
     Type:  bug           |         Status:  new        
 Priority:  normal        |      Milestone:  6.10 branch
Component:  GHCi          |        Version:  6.9        
 Severity:  normal        |     Resolution:             
 Keywords:                |     Difficulty:  Unknown    
 Testcase:                |   Architecture:  Unknown    
       Os:  Unknown       |  
--------------------------+-------------------------------------------------
Comment (by igloo):

 I was thinking that if an argument began with " then we would parse it as
 a Haskell string, and otherwise we would do something like `break
 isWhite`.

 Trying to emulate the system shell sounds far too difficult to me.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2007#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 17:35:43 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 17:29:43 2008
Subject: [GHC] #2001: panic when recompiling after ctrl-C leaves .o
 without .hi
In-Reply-To: <051.a9f35addcc3c7bb910990fccf4192860@localhost>
References: <051.a9f35addcc3c7bb910990fccf4192860@localhost>
Message-ID: <060.60e24dc3172c5396dc194d46d5cff989@localhost>

#2001: panic when recompiling after ctrl-C leaves .o without .hi
--------------------------+-------------------------------------------------
 Reporter:  Isaac Dupree  |          Owner:         
     Type:  bug           |         Status:  closed 
 Priority:  normal        |      Milestone:         
Component:  Compiler      |        Version:  6.8.2  
 Severity:  minor         |     Resolution:  wontfix
 Keywords:                |     Difficulty:  Unknown
 Testcase:                |   Architecture:  x86    
       Os:  Linux         |  
--------------------------+-------------------------------------------------
Comment (by Isaac Dupree):

 oh, I see, it was not CmmSpillReload that was being recompiled, but
 something that depends on it, and it was GHC-HEAD's Makefile system
 getting confused.  I'm not sure if it should be called "Panic!" though --
 I thought that was only for conditions that were supposed to be impossible
 given a correct GHC build?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2001#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 17:42:39 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 17:36:41 2008
Subject: [GHC] #2002: problems with very large (list) literals
In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost>
References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost>
Message-ID: <060.f730c1ec41a276607649f4e698199163@localhost>

#2002: problems with very large (list) literals
--------------------------+-------------------------------------------------
 Reporter:  Isaac Dupree  |          Owner:         
     Type:  bug           |         Status:  new    
 Priority:  high          |      Milestone:  6.8.3  
Component:  Compiler      |        Version:  6.8.2  
 Severity:  normal        |     Resolution:         
 Keywords:                |     Difficulty:  Unknown
 Testcase:                |   Architecture:  x86    
       Os:  Linux         |  
--------------------------+-------------------------------------------------
Comment (by Isaac Dupree):

 Could be. Compared to 6.6, though, it's not really a regression, in fact
 it's an improvement (in 6.6.1 no amount of memory will allow it to finish
 -- I think that might have been a quadratic-behavior bug that was fixed.
 I don't think "stack overflow" is really a regression from "fails to
 terminate on valid code"?)

 As for the second part of my report (large alex files), I haven't tested
 it with 6.6.1, but I'm sure it wouldn't terminate, since in 6.6.1 the
 large list literals alone would ensure that.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2002#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 17:56:11 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 17:50:13 2008
Subject: [GHC] #2007: :main deals poorly with \escape characters
In-Reply-To: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
References: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
Message-ID: <060.4491d49a016c2f1327aa18fcbc9732f8@localhost>

#2007: :main deals poorly with \escape characters
--------------------------+-------------------------------------------------
 Reporter:  NeilMitchell  |          Owner:             
     Type:  bug           |         Status:  new        
 Priority:  normal        |      Milestone:  6.10 branch
Component:  GHCi          |        Version:  6.9        
 Severity:  normal        |     Resolution:             
 Keywords:                |     Difficulty:  Unknown    
 Testcase:                |   Architecture:  Unknown    
       Os:  Unknown       |  
--------------------------+-------------------------------------------------
Comment (by NeilMitchell):

 What would `:main "foo" "bar"` give? If we parse it as a Haskell string,
 it does need to be a sequence of Haskell strings. What about `:main bar
 foo "foo bar"`?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2007#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 19:48:04 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 19:42:05 2008
Subject: [GHC] #2008: GHCi takes increasingly more memory
In-Reply-To: <051.6d649c23331d31238e1b16c9a01068ae@localhost>
References: <051.6d649c23331d31238e1b16c9a01068ae@localhost>
Message-ID: <060.f8457f26fff2c2c74124bbff9373093a@localhost>

#2008: GHCi takes increasingly more memory
--------------------------+-------------------------------------------------
 Reporter:  NeilMitchell  |          Owner:             
     Type:  bug           |         Status:  new        
 Priority:  normal        |      Milestone:  6.10 branch
Component:  GHCi          |        Version:  6.9        
 Severity:  normal        |     Resolution:             
 Keywords:                |     Difficulty:  Unknown    
 Testcase:                |   Architecture:  Unknown    
       Os:  Windows       |  
--------------------------+-------------------------------------------------
Changes (by igloo):

  * milestone:  => 6.10 branch

Comment:

 After 5.5 hours, with GHC 6.8.2 and Windows XP, I see no difference in any
 of the virtual or physical memory figures in process explorer, or in the
 memory usage reported by task manager.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2008#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 19:51:46 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 19:45:49 2008
Subject: [GHC] #2003: The Data.Time.Format parser should be more liberal
In-Reply-To: <054.afa516df5a0125b80d39ff7f1a5eecb2@localhost>
References: <054.afa516df5a0125b80d39ff7f1a5eecb2@localhost>
Message-ID: <063.9d63aef6da00f71efdbdc718631178c3@localhost>

#2003: The Data.Time.Format parser should be more liberal
-------------------------------+--------------------------------------------
 Reporter:  BjornBuckwalter    |          Owner:         
     Type:  feature request    |         Status:  new    
 Priority:  normal             |      Milestone:  Not GHC
Component:  libraries (other)  |        Version:         
 Severity:  normal             |     Resolution:         
 Keywords:                     |     Difficulty:  Unknown
 Testcase:                     |   Architecture:  Unknown
       Os:  Unknown            |  
-------------------------------+--------------------------------------------
Changes (by igloo):

  * milestone:  => Not GHC

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2003#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 06:20:53 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 06:15:22 2008
Subject: [GHC] #2005: localhost on mac causes getnameinfo error in
 safari.
In-Reply-To: <043.2e0e6309ca162e2f7e3751b621e7afca@localhost>
References: <043.2e0e6309ca162e2f7e3751b621e7afca@localhost>
Message-ID: <052.7c9dbaf364a0353bb5b20f0549ed178c@localhost>

#2005: localhost on mac causes getnameinfo error in safari.
------------------------------------+---------------------------------------
 Reporter:  alex                    |          Owner:         
     Type:  bug                     |         Status:  new    
 Priority:  normal                  |      Milestone:  Not GHC
Component:  libraries/network       |        Version:  6.8.2  
 Severity:  normal                  |     Resolution:         
 Keywords:  network localhost ipv6  |     Difficulty:  Unknown
 Testcase:                          |   Architecture:  x86    
       Os:  MacOS X                 |  
------------------------------------+---------------------------------------
Changes (by igloo):

  * milestone:  6.8 branch => Not GHC

Comment:

 Ooops, milestone should be Not GHC as network isn't a bootlib.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2005#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 06:23:25 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 06:17:25 2008
Subject: [GHC] #2007: :main deals poorly with \escape characters
In-Reply-To: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
References: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
Message-ID: <060.3f91b0cd4927ee2fda4deb6b39eca120@localhost>

#2007: :main deals poorly with \escape characters
--------------------------+-------------------------------------------------
 Reporter:  NeilMitchell  |          Owner:             
     Type:  bug           |         Status:  new        
 Priority:  normal        |      Milestone:  6.10 branch
Component:  GHCi          |        Version:  6.9        
 Severity:  normal        |     Resolution:             
 Keywords:                |     Difficulty:  Unknown    
 Testcase:                |   Architecture:  Unknown    
       Os:  Unknown       |  
--------------------------+-------------------------------------------------
Comment (by igloo):

 `getArgs` would return `["foo", "bar"]` and `["bar", "foo", "foo bar"]`.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2007#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 07:10:20 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 07:04:30 2008
Subject: [GHC] #1845: unconditional relative branch out of range (GHC
 version 6.8.1 for powerpc_apple_darwin)
In-Reply-To: <044.65389402080b2ab045a1b2fde12245f8@localhost>
References: <044.65389402080b2ab045a1b2fde12245f8@localhost>
Message-ID: <053.b41eaeaabb6b3c68e61764ef855bbbec@localhost>

#1845: unconditional relative branch out of range (GHC version 6.8.1 for
powerpc_apple_darwin)
---------------------+------------------------------------------------------
 Reporter:  guest    |          Owner:  thorkilnaur
     Type:  bug      |         Status:  new        
 Priority:  normal   |      Milestone:  6.8.3      
Component:  GHCi     |        Version:  6.8.1      
 Severity:  normal   |     Resolution:             
 Keywords:           |     Difficulty:  Unknown    
 Testcase:           |   Architecture:  powerpc    
       Os:  MacOS X  |  
---------------------+------------------------------------------------------
Comment (by maeder):

 Just adding `-mlongcall` to `extra-gcc-opts` did not help. When trying to
 compile with

 {{{
 SRC_HC_OPTS += -fvia-C
 }}}

 in `mk/build.mk` I got the following error:

 {{{
  ../compiler/ghc-inplace -H16m -O -fvia-C -optc-O2 -package-name rts
 -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint     -c
 Apply.cmm -o Apply.o
 /tmp/ghc24169_0/ghc24169_0.s:unknown:Undefined local symbol
 L___DISCARD__$stub
 make[1]: *** [Apply.o] Error 1
 make: *** [stage1] Error 1
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1845#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 07:33:51 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 07:27:52 2008
Subject: [GHC] #1998: Stricter enumFrom instance for Integer,
 to match Int
In-Reply-To: <043.376380d7218ee2804ccca585f66a35df@localhost>
References: <043.376380d7218ee2804ccca585f66a35df@localhost>
Message-ID: <052.d74a25c5d8042c741247ce48e4e9d1e6@localhost>

#1998: Stricter enumFrom instance for Integer, to match Int
---------------------------------+------------------------------------------
 Reporter:  dons                 |          Owner:             
     Type:  bug                  |         Status:  closed     
 Priority:  normal               |      Milestone:  6.8.3      
Component:  libraries/base       |        Version:  6.8.2      
 Severity:  normal               |     Resolution:  duplicate  
 Keywords:  Integer, strictness  |     Difficulty:  Easy (1 hr)
 Testcase:                       |   Architecture:  Multiple   
       Os:  Multiple             |  
---------------------------------+------------------------------------------
Changes (by simonmar):

  * status:  new => closed
  * resolution:  => duplicate

Comment:

 #1997 is now a bug report, so closing this one.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1998#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 07:44:53 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 07:38:51 2008
Subject: [GHC] #2011: [6.8.1 regression] panic: lookupVers1 base:GHC.Prim
 sym{tc}
Message-ID: <047.5794bcb02e44dfb8bb70a89a113f27e3@localhost>

#2011: [6.8.1 regression] panic: lookupVers1 base:GHC.Prim sym{tc}
-------------------------+--------------------------------------------------
    Reporter:  simonmar  |       Owner:  simonpj
        Type:  bug       |      Status:  new    
    Priority:  high      |   Milestone:  6.8.3  
   Component:  Compiler  |     Version:  6.8.2  
    Severity:  normal    |    Keywords:         
  Difficulty:  Unknown   |    Testcase:         
Architecture:  Unknown   |          Os:  Unknown
-------------------------+--------------------------------------------------
 When rebuilding the base package you might encounter this:

 {{{
 ../../compiler/stage1/ghc-inplace -package-name base-3.0.1.0 -hide-all-
 packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build
 -Iinclude -#include "HsBase.h" -odir dist/build -hidir dist/build -stubdir
 dist/build -package rts-1.0 -O -fglasgow-exts -package-name base -XCPP
 -idist/build  -H16m -O -O -Rghc-timing -fgenerics -c
 Data/Generics/Twins.hs -o dist/build/Data/Generics/Twins.o  -ohi
 dist/build/Data/Generics/Twins.hi
 ghc-6.8.2: panic! (the 'impossible' happened)
   (GHC version 6.8.2 for powerpc-apple-darwin):
         lookupVers1 base:GHC.Prim sym{tc}
 }}}

 Workaround is to clean in `libraries/base`.

 The problem is that `MkIface.computeChangedOccs` needs to avoid wired-in
 names when checking version numbers, because wired-in names are never
 mentioned in usages.

 I believe simonpj has a patch for this in his working tree, we diagnosed
 it before disappearing for the Christmas period.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2011>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 07:54:01 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 07:48:09 2008
Subject: [GHC] #2012: compiling via-C does not work on ppc
Message-ID: <045.6ad3ccd84b7b179a5baec1657fb43453@localhost>

#2012: compiling via-C does not work on ppc
-------------------------+--------------------------------------------------
    Reporter:  maeder    |       Owner:         
        Type:  bug       |      Status:  new    
    Priority:  normal    |   Milestone:         
   Component:  Compiler  |     Version:  6.8.2  
    Severity:  normal    |    Keywords:         
  Difficulty:  Unknown   |    Testcase:         
Architecture:  powerpc   |          Os:  MacOS X
-------------------------+--------------------------------------------------
 building ghc-6.8.2 on ppc Mac OS X 10.4 (Tiger) with "`SRC_HC_OPTS +=
 -fvia-C`" (see #1845) yields:

 {{{
 ../compiler/ghc-inplace -H16m -O -fvia-C -keep-tmp-files -optc-O2
 -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h
 -dcmm-lint     -c Apply.cmm -o Apply.o
 /tmp/ghc24131_0/ghc24131_0.s:unknown:Undefined local symbol
 L___DISCARD__$stub
 make[1]: *** [Apply.o] Error 1
 make: *** [stage1] Error 1
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2012>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 08:54:15 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 08:48:14 2008
Subject: [GHC] #1509: Make unboxed tuples more supported
In-Reply-To: <044.1f30aaa9c80145fa2207f4959b5f6c5d@localhost>
References: <044.1f30aaa9c80145fa2207f4959b5f6c5d@localhost>
Message-ID: <053.b6f95c7ec34d45e37a514ce3898e8007@localhost>

#1509: Make unboxed tuples more supported
-----------------------------+----------------------------------------------
 Reporter:  guest            |          Owner:         
     Type:  feature request  |         Status:  new    
 Priority:  low              |      Milestone:  _|_    
Component:  Compiler         |        Version:  6.6.1  
 Severity:  minor            |     Resolution:         
 Keywords:                   |     Difficulty:  Unknown
 Testcase:                   |   Architecture:  Unknown
       Os:  Unknown          |  
-----------------------------+----------------------------------------------
Comment (by Isaac Dupree):

 Adding prefix-unboxed-tuples turned out to just require a parser
 modification -- for GHC at least, Data.Tuple only defines data types and
 constructors (and Eq,Ord... instances) of (boxed) tuples; unboxed tuples
 were already built-in, (or anyway my test passed and ran successfully
 after a simple parser addition).  see darcs patches on cvs-ghc list.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1509#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From Christian.Maeder at dfki.de  Wed Jan  2 09:39:36 2008
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Wed Jan  2 09:33:39 2008
Subject: Problem building hdbc-sqlite3 with ghc 6.8.2
In-Reply-To: <49E913CA-C853-451A-9E6C-FA460EFC6B39@citycampus.com>
References: <49E913CA-C853-451A-9E6C-FA460EFC6B39@citycampus.com>
Message-ID: <477BA228.9030406@dfki.de>

manu wrote:
> hello,
> 
> has anybody managed to build hdbc-sqlite3 with ghc 6.8.2 ?
> 
> I get the following error :
> 
> Macintosh:HDBC-sqlite3-1.1.3.0 manu$ runhaskell Setup.lhs build
> Preprocessing library HDBC-sqlite3-1.1.3.0...
> ghc-6.8.2: unrecognised flags: -F/Users/manu/Library/Frameworks
> Usage: For basic information, try the `--help' option.
> compiling dist/build/Database/HDBC/Sqlite3/Statement_hsc_make.c failed
> command was: /usr/local/bin/ghc -c -package base-3.0.1.0 -package
> mtl-1.1.0.0 -package HDBC-1.1.3 -I. -F/Users/manu/Library/Frameworks
> dist/build/Database/HDBC/Sqlite3/Statement_hsc_make.c -o
> dist/build/Database/HDBC/Sqlite3/Statement_hsc_make.o
> 
> 
> if somebody has an idea...

I seems you used my binary dist that I made with a modified
utils/hsc2hs/Main.hs
http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/13583
http://hackage.haskell.org/trac/ghc/ticket/1395

hsc2hs only worked for me when gcc was used instead ghc (when
bootstrapping ghc-6.8.2 itself). Maybe I should build new binary-dists.
Is it for ppc or x86?

Cheers Christian
From trac at galois.com  Wed Jan  2 10:24:16 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 10:18:30 2008
Subject: [GHC] #1395: let ./configure check for a GNUreadline framework
In-Reply-To: <052.068bc0f583c08a182f51a06ad4864715@localhost>
References: <052.068bc0f583c08a182f51a06ad4864715@localhost>
Message-ID: <061.312f7bafe14fca64aef2af819b46ec0c@localhost>

#1395: let ./configure check for a GNUreadline framework
-----------------------------+----------------------------------------------
 Reporter:  maeder@tzi.de    |          Owner:             
     Type:  feature request  |         Status:  reopened   
 Priority:  normal           |      Milestone:  6.8 branch 
Component:  Build System     |        Version:  6.8        
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by maeder):

 My modification of `utils/hsc2hs/Main.hs` (probably) caused the problem
 reported in
 http://article.gmane.org/gmane.comp.lang.haskell.cafe/34373

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1395#comment:25>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 10:51:21 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 10:45:20 2008
Subject: [GHC] #1997: Stricter enumFrom instance for Integer,
 to match Int
In-Reply-To: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost>
References: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost>
Message-ID: <052.f385347f924ca8f405f11443dedc8b2c@localhost>

#1997: Stricter enumFrom instance for Integer, to match Int
----------------------------+-----------------------------------------------
 Reporter:  dons            |          Owner:             
     Type:  bug             |         Status:  new        
 Priority:  normal          |      Milestone:  6.10 branch
Component:  libraries/base  |        Version:  6.8.2      
 Severity:  normal          |     Resolution:             
 Keywords:                  |     Difficulty:  Easy (1 hr)
 Testcase:                  |   Architecture:  Multiple   
       Os:  Multiple        |  
----------------------------+-----------------------------------------------
Changes (by simonmar):

  * milestone:  Not GHC => 6.10 branch

Comment:

 Note that this was reported already in #1097, but it got forgotten
 probably because it has a milestone of "Not GHC" and no deadline.

 The Haskell 98 report has a bug (already documented in
 [http://haskell.org/definition/haskell98-revised-bugs.html]) in that the
 reference implementation of the `Enum` class for `Float` and `Double` is
 lazy.

 I suggest we do as Don suggests, and make all the numeric types behave
 consistently with respect to strictness of `enumFrom*`.

 (re-milestoning to 6.10 so we don't forget)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1997#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 10:52:26 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 10:46:30 2008
Subject: [GHC] #1097: enumFrom on basic numeric types should be strict
In-Reply-To: <056.1ac69e07bac1f738b8d4a415ad25c1fe@localhost>
References: <056.1ac69e07bac1f738b8d4a415ad25c1fe@localhost>
Message-ID: <065.24356a806e861bec55adbb5bcb1f2a9b@localhost>

#1097: enumFrom on basic numeric types should be strict
-----------------------------------+----------------------------------------
 Reporter:  bdonlan@gmail.com      |          Owner:             
     Type:  bug                    |         Status:  closed     
 Priority:  normal                 |      Milestone:  Not GHC    
Component:  libraries/base         |        Version:  6.6        
 Severity:  minor                  |     Resolution:  duplicate  
 Keywords:  enum strictness        |     Difficulty:  Easy (1 hr)
 Testcase:  lib/should_run/enum04  |   Architecture:  Unknown    
       Os:  Unknown                |  
-----------------------------------+----------------------------------------
Changes (by simonmar):

  * status:  reopened => closed
  * resolution:  => duplicate

Comment:

 duplicated by #1997

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1097#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 10:52:43 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 10:46:42 2008
Subject: [GHC] #1997: Stricter enumFrom instance for Integer,
 to match Int
In-Reply-To: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost>
References: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost>
Message-ID: <052.5a08f63346b82362b028fb5c3d61d944@localhost>

#1997: Stricter enumFrom instance for Integer, to match Int
-----------------------------------+----------------------------------------
 Reporter:  dons                   |          Owner:             
     Type:  bug                    |         Status:  new        
 Priority:  normal                 |      Milestone:  6.10 branch
Component:  libraries/base         |        Version:  6.8.2      
 Severity:  normal                 |     Resolution:             
 Keywords:                         |     Difficulty:  Easy (1 hr)
 Testcase:  lib/should_run/enum04  |   Architecture:  Multiple   
       Os:  Multiple               |  
-----------------------------------+----------------------------------------
Changes (by simonmar):

  * testcase:  => lib/should_run/enum04

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1997#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 10:58:43 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 10:52:42 2008
Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out of
 range.
Message-ID: <044.2f007075e8a3e652be5aa7c77056c714@localhost>

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
-------------------------------+--------------------------------------------
    Reporter:  mboes           |       Owner:         
        Type:  bug             |      Status:  new    
    Priority:  normal          |   Milestone:         
   Component:  GHCi            |     Version:  6.8.1  
    Severity:  normal          |    Keywords:         
  Difficulty:  Unknown         |    Testcase:         
Architecture:  x86_64 (amd64)  |          Os:  FreeBSD
-------------------------------+--------------------------------------------
 On freebsd-7.0 I have a working ghc-6.8.2 bootstrapped from a ghc-6.6.1
 itself boostrapped from a 32-bit machine. I'd like to create a bindist for
 this platform, for which there are as yet no available binary distribution
 of ghc, but before that it would be nice if ghci worked. Currently I get
 the following error:

 {{{
 mboes@caracas:~/ > ghci
 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 ghc-6.8.2: internal error: R_X86_64_32S relocation out of range: (noname)
 = 0x802d779c0

     (GHC version 6.8.2 for x86_64_unknown_freebsd)
     Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug
 [1]    21394 abort      ghci
 }}}

 This bug has also been spotted before by [http://www.haskell.org/pipermail
 /cvs-ghc/2007-November/039305.html Tim Newsham] on ghc-6.8.1 on Freebsd-
 amd64 as well. Could this be related to #1562 or #1073 on Linux?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 11:23:58 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 11:17:57 2008
Subject: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic,
 panic!!!!
In-Reply-To: <057.ee3a70497de9cc3d83abf1aab5293225@localhost>
References: <057.ee3a70497de9cc3d83abf1aab5293225@localhost>
Message-ID: <066.07d870e20db951b837fd10f5445e77bf@localhost>

#1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!
-------------------------------------------------+--------------------------
 Reporter:  jvlask@hotmail.com                   |          Owner:  simonmar        
     Type:  bug                                  |         Status:  new             
 Priority:  normal                               |      Milestone:  6.8.3           
Component:  GHCi                                 |        Version:  6.6             
 Severity:  critical                             |     Resolution:                  
 Keywords:  ghci foreign ffi dll import stdcall  |     Difficulty:  Moderate (1 day)
 Testcase:                                       |   Architecture:  x86             
       Os:  Windows                              |  
-------------------------------------------------+--------------------------
Changes (by felixmar):

 * cc: fmartini@gmail.com (added)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1288#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 12:42:41 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 12:36:41 2008
Subject: [GHC] #2014: getLinkDeps panic
Message-ID: <043.959b8170a1a6ec2b7cea0d1cfc8fd3ff@localhost>

#2014: getLinkDeps panic
-------------------------+--------------------------------------------------
    Reporter:  fons      |       Owner:         
        Type:  bug       |      Status:  new    
    Priority:  normal    |   Milestone:         
   Component:  Compiler  |     Version:  6.8.2  
    Severity:  blocker   |    Keywords:         
  Difficulty:  Unknown   |    Testcase:         
Architecture:  Unknown   |          Os:  Unknown
-------------------------+--------------------------------------------------
 I am working on a project which uses mutually recursive modules and
 Template Haskell. Since "ghc --make" does not seem to figure out the
 dependencies properly in this case (see bug #1012) I gave Cabal's make
 backend a try without luck (I'm stuck again).

 The compilation results in:


 {{{
 /usr/local/bin/ghc -package-name ForSyDe-0.1 -hide-all-packages -i
 -idist/build/autogen -idist/build -isrc -Idist/build -odir dist/build
 -hidir dist/build -stubdir dist/build -package packedstring-0.1.0.0
 -package base-3.0.1.0 -package regex-posix-0.72.0.2 -package mtl-1.1.0.0
 -package pretty-1.0.0.0 -package template-haskell-2.2.0.0 -O -Wall -fno-
 warn-name-shadowing -fno-warn-orphans -idist/build  -c
 src/ForSyDe/Process/SynchProc.hs -o dist/build/ForSyDe/Process/SynchProc.o
 -ohi dist/build/ForSyDe/Process/SynchProc.hi
 Loading package base ... linking ... done.
 Loading package pretty-1.0.0.0 ... linking ... done.
 Loading package array-0.1.0.0 ... linking ... done.
 Loading package packedstring-0.1.0.0 ... linking ... done.
 Loading package containers-0.1.0.1 ... linking ... done.
 Loading package template-haskell ... linking ... done.
 Loading package mtl-1.1.0.0 ... linking ... done.
 Loading package bytestring-0.9.0.1 ... linking ... done.
 Loading package regex-base-0.72.0.1 ... linking ... done.
 Loading package regex-posix-0.72.0.2 ... linking ... done.
 ghc-6.8.2: panic! (the 'impossible' happened)
   (GHC version 6.8.2 for i386-apple-darwin):
         getLinkDeps No iface for ForSyDe-0.1:ForSyDe.System.SysDef

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

 make: *** [dist/build/ForSyDe/Process/SynchProc.o] Error 1
 }}}

 However, the interface file is available to ghc:


 {{{
 $ ls -l dist/build/ForSyDe/System/SysDef.hi
 -rw-r--r--  1 fons  staff  2225  2 ene 18:13
 dist/build/ForSyDe/System/SysDef.hi
 }}}

 Sorry, but I couldn't narrow down the problem. To reproduce it, simply
 download my library
 (http://homepage.mac.com/alfonso.acosta/.Public/ForSyDe.tgz ) and build
 using Cabal's make backend:


 {{{
 $ tar -xvzf ForSyDe.tgz; cd ForSyDe; ./Setup.hs configure; ./Setup.hs
 makefile; make
 }}}


 Curiously enough, building the library itself does not work but loading a
 test in ghci, works perfectly well and builds the whole library without
 problems:


 {{{
 $ cd ForSyDe/examples/ ; ghci -i../src ParAddFour.hs
 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 ... (vompilation skipped)
 Ok, modules loaded: ForSyDe, ParAddFour, ForSyDe.AbsentExt,
 Language.Haskell.TH.Lift, ForSyDe.Vector, ForSyDe.Backend,
 ForSyDe.Backend.Simulate, Language.Haskell.TH.TypeLib, ForSyDe.Process,
 ForSyDe.Process.ProcVal, ForSyDe.ForSyDeErr, ForSyDe.ForSyDeErr,
 ForSyDe.Netlist, ForSyDe.Process.ProcFun, ForSyDe.Process.ProcFun,
 Language.Haskell.TH.LiftInstances, ForSyDe.System, ForSyDe.System.SysDef,
 ForSyDe.System.SysDef, ForSyDe.OSharing, ForSyDe.OSharing.UDynamic,
 ForSyDe.System.SysFun, ForSyDe.Signal, ForSyDe.Netlist.Traverse,
 ForSyDe.System.Instantiate, ForSyDe.Process.SynchProc.
 *ParAddFour>
 }}}

 It is a major blocker for the project (I have been stuck for days). I hope
 you find appropiate that I tagged it as such.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2014>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 12:51:11 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 12:45:13 2008
Subject: [GHC] #1958: collect2: ld terminated with signal 10 [Bus
 error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of
 GHC 6.9
In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost>
References: <050.c31695132cb1b93380c95a8b6c208782@localhost>
Message-ID: <059.38760715a2080cff52726cac89a9d322@localhost>

#1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a
PPC Mac OS X 10.5 Leopard as part of GHC 6.9
-------------------------+--------------------------------------------------
 Reporter:  thorkilnaur  |          Owner:  thorkilnaur
     Type:  bug          |         Status:  new        
 Priority:  high         |      Milestone:  6.8.3      
Component:  Compiler     |        Version:  6.9        
 Severity:  normal       |     Resolution:             
 Keywords:               |     Difficulty:  Unknown    
 Testcase:               |   Architecture:  powerpc    
       Os:  MacOS X      |  
-------------------------+--------------------------------------------------
Comment (by thorkilnaur):

 Thanks a lot for this information. I would assume that the PPC Mac OS X
 Leopard builder fails to build stage 2 for the same reason
 (http://darcs.haskell.org/buildbot/all/tnaur%20PPC%20OSX%20head%202/builds/20
 /step-stage2/0):
 {{{
 /usr/bin/ld -r -x -o HSghc.o  stage2/basicTypes/BasicTypes.o
 stage2/basicTypes/DataCon.o stage2/basicTypes/Demand.o
 stage2/basicTypes/Id.o stage2/basicTypes/IdInfo.o
 stage2/basicTypes/Literal.o stage2/basicTypes/MkId.o
 stage2/basicTypes/Module.o stage2/basicTypes/Name.o
 stage2/basicTypes/NameEnv.o stage2/basicTypes/NameSet.o
 stage2/basicTypes/NewDemand.o stage2/basicTypes/OccName.o
 stage2/basicTypes/RdrName.o stage2/basicTypes/SrcLoc.o
 stage2/basicTypes/UniqSupply.o stage2/basicTypes/Unique.o
 stage2/basicTypes/Var.o stage2/basicTypes/VarEnv.o
 stage2/basicTypes/VarSet.o stage2/cmm/CLabel.o stage2/cmm/Cmm.o
 stage2/cmm/CmmBrokenBlock.o stage2/cmm/CmmCPS.o stage2/cmm/CmmCPSGen.o
 stage2/cmm/CmmCPSZ.o stage2/cmm/CmmCallConv.o stage2/cmm/CmmContFlowOpt.o
 stage2/cmm/CmmCvt.o stage2/cmm/CmmExpr.o stage2/cmm/CmmInfo.o
 stage2/cmm/CmmLex.o stage2/cmm/CmmLint.o stage2/cmm/CmmLive.o
 stage2/cmm/CmmLiveZ.o stage2/cmm/CmmOpt.o stage2/cmm/CmmParse.o
 stage2/cmm/CmmProcPoint.o stage2/cmm/CmmProcPointZ.o
 stage2/cmm/CmmSpillReload.o stage2/cmm/CmmTx.o stage2/cmm/CmmUtils.o
 stage2/cmm/CmmZipUtil.o stage2/cmm/DFMonad.o stage2/cmm/Dataflow.o
 stage2/cmm/MachOp.o stage2/cmm/MkZipCfg.o stage2/cmm/MkZipCfgCmm.o
 stage2/cmm/OptimizationFuel.o stage2/cmm/PprC.o stage2/cmm/PprCmm.o
 stage2/cmm/PprCmmZ.o stage2/cmm/StackColor.o stage2/cmm/StackPlacements.o
 stage2/cmm/ZipCfg.o stage2/cmm/ZipCfgCmmRep.o stage2/cmm/ZipCfgExtras.o
 stage2/cmm/ZipDataflow0.o stage2/codeGen/Bitmap.o
 stage2/codeGen/CgBindery.o stage2/codeGen/CgCallConv.o
 stage2/codeGen/CgCase.o stage2/codeGen/CgClosure.o stage2/codeGen/CgCon.o
 stage2/codeGen/CgExpr.o stage2/codeGen/CgForeignCall.o
 stage2/codeGen/CgHeapery.o stage2/codeGen/CgHpc.o
 stage2/codeGen/CgInfoTbls.o stage2/codeGen/CgLetNoEscape.o
 stage2/codeGen/CgMonad.o stage2/codeGen/CgParallel.o
 stage2/codeGen/CgPrimOp.o stage2/codeGen/CgProf.o
 stage2/codeGen/CgStackery.o stage2/codeGen/CgTailCall.o
 stage2/codeGen/CgTicky.o stage2/codeGen/CgUtils.o
 stage2/codeGen/ClosureInfo.o stage2/codeGen/CodeGen.o
 stage2/codeGen/SMRep.o stage2/coreSyn/CoreFVs.o stage2/coreSyn/CoreLint.o
 stage2/coreSyn/CorePrep.o stage2/coreSyn/CoreSubst.o
 stage2/coreSyn/CoreSyn.o stage2/coreSyn/CoreTidy.o
 stage2/coreSyn/CoreUnfold.o stage2/coreSyn/CoreUtils.o
 stage2/coreSyn/ExternalCore.o stage2/coreSyn/MkExternalCore.o
 stage2/coreSyn/PprCore.o stage2/coreSyn/PprExternalCore.o
 stage2/cprAnalysis/CprAnalyse.o stage2/deSugar/Check.o
 stage2/deSugar/Coverage.o stage2/deSugar/Desugar.o
 stage2/deSugar/DsArrows.o stage2/deSugar/DsBinds.o
 stage2/deSugar/DsCCall.o stage2/deSugar/DsExpr.o
 stage2/deSugar/DsForeign.o stage2/deSugar/DsGRHSs.o
 stage2/deSugar/DsListComp.o stage2/deSugar/DsMeta.o
 stage2/deSugar/DsMonad.o stage2/deSugar/DsUtils.o stage2/deSugar/Match.o
 stage2/deSugar/MatchCon.o stage2/deSugar/MatchLit.o
 stage2/ghci/ByteCodeAsm.o stage2/ghci/ByteCodeFFI.o
 stage2/ghci/ByteCodeGen.o stage2/ghci/ByteCodeInstr.o
 stage2/ghci/ByteCodeItbls.o stage2/ghci/ByteCodeLink.o
 stage2/ghci/Debugger.o stage2/ghci/GhciMonad.o stage2/ghci/GhciTags.o
 stage2/ghci/InteractiveUI.o stage2/ghci/Linker.o stage2/ghci/ObjLink.o
 stage2/ghci/RtClosureInspect.o stage2/hsSyn/Convert.o
 stage2/hsSyn/HsBinds.o stage2/hsSyn/HsDecls.o stage2/hsSyn/HsDoc.o
 stage2/hsSyn/HsExpr.o stage2/hsSyn/HsImpExp.o stage2/hsSyn/HsLit.o
 stage2/hsSyn/HsPat.o stage2/hsSyn/HsSyn.o stage2/hsSyn/HsTypes.o
 stage2/hsSyn/HsUtils.o stage2/iface/BinIface.o stage2/iface/BuildTyCl.o
 stage2/iface/IfaceEnv.o stage2/iface/IfaceSyn.o stage2/iface/IfaceType.o
 stage2/iface/LoadIface.o stage2/iface/MkIface.o stage2/iface/TcIface.o
 stage2/main/BreakArray.o stage2/main/CmdLineParser.o
 stage2/main/CodeOutput.o stage2/main/Config.o stage2/main/Constants.o
 stage2/main/DriverMkDepend.o stage2/main/DriverPhases.o
 stage2/main/DriverPipeline.o stage2/main/DynFlags.o stage2/main/ErrUtils.o
 stage2/main/Finder.o stage2/main/GHC.o stage2/main/HeaderInfo.o
 stage2/main/HscMain.o stage2/main/HscStats.o stage2/main/HscTypes.o
 stage2/main/InteractiveEval.o stage2/main/PackageConfig.o
 stage2/main/Packages.o stage2/main/ParsePkgConf.o stage2/main/PprTyThing.o
 stage2/main/StaticFlags.o stage2/main/SysTools.o stage2/main/TidyPgm.o
 stage2/nativeGen/AsmCodeGen.o stage2/nativeGen/MachCodeGen.o
 stage2/nativeGen/MachInstrs.o stage2/nativeGen/MachRegs.o
 stage2/nativeGen/NCGMonad.o stage2/nativeGen/PositionIndependentCode.o
 stage2/nativeGen/PprMach.o stage2/nativeGen/RegAllocColor.o
 stage2/nativeGen/RegAllocInfo.o stage2/nativeGen/RegAllocLinear.o
 stage2/nativeGen/RegAllocStats.o stage2/nativeGen/RegArchBase.o
 stage2/nativeGen/RegArchX86.o stage2/nativeGen/RegCoalesce.o
 stage2/nativeGen/RegLiveness.o stage2/nativeGen/RegSpill.o
 stage2/nativeGen/RegSpillClean.o stage2/nativeGen/RegSpillCost.o
 stage2/ndpFlatten/FlattenInfo.o stage2/ndpFlatten/FlattenMonad.o
 stage2/ndpFlatten/Flattening.o stage2/ndpFlatten/NDPCoreUtils.o
 stage2/ndpFlatten/PArrAnal.o stage2/parser/Ctype.o
 stage2/parser/HaddockLex.o stage2/parser/HaddockParse.o
 stage2/parser/HaddockUtils.o stage2/parser/LexCore.o stage2/parser/Lexer.o
 stage2/parser/Parser.o stage2/parser/ParserCore.o
 stage2/parser/ParserCoreUtils.o stage2/parser/RdrHsSyn.o
 stage2/prelude/ForeignCall.o stage2/prelude/PrelInfo.o
 stage2/prelude/PrelNames.o stage2/prelude/PrelRules.o
 stage2/prelude/PrimOp.o stage2/prelude/TysPrim.o
 stage2/prelude/TysWiredIn.o stage2/profiling/CostCentre.o
 stage2/profiling/SCCfinal.o stage2/rename/RnBinds.o stage2/rename/RnEnv.o
 stage2/rename/RnExpr.o stage2/rename/RnHsDoc.o stage2/rename/RnHsSyn.o
 stage2/rename/RnNames.o stage2/rename/RnPat.o stage2/rename/RnSource.o
 stage2/rename/RnTypes.o stage2/simplCore/CSE.o stage2/simplCore/FloatIn.o
 stage2/simplCore/FloatOut.o stage2/simplCore/LiberateCase.o
 stage2/simplCore/OccurAnal.o stage2/simplCore/SAT.o
 stage2/simplCore/SATMonad.o stage2/simplCore/SetLevels.o
 stage2/simplCore/SimplCore.o stage2/simplCore/SimplEnv.o
 stage2/simplCore/SimplMonad.o stage2/simplCore/SimplUtils.o
 stage2/simplCore/Simplify.o stage2/simplStg/SRT.o
 stage2/simplStg/SimplStg.o stage2/simplStg/StgStats.o
 stage2/specialise/Rules.o stage2/specialise/SpecConstr.o
 stage2/specialise/Specialise.o stage2/stgSyn/CoreToStg.o
 stage2/stgSyn/StgLint.o stage2/stgSyn/StgSyn.o stage2/stranal/DmdAnal.o
 stage2/stranal/SaAbsInt.o stage2/stranal/SaLib.o
 stage2/stranal/StrictAnal.o stage2/stranal/WorkWrap.o
 stage2/stranal/WwLib.o stage2/typecheck/FamInst.o stage2/typecheck/Inst.o
 stage2/typecheck/TcArrows.o stage2/typecheck/TcBinds.o
 stage2/typecheck/TcClassDcl.o stage2/typecheck/TcDefaults.o
 stage2/typecheck/TcDeriv.o stage2/typecheck/TcEnv.o
 stage2/typecheck/TcExpr.o stage2/typecheck/TcForeign.o
 stage2/typecheck/TcGadt.o stage2/typecheck/TcGenDeriv.o
 stage2/typecheck/TcHsSyn.o stage2/typecheck/TcHsType.o
 stage2/typecheck/TcInstDcls.o stage2/typecheck/TcMType.o
 stage2/typecheck/TcMatches.o stage2/typecheck/TcPat.o
 stage2/typecheck/TcRnDriver.o stage2/typecheck/TcRnMonad.o
 stage2/typecheck/TcRnTypes.o stage2/typecheck/TcRules.o
 stage2/typecheck/TcSimplify.o stage2/typecheck/TcSplice.o
 stage2/typecheck/TcTyClsDecls.o stage2/typecheck/TcTyDecls.o
 stage2/typecheck/TcTyFuns.o stage2/typecheck/TcType.o
 stage2/typecheck/TcUnify.o stage2/types/Class.o stage2/types/Coercion.o
 stage2/types/FamInstEnv.o stage2/types/FunDeps.o stage2/types/Generics.o
 stage2/types/InstEnv.o stage2/types/TyCon.o stage2/types/Type.o
 stage2/types/TypeRep.o stage2/types/Unify.o stage2/utils/Bag.o
 stage2/utils/Binary.o stage2/utils/BufWrite.o stage2/utils/Digraph.o
 stage2/utils/Encoding.o stage2/utils/FastMutInt.o
 stage2/utils/FastString.o stage2/utils/FastTypes.o
 stage2/utils/FiniteMap.o stage2/utils/GraphBase.o
 stage2/utils/GraphColor.o stage2/utils/GraphOps.o stage2/utils/GraphPpr.o
 stage2/utils/IOEnv.o stage2/utils/Interval.o stage2/utils/ListSetOps.o
 stage2/utils/Maybes.o stage2/utils/OrdList.o stage2/utils/Outputable.o
 stage2/utils/Panic.o stage2/utils/Pretty.o stage2/utils/State.o
 stage2/utils/StringBuffer.o stage2/utils/UniqFM.o stage2/utils/UniqSet.o
 stage2/utils/Util.o stage2/vectorise/VectBuiltIn.o
 stage2/vectorise/VectCore.o stage2/vectorise/VectMonad.o
 stage2/vectorise/VectType.o stage2/vectorise/VectUtils.o
 stage2/vectorise/Vectorise.o stage2/parser/cutils.o
 make[1]: *** [HSghc.o] Bus error
 make[1]: *** Deleting file `HSghc.o'
 make: *** [stage2] Error 2
 }}}
 I have looked a bit more into this and still believe that it is a Leopard
 ld problem. Although I am not able to understand what goes on with the
 failing PPC code in detail, I am a bit concerned about the use of an
 expression that subtracts a {{{.text}}} section relocatable symbol from a
 {{{.const_data}}} section relocatable symbol: The Apple Assembler
 documentation seems to suggest that this is invalid (see section headed
 "Relocatable Expressions" in
 http://developer.apple.com/documentation/DeveloperTools/Reference/Assembler/Assembler.pdf).

 Although I am not sure of the difference between {{{.const_data}}} and
 {{{.text}}}, I tried to change the code generator to replace
 {{{.const_data}}} sections with {{{.text}}} sections as indicated in the
 attached patch. The resulting compiler is able to pass the sore spots
 encountered earlier. It is also able to pass validate with relatively few
 errors reported, but I am not sure that this is particularly significant.
 For completion, the errors reported are
 {{{
 OVERALL SUMMARY for test run started at Wed Jan  2 09:53:41 CET 2008
     2051 total tests, which gave rise to
     7771 test cases, of which
        1 caused framework failures
     6026 were skipped

     1666 expected passes
       76 expected failures
        0 unexpected passes
        3 unexpected failures

 Unexpected failures:
    currentDirectory001(normal)
    directory001(normal)
    ghci024(ghci)
 }}}
 but I don't believe that they are relevant to this issue.

 Suggestions for further investigation are most welcome.

 Best regards
 Thorkil

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1958#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 00:24:31 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 00:18:28 2008
Subject: [GHC] #1944: round function causes cblas NaNs
In-Reply-To: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost>
References: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost>
Message-ID: <061.f54eb299fa7b34606bb9b9659be532fb@localhost>

#1944: round function causes cblas NaNs
---------------------------+------------------------------------------------
 Reporter:  SevenThunders  |          Owner:         
     Type:  bug            |         Status:  new    
 Priority:  normal         |      Milestone:  6.8.3  
Component:  Compiler       |        Version:  6.8.1  
 Severity:  critical       |     Resolution:         
 Keywords:                 |     Difficulty:  Unknown
 Testcase:                 |   Architecture:  x86    
       Os:  Windows        |  
---------------------------+------------------------------------------------
Comment (by SevenThunders):

 I have tested this bug now with an entirely different cblas, namely the
 acml library distributed by AMD.  Although my simplified test case
 compiles and runs correctly for the acml library, when the library is
 linked against my complex numerical application, NaNs proliferate
 everywhere in ghc 6.8.2.  This happens for both the single and multiple
 threaded cblas code.  Hopefully I won't need to generate a test case for
 the acml library.

 If I compile it with ghc 6.6.1 it works fine.  I'd say this is a pretty
 serious bug and I'm surprised that it hasn't appeared in other
 applications and other bug reports.  I simply would not trust any external
 floating point library that has been linked into ghc 6.8.2.  I've
 replicated the bug now on two different windows machines, one AMD and one
 core duo, and with three different cblas libraries.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1944#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 04:49:28 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 04:43:25 2008
Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out
 of range.
In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
References: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
Message-ID: <053.c25ead2b8d94adc0b23e55139b501898@localhost>

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
---------------------+------------------------------------------------------
 Reporter:  mboes    |          Owner:                
     Type:  bug      |         Status:  new           
 Priority:  normal   |      Milestone:  6.8.3         
Component:  GHCi     |        Version:  6.8.1         
 Severity:  normal   |     Resolution:                
 Keywords:           |     Difficulty:  Unknown       
 Testcase:           |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD  |  
---------------------+------------------------------------------------------
Changes (by simonmar):

  * milestone:  => 6.8.3

Comment:

 Could you link the stage 2 compiler with -debug:
 {{{
 $ cd compiler
 $ rm stage2/ghc-6.9*
 $ make stage=2 EXTRA_HC_OPTS=-debug
 }}}
 and then capture the linker debugging output:
 {{{
 $ ./stage2/ghc-inplace +RTS -Dl 2>&1 | tee log
 }}}

 this should help track down the problem.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 05:14:31 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 05:08:28 2008
Subject: [GHC] #1012: ghc panic with mutually recursive modules and
 template haskell
In-Reply-To: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
References: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
Message-ID: <053.f322183d6818d89f7ed3207438522025@localhost>

#1012: ghc panic with mutually recursive modules and template haskell
------------------------------+---------------------------------------------
 Reporter:  guest             |          Owner:          
     Type:  bug               |         Status:  reopened
 Priority:  normal            |      Milestone:  _|_     
Component:  Template Haskell  |        Version:  6.8.2   
 Severity:  normal            |     Resolution:          
 Keywords:                    |     Difficulty:  Unknown 
 Testcase:  TH_import_loop    |   Architecture:  Multiple
       Os:  Multiple          |  
------------------------------+---------------------------------------------
Comment (by simonmar):

 Since `ModuleB` is outside the `ModuleA/ModuleC` loop, it can import
 `ModuleA` without creating any new loops, and I bet this will work around
 the problem and get you unblocked.

 What's happening is that the dependency analysis isn't figuring out that
 the real `ModuleA` must be compiled before `ModuleB`.  I think the
 solution is something along the lines of: every module that depends on a
 module in a cycle, but is not a member of that cycle, should have an
 implicit dependency on each of the modules in the cycle.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1012#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 05:15:00 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 05:08:57 2008
Subject: [GHC] #1012: ghc panic with mutually recursive modules and
 template haskell
In-Reply-To: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
References: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
Message-ID: <053.440a1471d4abb689abee79a7cca4ac15@localhost>

#1012: ghc panic with mutually recursive modules and template haskell
------------------------------+---------------------------------------------
 Reporter:  guest             |          Owner:            
     Type:  bug               |         Status:  reopened  
 Priority:  normal            |      Milestone:  6.8 branch
Component:  Template Haskell  |        Version:  6.8.2     
 Severity:  normal            |     Resolution:            
 Keywords:                    |     Difficulty:  Unknown   
 Testcase:  TH_import_loop    |   Architecture:  Multiple  
       Os:  Multiple          |  
------------------------------+---------------------------------------------
Changes (by simonmar):

  * milestone:  _|_ => 6.8 branch

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1012#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 05:50:43 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 05:44:40 2008
Subject: [GHC] #1944: round function causes cblas NaNs
In-Reply-To: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost>
References: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost>
Message-ID: <061.9bbe4b4db9ba6c4e5e64eceb26a7bb9d@localhost>

#1944: round function causes cblas NaNs
---------------------------+------------------------------------------------
 Reporter:  SevenThunders  |          Owner:         
     Type:  bug            |         Status:  new    
 Priority:  normal         |      Milestone:  6.8.3  
Component:  Compiler       |        Version:  6.8.1  
 Severity:  critical       |     Resolution:         
 Keywords:                 |     Difficulty:  Unknown
 Testcase:                 |   Architecture:  x86    
       Os:  Windows        |  
---------------------------+------------------------------------------------
Comment (by simonmar):

 Presumably something in the floating-point unit state is changing in a way
 that upsets the code in the cblas library.  I don't know of anything that
 could cause this; the native code generator does in one place generate
 code that saves and restores the FPU control word, but that was added in
 6.8.2 (see #1910).

 To proceed we really need to know what is changing in the FPU state, so
 that we can trace it back to the point at which it changed.  At the very
 least, we need a reproducible test case.  I downloaded your files and
 tried it, but it looks like I have a DLL missing:

 {{{
 c:\builds\atlas\Test2>maketest

 c:\builds\atlas\Test2>set CLIB=atlas

 c:\builds\atlas\Test2>set TopFile=Test2

 c:\builds\atlas\Test2>set csrc=ctest2.c

 c:\builds\atlas\Test2>set OutFile=Test2.exe

 c:\builds\atlas\Test2>dlltool.exe -D atlas.dll -l atlas.lib

 c:\builds\atlas\Test2>set XFLAGS=-threaded -O -XForeignFunctionInterface

 c:\builds\atlas\Test2>rem set XFLAGS=-threaded -O -fffi

 c:\builds\atlas\Test2>ghc -threaded -O -XForeignFunctionInterface -I.
 -I..\matri
 xstack --make Test2.hs ctest2.c -o Test2.exe -optl-latlas -optl-L"."
 [1 of 1] Compiling Main             ( Test2.hs, Test2.o )
 Linking Test2.exe ...

 c:\builds\atlas\Test2>Test2

 c:\builds\atlas\Test2>dir
  Volume in drive C has no label.
  Volume Serial Number is 6041-4C23

  Directory of c:\builds\atlas\Test2

 03/01/2008  10:38    <DIR>          .
 03/01/2008  10:38    <DIR>          ..
 29/11/2007  02:28         5,485,456 atlas.dll
 03/01/2008  10:38             1,490 atlas.lib
 29/11/2007  02:28               547 ctest2.c
 29/11/2007  02:28               721 ctest2.h
 03/01/2008  10:38               849 ctest2.o
 03/01/2008  10:37               433 index.html
 29/11/2007  02:28               309 maketest.bat
 03/01/2008  10:38           687,370 Test2.exe
 03/01/2008  10:38               502 Test2.exe.manifest
 03/01/2008  10:38             1,913 Test2.hi
 29/11/2007  02:28               178 Test2.hs
 03/01/2008  10:38             4,920 Test2.o
               12 File(s)      6,184,688 bytes
                2 Dir(s)  47,145,406,464 bytes free

 c:\builds\atlas\Test2>Test2.exe

 c:\builds\atlas\Test2>
 }}}

 Using dependency walker it looks like I don't have "MSJAVA.DLL".  Although
 why I need that, I have no idea.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1944#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 06:32:04 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 06:26:02 2008
Subject: [GHC] #1898: segfault with +RTS -N2 (related to tryTakeMVar?)
In-Reply-To: <049.0881d74ddf1057ac706f274f5a37f964@localhost>
References: <049.0881d74ddf1057ac706f274f5a37f964@localhost>
Message-ID: <058.f150b32790ec522197d75a0b0833b722@localhost>

#1898: segfault with +RTS -N2 (related to tryTakeMVar?)
------------------------+---------------------------------------------------
 Reporter:  j.waldmann  |          Owner:  simonmar
     Type:  bug         |         Status:  new     
 Priority:  high        |      Milestone:  6.8.3   
Component:  Compiler    |        Version:  6.8.1   
 Severity:  normal      |     Resolution:          
 Keywords:              |     Difficulty:  Unknown 
 Testcase:              |   Architecture:  x86     
       Os:  Linux       |  
------------------------+---------------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar

Comment:

 I'm testing a fix for this.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1898#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From Christian.Maeder at dfki.de  Thu Jan  3 08:41:56 2008
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Thu Jan  3 08:35:53 2008
Subject: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
Message-ID: <477CE624.3040806@dfki.de>

Hi Ian,

Judah's framework (2342543 Bytes)
http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip

should replace (my old one)
http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip

as described in http://hackage.haskell.org/trac/ghc/ticket/1931

I've also a copy at
http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/GNUreadline-framework.zip

Cheers Christian

(only the header files are different to allow inclusion via the -F flag
to gcc on Macs)
From trac at galois.com  Thu Jan  3 09:14:55 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 09:08:51 2008
Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out
 of range.
In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
References: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
Message-ID: <053.31a58b088eba2d0c8bac24ec00587536@localhost>

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
---------------------+------------------------------------------------------
 Reporter:  mboes    |          Owner:                
     Type:  bug      |         Status:  new           
 Priority:  normal   |      Milestone:  6.8.3         
Component:  GHCi     |        Version:  6.8.1         
 Severity:  normal   |     Resolution:                
 Keywords:           |     Difficulty:  Unknown       
 Testcase:           |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD  |  
---------------------+------------------------------------------------------
Comment (by mboes):

 Debug output of
 {{{
 ./stage2/ghc-inplace --interactive +RTS -Dl 2>&1 | tee log
 }}}
 is at [http://code.haskell.org/~mboes/log.bz2] (log too big for attachment
 on trac).

 Note that FreeBSD, just like OpenBSD, does not define MAP_32BIT and
 MAP_ANONYMOUS. I see in Linker.c the following #define:
 {{{
 #if defined(x86_64_HOST_ARCH) && defined(MAP_32BIT)
 #define EXTRA_MAP_FLAGS MAP_32BIT
 #else
 #define EXTRA_MAP_FLAGS 0
 #endif
 }}}

 But then I see an attempt to resolve symbols allocated in high memory
 using a bounce sequence:
 {{{
 // On x86_64, 32-bit relocations are often used, which requires that
 // we can resolve a symbol to a 32-bit offset.  However, shared
 // libraries are placed outside the 2Gb area, which leaves us with a
 // problem when we need to give a 32-bit offset to a symbol in a
 // shared library.
 //
 // For a function symbol, we can allocate a bounce sequence inside the
 // 2Gb area and resolve the symbol to this.  The bounce sequence is
 // simply a long jump instruction to the real location of the symbol.
 //
 // For data references, we're screwed.
 //
 ...
 static void*
 x86_64_high_symbol( char *lbl, void *addr )
 {
     x86_64_bounce *bounce;

     if ( x86_64_bounce_buffer == NULL ||
          x86_64_bb_next_off >= X86_64_BB_SIZE ) {
         x86_64_bounce_buffer =
             mmap(NULL, X86_64_BB_SIZE * sizeof(x86_64_bounce),
                  PROT_EXEC|PROT_READ|PROT_WRITE,
                  MAP_PRIVATE|EXTRA_MAP_FLAGS|MAP_ANONYMOUS, -1, 0);
         if (x86_64_bounce_buffer == MAP_FAILED) {
             barf("x86_64_high_symbol: mmap failed");
         }
         x86_64_bb_next_off = 0;
     }
 ...
 }}}

 Since there is no MAP_32BIT on FreeBSD it would seem the above bounce
 sequence can get arbitrarily allocated in high memory. Could this be the
 problem? I'm way out of my depth here, so please forgive the daftness of
 this question, but on my system there are no 32bit libraries at all, only
 64bit ones. Hence, could we do away with 32bit relocations entirely?

 Hope this helps,

 Mathieu

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 09:40:40 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 09:35:15 2008
Subject: [GHC] #1999: panic with GADT etc.
In-Reply-To: <046.74c6dc616261a913ffd4180fb00731f0@localhost>
References: <046.74c6dc616261a913ffd4180fb00731f0@localhost>
Message-ID: <055.c0cfc2eb05633a1f914507479d03ad0c@localhost>

#1999: panic with GADT etc.
----------------------+-----------------------------------------------------
 Reporter:  jeltsch   |          Owner:  chak       
     Type:  bug       |         Status:  new        
 Priority:  normal    |      Milestone:  6.10 branch
Component:  Compiler  |        Version:  6.9        
 Severity:  normal    |     Resolution:             
 Keywords:            |     Difficulty:  Unknown    
 Testcase:            |   Architecture:  x86        
       Os:  Linux     |  
----------------------+-----------------------------------------------------
Changes (by simonpj):

  * owner:  => chak

Comment:

 However, it may well not work in the HEAD, where Manuel is busy ripping
 out the old implementation of GADTs, in favour of the new type-function-
 based machinery.

 So I'm assigning this to Manuel; it'd be good to make a test case out of
 it too.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1999#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 10:03:28 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 09:57:24 2008
Subject: [GHC] #1898: segfault with +RTS -N2 (related to tryTakeMVar?)
In-Reply-To: <049.0881d74ddf1057ac706f274f5a37f964@localhost>
References: <049.0881d74ddf1057ac706f274f5a37f964@localhost>
Message-ID: <058.e0ac528ea5bf2ae51eb0fe33245137bd@localhost>

#1898: segfault with +RTS -N2 (related to tryTakeMVar?)
------------------------+---------------------------------------------------
 Reporter:  j.waldmann  |          Owner:  igloo  
     Type:  merge       |         Status:  new    
 Priority:  high        |      Milestone:  6.8.3  
Component:  Compiler    |        Version:  6.8.1  
 Severity:  normal      |     Resolution:         
 Keywords:              |     Difficulty:  Unknown
 Testcase:              |   Architecture:  x86    
       Os:  Linux       |  
------------------------+---------------------------------------------------
Changes (by simonmar):

  * owner:  simonmar => igloo
  * type:  bug => merge

Comment:

 Fixed:
 {{{
 Thu Jan  3 03:27:17 PST 2008  Simon Marlow <simonmar@microsoft.com>
   * FIX #1898: add a missing UNTAG_CLOSURE() in checkBlackHoles
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1898#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From igloo at earth.li  Thu Jan  3 10:18:43 2008
From: igloo at earth.li (Ian Lynagh)
Date: Thu Jan  3 10:12:44 2008
Subject: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
In-Reply-To: <477CE624.3040806@dfki.de>
References: <477CE624.3040806@dfki.de>
Message-ID: <20080103151843.GA15045@matrix.chaos.earth.li>


Hi Christian,

On Thu, Jan 03, 2008 at 02:41:56PM +0100, Christian Maeder wrote:
> 
> Judah's framework (2342543 Bytes)
> http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip
> 
> should replace (my old one)
> http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip

Done!


Thanks
Ian

From trac at galois.com  Thu Jan  3 10:19:39 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 10:13:36 2008
Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern
 checking
In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@localhost>
References: <047.bea78f01cbb904765ad77c751bc8d3af@localhost>
Message-ID: <056.856d99077c5d941618f0e4c8df60628d@localhost>

#595: Overhaul GHC's overlapping/non-exhaustive pattern checking
----------------------+-----------------------------------------------------
 Reporter:  simonmar  |          Owner:                    
     Type:  task      |         Status:  new               
 Priority:  normal    |      Milestone:  _|_               
Component:  Compiler  |        Version:  None              
 Severity:  normal    |     Resolution:  None              
 Keywords:  warnings  |     Difficulty:  Difficult (1 week)
 Testcase:  N/A       |   Architecture:  Unknown           
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Comment (by simonpj):

 And #2006

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/595#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 10:20:26 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 10:14:24 2008
Subject: [GHC] #2006: unreachable GADT pattern clauses show up as
 warnings with -Wall
In-Reply-To: <044.a004885c928a62e2a73bf12df457c462@localhost>
References: <044.a004885c928a62e2a73bf12df457c462@localhost>
Message-ID: <053.451e4e7cb7965e956e88252b9a4f7f5e@localhost>

#2006: unreachable GADT pattern clauses show up as warnings with -Wall
----------------------+-----------------------------------------------------
 Reporter:  ryani     |          Owner:             
     Type:  bug       |         Status:  new        
 Priority:  normal    |      Milestone:  6.10 branch
Component:  Compiler  |        Version:  6.8.1      
 Severity:  normal    |     Resolution:             
 Keywords:            |     Difficulty:  Unknown    
 Testcase:            |   Architecture:  Unknown    
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by simonpj):

  * milestone:  6.8 branch => 6.10 branch

Comment:

 Quite right.  The "non-exhaustive pattern" warning comes from a part of
 the compiler that needs a serious overhaul.  See #595.  In particular,
 it's utterly unaware of GADTs, so it's going to produce spurious warnings,
 and will continue to do so until it is overhauled.

 We definitely won't fix this on the 6.8 branch.  Probably it needs a
 volunteer.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2006#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 11:03:28 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 10:57:24 2008
Subject: [GHC] #2000: -funfolding-update-in-place badly documented
In-Reply-To: <045.ac76dc598481f3a493531a6d155a8b48@localhost>
References: <045.ac76dc598481f3a493531a6d155a8b48@localhost>
Message-ID: <054.7889f75585f24f40040b93548112ca64@localhost>

#2000: -funfolding-update-in-place badly documented
----------------------+-----------------------------------------------------
 Reporter:  m4dc4p    |          Owner:  igloo  
     Type:  merge     |         Status:  new    
 Priority:  normal    |      Milestone:  6.8.3  
Component:  Compiler  |        Version:  6.8.1  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  x86    
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Changes (by simonpj):

  * type:  bug => merge

Comment:

 It's an obsolete flag that does nothing.  I'll remove the documentation:
 {{{
 Thu Jan  3 16:00:36 GMT 2008  simonpj@microsoft.com
   * Remove -funfolding-update-in-place flag documentation
 }}}
 Merge to 6.8 branch, pls.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2000#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 11:18:11 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 11:12:09 2008
Subject: [GHC] #2011: [6.8.1 regression] panic: lookupVers1
 base:GHC.Prim sym{tc}
In-Reply-To: <047.5794bcb02e44dfb8bb70a89a113f27e3@localhost>
References: <047.5794bcb02e44dfb8bb70a89a113f27e3@localhost>
Message-ID: <056.f0caab7bc45b9f30f833a81592425da5@localhost>

#2011: [6.8.1 regression] panic: lookupVers1 base:GHC.Prim sym{tc}
----------------------+-----------------------------------------------------
 Reporter:  simonmar  |          Owner:  igloo  
     Type:  merge     |         Status:  new    
 Priority:  high      |      Milestone:  6.8.3  
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  Unknown
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by simonpj):

  * owner:  simonpj => igloo
  * type:  bug => merge

Comment:

 The patch is this one.  Ian, please merge to 6.8 branch.
 {{{
 Thu Dec 20 16:43:07 GMT 2007  simonpj@microsoft.com
   * Fix nasty recompilation bug in MkIface.computeChangedOccs

         MERGE to 6.8 branch

   In computeChangedOccs we look up the old version of a Name.
   But a WiredIn Name doesn't have an old version, because WiredIn things
   don't appear in interface files at all.

   Result: ghc-6.9: panic! (the 'impossible' happened)
     (GHC version 6.9 for x86_64-unknown-linux):
         lookupVers1 base:GHC.Prim chr#{v}

   This fixes the problem.  The patch should merge easily onto the branch.
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2011#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 11:47:13 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 11:41:14 2008
Subject: [GHC] #793: Use gcc's libffi to replace Adjustor.c and
 ByteCodeFFI.hs?
In-Reply-To: <047.bebe0ee1522997ea1300a5b9fc8eb59f@localhost>
References: <047.bebe0ee1522997ea1300a5b9fc8eb59f@localhost>
Message-ID: <056.f21472831cab3c730bb9ee5e60b3d35f@localhost>

#793: Use gcc's libffi to replace Adjustor.c and ByteCodeFFI.hs?
----------------------------+-----------------------------------------------
 Reporter:  simonmar        |          Owner:  simonmar        
     Type:  task            |         Status:  new             
 Priority:  normal          |      Milestone:  6.8 branch      
Component:  Runtime System  |        Version:  6.4.1           
 Severity:  normal          |     Resolution:                  
 Keywords:                  |     Difficulty:  Moderate (1 day)
 Testcase:  N/A             |   Architecture:  Unknown         
       Os:  Unknown         |  
----------------------------+-----------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar

Comment:

 I have the `createAdjustor` part of this working, but it needs proper
 autoconf gubbins etc., and we need to decide whether to import `libffi`
 into our tree and hook it into the build system or not.  Right now I'm
 compiling against the `libffi` supplied by Debian/Ubuntu, which appears to
 be close to the version in the gcc SVN repository.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/793#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 11:57:32 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 11:51:29 2008
Subject: [GHC] #793: Use gcc's libffi to replace Adjustor.c and
 ByteCodeFFI.hs?
In-Reply-To: <047.bebe0ee1522997ea1300a5b9fc8eb59f@localhost>
References: <047.bebe0ee1522997ea1300a5b9fc8eb59f@localhost>
Message-ID: <056.6dc72f64f12c9d647f60d775a9a3a78e@localhost>

#793: Use gcc's libffi to replace Adjustor.c and ByteCodeFFI.hs?
----------------------------+-----------------------------------------------
 Reporter:  simonmar        |          Owner:  simonmar        
     Type:  task            |         Status:  new             
 Priority:  normal          |      Milestone:  6.8 branch      
Component:  Runtime System  |        Version:  6.4.1           
 Severity:  normal          |     Resolution:                  
 Keywords:                  |     Difficulty:  Moderate (1 day)
 Testcase:  N/A             |   Architecture:  Unknown         
       Os:  Unknown         |  
----------------------------+-----------------------------------------------
Comment (by igloo):

 I don't think we should bundle it. It's the sort of thing where more
 obscure platforms need the latest version, and we don't another thing we
 have to make sure we keep up-to-date. Also, for the common case (including
 Windows users) it isn't necessary to have it, as the existing code can be
 used instead.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/793#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 12:16:35 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 12:10:44 2008
Subject: [GHC] #1395: let ./configure check for a GNUreadline framework
In-Reply-To: <052.068bc0f583c08a182f51a06ad4864715@localhost>
References: <052.068bc0f583c08a182f51a06ad4864715@localhost>
Message-ID: <061.bece9f1d24cbbf8d44894353c9d66305@localhost>

#1395: let ./configure check for a GNUreadline framework
-----------------------------+----------------------------------------------
 Reporter:  maeder@tzi.de    |          Owner:             
     Type:  feature request  |         Status:  reopened   
 Priority:  normal           |      Milestone:  6.8 branch 
Component:  Build System     |        Version:  6.8        
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by guest):

 Replying to [comment:25 maeder]:
 > My modification of `utils/hsc2hs/Main.hs` (probably) caused the problem
 reported in
 > http://article.gmane.org/gmane.comp.lang.haskell.cafe/34373

 Cabal already handles this type of problem by passing different flags
 based on whether `hsc2hs` is using `gcc` or `ghc`.  This is done in
 `Distribution.Simple.PreProcess.ppHsc2hs` and
 `Simple.Program.hsc2hsProgram`.

 Perhaps Cabal should add the `-F$HOME/Library/Frameworks` instead of
 `hsc2hs` itself?   See http://hackage.haskell.org/trac/hackage/ticket/189

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1395#comment:26>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 12:24:11 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 12:18:14 2008
Subject: [GHC] #1395: let ./configure check for a GNUreadline framework
In-Reply-To: <052.068bc0f583c08a182f51a06ad4864715@localhost>
References: <052.068bc0f583c08a182f51a06ad4864715@localhost>
Message-ID: <061.8317ed53871cada8d7d4dfa7521dd7a1@localhost>

#1395: let ./configure check for a GNUreadline framework
-----------------------------+----------------------------------------------
 Reporter:  maeder@tzi.de    |          Owner:             
     Type:  feature request  |         Status:  reopened   
 Priority:  normal           |      Milestone:  6.8 branch 
Component:  Build System     |        Version:  6.8        
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by guest):

 By the way; I wrote the previous comment while logged in as `guest`, but
 forgot to sign it.

 -Judah

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1395#comment:27>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 13:03:07 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 12:57:14 2008
Subject: [GHC] #1987: GHCi's config file in <AppData>\ghc folder on
 Windows
In-Reply-To: <047.80a8b57d40878eeae0279f928cac66b2@localhost>
References: <047.80a8b57d40878eeae0279f928cac66b2@localhost>
Message-ID: <056.f6ae8f08f40f54eb1f16515eabd096b9@localhost>

#1987: GHCi's config file in <AppData>\ghc folder on Windows
-----------------------------+----------------------------------------------
 Reporter:  felixmar         |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  low              |      Milestone:  6.10 branch
Component:  GHCi             |        Version:  6.9        
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Unknown    
 Testcase:                   |   Architecture:  Unknown    
       Os:  Windows          |  
-----------------------------+----------------------------------------------
Changes (by ross):

  * type:  proposal => feature request

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1987#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From naur at post11.tele.dk  Thu Jan  3 14:58:47 2008
From: naur at post11.tele.dk (Thorkil Naur)
Date: Thu Jan  3 14:53:41 2008
Subject: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
In-Reply-To: <20080103151849.DJSH5833.fep27.mail.dk@matrix.matrix.chaos.earth.li>
References: <477CE624.3040806@dfki.de>
	<20080103151849.DJSH5833.fep27.mail.dk@matrix.matrix.chaos.earth.li>
Message-ID: <200801032058.47615.naur@post11.tele.dk>

Hello,

Thanks everybody. However, I believe that using a modified readline library is 
debatable, mainly because it adds the burden of keeping this library 
up-to-date to the GHC maintenance process. Having a renamed library is one 
thing and it does not seem that also modifying the contents of the library is 
an improvement.  For me to consider this idea, it should be the very last 
solution, every other stone having been turned. And I certainly believe that 
stones remain to be turned in this case.

I would very much like to hear your comments to this.

In addition, if you must replace this framework with another with different 
contents, I would suggest the use of some versioning scheme. Otherwise is 
seems that a lot of confusion could result.

Thanks and best regards
Thorkil

On Thursday 03 January 2008 16:18, Ian Lynagh wrote:
> 
> Hi Christian,
> 
> On Thu, Jan 03, 2008 at 02:41:56PM +0100, Christian Maeder wrote:
> > 
> > Judah's framework (2342543 Bytes)
> > http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip
> > 
> > should replace (my old one)
> > http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
> 
> Done!
> 
> 
> Thanks
> Ian
> 
> 
From trac at galois.com  Thu Jan  3 15:48:43 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 15:42:40 2008
Subject: [GHC] #1944: round function causes cblas NaNs
In-Reply-To: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost>
References: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost>
Message-ID: <061.811f364dc099b7ac8023cf7d4998f345@localhost>

#1944: round function causes cblas NaNs
---------------------------+------------------------------------------------
 Reporter:  SevenThunders  |          Owner:         
     Type:  bug            |         Status:  new    
 Priority:  normal         |      Milestone:  6.8.3  
Component:  Compiler       |        Version:  6.8.1  
 Severity:  critical       |     Resolution:         
 Keywords:                 |     Difficulty:  Unknown
 Testcase:                 |   Architecture:  x86    
       Os:  Windows        |  
---------------------------+------------------------------------------------
Comment (by SevenThunders):

 Replying to [comment:7 simonmar]:
 > Presumably something in the floating-point unit state is changing in a
 way that upsets the code in the cblas library.  I don't know of anything
 that could cause this; the native code generator does in one place
 generate code that saves and restores the FPU control word, but that was
 added in 6.8.2 (see #1910).
 >
 > To proceed we really need to know what is changing in the FPU state, so
 that we can trace it back to the point at which it changed.  At the very
 least, we need a reproducible test case.  I downloaded your files and
 tried it, but it looks like I have a DLL missing:

 > Using dependency walker it looks like I don't have "MSJAVA.DLL".
 Although why I need that, I have no idea.

 Hmmm, my dependency walker is not showing the same results.  I have no
 dependency on MSJAVA.dll.  The dependencies I show are MSVCRT.dll,
 KERNEL32.dll, NTDLL.dll.  This could be because of the C runtime libraries
 that you are linking  to on your system.  So this is what I did to try to
 remove any possible variation in results.

 First I recompiled my test case using GHC 6.8.2 on my intel core duo
 laptop running windows xp (32 bit).  It still shows the errant NaNs.  I
 then uploaded my atlas.dll file once again just in case.  (Although the
 size of the two files is identical). I then uploaded my C runtime DLLs and
 the system DLLs.  They should be virus free, if my virus protection
 software is any good.  These files are now in subdirectory CRunTime.  I
 suspect it's not entirely kosher to freely publish copyrighted MS software
 so if you can get these to work, let me know and I will delete the system
 files.  You will probably temporarily have to mess with your path or put
 all the DLL's in the same directory with the application to force it to
 pick up the C Runtime I've provided.

 The location of these binaries can be found in:
 http://home.earthlink.net/~mattcbro/Test2/

 Apparently igloo was able to run my test case with my binaries and
 obtained some odd results so I am not alone in this.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1944#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 16:37:10 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 16:31:11 2008
Subject: [GHC] #1958: collect2: ld terminated with signal 10 [Bus
 error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of
 GHC 6.9
In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost>
References: <050.c31695132cb1b93380c95a8b6c208782@localhost>
Message-ID: <059.da7961db705744a1aad718017c455dd2@localhost>

#1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a
PPC Mac OS X 10.5 Leopard as part of GHC 6.9
-------------------------+--------------------------------------------------
 Reporter:  thorkilnaur  |          Owner:  thorkilnaur
     Type:  bug          |         Status:  new        
 Priority:  high         |      Milestone:  6.8.3      
Component:  Compiler     |        Version:  6.9        
 Severity:  normal       |     Resolution:             
 Keywords:               |     Difficulty:  Unknown    
 Testcase:               |   Architecture:  powerpc    
       Os:  MacOS X      |  
-------------------------+--------------------------------------------------
Comment (by eelco):

 I haven't spent much time on this (because I compiling GHC wasn't the
 final goal ;), but the compiler built with 'quickest' gave some strange
 errors concerning interface files when trying to build HAppS.  So I tried
 building 6.8.2 again, again with ld_classic, but now with build flavor
 'quick'.  I had to restart the build 3 or 4 times, since it segfaulted on
 (seemingly) random files.  After that I tried building HAppS again.
 Unfortunately, I got stuck at the same point, this time with a panic.

 {{{
 [10 of 18] Compiling HAppS.State.Transaction (
 src/HAppS/State/Transaction.hs, dist/build/HAppS/State/Transaction.o )

 src/HAppS/State/Transaction.hs:264:42:
     Warning: Defined but not used: `logger'

 src/HAppS/State/Transaction.hs:264:52:
     Warning: Defined but not used: `ev'
 ghc-6.8.2: panic! (the 'impossible' happened)
   (GHC version 6.8.2 for powerpc-apple-darwin):
         splitFunTy
     <nt>base:GHC.Conc.STM{tc r2T} base:GHC.Base.(){(w) tc 40}
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1958#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 20:29:24 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 20:23:18 2008
Subject: [GHC] #2015: SOE samples crash when running from ghci rather than
 compiling and running with ghc
Message-ID: <047.485ea5c57b8e879f2c33305a489b8545@localhost>

#2015: SOE samples crash when running from ghci rather than compiling and running
with ghc
-------------------------+--------------------------------------------------
    Reporter:  justinhj  |       Owner:          
        Type:  bug       |      Status:  new     
    Priority:  normal    |   Milestone:          
   Component:  GHCi      |     Version:  6.8.2   
    Severity:  normal    |    Keywords:  SOE ghci
  Difficulty:  Unknown   |    Testcase:          
Architecture:  Unknown   |          Os:  Windows 
-------------------------+--------------------------------------------------
 When running the SOE samples from http://haskell.org/soe/software1.htm
 I can compile and run at the command line fine, but if I use ghci instead
 of ghc I always get this error...

 {{{

 C:\cygwin\home\Justin\haskell\SOE\src>ghci
 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 Prelude> :load test.hs
 Ok, modules loaded: Snowflake, Main, SOE.
 Prelude Main> main
 Loading package old-locale-1.0.0.0 ... linking ... done.
 Loading package old-time-1.0.0.0 ... linking ... done.
 Loading package OpenGL-2.2.1.1 ... linking ... done.
 Loading package GLFW-0.1 ... <interactive>: Unknown PEi386 section name
 `.reloc'
  (while processing: C:\Program
 Files\Haskell\GLFW-0.1\ghc-6.8.2/HSGLFW-0.1.o)
 : panic! (the 'impossible' happened)
   (GHC version 6.8.2 for i386-unknown-mingw32):
         loadObj: failed

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2015>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  4 05:15:03 2008
From: trac at galois.com (GHC)
Date: Fri Jan  4 05:08:57 2008
Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out
 of range.
In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
References: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
Message-ID: <053.16ee04bbc1dbdfdaafa1c3812a8e45af@localhost>

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
---------------------+------------------------------------------------------
 Reporter:  mboes    |          Owner:                
     Type:  bug      |         Status:  new           
 Priority:  normal   |      Milestone:  6.8.3         
Component:  GHCi     |        Version:  6.8.1         
 Severity:  normal   |     Resolution:                
 Keywords:           |     Difficulty:  Unknown       
 Testcase:           |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD  |  
---------------------+------------------------------------------------------
Comment (by simonmar):

 See also Greg Wright's email in which he mentions exactly this problem:
 [http://www.haskell.org/pipermail/glasgow-haskell-
 users/2007-April/012291.html]

 In the HEAD, the fragment of code mentioned above is now gone, in favour
 of a more general mechanism.  You want the patch entitled "add PIC
 relocations for x86_64, and use a simpler hack in place of
 x86_64_high_symbol()" from HEAD.

 However, this on its own won't be enough: when we allocate memory for
 objects with `mmap()`, we need to get memory in the low 2Gb, which is why
 we use `MAP_32BIT` on Linux.  I'm not sure what the right way to do this
 on *BSD is, but you could try adding a hint address to the `mmap()` call,
 something in the low 2Gb, as Greg suggested in his mail above.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From Christian.Maeder at dfki.de  Fri Jan  4 06:03:10 2008
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Fri Jan  4 05:57:05 2008
Subject: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
In-Reply-To: <200801032058.47615.naur@post11.tele.dk>
References: <477CE624.3040806@dfki.de>	<20080103151849.DJSH5833.fep27.mail.dk@matrix.matrix.chaos.earth.li>
	<200801032058.47615.naur@post11.tele.dk>
Message-ID: <477E126E.90301@dfki.de>

(Let's discuss this openly on glasgow-haskell-users)

I'm not happy about this framework hick-hack either. I've only pushed
it, because we needed a readline solution on macs.

The alternative is to use static linking of gmp (as suggested by chak)
_and_ readline (version 5), so that user programs are also statically
linked with these libs. Nobody supplied a binary distribution so far,
though. I only supplied the binary distributions that I (naively) made
anyway.

Regarding this actual GNUreadline-framework.zip replacement, this is
harmless and seems to matter only for those who build ghc with
frameworks (as only the inclusion of header files changed)

In any case we should strive to fix the frameworks issues _and_ add
support for static linking of gmp, readline and possibly other libs
(plus license issues).

HTH Christian

Thorkil Naur wrote:
> Hello,
> 
> Thanks everybody. However, I believe that using a modified readline library is 
> debatable, mainly because it adds the burden of keeping this library 
> up-to-date to the GHC maintenance process. Having a renamed library is one 
> thing and it does not seem that also modifying the contents of the library is 
> an improvement.  For me to consider this idea, it should be the very last 
> solution, every other stone having been turned. And I certainly believe that 
> stones remain to be turned in this case.
> 
> I would very much like to hear your comments to this.
> 
> In addition, if you must replace this framework with another with different 
> contents, I would suggest the use of some versioning scheme. Otherwise is 
> seems that a lot of confusion could result.
> 
> Thanks and best regards
> Thorkil
> 
> On Thursday 03 January 2008 16:18, Ian Lynagh wrote:
>> Hi Christian,
>>
>> On Thu, Jan 03, 2008 at 02:41:56PM +0100, Christian Maeder wrote:
>>> Judah's framework (2342543 Bytes)
>>> http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip
>>>
>>> should replace (my old one)
>>> http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
>> Done!
>>
>>
>> Thanks
>> Ian
>>
>>
From trac at galois.com  Fri Jan  4 07:27:13 2008
From: trac at galois.com (GHC)
Date: Fri Jan  4 07:21:07 2008
Subject: [GHC] #1012: ghc panic with mutually recursive modules and
 template haskell
In-Reply-To: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
References: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
Message-ID: <053.9824333cecd6210d24a1b2868b2c1ab6@localhost>

#1012: ghc panic with mutually recursive modules and template haskell
------------------------------+---------------------------------------------
 Reporter:  guest             |          Owner:            
     Type:  bug               |         Status:  closed    
 Priority:  normal            |      Milestone:  6.8 branch
Component:  Template Haskell  |        Version:  6.8.2     
 Severity:  normal            |     Resolution:  fixed     
 Keywords:                    |     Difficulty:  Unknown   
 Testcase:  TH_import_loop    |   Architecture:  Multiple  
       Os:  Multiple          |  
------------------------------+---------------------------------------------
Changes (by simonpj):

  * status:  reopened => closed
  * resolution:  => fixed

Comment:

 Simon is right: B.hs depends on C.hs, which depends on A.hs-boot.  I think
 it's quite accidental that A happens to be compiled before B in your
 "curiously enough" case, but after B in your original case.

 All you need do is to make B depend on A, thus
 {{{
 {-# LANGUAGE TemplateHaskell #-}
 module ModuleB where

 import ModuleC
 import ModuleA

 $(nothing)
 }}}
 and it all works fine.  Use -v to see the compilation order.

 I will clarify the documentation, thus:

    You can only run a function at compile time if it is imported from
 another module ''that is not part of a mutually-recursive group of modules
 that includes the module currently being