October 2016 - ghc-tickets

[GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults
by GHC 30 Nov '16

30 Nov '16

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------+---------------------------------- {{{ -- test.hs import System.Mem (performMajorGC) main = performMajorGC >> putStrLn "Done" }}} built with `ghc -pgmlo opt -pgmlc llc -fllvm --make test.hs` segfaults both for LLVM 3.4 and 3.5svn (taken from http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64) 32-bit ghc-7.9.20140404+llvm produces good executable. Adding `ArchX86_64` `OSMinGW32` case to `moduleLayout` in `compiler/llvmGen/LlvmCodeGen/Ppr.hs` improves things slightly (some code segfaulting without it starts to work) but still does not cure the code above. Also I've found the Cmm produced for LLVM CG differs from that produced for NCG. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8974> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 52

[GHC] #12725: T7037 is broken on Windows
by GHC 30 Nov '16

30 Nov '16

#12725: T7037 is broken on Windows --------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- `T7037` appears to fail on Windows. Namely, `stdout` appears to be empty, whereas the expected output is `"ok"`. I had suspected that the issue was the `execv` call failing but this doesn't seem to be thew case; no code after `execv` is executed. A problem for another day... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12725> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12554: Testsuite exibits large amount of framework failures
by GHC 30 Nov '16

30 Nov '16

#12554: Testsuite exibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've tried this on multiple computers and they all have the same issue. I get around 400 testsuite failures with the error: {{{ r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run T11680 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T11797.run T11797 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11797.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T10734.run T10734 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T10734.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T11345.run T11345 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11345.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T10820.run T10820 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T10820.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T11484.run T11484 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11484.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T9022.run T9022 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T9022.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12130.run T12130 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12130.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T8761.run T8761 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T8761.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run T12407 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run T11463 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run T12478_4 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run T12478_3 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12513.run T12513 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12513.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12530.run T12530 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12530.run') }}} What they all have in common is that they are all using the latest MSYS2 and tools: {{{ Tamar@Squid MINGW64 ~/ghc $ python3 --version Python 3.5.2 Tamar@Squid MINGW64 ~/ghc $ uname -a MINGW64_NT-10.0 Kino 2.5.2(0.297/5/3) 2016-07-15 08:31 x86_64 Msys }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12554> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37

[GHC] #11219: Implement fine-grained `-Werror=...` facility
by GHC 29 Nov '16

29 Nov '16

#11219: Implement fine-grained `-Werror=...` facility -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: Design/Warnings -------------------------------------+------------------------------------- ...copied from Design/Warnings: Introduce variant of `-Werror` (c.f. GCC's `-Werror=*`) which allows to specify the individual warnings to be promoted to errors, e.g. - `-Wall -Werror=orphans` would only promote `-Worphans` warnings into errors - `-Wall -Werror -Wno-error=missing-methods` would promote all warnings //except// `-Wmissing-methods` into errors TODO: specify semantics a bit more exactly (the basic idea is to follow gcc/clang as much as sensible, and only deviate where it's necessary) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11219> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11629: reify returns Dec that use ConT instead of PromotedT
by GHC 29 Nov '16

29 Nov '16

#11629: reify returns Dec that use ConT instead of PromotedT -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11629> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9007: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object
by GHC 29 Nov '16

29 Nov '16

#9007: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object ----------------------------------+---------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- Building HEAD on Debian wheezy with the Debian packaging setup fails: {{{ configure: Building in-tree ghc-pwd /usr/bin/ld: utils/ghc-pwd/dist-boot/Main.o: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object; recompile with -fPIC utils/ghc-pwd/dist-boot/Main.o: could not read symbols: Bad value collect2: error: ld returned 1 exit status configure: error: Building ghc-pwd failed }}} http://deb.haskell.org/dailies/2014-04-16/ghc_7.9.20140416-0.daily_amd64.bu… This is possibly related to the Hardening flags added by Debian: {{{ ~ $ dpkg-buildflags --get LDFLAGS -Wl,-z,relro ~ $ dpkg-buildflags --get CFLAGS -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror =format-security }}} Other related bug might be #3668 and https://bugs.debian.org/712228 I’ll disable the hardening flags and see if it helps. The error first occurred 2014-03-27. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9007> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #11656: Alllow static pointers to local closed definitions
by GHC 29 Nov '16

29 Nov '16

#11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A limitation of the original patch implementing `-XStaticPointers` is that while the following all work, {{{#!hs t1 = static not t2 = static (\x -> case x of True -> False; False -> True) }}} the below does not: {{{#!hs t3 = static foo where foo True = False }}} Yet `foo` is perfectly "static": it's a closed expression that can readily be floated to top-level. So in short: `-XStaticPointers` should not consider only expressions with top-level identifiers, but in general any closed expression (which may involve local closed identifiers too). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11656> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #12558: GHCi Segmentation fault/access violation in generated code
by GHC 28 Nov '16

28 Nov '16

#12558: GHCi Segmentation fault/access violation in generated code ------------------------------+------------------------------- Reporter: lazac | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------+------------------------------- GHCi crashes with the error message `Segmentation fault/access violation in generated code`. The problem arises when trying to use the [https://github.com/haskell-tools/haskell-tools Haskell Tools project] from GHCi. The program can be successfully compiled with the ghc compiler. The cause of this behavior is that there are elements thats type is computed by a type family application. When I changed the representation to eliminate these, the problem was gone. I can turn the problem on and off only by adding an import or removing it. To solve the problem simply comment out the modules that use the information with the complex calculated type, as done in the attached diff. To try out use a minimal program: {{{#!hs module Main where import Language.Haskell.Tools.Refactor main = demoRefactor "" "." "A" }}} Execute the `ghci -package ghc -isrc\ast;src\ast-ghc;sr c\ast-trf;src\ast-ppr;src\ast-gen;src\refactor;src Main` command from the project root. That will search for a simple `A.hs` file in the working directory. A minimalistic module is enough to trigger the problem: {{{#!hs module A where }}} PS: I tried to create a smaller example, but the problem just appears and disappears without "reason" when I try to modify the code. (For example importing a module that is not actually used.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12558> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12686: Attempt to promote a value to a type results in an internal error
by GHC 28 Nov '16

28 Nov '16

#12686: Attempt to promote a value to a type results in an internal error -------------------------------------+------------------------------------- Reporter: johnleo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Trying to compile {{{#!hs {-# LANGUAGE GADTs, DataKinds, KindSignatures #-} data Nat = Zero | Succ Nat data Vec :: * -> Nat -> * where Nil :: Vec a 'Zero Cons :: a -> Vec a n -> Vec a ('Succ n) data Bad = Bad { a :: Nat, b :: Vec Int a} }}} results in `error: Not in scope: type variable ‘a’`. Change the last structure to {{{#!hs data Bad = Bad { a :: Nat, b :: Vec Int 'a} }}} and the result is {{{ • GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r15Y :-> ATcTyCon Bad, r17P :-> APromotionErr RecDataConPE] • In the second argument of ‘Vec’, namely ‘a’ In the type ‘Vec Int a’ In the definition of data constructor ‘Bad’ }}} The user is attempting to promote a value to a type, which cannot be done, but the error message should be more informative. Reproduces in 8.0.1 and 8.1.20160916. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12686> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12753: GHCi/Template Haskell: Don't panic on linker errors.
by GHC 27 Nov '16

27 Nov '16

#12753: GHCi/Template Haskell: Don't panic on linker errors. -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11042 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When the link editor is called by `Linker.hs` as part of loading a library and an error occurs GHCi panics. As a consequence users submit bug reports because the panic message tells them do do so. The link editor process can fail because of missing libraries, failure to create a link file, missing linker program, etc., all of which are beyond the control of GHC and should not be considered a bug in GHC. When the link editor fails 1. an error message should be printed and GHC should terminate if the error is fatal. 1. a warning (that could be silenced) should be issued in non-fatal cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12753> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1