December 2016 - ghc-tickets

[GHC] #12982: Missed constant folding oportunities
by GHC 17 Apr '18

17 Apr '18

#12982: Missed constant folding oportunities -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: | Version: 8.0.1 libraries/hoopl | 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 work colleague of mine found that some expressions were not being constant folded as expected. For example: {{#!hs module Test where import Data.Int number :: Int64 number = 2 ^ 10 - 3 }}} compiled using: {{{ ghc -O2 -keep-s-file -c test.hs }}} should result in an assembler file containing the constant `1021` but doesn't. However, if I change the above expression to: {{{ number = 1024 -3 }}} then the output assembler files does contain the value `1021`. I did a bit of a search and found some constant folding code in the `hoopl` library, but that doesn't seem to be what GHC actually uses. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12982> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11117: mdo blocks in error messages are shown modified
by GHC 17 Apr '18

17 Apr '18

#11117: mdo blocks in error messages are shown modified -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE RecursiveDo #-} main = mdo Just x <- return (Right x) return () }}} gives {{{ MdoTypeError.hs:3:3: Couldn't match expected type ‘Either a0 b0’ with actual type ‘Maybe b0’ Relevant bindings include x :: b0 (bound at MdoTypeError.hs:3:8) In the pattern: Just x In a stmt of an 'mdo' block: Just x <- return (Right x) In a stmt of an 'mdo' block: rec { Just x <- return (Right x) } }}} Note that the error message mentions `rec` even though that is not what the user entered. In other instances, we are careful to show the code more similar to the original (e.g. `do`-notation instead of `>>=`). This should also be done here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11117> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10920: ghci can't load local Prelude module
by GHC 14 Apr '18

14 Apr '18

#10920: ghci can't load local Prelude module -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- I have a `Prelude.hs` file which contains {{{#!hs module Prelude where }}} If I invoke `ghci` from the same directory, I get {{{ Top level: attempting to use module ‘Prelude’ (./Prelude.hs) which is not loaded }}} Note: `ghc --make` correctly compiles modules that use the local `Prelude.hs`, so I expect `ghci` to handle that case too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10920> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10631: Report of GHC Panic
by GHC 14 Apr '18

14 Apr '18

#10631: Report of GHC Panic -------------------------------------+------------------------------------- Reporter: seewalker | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I'll just copy here the error message; I wouldn't say I have the judgement to interpret it: ''ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/84/5rj51n8x70g4km60lfh_ds1m0000gt/T/ghc22694_0/libghc22694_107.dylib, 5): Symbol not found: _AlexSzuELoZZpfyhWUk8IXGTl3Kiel_ModulesziDBTypes_zdfPersistFieldLinkTag_closure Referenced from: /var/folders/84/5rj51n8x70g4km60lfh_ds1m0000gt/T/ghc22694_0/libghc22694_107.dylib Expected in: flat namespace in /var/folders/84/5rj51n8x70g4km60lfh_ds1m0000gt/T/ghc22694_0/libghc22694_107.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug'' This occurred while interactively developing a website with "yesod devel". After the compiler crashed, I killed the program, invoked "yesod devel" again without changing anything in my source code. This next time, no error occurred. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10631> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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

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