May 2013 - ghc-tickets

Re: [GHC] #6135: Unboxed Booleans
by GHC 20 May '13

20 May '13

#6135: Unboxed Booleans -------------------------------+-------------------------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #605 -------------------------------+-------------------------------------------- Comment(by jstolarek): I have implemented the changes. Now I am left with cleaning up the code, writing more tests and verifying that there are no performance regressions. This will take some more time, but I would like to ask how should I prepare my patches (there will be a total of 7: ghc, testsuite and libraries: base, ghc-prim, integer-gmp, integer-simpl and primitive). Should I squash all the commits in my branches into one big commit or can I leave the commits as they are (or perhaps squash them selectively)? Which user documentation, if any, should I update (aside from the wiki page)? What information should be documented in the source code? There is one thing I wasn't able to implement the way I think it should be: constant folding for Integer. Each comparison function for Integer is now split into a primop, which returns an Int#, and a wrapper, which calls tagToEnum# and returns a Bool. The constant folding rules for Integer are working on the wrappers, so that whenever somebody writes ((1 :: Integer) == 1) it gets constant folded to True. This works properly and doesn't break any existing code, but is inconsistent with the rules for other comparisons, which are defined for primops, not for their wrappers. So the call to "`eqInteger 1 1`" (the wrapper) gets constant folded, while the call to "`eqInteger# 1 1`" (the primop) doesn't. I have run into problems with this (posted on ghc-devs on May 16th) and I don't know how to fix this. What is others' opinion on accepting the patches with this defect and opening a separate ticket for constant folding of Integer primops? I actually don't like that idea, but I'm afraid I might be stuck on this one for another 2 or 3 weeks - it would be a lot easier for me to push all the changes I have been making and then focus solely on Integer constant folding. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 20 May '13

20 May '13

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -----------------------------+---------------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- LLVM provides a number of atomicity / memory ordering primitives. currently the CAS primops exposed at the CMM level are ffi'd inline assembly fun calls. this means that for certain concurrency primops, we've got fun calls within funcalls that could be easily inlined if we did it in a more llvm direct way. A notable example of this is the implementation of {{{ stg_atomicModifyMutVarzh }}} relevant basic llmv docs are the following [http://llvm.org/docs/LangRef.html#cmpxchg-instruction Atomic llvm ops] [http://llvm.org/docs/Atomics.html semantics of the various ordering levels] relevant locations in the ghc source [https://github.com/ghc/ghc/blob/master/includes/stg/SMP.h#L170 CAS inline assembly] [https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L282 defn of atomicModifyMutVar cmm code] Based upon my reading of the relevant GHC cmm code, and reading the semantics of the LLVM operations, the right level of atomic ordering in the generated bit code would be "SequentiallyConsistent". a first step would be to modify the CMM -> LLVM pass to substitute the cas funcall with the right llvm operation. This ''' SEEMS ''' like it'd be very very easy to do and low hanging fruit. Theres a few upsides that ''' might ''' come out of this. 1. would be easy to augment to also provide a doubleCAS primitive, which would be useful in writing various lock free data structures. 2. would increase the portability / ease of retargeting new platforms / hardware via LLVM. (not needing to worry about the target's memory consistency model / write new cases of inline assembly) 3. (this would need benchmarks) could potentially improve the performance of certain heavy concurrency operations by eliminating a funcall in an otherwise tight loop. 4. Theres probably other interesting possible upside, such as perhaps having more of the rts be nicely writeable in CMM? (esp since theres now native funcall support) 5. Also would make the CMM memory model a bit more explicit perhaps? This seems like a *relatively* managable patch to write. I'm up for spending time on this if, should it work, it'd be likely to be merged in. it'd also be a good warm up for a number of other things I want to do, including http://hackage.haskell.org/trac/ghc/ticket/5567#comment:10 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7883> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7879: validate in build tree fails due to problem copying haddock resources to inplace
by GHC 19 May '13

19 May '13

#7879: validate in build tree fails due to problem copying haddock resources to inplace -----------------------------+---------------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I setup my build tree using the instructions here http://hackage.haskell.org/trac/ghc/wiki/Building/Using . After booting and configuring, I ran "sh validate" which eventually halted on the following command with the following error: "/Users/andreas/repos/temp-ghc-3/ghc-build/inplace/bin/haddock" --odir="libraries/ghc-prim/dist-install/doc/html/ghc-prim" --no-tmp-comp- dir --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim /ghc-prim.haddock --html --hoogle --title="ghc-prim-0.3.1.0: GHC primitives" --prologue="libraries/ghc-prim/dist-install/haddock- prologue.txt" --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-H32m --optghc=-O --optghc=-Werror --optghc=-Wall --optghc=-H64m --optghc=-O0 --optghc=-package-name --optghc =ghc-prim-0.3.1.0 --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim/dist- install/build --optghc=-ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc- prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc =-optP-include --optghc=-optPlibraries/ghc-prim/dist- install/build/autogen/cabal_macros.h --optghc=-package --optghc=rts-1.0 --optghc=-package-name --optghc=ghc-prim --optghc=-XHaskell98 --optghc=-XCPP --optghc=-XMagicHash --optghc=-XForeignFunctionInterface --optghc=-XUnliftedFFITypes --optghc=-XUnboxedTuples --optghc=-XEmptyDataDecls --optghc=-XNoImplicitPrelude --optghc=-O2 --optghc=-O --optghc=-dcore-lint --optghc=-fno-warn-deprecated-flags --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build libraries/ghc- prim/./GHC/Classes.hs libraries/ghc-prim/./GHC/CString.hs libraries/ghc- prim/./GHC/Debug.hs libraries/ghc-prim/./GHC/Magic.hs libraries/ghc-prim /dist-install/build/GHC/PrimopWrappers.hs libraries/ghc- prim/./GHC/IntWord64.hs libraries/ghc-prim/./GHC/Tuple.hs libraries/ghc- prim/./GHC/Types.hs libraries/ghc-prim/dist- install/build/autogen/GHC/Prim.hs +RTS -tlibraries/ghc-prim/dist- install/doc/html/ghc-prim/ghc-prim.haddock.t --machine-readable Haddock coverage: 78% ( 7 / 9) in 'GHC.Types' 17% ( 1 / 6) in 'GHC.CString' Warning: Couldn't find .haddock for export GHC.Prim.Int64# Warning: Couldn't find .haddock for export GHC.Prim.Word64# 3% ( 1 / 38) in 'GHC.IntWord64' 3% ( 2 / 63) in 'GHC.Tuple' 0% ( 0 / 3) in 'GHC.Debug' 0% ( 0 /342) in 'GHC.PrimopWrappers' 31% (164 /537) in 'GHC.Prim' 100% ( 3 / 3) in 'GHC.Magic' 38% ( 6 / 16) in 'GHC.Classes' haddock: internal error: /Users/andreas/repos/temp-ghc-3/ghc- build/inplace/lib/html/Ocean.std-theme/hslogo-16.png: copyFile: does not exist (No such file or directory) Apparently it can't find /Users/andreas/repos/temp-ghc-3/ghc- build/inplace/lib/html/Ocean.std-theme/hslogo-16.png. That file is in fact there, but it is linked to another file: ls -lh /Users/andreas/repos/temp-ghc-3/ghc-build/inplace/lib/html/Ocean .std-theme total 40 lrwxr-xr-x 1 andreas staff 80B Apr 28 13:13 hslogo-16.png -> ../../../../../../ghc/utils/haddock/resources/html/Ocean.std- theme/hslogo-16.png lrwxr-xr-x 1 andreas staff 76B Apr 28 13:13 minus.gif -> ../../../../../../ghc/utils/haddock/resources/html/Ocean.std- theme/minus.gif lrwxr-xr-x 1 andreas staff 76B Apr 28 13:13 ocean.css -> ../../../../../../ghc/utils/haddock/resources/html/Ocean.std- theme/ocean.css lrwxr-xr-x 1 andreas staff 75B Apr 28 13:13 plus.gif -> ../../../../../../ghc/utils/haddock/resources/html/Ocean.std- theme/plus.gif lrwxr-xr-x 1 andreas staff 79B Apr 28 13:13 synopsis.png -> ../../../../../../ghc/utils/haddock/resources/html/Ocean.std- theme/synopsis.png piz-sardona:ghc-build andreas$ cd /Users/andreas/repos/temp-ghc-3/ghc- build/inplace/lib/html/Ocean.std-theme It seems to be trying to link to utils/haddock/resources/html/Ocean.std- theme/hslogo-16.png in my source tree. But the problem is that there is one too many ".." in the links. If there were one fewer ".." in the path, then it would work fine. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7879> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7592: Building the latest master branch on FreeBSD 9.1 fails
by GHC 19 May '13

19 May '13

#7592: Building the latest master branch on FreeBSD 9.1 fails -----------------------------+---------------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following sequence fails on FreeBSD 9.1: {{{ % perl boot % ./configure --prefix=/ghc-head --with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp- includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with- gcc=/usr/local/bin/gcc47 --with-gcc-4.2=/usr/local/bin/gcc47 % gmake -j10 -d MAKE=gmake ... Putting child 0x801e5fd80 (ghc/stage1/package-data.mk) PID 36063 on the chain. Recipe of `ghc/stage1/package-data.mk' is being run. Pruning file `compiler/stage1/package-data.mk'. Live child 0x801e5fd80 (ghc/stage1/package-data.mk) PID 36063 Configuring ghc-bin-7.7.20130111... Warning: 'data-dir: ..' is a relative path outside of the source tree. This will not work when generating a tarball with 'sdist'. Reaping winning child 0x801e5fd80 PID 36063 Removing child 0x801e5fd80 PID 36063 from chain. Considering target file `ghc/stage1/package-data.mk'. File `ghc/stage1/package-data.mk' was considered already. Re-executing[2]: gmake -r --no-print-directory -f ghc.mk phase=0 phase_0_builds GNU Make 3.82 Built for amd64-portbld-freebsd9.1 Copyright (C) 2010 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. Reading makefiles... Reading makefile `ghc.mk'... ghc.mk:84: *** Make has restarted itself 2 times; is there a makefile bug?. Sto p. Reaping losing child 0x80156e290 PID 34605 gmake: *** [all] Error 2 Removing child 0x80156e290 PID 34605 from chain. }}} If I type "gmake -j10 MAKE=gmake" gain, the building completes. I believe this is relating to http://www.haskell.org/pipermail/glasgow- haskell-users/2012-March/022150.html Actually if I remove "error" on line 84, this does not happen and the building completes without any problems. GHC for bootstrapping: 7.4.1, GCC 4.7.3, gmake: 3.82 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7592> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #7834: dyn way and INTEGER_LIBRARY=integer-simple
by GHC 19 May '13

19 May '13

#7834: dyn way and INTEGER_LIBRARY=integer-simple -----------------------------+---------------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- a standard bootstrap with {{{ perl boot ./configure make INTEGER_LIBRARY=integer-simple }}} causes some problems: 1. there is a panic (at least when `-j4`) "fromJust..." (which strangely disappears on the second attempt) 2. `__word_encode{Float|Double}` is not found by the linker. There are `__int_encode{Float|Double}` symbols available, though, and changing the source helps for linking, but not for correctness, obviously. I'll add specific details (if not trivially reproducible) as soon as I am back at my dev machine. The bottom line is that since GHC HEAD now builds the 'dyn' way by default, this kind of bootstrap always fails. Normally not a problem on desktop linux, but in combination with a gmp-less embedded linux and cross-compiling it becomes annoying. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7834> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7920: type-checker panic (kindFunResult)
by GHC 18 May '13

18 May '13

#7920: type-checker panic (kindFunResult) -------------------------------+-------------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.6.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- {{{ *Main> :t (() :: m () -> t m) () () <interactive>:1:1: Couldn't match kind `* -> *' with `OpenKind' Expected type: () -> t0 Actual type: () -> t0 Kind incompatibility when matching types: t_n :: * -> * t0 :: OpenKind The function `() ::ghc: panic! (the 'impossible' happened) (GHC version 7.6.2 for x86_64-unknown-linux): kindFunResult <<details unavailable>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7920> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7917: update documentation of InstalledPackageInfo
by GHC 17 May '13

17 May '13

#7917: update documentation of InstalledPackageInfo -----------------------------+---------------------------------------------- Reporter: Lemming | Owner: Type: task | Status: new Priority: normal | Component: Documentation Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- When writing a binding to a foreign package that does not support pkg- config, it seems to be essential to know what the fields of InstalledPackageInfo precisely mean. I find the current description in section 4.9.8 of the GHC doc too short. What does extra-ghci-libraries mean? It is undocumented. In which field I should list shared objects? In which field I should enumerate static link libraries? Which libraries are used when compiling with -dynamic option and which ones are used for static linking? Are the library paths used both for static and dynamic link libraries? Which fields affect compilation of included C files? Which fields affect GHCi and which ones affect GHC? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7917> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7915: Documentation uses deprecated record GADT syntax
by GHC 16 May '13

16 May '13

#7915: Documentation uses deprecated record GADT syntax ------------------------------+--------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Documentation bug | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- Trivial patch attached. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7915> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7268: Explicit type signatures for top level record pattern matches polymorphism fail
by GHC 16 May '13

16 May '13

#7268: Explicit type signatures for top level record pattern matches polymorphism fail ---------------------------------------------+------------------------------ Reporter: TristanAllwood | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.4.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: typecheck/should_compile/T7268 | Blockedby: Blocking: | Related: ---------------------------------------------+------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I'm glad it's helpful. Thanks for pointing out the bug in the regression test...I've just pushed a fix. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7268#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7268: Explicit type signatures for top level record pattern matches polymorphism fail
by GHC 16 May '13

16 May '13

#7268: Explicit type signatures for top level record pattern matches polymorphism fail ---------------------------------------------+------------------------------ Reporter: TristanAllwood | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.4.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: typecheck/should_compile/T7268 | Blockedby: Blocking: | Related: ---------------------------------------------+------------------------------ Changes (by MartijnVanSteenbergen): * owner: simonpj => * status: closed => new * resolution: fixed => Comment: Hi Simon, looking at testcase T7891, wouldn't it be better to uncomment line 12 so that it becomes an actual regression test? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7268#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0