May 2016 - ghc-tickets

[GHC] #12056: Too aggressive `-w` option
by GHC 12 Jun '17

12 Jun '17

#12056: Too aggressive `-w` option -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- By running {{{ ghc -w -Wunrecognised-warning-flags -Wfoo Main.hs }}} I would expect the warning {{{ on the commandline: warning: unrecognised warning flag: -Wfoo }}} however this warning isn't reported. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #11501: Building nofib/fibon returns permission denied
by GHC 08 Jun '17

08 Jun '17

#11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib | Version: 7.10.3 benchmark suite | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Building nofib/fibon returns permission denied: {{{ == make boot - --no-print-directory; in /h/ywang30/nofib/fibon/Hackage/Bzlib ------------------------------------------------------------------------ // Codec/Compression/BZip/Stream.hsc make[3]: execvp: //: Permission denied make[3]: *** [Codec/Compression/BZip/Stream.hs] Error 127 }}} Steps to reproduce: Edit nofib/mk/boilerplate.mk:35 to NoFibSubDirs = fibon make clean && make boot in nofib/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11501> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #11317: Test prog003 fails with segfault on Windows (GHCi)
by GHC 07 Jun '17

07 Jun '17

#11317: Test prog003 fails with segfault on Windows (GHCi) --------------------------------------+------------------------------- Reporter: rdragon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: #11234 Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- On my `x86_64` Windows machine test `prog003` fails with a segfault: {{{ cd ./ghci/prog003 && ghciWayFlags=-static HC="/home/Rik/ghc/inplace/bin /ghc-stage2.exe" HC_OPTS="-dcore-lint -dcmm-lint -dno-debug-output -no- user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history " "/home/Rik/ghc/inplace/bin/ghc-stage2.exe" -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS <prog003.script > prog003.run.stdout 2> prog003.run.stderr >> prog003.run.stdout 2>> prog003.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Run 1 a :: Int -> Int 168 Run 2 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 3 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 4 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 5 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 6 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 7 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 8 Segmentation fault/access violation in generated code Stderr: *** unexpected failure for prog003(ghci) }}} (I do not think it is an access violation error since when I remove [https://github.com/ghc/ghc/blob/c2fab84239299176a8e72aa26ae894019d677bd9/te… line 65] and everything below line 70, the same stdout is generated.) This looks related to ticket #11234. The GHC version used was [http://git.haskell.org/ghc.git/commit/df6cb57b32d94b7f6f7c9a86207adfeee9712… df6cb57b32d94b7f6f7c9a86207adfeee9712ed6], although I already noticed the problem with a version a few days older. If someone could point me to information about how to install GDB suitable for debugging GHC on my Windows machine I will try to post the stack trace. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11317> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8703: Use guard pages rather than heap checks
by GHC 07 Jun '17

07 Jun '17

#8703: Use guard pages rather than heap checks ------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- By mmap'ing memory using MAP_ANONYMOUS (or /dev/zero) as PROT_NONE (Windows has an equivalent functionality with VirtualAlloc), it's possible to create a page that will fault when read or written to. It may be possible to remove the heap checks in the runtime, speeding up allocations, and instead expand the heap when a fault is raised. This is likely cheaper for large pages full of many small allocations than the cost of the heap checking branch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8703> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code
by GHC 05 Jun '17

05 Jun '17

#10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- `-fwarn-incomplete-patterns` doensn't seem to generate any warnings when `-fno-code` is specified. To reproduce, save this module as `foo.hs`. {{{#!hs module Foo where foo True = 4 }}} and compile with `-fwarn-incomplete-patterns`, with and without `-fno- code`. {{{ % ghc -fwarn-incomplete-patterns -fforce-recomp foo.hs [1 of 1] Compiling Foo ( foo.hs, foo.o ) foo.hs:2:1: Warning: Pattern match(es) are non-exhaustive In an equation for ‘foo’: Patterns not matched: False % ghc -fwarn-incomplete-patterns -fforce-recomp -fno-code foo.hs [1 of 1] Compiling Foo ( foo.hs, nothing ) % }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #11032: Missing result type handling for State# s in foreign import prim.
by GHC 02 Jun '17

02 Jun '17

#11032: Missing result type handling for State# s in foreign import prim. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (FFI) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been using `foreign import prim` for a while now to craft custom primops on an as-needed basis. Attempting to write {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE UnliftedFFITypes #-} {-# LANGUAGE GHCForeignImportPrim #-} {-# LANGUAGE ForeignFunctionInterface #-} foreign import prim "pinThreadzh" pinThread# :: State# s -> (# State# s, Int#, Int# #) foreign import prim "unpinThreadzh" unpinThread# :: State# s -> State# s }}} threw me for a loop when it didn't work. The former works fine. The latter complains that `State# s` isn't a valid result type! {{{ src/Concurrent/Internal/Thread.hs:23:1: Unacceptable result type in foreign declaration: ‘State# s’ cannot be marshalled in a foreign call When checking declaration: foreign import prim safe "static unpinThreadzh" unpinThread# :: State# s -> State# s }}} Builtin primitives work this way all the time, so I'm guessing we just missed it in a case statement somewhere inside the compiler when dealing with `foreign import prim` support. I can likely hack around it by giving back something like `(# State# s #)` for now but that is a rather unsatisfying solution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11032> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11834: GHC master, not compiling on Archlinux
by GHC 29 May '17

29 May '17

#11834: GHC master, not compiling on Archlinux -------------------------------------+------------------------------------- Reporter: nitrix | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Linking) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- /usr/bin/ld: -r and -pie may not be used together http://lpaste.net/159726 It appears on Archlinux, with GCC version 5.3.0, there's an implicit -pie flag passed to `ld`. I looked into compiler/main/DriverPipeline.hs at joinObjectFiles, it is unconditionally doing "-Wl,-r", thus the error above. One suggested fix on IRC is to modify getCompilerInfo to know if it supports -no-pie, then add it to the flags that are used. I tried and got somewhere lost in compiler/main/DynFlags.hs. (Completely new to GHC) Hopefully someone can figure it out, it seems important for development and I really want to get involved :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11834> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF
by GHC 26 May '17

26 May '17

#8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF ------------------------------+-------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- The code generator unnecessarily spills and reloads function arguments if the scrutinee turns out to be already evaluated (i.e. has non-zero tag bits). Here's the beginning of a function body, taken from the `insert` function at https://github.com/tibbe/unordered- containers/blob/master/Data/HashMap/Base.hs#L303: {{{ c2wQ: // stack check if ((Sp + -72) < SpLim) goto c2wR; else goto c2wS; c2wR: // stack check failure R1 = PicBaseReg + $wpoly_go_closure; I64[Sp - 40] = R2; I64[Sp - 32] = R3; P64[Sp - 24] = R4; I64[Sp - 16] = R5; P64[Sp - 8] = R6; Sp = Sp - 40; call (I64[BaseReg - 8])(R1) args: 48, res: 0, upd: 8; c2wS: // stack check success I64[Sp - 40] = PicBaseReg + block_c2my_info; // return addr for eval R1 = R6; // t I64[Sp - 32] = R2; // spill: s I64[Sp - 24] = R3; // spill: x P64[Sp - 16] = R4; // spill: k I64[Sp - 8] = R5; // spill: h Sp = Sp - 40; if (R1 & 7 != 0) goto c2my; else goto c2mz; // eval check of t c2mz: // eval check failed call (I64[R1])(R1) returns to c2my, args: 8, res: 8, upd: 8; // eval c2my: // eval check succeeded _s2b1::I64 = I64[Sp + 8]; // reload: h _s2b2::I64 = I64[Sp + 16]; // reload: k _s2b3::P64 = P64[Sp + 24]; // reload: x _s2b4::I64 = I64[Sp + 32]; // reload: s switch [0 .. 4] (R1 & 7 - 1) { case 0 : goto c2wK; case 1 : goto c2wL; case 2 : goto c2wM; case 3 : goto c2wN; case 4 : goto c2wO; } }}} It seems to me that all the spills/reloads could be pushed into the `c2mz` block. The `c2my` block, in its current form, is reused for a heap check failure case, so the heap check most likely will have to do its own spilling/reloading. However, since the scrutinee not having tags bit or the eval checking failing is not the common case, they should be out of the common path. If it matters the data type is spine strict so GHC should have enough information to know that the common case (e.g. self-recursive calls) already have an evaluated argument (although there might be an indirection in some cases). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8905> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10421: exponential blowup in inlining (without INLINE pragmas)
by GHC 26 May '17

26 May '17

#10421: exponential blowup in inlining (without INLINE pragmas) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The test case for #10397 also demonstrates an exponential blowup by the inliner, without any INLINE pragmas. I added another four fields to the `Register` type, and I get these final Core program sizes. (The variation in sizes between versions is not really important, the point is just that they are very large for all versions.) {{{ ghc-7.6.3: *** CorePrep: Result size of CorePrep = {terms: 1,702,684, types: 1,950,647, coercions: 103} ghc-7.8.4: *** CorePrep: Result size of CorePrep = {terms: 1,964,183, types: 1,950,620, coercions: 97} ghc-7.10.1: *** CorePrep: Result size of CorePrep = {terms: 1,964,212, types: 1,950,764, coercions: 97} ghc-7.11: *** CorePrep: Result size of CorePrep = {terms: 1,964,212, types: 1,950,764, coercions: 97} }}} Ideally GHC should not produce enormous Core programs on its own like this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty`
by GHC 23 May '17

23 May '17

#10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #1062, #1176, Differential Revisions: | #7666 -------------------------------------+------------------------------------- GHC has an internal copy of `pretty` in `compiler/utils/Pretty.hs`. Todo: * refactor GHC's copy to make it as similar as possible to `pretty`, without making any real code changes. * apply the bug fixes that `pretty` received to GHC's copy, making sure not to pick up any possible new bugs in the process. According to (1): "There is one situation where the laws for pretty are ambiguous and leave room for choice. GHC decided one way and pretty the other." * Find which law that is, and document the differences. This hopefully allows us to close the following tickets for free: #1062, #1176 and #7666, maybe more. Ideally we could remove GHC's copy altogether, but we're not there yet. GHC's copy uses FastString, which is supposedly needed for performance, whereas pretty uses `String`. (1) https://github.com/haskell/pretty/issues/1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26