- ghc-tickets - Haskell.org

Re: [GHC] #7472: Build on FreeBSD fails with ncurses
by GHC 14 Apr '13

14 Apr '13

#7472: Build on FreeBSD fails with ncurses ----------------------------------+----------------------------------------- Reporter: nematoder | Owner: pgj Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.6.1 Resolution: wontfix | Keywords: ncurses, freebsd Os: FreeBSD | Architecture: Unknown/Multiple Failure: Building GHC failed | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Comment(by pgj): Replying to [comment:5 pgj]: > Replying to [comment:4 simonmar]: > > Would someone like to create a wiki page for FreeBSD under [wiki:Building/Preparation] and put this and any other FreeBSD-specific info there please? > > Yes, I volunteer for this. Now the [wiki:Building/Preparation/FreeBSD page] is created. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7472#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve'
by GHC 14 Apr '13

14 Apr '13

#7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve' -------------------------------------------+-------------------------------- Reporter: songpp | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: GHCi | Version: 7.4.1 Keywords: loadArchive Unknown PEi386 | Os: Windows Architecture: x86 | Failure: GHCi crash Difficulty: Unknown | Testcase: Blockedby: 3658 | Blocking: Related: #2487, #7103 | -------------------------------------------+-------------------------------- Comment(by batterseapower): Experienced this with Mingw GCC 4.7.2 on Windows 7 when building GHC: {{{ "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name vector-0.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist- install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP- DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package ghc- prim-0.3.1.0 -package primitive-0.4.0.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -no-user-package-db -rtsopts -odir libraries/vector/dist-install/build -hidir libraries/vector/dist- install/build -stubdir libraries/vector/dist-install/build -dynamic-too -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o -dyno libraries/vector/dist- install/build/Data/Vector/Fusion/Stream/Monadic.dyn_o Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... ghc-stage2.exe: panic! (the 'impossible' happened) (GHC version 7.7.20130413 for i386-unknown-mingw32): loadArchive "C:\\MinGW\\msys\\1.0\\home\\Max\\Programming\\ghc\\libraries\\integer-gmp \\dist-install\\build\\libHSinteger-gmp-0.5.1.0.a": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghc-stage2.exe: Unknown PEi386 section name `.drectve' (while processing: C:\MinGW\msys\1.0\home\Max\Programming\ghc\libraries\integer-gmp\dist- install\build\libHSinteger-gmp-0.5.1.0.a) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7056#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7327: Inconsistent behavior for relative paths in runProcess
by GHC 14 Apr '13

14 Apr '13

#7327: Inconsistent behavior for relative paths in runProcess ----------------------------------+----------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: libraries/process | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ----------------------------------+----------------------------------------- Comment(by snoyberg): That should reproduce the problem. I don't actually have access to a Mac system, and therefore never personally reproduced this difference in behavior across OSes. I've asked Johan to see if he's still able to reproduce the issue and comment back on this ticket. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7327#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 14 Apr '13

14 Apr '13

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. ---------------------------------+------------------------------------------ Reporter: jpbernardy | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords: deriving | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC rejects valid program Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by jpbernardy): Basically what kosmikus said. This occurs often when you do generic programming. ie, when you encode the type A as A + 0 where 0 is a type with no constructor and + is an either-like type. So: yes, I have seen this in real programs. It's not too hard to write an instance manually, but the error message is confusing. I suspect that a proper fix (allowing to derive an instance) should be very easy, if it is not the case, a better error message (hinting at the user to write an instance with 'undefined') would also be an acceptable fix. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7401#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 14 Apr '13

14 Apr '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by jstolarek): I'm having some problems and I admit I could use some hint on what to do. I'm able to build the stage1 compiler, but every program compiled with it segfaults immediately. Looks like the approach I used to add the new prototype primops does not extend easily to modifying the existing primops. Here's the summary of what I did: * I changed primop definitions to return Int# ([[GhcFile(compiler/prelude/primops.txt.pp)]]) and modified genprimopcode accordingly ([[GhcFile(utils/genprimopcode/Syntax.hs)]]) * I modified Compare primop info to return Int# instead of Bool ([[GhcFile(compiler/prelude/PrimOp.lhs)]]) * I fixed the automatic deriving of Eq and Ord typeclasses ([[GhcFile(compiler/typecheck/TcGenDeriv.lhs)]]) * I removed all the comparison primop Core rules, so they wouldn't get in the way ([[GhcFile( compiler/prelude/PrelRules.lhs)]]). Once I get things working I will create new rules. * Once I realized that I'm getting segfaults I commented out some !MachOp rules in ([[GhcFile(compiler/cmm/CmmMachOp.hs)]]) (namely functions isComparisonMachOp and maybeInvertComparison) to make sure that problems are not caused by them. * I added primop wrappers in ghc-prim library and I modified base, ghc- prim and integer-gmp libraries to use those wrappers. I pushed these changes to github. The diffs are here: [https://github.com/jstolarek/ghc/commit/b5be2fb1083d16239024849b60a4b3009e6… GHC], [https://github.com/jstolarek/packages- base/commit/c484bcee5898257ceceecd9c354eadc376075e9c base], [https://github.com/jstolarek/packages-ghc- prim/commit/26096ff8875d8a6b1158078799cf394c654bdc50 ghc-prim], [https://github.com/jstolarek/packages-integer- gmp/commit/101bbc83ae632c8d2a1cd08bc9b68532f8e50a6a integer-gmp]. If anyone would be willing to look at them and suggest me where I went wrong I would be grateful. I know I need to make some more changes in ghc-prim library in GHC.!IntWord64 module and cbits, but I'm leaving that for now. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7598: ghc-stage1 generates wrong assembler on StgCmmPrim (operand out of range)
by GHC 14 Apr '13

14 Apr '13

#7598: ghc-stage1 generates wrong assembler on StgCmmPrim (operand out of range) --------------------------------+------------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Linux | Architecture: powerpc Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- Hello, an attempt to compile today GHC HEAD on linux powerpc fails with this message {{{ "inplace/bin/ghc-stage1" -static -H32m -O -package-name ghc-7.7.20130115 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/../rts/dist/build -Icompiler/stage2 -Icompiler/. -Icompiler/parser -Icompiler/utils -optP- DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.17.0 -package array-0.4.0.2 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.3.0 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.2.0.0 -package template-haskell-2.9.0.0 -package time-1.4.0.2 -package transformers-0.3.0.0 -package unix-2.6.1.0 -Wall -fno-warn-name-shadowing -XHaskell98 -XNondecreasingIndentation -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O2 -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -hisuf hi -osuf o -hcsuf hc -c compiler/codeGen/StgCmmPrim.hs -o compiler/stage2/build/StgCmmPrim.o /tmp/ghc20445_0/ghc20445_0.s: Assembler messages: /tmp/ghc20445_0/ghc20445_0.s:98896:0: Error: operand out of range (0x00000000000081ac is not between 0xffffffffffff8000 and 0x0000000000007ffc) make[1]: *** [compiler/stage2/build/StgCmmPrim.o] Error 1 make: *** [all] Error 2 }}} The platform is 32bit PowerPC running debian wheezy which provides GHC 7.4.1 used for bootstrapping GHC HEAD. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7598> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #7835: ghc --make: allow passign .cmm, .c and .hs files in one command line
by GHC 14 Apr '13

14 Apr '13

#7835: ghc --make: allow passign .cmm, .c and .hs files in one command line -----------------------------+---------------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- TL;DR: Allow users to make one run: {{{ $ ghc --make Test.hs TestPrim.hs test-prims.cmm -o t }}} instead of series: {{{ $ ghc -c test-prims.cmm $ ghc --make test-prims.o Test.hs TestPrim.hs }}} The buildable example is located at: https://github.com/trofi/cmm-example I'll just quote my email sent to ghc-devs@ a while ago: {{{ > Hi guys! > > Today I've tried to write a minimal [1] test case for ghc on ia64 > (it SIGSEGVs there). > > The test case consists of a .cmm and some .hs modues. > > I tried to build them in one run as: > $ ghc --make Test.hs TestPrim.hs test-prims.cmm -o t > ghc: cannot compile this file to desired target: test-prims.cmm > Usage: For basic information, try the `--help' option. > > Thus had to use > ${GHC} -c test-prims.cmm > ${GHC} --make test-prims.o Test.hs TestPrim.hs > > What do you think of allowing to use .c, .cmm and similar > files along with .hs files to make one-shot builds a bit easier? > > If noone is opposed I'll fill a request on bugtracker. > > Thanks! > > [1]: https://github.com/trofi/cmm-example }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7835> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7829: make better/more robust loopbreaker choices
by GHC 13 Apr '13

13 Apr '13

#7829: make better/more robust loopbreaker choices -----------------------------+---------------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The choice of loopbreaker can severely influence downstream compilation. This task ticket is about making the choice more robust/better/"smarter". This ticket is also empty of concrete suggestions how to do so... think of it like a community TODO. One example feature of the current algorithm that seems a bit fragile is the use of two schemes for breaking ties depending on the max "depth" of 2. Peruse the code and its comments and Notes in !OccAnal if you're interested. This also ticket serves to document a small regression incurred by my commit af12cf66d1a416a135cb98b86717aba2cd247e1a. There's a 4% increase in allocation in nofib/rewrite as a result of my change altering the loopbreaker choice. The actual details aren't relevant, but here's the basic story in order to convey the delicacy of loopbreaker choice. My commit slightly reduces the calculated size of a function in a mutually recursive group, so that it comes in under the "never unfold limit" instead of over. This ultimately causes the looperbreaker chooser to break a tie in a different way (there's two "Plans"). The previous choice was more fortuitous: it enabled a beneficial inlining that "misses its chance" with the new choice of loopbreaker. I don't remember nor ever totally understood the details of this last part of the story. I don't have the cycles at the moment to wade into it -dverbose-core2core -ddump-inlings again. Apologies. If a brave soul is interested, you should be able to recover the more fortuitous loopbreaker choice by setting `CoreUnfolding.sizeExpr.isRealWorldId` to `const False`. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7829> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7828: RebindableSyntax and Arrow
by GHC 13 Apr '13

13 Apr '13

#7828: RebindableSyntax and Arrow --------------------------------------+------------------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- When trying to add constraints to the types of the arrow primitives I get a type error. I think that doing such a thing should be possible and I've attached the code I used to test this. The errors I get when using the arrow notation for the function test are as follows: {{{ test :: Typeable a => R a a test = proc n -> returnA -< n }}} {{{ bug-arrow.hs:15:8: Could not deduce (Typeable c) arising from a use of `arr' from the context (Typeable a) bound by the type signature for test :: Typeable a => R a a at bug-arrow.hs:14:9-27 Possible fix: add (Typeable c) to the context of a type expected by the context: (b -> c) -> R b c or the type signature for test :: Typeable a => R a a In the expression: arr When checking that `arr' (needed by a syntactic construct) has the required type: forall b1 c1. (b1 -> c1) -> R b1 c1 arising from a proc expression at bug-arrow.hs:15:8-29 In the expression: proc n -> returnA -< n bug-arrow.hs:15:8: Could not deduce (Typeable c) arising from a use of `>>>' from the context (Typeable a) bound by the type signature for test :: Typeable a => R a a at bug-arrow.hs:14:9-27 Possible fix: add (Typeable c) to the context of a type expected by the context: R a1 b -> R b c -> R a1 c or the type signature for test :: Typeable a => R a a In the expression: (>>>) When checking that `(>>>)' (needed by a syntactic construct) has the required type: forall a2 b1 c1. R a2 b1 -> R b1 c1 -> R a2 c1 arising from a proc expression at bug-arrow.hs:15:8-29 In the expression: proc n -> returnA -< n bug-arrow.hs:15:8: Could not deduce (Typeable d) arising from a use of `first' from the context (Typeable a) bound by the type signature for test :: Typeable a => R a a at bug-arrow.hs:14:9-27 Possible fix: add (Typeable d) to the context of a type expected by the context: R b c -> R (b, d) (c, d) or the type signature for test :: Typeable a => R a a In the expression: first When checking that `first' (needed by a syntactic construct) has the required type: forall b1 c1 d1. R b1 c1 -> R (b1, d1) (c1, d1) arising from a proc expression at bug-arrow.hs:15:8-29 In the expression: proc n -> returnA -< n }}} When I replace the definition with the translated core code (minus type applications and scoped type variables) the code compiles: {{{ test :: Typeable a => R a a test = (>>>) (arr (\ (n_apd) -> n_apd)) ((>>>) (arr (\ (ds_dst) -> ds_dst)) (returnA) ) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7828> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7821: PPC cross-compile impossible happened
by GHC 13 Apr '13

13 Apr '13

#7821: PPC cross-compile impossible happened --------------------------------+------------------------------------------- Reporter: matts | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- While trying to build a powerpc targetted GHC cross compiler from current GIT head version I saw the impossible happened message below: echo 'export LD_LIBRARY_PATH=":$LD_LIBRARY_PATH"' >> inplace/bin/genapply echo 'exec "$executablename" ${1+"$@"}' >> inplace/bin/genapply chmod +x inplace/bin/genapply "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries /ghc-prim/dist-install/ build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim /dist-install/build -I libraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibra ries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEm ptyDataDecls -XNoImplicitPrelude -O -fasm -no-user-package-db -rtsopts -odir libraries/ghc -prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-pri m/dist-install/build -dynamic-too -c libraries/ghc-prim/./GHC/Classes.hs -o libraries/ghc-prim/ dist-install/build/GHC/Classes.o -dyno libraries/ghc-prim/dist- install/build/GHC/Classes.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.7.20130407 for powerpc-e500v2-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_nvZF Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Classes.o] Error 1 make[1]: *** Deleting file `libraries/ghc-prim/dist- install/build/GHC/Classes.o' -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7821> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3