January 2015 - ghc-tickets

[GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal
by GHC 27 Feb '15

27 Feb '15

#9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Difficult (2-5 | Type of failure: days) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- More details to follow. I've created this ticket to be able to refer to from related preparatory commits. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9586> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 45

[GHC] #8189: Default to infinite stack size?
by GHC 24 Feb '15

24 Feb '15

#8189: Default to infinite stack size? ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- http://www.haskell.org/pipermail/haskell-cafe/2013-August/108570.html It looks like any code of the form {{{ ... = do x1 <- m1 x2 <- m2 [do something with x1 and m2] }}} will stack overflow when used with a strict monad (like IO) and sufficiently large data to deal with (a 1m element list is enough to exceed the default 8MB stack size limit). Other examples include: {{{ sequence (m:ms) = do x <- m xs <- sequence ms return (x:xs) }}} and {{{ liftM2, liftM3, ... }}} By slightly modifying your program to do the same thing via heap allocation (e.g. using a difference list in sequence), a stack-overflow rejected program turns into a valid program. This means that valid and idiomatic code like {{{ xs <- replicateM n someIOAction xs <- mapM someIOAction [1..n] }}} will eventually crash, which has an impact on practically all Haskell software and libraries out there. For examples, see https://github.com/ndmitchell/shake/blob/e0e0a43/Development/Shake/Database… https://github.com/haskell-suite/haskell-src-exts/issues/27 as well as the mapM usages in cabal, haddock, any database binding that allows querying a lists of results, etc. While some argue that ''"you shouldn't use lists of that size"'', ''"allocating a 150 MB list is wrong"'' or that they ''"carefully avoid any use of sequence/mapM due to the problem"'' pointed out above, I think that collecting a million results of a strict monadic action into a linked list using standard functions like mapM is a common pattern and valid use case. The stack based evaluation that GHC performs is an optimization and should be transparent to the user; it should not re-define some data to live in a fixed-size memory region, and it should work just as well as it does in GHCi. It seems that a default infinite stack size would mitigate this. A drawback might be that the stack space overflows we get so far to quickly spot a "wrong" program would not indicate certain errors any more. I currently doubt the usefulness of this debugging method, since it does not work reliably in the presence of optimization, doing the same thing via heap allocation makes the programs "correct", and it rejects valid programs if the input data is large enough. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35

[GHC] #9103: hackage's type-level-0.2.4 fails to compile
by GHC 23 Feb '15

23 Feb '15

#9103: hackage's type-level-0.2.4 fails to compile -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Attached trimmed-down dependencyless archive. Steps to reproduce: {{{ $ tar -xzf type-level-0.2.4.tar.gz $ ghci -hide-all-packages -package=base -package=template-haskell Data/TypeLevel.hs }}} The error on 7.8.2 and in -HEAD is: {{{ [6 of 8] Compiling Data.TypeLevel.Num.Ops ( Data/TypeLevel/Num/Ops.hs, interpreted ) Data/TypeLevel/Num/Ops.hs:90:10: Illegal instance declaration for ‘Succ' (x, x) (x, x) D0 D0 True’ The liberal coverage condition fails in class ‘Succ'’ for functional dependency: ‘yh yl yz -> xh xl’ Reason: lhs types ‘D0’, ‘D0’, ‘True’ do not jointly determine rhs types ‘(x, x)’, ‘(x, x)’ In the instance declaration for ‘Succ' (x, x) (x, x) D0 D0 True’ ... }}} Typechecked fine on ghc-7.6.3 {{{ [1 of 8] Compiling Data.TypeLevel.Num.Reps ( Data/TypeLevel/Num/Reps.hs, interpreted ) [2 of 8] Compiling Data.TypeLevel.Num.Sets ( Data/TypeLevel/Num/Sets.hs, interpreted ) [3 of 8] Compiling Data.TypeLevel.Num.Aliases.TH ( Data/TypeLevel/Num/Aliases/TH.hs, interpreted ) [4 of 8] Compiling Data.TypeLevel.Num.Aliases ( Data/TypeLevel/Num/Aliases.hs, interpreted ) Generating and compiling a zillion numerical type aliases, this might take a while [5 of 8] Compiling Data.TypeLevel.Bool ( Data/TypeLevel/Bool.hs, interpreted ) [6 of 8] Compiling Data.TypeLevel.Num.Ops ( Data/TypeLevel/Num/Ops.hs, interpreted ) [7 of 8] Compiling Data.TypeLevel.Num ( Data/TypeLevel/Num.hs, interpreted ) [8 of 8] Compiling Data.TypeLevel ( Data/TypeLevel.hs, interpreted ) Ok, modules loaded: Data.TypeLevel, Data.TypeLevel.Num, Data.TypeLevel.Bool, Data.TypeLevel.Num.Reps, Data.TypeLevel.Num.Aliases, Data.TypeLevel.Num.Sets, Data.TypeLevel.Num.Ops, Data.TypeLevel.Num.Aliases.TH. *Data.TypeLevel> }}} I have failed to decipher an error message, but looks like it tries to instantiate a thing it should not. My apologies if it's not-a-bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9103> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #9778: Namespace collision detection for promoted types
by GHC 23 Feb '15

23 Feb '15

#9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In the following example {{{#!hs {-# LANGUAGE DataKinds #-} module Foo where data Nat = Z | S Nat data S foo :: S n -> S n foo = id }}} GHC displays the error {{{ Foo.hs:12:8: ‘S’ is applied to too many type arguments In the type signature for ‘foo’: foo :: S n -> S n Failed, modules loaded: none. }}} Although it's clear in my example where the problem is, this example was distilled from a case where I imported module1 with type `S` defined and module2 with the promoted type `S`, which is what I was trying to use. Can we get namespace collision detection instead? Something like: {{{ Foo.hs:9:15 Ambiguous occurence ‘S’ It could refer to either Foo.S defined at Foo.hs:7:1 or to the promoted constructor S defined at Foo.hs:5:16 Use 'S to refer to the promoted constructor. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9778> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9986: lhs -> hs fallout
by GHC 23 Feb '15

23 Feb '15

#9986: lhs -> hs fallout -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.9 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It looks that during .lhs -> .hs switch the comments were not updated. Grepping for ".lhs" reveals 117 lines where .lhs files are referenced: {{{ basicTypes/OccName.hs:154:-- see also: Note [Data Constructor Naming] in DataCon.lhs basicTypes/BasicTypes.hs:447:-- instance. See Note [Safe Haskell isSafeOverlap] (in `InstEnv.lhs`) for a basicTypes/BasicTypes.hs:874: Note [Expanding variables] in Rules.lhs. basicTypes/Id.hs:579:-- See Note [Specialisations and RULES in IdInfo] in IdInfo.lhs basicTypes/Id.hs:689: -- Another good example is in fill_in in PrelPack.lhs. We should be able to basicTypes/DataCon.hs:407: -- See also Note [Data-con worker strictness] in MkId.lhs basicTypes/MkId.hs:1194: See DsUtils.lhs Note [Desugaring seq (1)] and (2) and (3) basicTypes/Var.hs:340:-- Ids, because Id.lhs uses 'mkGlobalId' etc with different types basicTypes/IdInfo.hs:423:-- CafInfo is used to build Static Reference Tables (see simplStg/SRT.lhs). cmm/CmmBuildInfoTables.hs:201:-- Adapted from simpleStg/SRT.lhs, which expects Id's. cmm/cmm-notes:98:SMRep.lhs cmm/cmm-notes:123:CodeGen.lhs cmm/cmm-notes:124:CgBindery.lhs cmm/cmm-notes:126:CgCase.lhs cmm/cmm-notes:127:CgClosure.lhs cmm/cmm-notes:128:CgCon.lhs cmm/cmm-notes:129:CgExpr.lhs cmm/cmm-notes:130:CgLetNoEscape.lhs cmm/cmm-notes:132:CgHeapery.lhs cmm/cmm-notes:135:CgMonad.lhs cmm/cmm-notes:139:CgStackery.lhs cmm/cmm-notes:140:CgTailCall.lhs cmm/cmm-notes:143:ClosureInfo.lhs codeGen/StgCmmBind.hs:744: -- CgConTbls.lhs with a description generated from the data constructor codeGen/StgCmmExpr.hs:704:-- stgSyn/CoreToStg.lhs). Consider this: coreSyn/CorePrep.hs:111:9. Replace (lazy e) by e. See Note [lazyId magic] in MkId.lhs coreSyn/CoreUtils.hs:803:~~~~~~~~~~~~~~~~~~ in CoreUnfold.lhs coreSyn/CoreSyn.hs:245:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs coreSyn/CoreSyn.hs:268:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs coreSyn/CoreSyn.hs:274:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs coreSyn/CoreSyn.hs:289:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs coreSyn/CoreSyn.hs:438:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs coreSyn/CoreSyn.hs:764: -- See Note [Extra args in rule matching] in Rules.lhs coreSyn/CoreSyn.hs:921: -- (see MkId.lhs, calls to mkCompulsoryUnfolding). coreSyn/CoreSyn.hs:1100:-- See Note [Expanding variables] in Rules.lhs coreSyn/CoreSyn.hs:1256:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs coreSyn/CoreSyn.hs:1445:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs coreSyn/CoreArity.hs:612:See Note [Dictionary-like types] in TcType.lhs for why we use coreSyn/CoreFVs.hs:294: -- See Note [Finding rule RHS free vars] in OccAnal.lhs coreSyn/CoreFVs.hs:393:-- This actually happened in the defn of errorIO in IOBase.lhs: deSugar/DsExpr.hs:479: T (recConErr t1 "M.lhs/230/op1") deSugar/DsExpr.hs:481: (recConErr t1 "M.lhs/230/op3") deSugar/DsExpr.hs:486: M.lhs, line 230: missing field op1 was evaluated deSugar/DsExpr.hs:531: other -> recUpdError "M.lhs/230" deSugar/DsForeign.hs:673: -- codeGen/CodeGen.lhs; however, stginit functions have a negative impact deSugar/Check.hs:56: @Match.lhs@ to generate code) deSugar/Check.hs:631:tidy_eqn does more or less the same thing as @tidy@ in @Match.lhs@; ghci/ByteCodeGen.hs:1157: -- the DataCon. See DataCon.lhs for details. ghci/Linker.hs:1109: -- compiler/ghci/Linker.lhs + rts/Linker.c link the ghc.mk:243:# Generate supporting stuff for prelude/PrimOp.lhs hsSyn/HsDecls.hs:371: (DefMeth is defined in Class.lhs) hsSyn/Convert.hs:884: -- Convert.lhs, hence panic iface/IfaceType.hs:467:-- See equivalent function in TypeRep.lhs iface/LoadIface.hs:197: -- compiling Float.lhs, which mentions Float of course main/HscMain.hs:356: -- - filter out the .hs/.lhs source filename if we have one main/TidyPgm.hs:1266: -- split (see Note [Worker-wrapper for bottoming functions] in WorkWrap.lhs main/GHC.hs:1182:{- ToDo: Move the primary logic here to compiler/main/Packages.lhs main/DriverPhases.hs:52: literate pre-processor | .lhs | - | - main/Finder.hs:307:-- not a reexport (this invariant is upheld by @Packages.lhs@) and (2) main/DriverPipeline.hs:827: -- libraries/hpc/tests/function/subdir/tough2.lhs main/DriverPipeline.hs:1687: -- compiler/nativeGen/AsmCodeGen.lhs for another instance main/HscTypes.hs:1066: -- See Note [Overall plumbing for rules] in Rules.lhs main/HscTypes.hs:2704:This stuff is in here, rather than (say) in Linker.lhs, because the Linker.lhs nativeGen/PPC/CodeGen.hs:893: nonvolatile registers differs (see MachRegs.lhs). nativeGen/PIC.hs:748:-- (See PprMach.lhs) nativeGen/RegAlloc/Graph/TrivColorable.hs:73:32% of total compile time and 42% of total alloc when compiling SHA1.lhs from darcs. nativeGen/RegAlloc/Graph/TrivColorable.hs:81:the most efficient variant tried. Benchmark compiling 10-times SHA1.lhs follows. parser/cutils.h:9:// Out-of-line string functions, see PrimPacked.lhs prelude/TysPrim.hs:333:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs prelude/TysPrim.hs:531:defined in \tr{TysWiredIn.lhs}, not here. prelude/PrimOp.hs:188:is done with plain ccalls now (see PrelNumExtra.lhs). prelude/PrimOp.hs:486:@primOpIsCheap@, as used in \tr{SimplUtils.lhs}. For now (HACK prelude/PrelRules.hs:1006: -- See Note [Integer division constant folding] in libraries/base/GHC/Real.lhs prelude/PrelRules.hs:1137:-- See Note [magicDictId magic] in `basicTypes/MkId.lhs` rename/RnPat.hs:238: -- before going on to the RHSes (see RnSource.lhs). rename/RnEnv.hs:1374: -- See Note [Binders in Template Haskell] in Convert.lhs rename/RnExpr.hs:316:wired-in. See the Note about the NameSorts in Name.lhs. simplCore/SimplUtils.hs:1491: poly_id = transferPolyIdInfo var tvs_here $ -- Note [transferPolyIdInfo] in Id.lhs simplCore/SimplUtils.hs:1624:was like this (base/Foreign/C/Err/Error.lhs): simplCore/OccurAnal.hs:286:recursive functions] in Simplify.lhs simplCore/FloatIn.hs:86:SetLevels.lhs module, which tags things with their level numbers. simplCore/SetLevels.hs:830: -- See Note [Computing one-shot info] in Demand.lhs simplCore/SetLevels.hs:1053: mk_poly_bndr bndr uniq = transferPolyIdInfo bndr abs_vars $ -- Note [transferPolyIdInfo] in Id.lhs simplCore/SimplCore.hs:299: -- Reason: see Note [Shadowing] in SpecConstr.lhs simplCore/SimplCore.hs:634: -- See Note [Overall plumbing for rules] in Rules.lhs simplCore/Simplify.hs:55:the simplifier is in SimplCore.lhs. simplCore/Simplify.hs:2161: -- See Note [Data-con worker strictness] in MkId.lhs simplCore/Simplify.hs:2630:The Ord instance of Maybe in PrelMaybe.lhs, for example, took several extra simplStg/UnariseStg.hs:66: where -- See Note [Nullary unboxed tuple] in Type.lhs specialise/SpecConstr.hs:1839: -- See Note [Matching lets] in Rule.lhs specialise/SpecConstr.hs:1845:{- Disabled; see Note [Matching cases] in Rule.lhs stgSyn/CoreToStg.hs:92:-- constructing SRTs (see SRT.lhs). stgSyn/CoreToStg.hs:444: -- See Note [Nullary unboxed tuple] in Type.lhs stranal/DmdAnal.hs:1089:-- See Note [Trimming a demand to a type] in Demand.lhs typecheck/TcForeign.hs:137: -- See Note [Expanding newtypes] in TyCon.lhs typecheck/FamInst.hs:327:-- in FamInstEnv.lhs typecheck/TcExpr.hs:1321:Note [Converting strings] in Convert.lhs typecheck/TcType.hs:259:It's knot-tied back to Var.lhs. There is no reason in principle typecheck/TcType.hs:260:why Var.lhs shouldn't actually have the definition, but it "belongs" here. typecheck/TcEvidence.hs:138: [TcCoercion] -- See [CoAxiom Index] in Coercion.lhs typecheck/TcPat.hs:679:As explained by [Wrappers for data instance tycons] in MkIds.lhs, the typecheck/TcInteract.hs:1524:To achieve this required some refactoring of FunDeps.lhs (nicer typecheck/TcTyClsDecls.hs:1490: -- See Note [GADT record selectors] in MkId.lhs types/Kind.hs:218:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs types/Kind.hs:234:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs types/CoAxiom.hs:231:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs types/TyCon.hs:162:See also Note [Wrappers for data instance tycons] in MkId.lhs types/TyCon.hs:349:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs types/TypeRep.hs:98:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs types/Coercion.hs:126:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs types/Coercion.hs:203:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs types/Coercion.hs:945:-- of Coercion and the Note [Refl invariant] in types/TypeRep.lhs. types/Type.hs:606:interfaces. Notably this plays a role in tcTySigs in TcBinds.lhs. types/Type.hs:819:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs types/Type.hs:1324:-- See Note [Kind Constraint and kind *] in Kinds.lhs types/Unify.hs:235:-- thing to do. C.f. Note [Matching variable types] in Rules.lhs utils/Binary.hs:476:-- yes, we need Binary Integer and Binary Rational in basicTypes/Literal.lhs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9986> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8539: Data.Complex shouldn't use default implementation of (**)
by GHC 23 Feb '15

23 Feb '15

#8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect result Difficulty: Easy (less than 1 | at runtime hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{ Prelude Data.Complex> 0**2 0.0 Prelude Data.Complex> 0**2 :: Complex Double NaN :+ NaN Prelude Data.Complex> exp $ 2 * log 0 :: Complex Double NaN :+ NaN Prelude Data.Complex> log 0 :: Complex Double (-Infinity) :+ 0.0 Prelude Data.Complex> 2 * it :: Complex Double (-Infinity) :+ NaN Prelude Data.Complex> exp it :: Complex Double NaN :+ NaN }}} So Complex uses the default implementation of (!**). Then when 2*(-inf :+ 0) is evaluated. We do (2 * -inf - 0*0) :+ (2*0 + -inf*0). Which because of -inf*0 sets the imaginary part to NaN. Then exp (-inf :+ NaN) = exp x cos y :+ exp x sin y which becomes 0 * cos NaN :+ 0 * sin NaN. So we end up with NaN :+ NaN. Ross Paterson suggested: I would say the default implementation of (!**) is wrong: to match the Float/Double instances it should be x !** y = if x == 0 then 0 else exp (log x * y) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8539> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 44

[GHC] #8309: traceEvent truncates to 512 bytes
by GHC 23 Feb '15

23 Feb '15

#8309: traceEvent truncates to 512 bytes ------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: eventlog tracing | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The `Debug.Trace.traceEvent` (& `traceEventIO`) use a code path that unnecessarily uses printf format strings and uses a fixed size 512-byte buffer, hence truncating all user trace messages at that size. Here is the call path: * `Debug.Trace.traceEvent` (& `traceEventIO`) call `traceEvent#` primop * cmm impl of the primop `stg_traceEventzh` calls C RTS function `traceUserMsg` * `traceUserMsg` calls `traceFormatUserMsg(cap, "%s", msg);`, using the printf format string * `traceFormatUserMsg` uses `postUserMsg` which eventually calls `postLogMsg` * `postLogMsg` does the printf stuff Here's what `postLogMsg` does: {{{ #define BUF 512 void postLogMsg(EventsBuf *eb, EventTypeNum type, char *msg, va_list ap) { char buf[BUF]; nat size; size = vsnprintf(buf,BUF,msg,ap); if (size > BUF) { buf[BUF-1] = '\0'; size = BUF; } .... }}} This is obviously designed for RTS-internal users, not the user path. So the problem starts with this bit: {{{ void traceUserMsg(Capability *cap, char *msg) { traceFormatUserMsg(cap, "%s", msg); } }}} It just should not use that code path. It should call something that directly posts the message, without any silly printf strings. In fact, the code path from the primop down should really be changed to use an explicit given length, rather than using a null-terminated string and having to call strlen. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8309> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9926: Restore INSTALL file in src dist
by GHC 23 Feb '15

23 Feb '15

#9926: Restore INSTALL file in src dist -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I seem to recall previous source distributions having an `INSTALL` file with instructions. (The particular detail I was looking for was whether or not I need to `perl boot` the 7.10-rc1 source distro.) There don't seem to be any installation instructions anymore. Could this be restored for future source distros? Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9926> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10043: runtime fails in threaded way on SPARC (bus error -> unaligned access to data)
by GHC 23 Feb '15

23 Feb '15

#10043: runtime fails in threaded way on SPARC (bus error -> unaligned access to data) -----------------------------------+---------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Solaris Architecture: sparc | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+---------------------------------- Hello, it looks like runtime has changed between 7.8 and 7.10 in a way it no longer works well on SPARC. Tested on SPARC/Solaris 2.11. Both compilers compiled as their are w/o any changes so both unregisterised. On 7.8 testblockalloc runs well, on 7.10.1-rc2 it fails in threaded way with "Bus error" {{{ karel@niagara:~/src/ghc-7.10.0.20150123/testsuite/tests/rts$ ./testblockalloc +RTS -I0 Bus Error (core dumped) }}} When run in debugger it points to assignment of 0 to tso->alloc_limit: {{{ karel@niagara:~/src/ghc-7.10.0.20150123/testsuite/tests/rts$ gdb ./testblockalloc GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.11"... set ar(gdb) set args +RTS -I0 (gdb) r Starting program: /home/karel/src/ghc-7.10.0.20150123/testsuite/tests/rts/testblockalloc +RTS -I0 warning: Lowest section in /lib/librt.so.1 is .dynamic at 00000074 warning: Lowest section in /lib/libdl.so.1 is .dynamic at 00000074 warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074 Program received signal SIGSEGV, Segmentation fault. 0x006b62d4 in createThread (cap=0x821ec0, size=256) at rts/Threads.c:113 113 tso->alloc_limit = 0; (gdb) }}} usually bus error is generated by unaligned access to data. I'll have a look at it, but any idea is of course highly appreciated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10043> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10051: panic - the 'impossible' happened
by GHC 23 Feb '15

23 Feb '15

#10051: panic - the 'impossible' happened -------------------------------------+------------------------------------- Reporter: jpw1991 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: GHCi crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hi there, I'm new to Haskell and I'm loving it so far. I finished a learning project in Haskell and it works fine on Linux. I'm bringing it over to Windows and I got the following error while running it: C:\Repositories\HaskellPong>ghci Main.hs -LC:\SDL\lib -lSDL2 GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static archive) C:\SDL\lib\libSDL2.a ... ghc.exe: Unknown PEi386 section name `.rdata$.refptr.DUMMYAUD_bootstrap' (while processing: C:\SDL\lib\ libSDL2.a) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): loadArchive "C:\\SDL\\lib\\libSDL2.a": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug The repository is public, so you can go and get it from here: https://jwoodss@bitbucket.org/jwoodss/haskellpong.git -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10051> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6