March 2018 - ghc-tickets

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

13 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] #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

[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

[GHC] #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted
by GHC 12 Apr '18

12 Apr '18

#13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: simplifier | Operating System: Unknown/Multiple ticks | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: dynamic-paper | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- on ghc 8.2.1-rc2 on a mac running the latest Xcode and os {{{ make TEST=dynamic-paper WAY=profasm fails with ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone delta ... Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad it also fails with 1000 ticks make TEST=dynamic-paper WAY=profasm EXTRA_HC_OPTS='-fsimpl-tick- factor=1000' so there may be an infinite loop -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13715> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10010: LLVM/optimized code for sqrt incorrect for negative values
by GHC 10 Apr '18

10 Apr '18

#10010: LLVM/optimized code for sqrt incorrect for negative values -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (LLVM) | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The LLVM sqrt intrinsic is undefined below values of -0.0 See http://llvm.org/docs/LangRef.html#llvm-sqrt-intrinsic In some versions of LLVM it returns 0.0 in this case, but in newer versions the return value is undefined. This causes the result of Haskell's sqrt to vary at negative values based on the codegen and optimization flags chosen. {{{ main = print (sqrt (-7 :: Double)) }}} {{{ $ ghc -O -fllvm Sqrt.hs [1 of 1] Compiling Main ( Sqrt.hs, Sqrt.o ) Linking Sqrt ... $ ./Sqrt 0.0 $ ghc -O Sqrt.hs [1 of 1] Compiling Main ( Sqrt.hs, Sqrt.o ) Linking Sqrt ... $ ./Sqrt NaN }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10010> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8118: <stdout>: commitAndReleaseBuffer: invalid argument (invalid character)
by GHC 10 Apr '18

10 Apr '18

#8118: <stdout>: commitAndReleaseBuffer: invalid argument (invalid character) ----------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: OpenBSD Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I get the following error... {{{ <stdout>: commitAndReleaseBuffer: invalid argument (invalid character) }}} When running following program: {{{#!haskell {-# LANGUAGE OverloadedStrings #-} import qualified Data.Text as T import qualified Data.Text.IO as T main = T.putStrLn "čušpajž日本語" }}} Was tested in #haskell and I have all the UTF-8 Settings set and so forth. It compiles just fine, but crashes during runtime. gcc -v: {{{ Reading specs from /usr/lib/gcc-lib/amd64-unknown-openbsd5.4/4.2.1/specs Target: amd64-unknown-openbsd5.4 Configured with: OpenBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8118> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #10424: Build path leaks into ABI hashes
by GHC 09 Apr '18

09 Apr '18

#10424: Build path leaks into ABI hashes -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The build path of GHC leaks into the ABI hashes, i.e. if you build GHC in /tmp/fooADDF and then in /tmp/fooSDFS, you get different ABI hashes. This is a serious problem for distributions, as it means that we cannot rebuild the GHC package without rebuilding all Haskell packages as well. The (or at least one) problem is include paths. We have {{{ include-dirs: /home/jojo/build/haskell/ghc/rts/dist/build /home/jojo/build/haskell/ghc/includes /home/jojo/build/haskell/ghc/includes/dist- derivedconstants/header }}} in `inplace/lib/package.conf.d/builtin_rts.conf`, so when running the preprocessor, GHC passes this full path to the preprocessor: {{{ /usr/bin/gcc -E -undef -traditional -DOPTIMISE_INTEGER_GCD_LCM -include libraries/base/dist-install/build/autogen/cabal_macros.h -I libraries/base /dist-install/build -I libraries/base/dist-install/build -I libraries/base /dist-install/build/autogen -I libraries/base/include -I /home/jojo/build/haskell/ghc/libraries/integer-gmp/include -I /home/jojo/build/haskell/ghc/rts/dist/build -I /home/jojo/build/haskell/ghc/includes -I /home/jojo/build/haskell/ghc/includes/dist-derivedconstants/header '-D__GLASGOW_HASKELL__=711' -include /home/jojo/build/haskell/ghc/includes/ghcversion.h '-Dlinux_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dlinux_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' '-D__SSE__=1' '-D__SSE2__=1' -x assembler- with-cpp libraries/base/System/Info.hs -o /tmp/ghc14804_0/ghc14804_1.hscpp }}} It then reads the included files from the `hscpp` file : {{{ $ grep home /tmp/ghc14830_0/ghc14830_1.hscpp # 1 "/home/jojo/build/haskell/ghc/includes/ghcversion.h" 1 # 1 "/home/jojo/build/haskell/ghc/includes/ghcplatform.h" 1 }}} and puts it into the interface, where it becomes part of the hash: {{{ $ ./inplace/bin/ghc-stage1 --show-iface ./libraries/base/dist- install/build/System/Info.hi |grep Dep addDependentFile "/home/jojo/build/haskell/ghc/includes/ghcplatform.h" addDependentFile "/home/jojo/build/haskell/ghc/includes/ghcversion.h" addDependentFile "libraries/base/dist- install/build/autogen/cabal_macros.h" addDependentFile "/usr/include/stdc-predef.h" }}} Clearly, the end result is undesirable (changing hashes due to path names) and actually useless, as the build path will not be there later anyways. I’m not sure what the best way to fix this is. Here are a few ideas: * Do not include the path of `addDependentFile` entries in the hash, but only the file hash. Should solve the ABI hash. * Use relative paths in `inplace/lib/package.conf.d/builtin_rts.conf`. Not sure what breaks. This bug appeared in 7.8.4 and is present in both 7.10 and current HEAD. Any other ideas? (Debian bugreport at http://bugs.debian.org/785282) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10424> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h
by GHC 07 Apr '18

07 Apr '18

#12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12846 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Public symbols that we export in the public headers (rooted from Rts.h) need to be added to the symbols table of the RTS. We currently do this by hand but the list can quickly grow out of sync. Investigate a way to automate either the inclusion or a check during build time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12891> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18