April 2018 - ghc-tickets

[GHC] #9307: wave4main in nofib fails
by GHC 14 Apr '18

14 Apr '18

#9307: wave4main in nofib fails -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: NoFib benchmark | Version: 7.8.3 suite | Operating System: MacOS X Keywords: wave4main | Type of failure: Incorrect result Architecture: x86_64 (amd64) | at runtime Difficulty: Unknown | Test Case: wave4main Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Compiling HEAD with perf-llvm, (3.4.2) and running the nofib suite fails at the wave4main case. It is not clear to me whether wave4main should always produce the same output (and so the test fails because it does not do so) or whether the numbers generated depend on some feature of the build settings, or OS. {{{ HC = /Users/xxx/Projects/ghc/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -cpp -fglasgow-exts -rtsopts RUNTEST_OPTS = -ghc-timing ==nofib== wave4main: size of wave4main follows... __TEXT __DATA __OBJC others dec hex 4091904 450560 0 4295947176 4300489640 1005443a8 ==nofib== wave4main: time to run wave4main follows... ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; real 0m0.217s user 0m0.191s sys 0m0.011s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16932.1 2014-07-13 13:43:22.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.197s user 0m0.186s sys 0m0.008s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16961.1 2014-07-13 13:43:22.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.201s user 0m0.189s sys 0m0.009s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17011.1 2014-07-13 13:43:22.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.201s user 0m0.190s sys 0m0.008s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17051.1 2014-07-13 13:43:23.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.200s user 0m0.189s sys 0m0.009s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17080.1 2014-07-13 13:43:23.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 make: *** [runtests] Error 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9307> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
by GHC 14 Apr '18

14 Apr '18

#4245: ghci panic: thread blocked indefinitely in an MVar operation -------------------------------+-------------------------------------- Reporter: pturnbull | Owner: tibbe Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.12.3 Resolution: | Keywords: MVar Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by George): I can't reproduce this on 8.4.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4245#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10367: "ghc: panic! (the 'impossible' happened)"
by GHC 14 Apr '18

14 Apr '18

#10367: "ghc: panic! (the 'impossible' happened)" -------------------------------------+------------------------------------- Reporter: bgwines | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: panic | Operating System: MacOS X Architecture: | Type of failure: Runtime crash Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When running tasty-hunit tests through `cabal repl`, I get the following error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/l6/v2vhn_3j6bb1yvp6k5sh2hv80000gp/T/ghc80357_0/ghc80357_61.dylib, 9): Symbol not found: __hpc_tickboxes_horsezmcontrolzm0zi1zi0zi0_HorseziCommands_hpc Referenced from: /var/folders/l6/v2vhn_3j6bb1yvp6k5sh2hv80000gp/T/ghc80357_0/ghc80357_61.dylib Expected in: flat namespace in /var/folders/l6/v2vhn_3j6bb1yvp6k5sh2hv80000gp/T/ghc80357_0/ghc80357_61.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I have a hunch that it's because I enabled the following flags in my .cabal file, since I didn't get the exception before adding them: {{{ Test-Suite test-horse ... GHC-Options: -fhpc -hpcdir dist/hpc/horse-control-1.0 }}} When I run the tests via `cabal test`, I don't get the exception. I've created a branch that showcases the crash: https://github.com/bgwines /horse-control/tree/ghc-panic Repro steps: * clone repo * cd to repo * run `cabal repl` * run `:l Tests/test-horse.hs` * run `main` Reproducability: 100% Please feel free to contact me if there's information lacking, here! :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10367> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12870: Allow completely disabling +RTS options parsing
by GHC 13 Apr '18

13 Apr '18

#12870: Allow completely disabling +RTS options parsing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- I'd like to have a way to completely disable the +RTS flag so that a ghc- compiled binary does not eat it, but keeps it in `argv`/`getArgs` instead. This is needed whenever you try to make a program that's supposed to pass on all arguments, for example something like `ccache` or [https://github.com/fpco/pid1 pid1]. As you can imagine, swallowing +RTS argument's isn't great when you want to pass them on to a Haskell program. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12870> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO
by GHC 13 Apr '18

13 Apr '18

#14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO -------------------------------------+------------------------------------- Reporter: nickkuk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not sure whether such behavior is expected, but this program {{{ import System.IO main = fixIO (\x -> return 1) >>= print }}} prints "1"; and this {{{ import System.IO main = fixIO (\(x, _) -> return (1, print x)) >>= print . fst }}} prints "Main: thread blocked indefinitely in an MVar operation". Second program arises from something like {{{ {-# LANUGAGE RecursiveDo #-} main = mdo ... x <- return 1 let f = do ... print x ... ... return f }}} It is not necessary to call f somewhere in mdo to get "Main: thread blocked indefinitely in an MVar operation". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14356> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15032: GHCi panics when attempting to load archives
by GHC 13 Apr '18

13 Apr '18

#15032: GHCi panics when attempting to load archives --------------------------------------+------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.2-rc1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- If I have the following module: {{{#!hs module Numeric.Integer ( is_prime_ats ) where import Foreign.C foreign import ccall is_prime_ats :: CInt -> CBool }}} and I attempt to open it in GHCi with the following {{{ /opt/ghc/bin/ghci-8.4.2 -lnumbertheory -L../dist-newstyle/lib Numeric.Common }}} (with a file libnumertheory.a is in ../dist-newstyle/lib) I get a panic and a request to open a bug report. I am guessing that at the least this supposed to be a different error message. {{{ GHCi, version 8.4.1.20180329: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.4.1.20180329 for x86_64-unknown-linux): Loading archives not supported Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15032> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14708: GHC panics when linking with an archive and using an annotation
by GHC 13 Apr '18

13 Apr '18

#14708: GHC panics when linking with an archive and using an annotation -------------------------------------+------------------------------------- Reporter: tchajed | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC panics when compiling code with an annotation and linking with an archive (a `.a` file). I think this is the same as #9438, but I have a really simple test case consisting of the following two files: {{{#!c // add.c int add2(int x, int y) { return x + y; } }}} {{{#!hs -- app.hs {-# ANN module () #-} main :: IO () main = return () }}} First I make an archive: {{{ $ gcc -c add.c -o add.o $ ar libadd.a add.o }}} And then the following fails: {{{ $ ghc -ladd -L. app.hs [1 of 1] Compiling Main ( app.hs, app.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-apple-darwin): Loading archives not supported Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make: *** [app] Error 1 }}} The attached tar.gz has these source files and a Makefile to run the above. I've tested it on OS X 10.11 and Linux, both with GHC 8.2.2, and the behavior is the same. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14708> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb
by GHC 13 Apr '18

13 Apr '18

#7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Phab:D4567 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"a303584e58b3f4791bc5881cb722e7f498e14554/ghc" a303584e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a303584e58b3f4791bc5881cb722e7f498e14554" Fix processHeapClosureForDead CONSTR_NOCAF case: CONSTR_NOCAF was introduced with 55d535da10d as a replacement for CONSTR_STATIC and CONSTR_NOCAF_STATIC, however, as explained in Note [static constructors], we copy CONSTR_NOCAFs (which can also be seen in evacuate) during GC, and they can become dead, like other CONSTR_X_Ys. processHeapClosureForDead is updated to reflect this. Reviewers: bgamari, simonmar, erikd Subscribers: thomie, carter GHC Trac Issues: #7836 Differential Revision: https://phabricator.haskell.org/D4567 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7836#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15022: Stackage HEAD detected a suspicious change
by GHC 13 Apr '18

13 Apr '18

#15022: Stackage HEAD detected a suspicious change -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Here it goes: {{{ ==== SUSPICIOUS CHANGES stm-delay: at nightly-2018-04-05-5161609117c16cb7b29b2b8b1cd41e74341d4137.csv build succeeded, 2 test suites passed, 0 test suites failed at nightly-2018-04-05-3cfb12d8adac37e5565d66fd173e4648cc041e65.csv build succeeded, 1 test suites passed, 0 test suites failed There are changes that need attention of GHC team. }}} This not necessarily indicates a bug or regression, but the fact is, between these two commits 1 test suite stopped building. Maybe it's worth some investigation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families
by GHC 12 Apr '18

12 Apr '18

#8165: Use GeneralizedNewtypeDeriving to automatically create associated type families ------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- Here's a simple example: {{{ class C a where type T a instance C Int where type T Int = Bool newtype NT = NT Int deriving C }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8165> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23