June 2015 - ghc-tickets

[GHC] #10047: inconsistency in name binding between splice and quasiquotation
by GHC 04 Sep '15

04 Sep '15

#10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.4 Haskell | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Let me preface this by saying that this may not be a bug. If not then it would be nice if the documentation for Template Haskell could clarify what's going on here. My understanding of quasiquotation is that a quasiquote `[n|foo|]` is equivalent to a splice `$(quoteExp n "foo")`. However, that is not the case in all contexts. {{{ module Q where import Language.Haskell.TH import Language.Haskell.TH.Quote n = QuasiQuoter { quoteExp = dyn } }}} {{{ rwbarton@morphism:/tmp$ ghci -XTemplateHaskell -XQuasiQuotes Q 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. [1 of 1] Compiling Q ( Q.hs, interpreted ) Q.hs:6:5: Warning: Fields of ‘QuasiQuoter’ not initialised: quotePat, quoteType, quoteDec In the expression: QuasiQuoter {quoteExp = dyn} In an equation for ‘n’: n = QuasiQuoter {quoteExp = dyn} Ok, modules loaded: Q. *Q> :t [| $(dyn "foo") |] [| $(dyn "foo") |] :: ExpQ *Q> :t [| [n|foo|] |] Loading package pretty-1.1.1.1 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package template-haskell ... linking ... done. <interactive>:1:7: Not in scope: ‘foo’ In the Template Haskell quotation [| [n|foo|] |] }}} Why do these behave differently? (Lastly, the link to the paper "Why It's Nice to be Quoted: Quasiquoting for Haskell" in the User's Guide at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/template- haskell.html#th-quasiquotation is broken. Does this paper have a permanent home? In any case, I only skimmed it but it didn't seem to answer my question.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10047> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10541: Expose kind information for type variables with reify
by GHC 01 Sep '15

01 Sep '15

#10541: Expose kind information for type variables with reify -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The comment on [https://hackage.haskell.org/package/template- haskell-2.10.0.0/docs/Language-Haskell-TH-Syntax.html#v:TyVarI TyVarI] notes that the attached Type is always {{{VarT theName}}}, and that this could potentially be extended. Currently, there isn't a way to access kind information for a type variable through the Template Haskell API. It would be useful (at least for me) to have this ability here. The limitation on the returned Type comes from the [https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcSplice.hs#L1060 ATyVar clause of reifyThing], which zonks the TyVar to a GHC type and then uses reifyType to convert it to a TH type. For a TyVarTy, [https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcSplice.hs#L1281 reifyType] always returns {{{VarT theName}}}. I can see a few possible ways of exposing kind information here: (a) Fill the Type argument to TyVarI with {{{SigT (VarT theName) theKind}}}. This could be done either as a special case in place of the call to reifyType in reifyThing, or as a modification to reifyType's behavior. The question of when SigT should be included is open: all the time? when the kind isn't {{{*}}}? when the kind is something that involves more than {{{*}}} and {{{->}}}? (b) Change TyVarI from {{{TyVarI Name Type}}} to {{{TyVarI Name TyVarBndr}}}. This seems like the most straightforward, stable way of exposing kind information, but it requires a breaking API change. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10541> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9447: Add support for resizing `MutableByteArray#`s
by GHC 27 Aug '15

27 Aug '15

#9447: Add support for resizing `MutableByteArray#`s -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D133 -------------------------------------+------------------------------------- This is motivated by #9281 which changes how memory is allocated, and gives rise to the need to be able to efficiently shrink or grow `MutableByteArray#`s before they're frozen into `ByteArray#` while retaining their original byte content to avoid a major bottle-neck. This ticket is for tracking/documenting all changes related to this new facility. Here's the current road-map: 1. Implement {{{#!hs shrinkMutableByteArray# :: MutableByteArray# s -> Int# -> State# s -> State# s resizeMutableByteArray# :: MutableByteArray# s -> Int# -> State# s -> (# State# s, MutableByteArray# s #) }}} (see Phab:D133) 2. As suggested by Johan, {{{#!hs getSizeofMutableByteArray# :: MutableByteArray# s -> State# s -> (# State# s Int# #) }}} This is similar in spirit to `numCapabilities` and `getNumCapabilities`. Add a deprecate pragma (or equivalent) for `sizeofMutableByteArray#`. Add a note to `sizeofMutableByteArray#` stating that it's unsafe in the presence of calls to resize-operations on the same MBA. 3. Submit patches to upstream libraries replacing calls to `sizeofMutableByteArray#` with `getSizeofMutableByteArray#` 4. Investigate how to provide in-place (zero-copy) growing of MBAs (step 1. only implements in-place shrinking). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9447> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10032: --with-system-libffi not working on Solaris
by GHC 27 Aug '15

27 Aug '15

#10032: --with-system-libffi not working on Solaris -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.11 System | Operating System: Solaris Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hello, an attempt to configure ghc-7.10.1-rc2 with: {{{ $ ./configure --with-gmp-includes=/usr/include/gmp/ --with-gmp- libraries=/usr/lib/ --with-system-libffi --with-ffi- includes=/usr/lib/libffi-3.0.9/include/ --with-ffi-libraries=/usr/lib/ }}} results in kind of broken distribution, since gmake test_bindist fails with: {{{ bindisttest/"install dir"/bin/runghc bindisttest/HelloWorld > bindisttest/output diff -U 1 bindisttest/output bindisttest/expected_output No differences encountered bindisttest/"install dir"/bin/ghc --make bindisttest/HelloWorld [1 of 1] Compiling Main ( bindisttest/HelloWorld.lhs, bindisttest/HelloWorld.o ) Linking bindisttest/HelloWorld ... bindisttest/HelloWorld > bindisttest/output diff -U 1 bindisttest/output bindisttest/expected_output No differences encountered bindisttest/"install dir"/bin/ghc-pkg check --no-user-package-db There are problems in package rts-1.0: library-dirs: @FFILibDir@ is a relative path which makes no sense (as there is nothing for it to be relative to). You can make paths relative to the package database itself by using ${pkgroot}. include-dirs: @FFIIncludeDir@ is a relative path which makes no sense (as there is nothing for it to be relative to). You can make paths relative to the package database itself by using ${pkgroot}. The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. rts-1.0 ghc-7.10.0.20150123 haskeline-0.7.2.0 terminfo-0.4.0.1 xhtml-3000.2.1 transformers-0.4.2.0 hoopl-3.10.0.2 bin-package-db-0.0.0.0 Cabal-1.22.1.0 binary-0.7.3.0 template-haskell-2.10.0.0 pretty-1.1.2.0 hpc-0.6.0.2 process-1.2.2.0 directory-1.2.2.0 unix-2.7.1.0 time-1.5.0.1 containers-0.5.6.2 bytestring-0.10.6.0 deepseq-1.4.0.0 array-0.5.0.1 filepath-1.3.1.0 base-4.8.0.0 integer-gmp-1.0.0.0 ghc-prim-0.3.1.0 gmake[1]: *** [test_bindist] Error 1 gmake: *** [test_bindist] Error 2 }}} Honestly speaking I must add that even gmake binary-dist was not without issue since this expected ffi headers to be located in rts/dist/build directory but they were obviously not there. I've copied them manually and then binary-dist was able to run. I'm not sure if this is Solaris specific issue or if this also affects other Unix(-like) OSes. I mark that for 7.11 (HEAD) since I'm not sure I'll have a time to address this issue for 7.10.1-rc3/fcs. The workaround is easy, just let ghc use its own copy of ffi library and not the system provided one. In the long term however, having ghc using system provided one is better. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10032> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8096: Add fudge-factor for performance tests run on non-validate builds
by GHC 26 Aug '15

26 Aug '15

#8096: Add fudge-factor for performance tests run on non-validate builds ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Since I'm not going to get around to this immediately, Trac'ifying for posterity: These tests have been doing better than expected in the nightlies for some while. {{{ Unexpected failures: perf/compiler T3064 [stat too good] (normal) perf/compiler T3294 [stat too good] (normal) perf/compiler T5642 [stat too good] (normal) perf/haddock haddock.Cabal [stat too good] (normal) perf/haddock haddock.base [stat too good] (normal) }}} Unfortunately, fixing them is not a simple matter of shifting the ranges up, since the tests only exceed expectations on a /perf/ build, so on a normal build such as 'quick', these tests all pass normally. I could bump up the upper bounds so that the builder stops bleating about them; perhaps we could do something more complicated where the expected performance depends on what level of optimization GHC was built with (but I don't know how to implement this.) ---- The problem with just widening the bounds to cover 2 different types of build is that it increases the chance that performance changes won't actually be noticed by thge person responsible. Having different bounds for different build configurations is a pain, because (a) the testsuite has to work out which set of bounds to use, and (b) you now have even more wobbly values to keep up-to-date. I think perhaps the best thing would be to add some sort of (per-test?) fudge factor for non-validate builds. That way validate will still find performance regressions, like it does today, but other builds are less likely to give false positives. (Igloo) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8096> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9315: Weird change in allocation numbers of T9203
by GHC 26 Aug '15

26 Aug '15

#9315: Weird change in allocation numbers of T9203 ------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- While trying to improve our handle on allocation numbers, I’m stuck with the test case T9203. On some machines, it allocates roughly 95747304 bytes (this includes travis and my laptop), on others 42946176 bytes (e.g. on the machine where I monitor benchmark performance). All machines are 64 bit Linux machines. The output of `-ddump-simpl`, `-ddump-stg` and `-ddump-cmm` is identical (up to variable names). Even `-ddump-asm` looks the same, besides some jump target reordering. The binary runs too small to get a heap profile. I’m a bit stuck here: What can be the cause for these differences? (BTW, if have an up-to-date GHC tree, can you report the number you get? Run `make -C testsuite VERBOSE=4 TEST=9203` for that.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9315> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #9932: GHC fails to build when cross compiling for mingw with the message "Threads not supported"
by GHC 26 Aug '15

26 Aug '15

#9932: GHC fails to build when cross compiling for mingw with the message "Threads not supported" -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Keywords: Cross compiling | Operating System: Linux Architecture: x86 | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: 9542 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'm trying to build a mingw32 cross compiler. I configured with `./configure --target=x86_64-x64-mingw32`, then I built with `make -j 1`. The build then fails with the message ` # error "Threads not supported"` followed by some other errors. (The last part of the make log is attached) To bypass #9542, I deleted the following lines from utils/hsc2hs/Main.hs: {{{ #if defined(__GLASGOW_HASKELL__) && !defined(BUILD_NHC) #include "../../includes/ghcconfig.h" #endif }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9932> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9257: CC_CLANG_BACKEND not reconfigured during bindist install
by GHC 26 Aug '15

26 Aug '15

#9257: CC_CLANG_BACKEND not reconfigured during bindist install -------------------------------------+------------------------------------- Reporter: MtnViewMark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: clang | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Installing GHC Difficulty: Moderate (less | failed than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- 1) build GHC is built on a machine with clang -- project.mk ends up with the macro CC_CLANG_BACKEND=1 2) make binary-dist on that machine 3) bring that bindist to a machine that doesn't use clang 4) unpack the bindist, ./configure, make install This error ensues: cc1: error: unrecognized command line option "-Wno-invalid-pp-token" cc1: error: unrecognized command line option "-Wno-unicode" The problem rests in that there is on gcc invocation during that make install: /usr/bin/gcc -E ... rts/package.conf.in -o rts/dist/package.conf.install.raw This call is picking up arguments from RAWCPP_FLAGS, set in mk/config.mk, based on CC_CLANG_BACKEND, set in mk/project.mk... which was computed at build time. carter has hypothesized that adding the macro FP_CC_LLVM_BACKEND to distrib/configure.ac.in might fix this. In theory that will cause the config file that is bunded into the bindist to recompute the CC_CLANG_BACKEND flag at dist config time. However, this may not work because the only file that emits CC_CLANG_BACKEND is project.mk and that doesn't seem to get re-written during dist time config. -- so something else will be needed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9257> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10377: Remove double negative of ("Unregisterised", "NO")
by GHC 24 Aug '15

24 Aug '15

#10377: Remove double negative of ("Unregisterised", "NO") -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `settings` file has variable named `Unregisterised` which on most arches is sed to `NO`. I propose that the variable be renamed to `Registered` (dropping the "ised" part as well) so that: {{{ Old New ("Unregisterised", "NO") -> ("Registered", "YES") ("Unregisterised", "YES") -> ("Registered", "NO") }}} Unless someone can come up with a good reason why it should stay as it is, I will submit a patch for this to phabricator. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10377> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8
by GHC 24 Aug '15

24 Aug '15

#8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8 -------------------------------------------+------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Changing type signature of comparison primops from `Bool` to `Int#` in GHC 7.8 (see #6135) caused a problem: type signatures of functions might be different for the bootstrapping compiler (if it is older than 7.8) than they are for the stage1 compiler. In order to solve this problem I introduced a compatibility module [[GhcFile(compiler/utils/ExtsCompat46)]] that provides different definition of primops for older versions of GHC (`__GLASGOW_HASKELL__ <= 706`) and different for newer versions (`__GLASGOW_HASKELL__ > 706`). However, once we set minimal version of GHC required for bootstrapping to be 7.8, we can (and should!) remove that compatibility module and go back to using GHC.Exts. This ticket is a reminder that we should do this after we release GHC 7.10 or 7.12. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8330> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4