November 2013 - ghc-tickets

[GHC] #8131: T7571 with WAY=llvm fails, but not WAY=optllvm
by GHC 19 Jul '15

19 Jul '15

#8131: T7571 with WAY=llvm fails, but not WAY=optllvm ------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Test case (#7571 just will not die, it seems) {{{ $ make TEST=T7571 WAY=llvm ... ====> Scanning ./all.T =====> T7571(llvm) 6 of 7 [0, 0, 0] cd . && '/home/a/ghc/ghc-pristine/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm -fllvm -no-hs-main >T7571.comp.stderr 2>&1 Actual stderr output differs from expected: --- /dev/null 2013-08-07 22:18:14.132934017 -0500 +++ ./T7571.comp.stderr 2013-08-14 01:26:33.942103723 -0500 @@ -0,0 +1 @@ +WARNING: Non constant alignment value given for memcpy! Please report to GHC developers *** unexpected failure for T7571(llvm) }}} However, this test case does not fail under WAY=optllvm, which I think is worth investigating probably: {{{ $ make TEST=T7571 WAY=optllvm ... ====> Scanning ./all.T =====> T7571(optllvm) 6 of 7 [0, 0, 0] cd . && '/home/a/ghc/ghc-pristine/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm -O -fllvm -no-hs-main >T7571.comp.stderr 2>&1 OVERALL SUMMARY for test run started at Wed Aug 14 01:25:42 CDT 2013 7 total tests, which gave rise to 28 test cases, of which 27 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 0 unexpected failures }}} However, there is another way to trigger this bug in *both* cases: {{{ #include "Cmm.h" testMemcpy (W_ dst, W_ src, W_ l, W_ sz) { prim %memcpy(dst, src, l, sz); return (); } }}} will fail both ways. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8123: GHCi warns about -eventlog even though it's sometimes necessary
by GHC 19 Jul '15

19 Jul '15

#8123: GHCi warns about -eventlog even though it's sometimes necessary -------------------------+------------------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: GHCi | Operating System: Linux Keywords: | Type of failure: Incorrect warning at Architecture: | compile-time x86_64 (amd64) | Test Case: Difficulty: | Blocking: Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- If I invoke GHCi as {{{ghci -eventlog}}}, it says: {{{Warning: -debug, -threaded and -ticky are ignored by GHCi}}}. However, the flag does make a difference, in that GHCi will be able to load object files that were compiled using {{{-eventlog}}}. For this reason, I don't think {{{-eventlog}}} should trigger the warning. Also runghc has the same issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8123> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8206: Add support for Portable Native Client
by GHC 05 Jul '15

05 Jul '15

#8206: Add support for Portable Native Client -------------------------------------------------+------------------------- Reporter: guest | Owner: Alex Type: feature request | Sayers Priority: normal | Status: new Component: Compiler | Milestone: Keywords: NaCl PNaCl Portable Native | Version: Client pexe | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------------+------------------------- == Motivation == [http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable- native-client Portable Native Client] (PNaCl) is a feature in Google Chrome which (roughly) allows it to use LLVM bitcode like browsers use javascript today. The bitcode is downloaded, validated, compiled, and (safely) executed, with access to an API for manipulating the DOM of the page which loaded it. The dream: Haskell executed in the browser at near- native speed. Unfortunately, while GHC has an LLVM backend, the bitcode it generates doesn't satisfy the PNaCl validator. == Portable Native Client == The user visits a page with an <embed> tag pointing to a "pexe" - a PNaCl bitcode file. The bitcode is downloaded and streamed first into a code validator, and then into a compiler. The resulting machine code is then executed as a memory-protected process. The [https://developers.google.com /native-client/pepperc/ Pepper API], a library Google provides, provides access to the browser for things like connecting to websockets, playing audio, and communicating with javascript running on the page. PNaCl is present in Chrome 29 (go to chrome://flags to enable it), and will be enabled for arbitrary sources (the "open web") in Chrome 30. Mozilla have announced that they don't intend to support Native Client. == The Easily-Fixed == The pexe bitcode format is a frozen subset of LLVM bitcode. The PNaCl toolchain provides `pnacl-finalize`, which translates LLVM bitcode into pexe bitcode. PNaCl [http://www.chromium.org/nativeclient/pnacl/bitcode- abi##callingconventions only allows] the standard "ccc" calling convention, whereas GHC likes to use its own "cc 10" calling convention. You can make GHC use ccc by using an unregisterised build, for a slow-down factor of about 2. It seems likely that code-next-to-tables will upset the validator. If so, this can be turned off for a small performance hit. == The Not-So-Easily-Fixed == The validator requires that requests for IO are sent to Pepper. PNaCl also requires that you use newlib instead of glibc. Spawning new processes is forbidden (although creating pthreads is fine). It also seems likely that the validator with take umbrage at calls to `mmap`, which the GHC runtime uses to request memory allocation. It seems, therefore, that significant chunks of the RTS will have to be ported. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8206> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8353: Easy way to defer type errors
by GHC 04 Jul '15

04 Jul '15

#8353: Easy way to defer type errors ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A number of comments I've heard recently have focused on the joy of `-fdefer-type-errors`, especially for newcomers to Haskell. However, in GHCi, one has to 1. be aware that `-fdefer-type-errors` exists 2. know the `:set ...` syntax to turn it on, and then 3. is stuck with this setting on until they turn it off Instead, I propose new `:load!` and `:reload!` commands (abbreviated to `:l!` and `:r!`) which turn on `-fdefer-type-errors` just for that one command. When a load or reload fails, the error message could suggest these alternate forms. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8353> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8363: Order matters for unused import warnings when reexporting identifiers
by GHC 01 Jul '15

01 Jul '15

#8363: Order matters for unused import warnings when reexporting identifiers ------------------------------------+------------------------------------- Reporter: bergmark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Import order seem to change whether unused import warnings trigger when a module re-exports an identifier, with another module importing it and another module exporting the same identifier. Reproduction: {{{ module Foo ( (<$>) , g ) where import Control.Applicative g :: Int g = 1 }}} {{{ module Main where import Control.Applicative import Foo main :: IO () main = print =<< ((+2) <$> return g) }}} {{{ $ ghc -fwarn-unused-imports Main.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main ... }}} If Main is not using `g` then this gives a warning that the import of `Foo` is redundant. If we switch the order of the imports we do get the warning: {{{ module Main where import Foo import Control.Applicative main :: IO () main = print =<< ((+2) <$> return g) }}} {{{ > ghc -fwarn-unused-imports Main.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Main.hs:4:1: Warning: The import of `Control.Applicative' is redundant except perhaps to import instances from `Control.Applicative' To import instances alone, use: import Control.Applicative() Linking Main ... }}} I expected both versions of Main to produce the same warning. Tested on GHC 7.7.20130824 and 7.4.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8363> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8222: CTYPE pragma on newtype is ignored
by GHC 01 Jul '15

01 Jul '15

#8222: CTYPE pragma on newtype is ignored --------------------------+------------------------------------------------ Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 Compiler | Operating System: Linux Keywords: | Type of failure: Incorrect result at runtime Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ User's guide includes an example where a CTYPE pragma is used for a newtype. {{{ newtype {-# CTYPE "useconds_t" #-} T = ... }}} However, in the following program, the CTYPE pragma seems to be ignored: {{{ {-# LANGUAGE CApiFFI #-} import Foreign.Ptr foreign import capi unsafe "sys/socket.h CMSG_DATA" c_CMSG_DATA :: Ptr Cmsg -> Ptr a newtype {-# CTYPE "sys/socket.h" "struct cmsghdr" #-} Cmsg = Cmsg () main = return () }}} Save this as {{{capi.hs}}}, then compile it like: {{{ ghc capi.hs -fforce-recomp -keep-tmp-files -tmpdir . }}} Then GHC creates a C file: {{{ #define IN_STG_CODE 0 #include "Rts.h" #include "Stg.h" #ifdef __cplusplus extern "C" { #endif #include <sys/socket.h> void* ghczuwrapperZC0ZCmainZCMainZCCMSGzuDATA(void* a1) {return CMSG_DATA(a1);} #ifdef __cplusplus } #endif }}} The argument type of the wrapper function is {{{void *}}}, but it should be {{{struct cmsghdr *}}}. If I replace {{{newtype}}} with {{{data}}} in capi.hs, the wrapper function gets the correct type. I can see this problem in HEAD and in 7.6.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8222> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8144: Interface hashes include time stamp of included .h file when CPP is used
by GHC 25 Jun '15

25 Jun '15

#8144: Interface hashes include time stamp of included .h file when CPP is used -------------------------+------------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- See https://github.com/nh2/ghc-bug-time-dependent-interface-hashes for a fast test case. Having '''Test.hs''': {{{ {-# LANGUAGE CPP #-} module Test () where }}} and an empty '''cabal_macros.h''', {{{ touch cabal_macros.h ghc -c Test.hs -optP-include -optPcabal_macros.h }}} will generate you a different interface hash ''most of the time'' in '''ghc --show-iface Test.hi'''. It looks like the modification time of the .h file makes it into the interface hash, but only at second resolution, and you get ''compilation IS NOT required'' if you manage to run it twice per second. I think the interface hash should be independent from the time stamp of the header file. This bug can trigger unnecessary recompilation and makes compilations with identical inputs non-deterministic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8144> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34

[GHC] #8435: Do not copy stack after stack overflow
by GHC 12 Jun '15

12 Jun '15

#8435: Do not copy stack after stack overflow ------------------------------+-------------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I am not sure, but I was doing a close reading of `threadStackOverflow` and noticed that after we throw a stack overflow exception, we fall through to the code responsible for allocating a new stack and copying the code over. An old iteration of the stack overflow code (removed in the commit cited below) did return after throwing the exception, and I did not see anything in the commit message suggesting the change was intentional. It seems sound to copy the stack; it will just become dead immediately. The relevant commit: {{{ commit f30d527344db528618f64a25250a3be557d9f287 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Wed Dec 15 12:08:43 2010 +0000 Implement stack chunks and separate TSO/STACK objects }}} Suggested (untested) patch: {{{ diff --git a/rts/Threads.c b/rts/Threads.c index 742119d..ccd6b17 100644 --- a/rts/Threads.c +++ b/rts/Threads.c @@ -533,6 +533,7 @@ threadStackOverflow (Capability *cap, StgTSO *tso) // Send this thread the StackOverflow exception throwToSingleThreaded(cap, tso, (StgClosure *)stackOverflow_closure); + return; } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8435> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8172: Expose CWD and import search paths in GHCi via new `:show paths` command
by GHC 11 Jun '15

11 Jun '15

#8172: Expose CWD and import search paths in GHCi via new `:show paths` command -------------------------------------------+------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------------+------------------------------- - Currently, GHCi provides a `:cd` command but no respective builtin command to query the currently set path. - Moreover, there's no obvious way to query the currently active `importPaths` dynamic flags field, to find out which `-i` options are currently in effect. The attached patch extends `:show` with a `:show paths` subcommand, printing the CWD and the current value of `importPaths`: {{{ Ok, modules loaded: Main, InteractiveUI, Paths_ghci_ng, GhciMonad, GhciTags. λ> :show paths current working directory: /home/hvr/Haskell/My/ghci-ng module import search paths: dist/build/ghci-ng/ghci-ng-tmp ghc dist/build/autogen λ> :set -i λ> :show paths current working directory: /home/hvr/Haskell/My/ghci-ng module import search paths: none > :cd /tmp Warning: changing directory causes all loaded modules to be unloaded, because the search path has changed. > :show paths current working directory: /tmp module import search paths: none }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8172> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8244: Removing the Cabal dependency
by GHC 06 Jun '15

06 Jun '15

#8244: Removing the Cabal dependency ------------------------------------+------------------------------------- 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: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC depends on cabal, which is so far has been problematic many times, for many reasons. A few discussions include: * http://www.haskell.org/pipermail/haskell-cafe/2013-September/108746.html * http://www.haskell.org/pipermail/ghc-devs/2013-March/000821.html GHC uses only a very small part of Cabal, in these files: {{{ ./compiler/ghci/Linker.lhs ./compiler/main/Packages.lhs ./compiler/main/PackageConfig.hs ./compiler/main/Finder.lhs }}} plus 1 file for ghc-pkg: ./utils/ghc-pkg/Main.hs (see http://www.haskell.org/pipermail/haskell-cafe/2013-September/108750.html for details). It was proposed that either * the package format could be a plain specification without direct code dependencies * the Cabal package could be split off into Cabal-the-build-system and a minimal part to describe the package DB to be shared by Cabal and GHC The Cabal part that is used is in only a few modules of Distribution.* while the remaining majority of the Cabal-the-library package is not used (e.g. none of Distribution.Simple.*). Decoupling GHC and Cabal seems to be a public desire, yet there are some problems with these approaches. Let us discuss them in this ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8244> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38