April 2015 - ghc-tickets

Re: [GHC] #3085: warn about language extensions that are not used
by GHC 06 Apr '15

06 Apr '15

#3085: warn about language extensions that are not used -------------------------------------+------------------------------------- Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: warnings Operating System: Unknown/Multiple | extensions language Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9757 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by asr): * cc: asr@… (removed) * cc: asr (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3085#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10191: Interactive linker crash when partially applying seq#
by GHC 06 Apr '15

06 Apr '15

#10191: Interactive linker crash when partially applying seq# -----------------------------------------+------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.4-rc1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+------------------------------- Consider the following commands: {{{#!hs :set -XMagicHash import GHC.IO import GHC.Prim IO (seq# ()) }}} When the last statement is run in GHCi, the following error message is displayed: {{{ ByteCodeLink.lookupCE(primop) During interactive linking, GHCi couldn't find the following symbol: ghczmprim_GHCziPrimopWrappers_seqzh_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} The expression works if I eta-unreduce the `seq#` call: `IO (\x -> seq# () x)`. The problem seems to be exclusive to GHCi: if you put that expression in a file, it works fine when compiled by GHC, and even GHCi works fine when using the resulting `.o` file. When there's no `.o` GHCi still crashes, and eta-unreduction doesn't help anymore (something to with optimizations I guess). I can also reproduce this on the Linux-x86 architecture. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10191> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8811: Profiling output jumbled together
by GHC 06 Apr '15

06 Apr '15

#8811: Profiling output jumbled together ------------------------------------+------------------------------------- Reporter: augustss | 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: | ------------------------------------+------------------------------------- In the time profile (-p), if the MODULE column is very wide and the no. column is also very wide they will run together with no space between. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8811> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10204: Odd interaction between rank-2 types and type families
by GHC 06 Apr '15

06 Apr '15

#10204: Odd interaction between rank-2 types and type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Type inference does work as expected, when a rank-2 type has type-family constraint. Consider the following program: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE Rank2Types #-} type family F a f :: (forall s. (F s ~ Int) => s -> b) -> b f _ = undefined k :: s -> Char k = undefined example :: Bool example = const True (f k) }}} It is rejected with the following error: {{{ Couldn't match type ‘b0’ with ‘Char’ ‘b0’ is untouchable inside the constraints (F s ~ Int) bound by a type expected by the context: (F s ~ Int) => s -> b0 at bug.hs:13:23-25 Expected type: s -> b0 Actual type: s -> Char In the first argument of ‘f’, namely ‘k’ In the second argument of ‘const’, namely ‘(f k)’ }}} This is unexpected because the result of `f` should be the same as the result of its parameter, and we know the exact type of the parameter, namely `Char`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10204> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10199: Sending SIGINT to a program that uses forkOS may crash with various errors
by GHC 06 Apr '15

06 Apr '15

#10199: Sending SIGINT to a program that uses forkOS may crash with various errors -------------------------------------+------------------------------------- Reporter: adeon | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.10.1 System | Operating System: Linux Keywords: | Type of failure: Runtime crash Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is the program: {{{#!hs module Main ( main ) where import Control.Concurrent import Control.Monad main :: IO () main = recursive 0 where recursive n = do tid <- forkIO $ do replicateM_ 100 $ forkOS $ return () replicateM_ (n `mod` 1000) yield recursive (n+1) }}} I was trying to investigate a potential issue with leaking StablePtrs in forkOS but that's another story. Compile with {{{ghc Main.hs -prof -auto-all -threaded -o Main}}}. Run as {{{./Main +RTS -h}}} (I don't know if it's absolutely necessary to turn heap profiling on but I have more trouble getting these error messages without it). Then, stop the program with SIGINT (by pressing CTRL+C or otherwise). The program sometimes crashes and produces one of the these two error messages: {{{ Main: internal error: RELEASE_LOCK: I do not own this lock: rts/Task.c 242 (GHC version 7.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{ Main: newBoundTask: RTS is not initialised; call hs_init() first }}} Sometimes the message may be slightly garbled (notice double internal error below): {{{ Î: internal error: Main: internal error: RELEASE_LOCK: I do not own this lock: rts/Task.c 242 (GHC version 7.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Replacing forkOS with forkIO seems to stop the messages. I can't reproduce this on FreeBSD. I'm using the downloaded binaries of 7.10.1 from GHC site on Arch Linux. I used this simple bash script to see more of these messages because it won't crash reliably: {{{#!bash #!/bin/bash while true; do timeout -s INT 0.2 ./Main +RTS -h done }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10199> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7961: Remove restrictions on promoting GADT's
by GHC 06 Apr '15

06 Apr '15

#7961: Remove restrictions on promoting GADT's -------------------------------------+------------------------------------- Reporter: danharaj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #6024 | Blocking: | Differential Revisions: Phab:D808 -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D808 Comment: I have posted an early version of my patch to implement kind equalities, fixing this ticket. Comments/experimentation welcome. It is easiest to access the branch from https://github.com/goldfirere/ghc, on the `nokinds` branch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7961#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9457: hsc2hs breaks with `--cflag=-Werror` in cross-compilation mode
by GHC 05 Apr '15

05 Apr '15

#9457: hsc2hs breaks with `--cflag=-Werror` in cross-compilation mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I would like to be able to do {{{ config_args='--target=i386-unknown-linux --with-gcc=i386-unknown-linux- gcc' ./validate }}} to validate a 32-bit GHC on a 64-bit Linux system. (I don't know why I have to specify `--with-gcc` in addition to `--target`; an unrelated mystery.) However `validate` sets `-Werror` and the C code that `hsc2hs` generates in cross-compilation mode is not always warning-free, e.g., {{{ Files.hsc: In function ‘_hsc2hs_test’: Files.hsc:81:14: error: variable ‘test_array’ set but not used [-Werror =unused-but-set-variable] cc1: all warnings being treated as errors }}} so `hsc2hs` draws incorrect conclusions from its tests. Either the `hsc2hs`-generated C code should be made (and kept) warning- free, or perhaps `hsc2hs` should append `-Wwarn` to the options that it passes to the C compiler. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9457> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10237: compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer
by GHC 05 Apr '15

05 Apr '15

#10237: compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Cross-compiling from linux-amd64 to linux-armhf and I get the above error message. The command (after removing a bunhc of irrelevant command line flags) is: {{{ inplace/bin/hsc2hs --cc=/usr/bin/aarch64-linux-gnu-gcc \ --ld=/usr/bin/aarch64-linux-gnu-gcc \ --cross-safe --cflag=-fno-stack-protector --cross-compile \ --cflag=-Daarch64_HOST_ARCH=1 \ --cflag=-Dlinux_HOST_OS=1 --cflag=-D__GLASGOW_HASKELL__=711 \ --cflag=-Icompiler/../rts/dist/build \ --cflag=-Werror=unused-but-set-variable \ --cflag=-include \ --cflag=compiler/stage2/build/autogen/cabal_macros.h \ compiler/ghci/LibFFI.hsc -o compiler/stage2/build/LibFFI.hs }}} The command `grep 'sizeof(ffi_cif)' compiler/ghci/LibFFI.hsc` finds: {{{#!hs cif <- mallocBytes (#const sizeof(ffi_cif)) }}} Native compile on this system works fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10237> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10243: SrcSpan incorrect for non-alphanumeric VarPat
by GHC 05 Apr '15

05 Apr '15

#10243: SrcSpan incorrect for non-alphanumeric VarPat -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- There is an inconsistency when parsing patterns which contain non- alphanumeric characters. For example, {{{!#hs foo (.) = 5 }}} the pattern parses as the following. {{{ (L {tests/examples/ArgPuncParens.hs:2:5-7} (VarPat (Unqual {OccName: .})))] }}} Then consider the following similar program. {{{#!hs foo (x) = 5 }}} The parse is as follows. {{{ (L {tests/examples/ArgPuncParens.hs:2:5-7} (ParPat (L {tests/examples/ArgPuncParens.hs:2:6} (VarPat (Unqual {OccName: x})))))] }}} Notice two differences. 1. The first parse lacks a surrounding `ParPat`. 2. If the `ParPat` is deliberately omitted then the given location encompasses the surrounding parentheses which is not consistent with the second example where `VarPat` specifically refers to `x`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10240: Build flavour 'quick-cross' tries to build integer-gmp
by GHC 03 Apr '15

03 Apr '15

#10240: Build flavour 'quick-cross' tries to build integer-gmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: cross- | Type of failure: None/Unknown compiling | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `BuildFlavour=quick-cross` setting is supposed to build `integer- simple` but some time after commit 5971ad56af it started trying to build `integer-gmp` regardless of the setting of `INTEGER_LIBRARY`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10240> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1