May 2017 - ghc-tickets

[GHC] #13380: raiseIO# result looks wrong
by GHC 20 Apr '18

20 Apr '18

#13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `primops.txt.pp` includes the following note: > `raiseIO#` needs to be a primop, because exceptions in the `IO` monad must be ''precise'' - we don't want the strictness analyser turning one kind of bottom into another, as it is allowed to do in pure code. > > But we ''do'' want to know that it returns bottom after being applied to two arguments, so that this function is strict in `y` > {{{#!hs > f x y | x>0 = raiseIO blah > | y>0 = return 1 > | otherwise = return 2 > }}} I believe the "But we do" portion is, unfortunately, entirely wrong. From a user perspective, it is extremely strange to replace a precise exception with an imprecise one. That is, I strongly believe the above code should be considered ''lazy'' in `y`. The function `f` calculates an `IO` action; the value of `y` is only necessary to calculate that action if `x` is non- positive. We can, conservatively, say for certain that the second component of the result of `raiseIO#` (i.e., the "return value") is bottom. We can also say, given {{{#!hs case raiseIO# e s of (# s', r #) -> q }}} that `q` is dead (we could replace it by `(# s', undefined #)`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13380> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #13276: Unboxed sums are not Typeable
by GHC 20 Apr '18

20 Apr '18

#13276: Unboxed sums are not Typeable -------------------------------------+------------------------------------- Reporter: Ben Gamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While the Typeable machinery introduce in the type-indexed Typeable rework (#11011) is fully capable of representing unboxed sums, we currently don't allow this since it would require that we generate an enormous number of bindings in `GHC.Types`. This is because we need to generate both `TyCon` and `KindRep` bindings for each type constructor and its promoted data constructors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13261: Consider moving Typeable evidence generation wholly back to solver
by GHC 20 Apr '18

20 Apr '18

#13261: Consider moving Typeable evidence generation wholly back to solver -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | 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: -------------------------------------+------------------------------------- Since 91c6b1f54aea658b0056caec45655475897f1972 we have generated a set of bindings with each datatype definition which the compiler will refer to when constructing `Typeable` evidence. As described in the commit message, this came with a rather significant performance penalty, especially given that it is paid regardless of whether the code being compiled uses `Typeable`. The type-indexed Typeable implementation (#11011) augments these bindings with additional information allowing the kind of a type of be reconstructing at runtime (#10343). Unfortunately, this further blows up the cost of associated with Typeable binding generation. Some of the testsuite regressions are hard to swallow to say the least. While I'm still working out what can be done to reduce this cost, I do wonder whether the generating these bindings at the time of type definition is so wise. Relatively few users make use of Typeable and the cost is not negligible. Moreover, generating bindings for families of tycons (e.g. unboxed sums, which have thousands of type constructors and promoted data constructors) all at once produces a truly massive amount of code (albeit it only has to be done once). On the other hand, I suppose if Richard's dependent types story comes to fruition then perhaps the weight imposed by generating Typeable bindings at type-definition time might pull its weight. Anyways, just idle reflections. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13261> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13450: Better parse error for empy character literal
by GHC 19 Apr '18

19 Apr '18

#13450: Better parse error for empy character literal -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Empty character literals give an obscure error message. As an example, this code: {{{#!hs example = foo : bar where foo = '' bar = "asdf" }}} gives the following error when loaded in GHCi: {{{ err.hs:4:6: parse error (possibly incorrect indentation or mismatched brackets) }}} This has affected me once, as a beginner. I've seen it affect a few other beginners, and the error message isn't very helpful to figuring out what's wrong. It would be nice if a better error message could be reported. If there's a parse error on `''`, then GHC could report something like: {{{ err.hs:3:11: parse error on `''`. Note: Character literals may not be empty. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13450> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10037: Several profiling tests give different results optimised vs. unoptimised
by GHC 19 Apr '18

19 Apr '18

#10037: Several profiling tests give different results optimised vs. unoptimised -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Profiling | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Most of the differences are relatively harmless (mostly CAF attribution), but it would be nice to get this right. In the meantime I'll mark them expect_broken and point to this ticket. The following tests in `tests/profiling/should_run` are affected: {{{ scc001 T2552 ioprof callstack001 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10037> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop
by GHC 17 Apr '18

17 Apr '18

#12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This worked in GHC 7.6.3, but ever since GHC 7.8, this code will cause the typechecker to loop infinitely: {{{#!hs {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MultiParamTypeClasses #-} module Bug where class C a b | a -> b where c :: a -> Int newtype Foo a = Foo a deriving (C b) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12860> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files
by GHC 17 Apr '18

17 Apr '18

#9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files ------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I have a package that bundles in C library sources. I never had a problem with this when using GHC 7.6. In GHC 7.8, the order of the c-sources in the cabal file now matters. Sources must be listed earlier if they have symbols that subsequently loaded object files will need. If the c-sources are in the wrong order, when running "cabal repl" I get Loading object (static) dist/build/decnumber/src/decQuad.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc14294_0/ghc14294_1.so: undefined symbol: DECSTICKYTAB Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug When using the same code and cabal file with GHC 7.6, "cabal repl" works fine: GHCi loads each static object (regardless of ordering in the cabal file), links up the necessary symbols, and launches successfully. Haskell Cafe discussion here: http://www.haskell.org/pipermail/haskell-cafe/2014-May/114041.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9074> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11045: Loading temp shared object failed - undefined symbol
by GHC 17 Apr '18

17 Apr '18

#11045: Loading temp shared object failed - undefined symbol -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While re-compiling [https://github.com/commercialhaskell/stack stack]: {{{ $ stack install --ghc-options -O2 stack-0.1.7.0: configure Configuring stack-0.1.7.0... stack-0.1.7.0: build Preprocessing library stack-0.1.7.0... [30 of 74] Compiling Stack.Types.Docker ( src/Stack/Types/Docker.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Docker.o ) [31 of 74] Compiling Options.Applicative.Complicated ( src/Options/Applicative/Complicated.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Options/Applicative/Complicated.o ) [32 of 74] Compiling Stack.Types.Config ( src/Stack/Types/Config.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Config.o ) [33 of 74] Compiling Stack.Constants ( src/Stack/Constants.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Constants.o ) [Stack.Types.Config changed] [34 of 74] Compiling Stack.Types.Internal ( src/Stack/Types/Internal.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Internal.o ) [Stack.Types.Config changed] [35 of 74] Compiling Stack.Types.StackT ( src/Stack/Types/StackT.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/StackT.o ) [36 of 74] Compiling Stack.Docker.GlobalDB ( src/Stack/Docker/GlobalDB.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Docker/GlobalDB.o ) [Stack.Types.Config changed] [37 of 74] Compiling Stack.Types.Package ( src/Stack/Types/Package.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Package.o ) [Stack.Types.Config changed] [38 of 74] Compiling Stack.Types.Build ( src/Stack/Types/Build.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Build.o ) [39 of 74] Compiling Stack.Types ( src/Stack/Types.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types.o ) [Stack.Types.Build changed] [40 of 74] Compiling Stack.GhcPkg ( src/Stack/GhcPkg.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/GhcPkg.o ) [Stack.Constants changed] [41 of 74] Compiling Stack.PackageIndex ( src/Stack/PackageIndex.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/PackageIndex.o ) [Data.Binary.VersionTagged changed] ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc22553_0/libghc_96.so: undefined symbol: stackzuFHzzONQT9HI3ATX2xQH198L_StackziTypesziCompiler_zdfBinaryCompilerVersionzuzdszdfGSumM2_closure Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building package stack-0.1.7.0 using: /home/simon/.stack/setup-exe-cache/setup-Simple- Cabal-1.22.4.0-x86_64-linux-ghc-7.10.2 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.22.4.0/ build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 $ git show commit 2fb2d11fffddde3c44920f7ea93e34b9d3195dad Author: Emanuel Borsboom <manny(a)fpcomplete.com> Date: Sun Nov 1 05:21:16 2015 -0800 <snip> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11045> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11499: Loading temp shared object failed in GHCi
by GHC 17 Apr '18

17 Apr '18

#11499: Loading temp shared object failed in GHCi --------------------------------------+------------------------------- Reporter: alfa07 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Keywords: | 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: --------------------------------------+------------------------------- While trying to launch ghci got the following error: ❯ stack ghci The following GHC options are incompatible with GHCi and have not been passed to it: -threaded -Odph Using main module: 1. Package `line-segment-intersection' component exe:demo with main-is file: /Users/maxim/Dev/ComputationGeometry/LineSegmentIntersection/app/Main.hs Configuring GHCi with the following packages: line-segment-intersection, GLUT, GLUtil, boundingboxes, freetype-simple, freetype2 GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib, 5): Symbol not found: _bdf_driver_class Referenced from: /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib Expected in: flat namespace in /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11499> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[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