April 2013 - ghc-tickets

Re: [GHC] #7097: linker fails to load package with binding to foreign library
by GHC 15 Apr '13

15 Apr '13

#7097: linker fails to load package with binding to foreign library ----------------------------------+----------------------------------------- Reporter: nus | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.4.2 Keywords: | Os: Windows Architecture: x86 | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: 3658 | Blocking: Related: #2283 #3242 #1883 | ----------------------------------+----------------------------------------- Comment(by awson): I'd want to clarify things a bit here. Suppose we have some compiled dll exporting some function `foo`. Suppose we write a client program in C calling this `foo`. Regardless of how this `foo` is prototyped: as bare `foo` or as {{{__declspec(dllimport) foo}}} a client program will happily call it, but depending on a prototype in ''different ways'': in the first case this will be {{{call foo}}} and if this symbol is external a linker will generate a thunk for this `foo` as {{{jmp __imp_foo}}}, in the second case a C compiler always generates {{{call __imp_foo}}}. Thus the single thing matters here: '''which prototype of a function''' was visible to C compiler when it compiled a code calling that function. If that prototype had {{{__declspec(dllimport)}}} attribute attached, a C compiler generated a call against {{{__imp_foo}}}, otherwise - a call against bare {{{foo}}}. GHC FFI of modern era (with no C backend) always generates the second variant AFAIK. This also explains the difference between 32 and 64 GHCs for Windows. 64-bit GHC is distributed with mingw-w64 headers which use {{{__declspec(dllimport)}}} extensively, and many packages fail to compile. 32-bit GHC is distributed with mingw headers which has almost (or entirely?) no {{{__declspec(dllimport)}}} declared APIs. To make 64-bit GHC usable on Windows I manually removed all {{{__declspec(dllimport)}}} from mingw-w64 headers and now it all works smoothly. Hope this helps. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7097#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7463: [PATCH] When -keep-hc-files is enabled, foreign stubs *_stub.c should also be kept.
by GHC 15 Apr '13

15 Apr '13

#7463: [PATCH] When -keep-hc-files is enabled, foreign stubs *_stub.c should also be kept. ---------------------------------+------------------------------------------ Reporter: PHO | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Other Difficulty: Unknown | Testcase: Blockedby: | Blocking: 3472 Related: | ---------------------------------+------------------------------------------ Comment(by PHO): Ah, I forgot to tell you that [http://pkgsrc.se/wip/ghc pkgsrc-wip/ghc] has switched to the binary bootstrapping way, so it's ok for me to stop supporting HC bootstrap. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7463#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

15 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 looking at the diff and I don't think that I could possibly split it into smaller changes. The problem is that once you change one of the primops to return `Int#`, you have to change them all because they all fall into the same Compare category. And then you need to fix deriving of Eq and Ord. These are the smallest changes I was able to make and have the code compile. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:47> 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 benl): Work more incrementally. Change just a bit at a time and make sure all the codeGen tests work before doing the next part. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:46> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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