September 2017 - ghc-tickets

[GHC] #12502: Reject wrong find utility
by GHC 27 Sep '17

27 Sep '17

#12502: Reject wrong find utility -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: newcomer | Operating System: Windows Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently our configure scripts try to find the correct find tool on the `PATH`. However because Windows also has a utility named `find`, depending on the user's configuration the Windows one may be on the path first. The Configure script currently rejects the tool and continues trying to find the correct `find` utility from `msys2`. However the binary distribution script doesn't get to know which find utility to use. So if the wrong `find` is on the path then the windows binary downloads will fail with a weird error. The find utility to use should probably be passed to the tarballs download script. We could just stuff it in an `Env variable` and use it in the script if available. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12502> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13911: GHC RTS VEH swallowing exceptions
by GHC 27 Sep '17

27 Sep '17

#13911: GHC RTS VEH swallowing exceptions --------------------------------------+---------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- On ticket #6079, a top level VEH handler was implemented which effectively means there is no uncaught exceptions for those it catches. #13108 improved things a little by giving some basic info upon segfaults, but otherwise left everything as is. Rather than trying to catch all exceptions, I think it would be more worthwhile to leave them uncaught, and let current & future tools have an eyes open approach to debugging. If something needs to go in the place of the global handler, perhaps SetUnhandledExceptionFilter is of use? VEH overrides all other exception handlers as far as I'm aware (C++, SEH, .NET), so trying to interop with any other code that wants to handle it's own exceptions won't work unless said code is also using VEH. This is causing an issue for some code I've been working on, and I've documented similar to this bug report there also: https://gitlab.com/tim-m89/clr-haskell/issues/25#note_33960203 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13911> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12110: Windows exception handler change causes segfault with API Monitor
by GHC 27 Sep '17

27 Sep '17

#12110: Windows exception handler change causes segfault with API Monitor ----------------------------------------+---------------------------------- Reporter: enolan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- [http://www.rohitab.com/apimonitor API Monitor] is a debugging tool that intercepts and logs calls to DLLs. It was extremely helpful with debugging #12010 and is broken in recent GHCs. Attaching it to a GHC compiled executable causes the message `Segmentation fault/access violation in generated code` to be printed. Launching one from inside API Monitor doesn't work either, though I can't read the console output before the window closes. Bisect shows the offending commit is 5200bdeb26 - "Replaced SEH handles with VEH handlers which should work uniformly across x86 and x64". I know this is somewhat outside of "standard usage", but there are very few useful debugging tools for stuff like this and I'd really like to not lose this one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12110> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11198: TypeInType error message regressions
by GHC 27 Sep '17

27 Sep '17

#11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- `TypeInType` causes error messages around certain kind errors to degrade. Here is the case: {{{ [W] (alpha :: k) ~ (Int :: *) }}} where `alpha` is a unification variable, `k` is a skolem, and there is no witness that `k ~ *`. The solver will simplify to {{{ [W] kco :: k ~ * [W] (alpha :: k) ~ (Int |> sym kco) }}} and then the latter, now homogeneous equality is solved by unification {{{ alpha := Int |> sym kco }}} This is all sound. But when reporting a kind error around `k` not equalling `*`, GHC likes to report the type error that the kind error came from. But, after zonking, the type error looks like `Int ~ Int`, when we drop coercions (as we tend to do in error messages). That's unfortunate. It affects test cases * T9196 * T8262 * T8603 * tcfail122 Simon has proposed a rule that should avoid this: never, ever use a wanted as a kind cast. That might work, but an attempt at implementing caused a loop when kind families were involved. I will keep pushing on this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11198> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression
by GHC 27 Sep '17

27 Sep '17

#13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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: -------------------------------------+------------------------------------- Github user jmoy documents an issue with lack of specialization happening for INLINABLE functions in GHC 8.0 here: https://github.com/jmoy/testing- specialize . Testing on 8.2.1 it seems that specialization happened (although I didn't verify this in the core) as the result was 10x faster. But the odd thing to me was uncommenting the `SPECIALIZE` pragma at the callsite actually resulted in a significant regression: https://github.com/jmoy/testing-specialize/issues/1#issuecomment-310868360 Maybe GHC is choosing the worse manual partial specialization for some reason. I'm sorry I can't produce a better ticket for this at the moment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13873> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14278: undefined symbol: gsl_multiroot_fsolver_broyden
by GHC 27 Sep '17

27 Sep '17

#14278: undefined symbol: gsl_multiroot_fsolver_broyden ----------------------------------------+------------------------------- Reporter: smyds | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- Hi, I am trying to compile the package [https://hackage.haskell.org/package/hmatrix hmatrix]. After cloning the [https://github.com/albertoruiz/hmatrix git repository], I ran {{{$ stack setup}}} and {{{$ stack build}}} successfully but then I ran into this : {{{ $ stack repl Configuring GHCi with the following packages: hmatrix, hmatrix-glpk, hmatrix-gsl, hmatrix-special, hmatrix-tests GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for i386-unknown-linux): Loading temp shared object failed: /tmp/ghc25335_0/libghc_7.so: undefined symbol: gsl_multiroot_fsolver_broyden Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I am running this on a devuan x86 machine, but I have tried the same procedure on a debian x86_64 with a similar result. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14278> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14217: Interface-file decls for large tuples
by GHC 27 Sep '17

27 Sep '17

#14217: Interface-file decls for large tuples -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm in the process of updating a large code base for GHC 8.2, and I have the following error (with -ddump-if-trace): {{{ ... Starting fork { Declaration for $fCT2 Loading decl for $fCT2 updating EPS_ Considering whether to load GHC.Prim {- SYSTEM -} Considering whether to load GHC.Prim {- SYSTEM -} } ending fork Declaration for $fCT2 Need decl for (%,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,%) Considering whether to load GHC.Classes {- SYSTEM -} Considering whether to load GHC.Types {- SYSTEM -} checkWiredInTyCon Double Crypto.Lol.Applications.Tests.SHETests Considering whether to load GHC.Types {- SYSTEM -} Starting fork { Class op ip a ty } ending fork Class op ip a ty ... Can't find interface-file declaration for type constructor or class ghc- prim-0.5.1.0:GHC.Classes.(%,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,%) Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error }}} The code in question involves a poly-kinded, promoted 8-tuple, though I have no idea where GHC is coming up with a 64-tuple. Since I'm updating a large library, I've been unable to produce a small example so far. I can make the code compile by simplifying it in various ways, so aside from this problem, the code works with 8.2.1. This issue is currently preventing me from updating my code base to 8.2.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14217> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14199: Document Type.Reflection better (Fun and Con')
by GHC 27 Sep '17

27 Sep '17

#14199: Document Type.Reflection better (Fun and Con') -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Keywords: Typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The pattern synonym `Type.Reflection.Fun` is not documented at all. Since it seems a bit subtle (`(->)` being more than just a type constructor), I think it actually deserves ''extra'' documentation, with examples. The pattern synonym `Type.Reflection.Con'` is insufficiently documented. Some examples would probably help. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14199> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #14237: -Wredundant-constraints incorrectly warns about required type equality constraints in default signatures
by GHC 27 Sep '17

27 Sep '17

#14237: -Wredundant-constraints incorrectly warns about required type equality constraints in default signatures -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC emits a warning about the following function: {{{#!hs f :: (Integer ~ a) => a -> Integer f = (+ 1) }}} {{{ /private/tmp/redundant-default- constraint/src/RedundantDefaultConstraints.hs:14:1: warning: [-Wredundant- constraints] • Redundant constraint: Integer ~ a • In the type signature for: f :: forall a. Integer ~ a => a -> Integer | 14 | f :: Integer ~ a => a -> Integer | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This is understandable (though the error message could perhaps be better) because the equality is pointless. It would be better to just rewrite the type signature as `Integer -> Integer`. However, this becomes problematic when combined with `DefaultSignatures`. GHC ''also'' emits a warning for the following program: {{{#!hs class Monad m => MonadFoo m where foo :: m () default foo :: (MonadFoo m', MonadTrans t, m ~ t m') => m () foo = lift foo }}} {{{ /private/tmp/redundant-default- constraint/src/RedundantDefaultConstraints.hs:8:18: warning: [-Wredundant- constraints] • Redundant constraint: m ~ t m' • In the type signature for: foo :: forall (m' :: * -> *) (t :: (* -> *) -> * -> *). (MonadFoo m', MonadTrans t, m ~ t m') => m () | 8 | default foo :: (MonadFoo m', MonadTrans t, m ~ t m') => m () | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This is wrong, because the constraint here is necessary. The type equality cannot be “inlined” into the type, since #12918 made that illegal. The constraint cannot be removed entirely, since then the program would fail to typecheck. Therefore, GHC should not produce an error in this case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14237> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14272: GHC goes out of memory while compiling simple program with optimizations
by GHC 27 Sep '17

27 Sep '17

#14272: GHC goes out of memory while compiling simple program with optimizations -------------------------------------+------------------------------------- Reporter: 39aldo39 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- When compiling the following program with `ghc -O Main.hs`, GHC goes out of memory. {{{#!hs import Data.Bits (bit) main :: IO () main = putStrLn (show (f undefined)) f :: [Int] -> Int f = sum . zipWith ((+) . bit) [0..] . map undefined . scanl undefined undefined }}} I have 6 GB RAM and 8 GB swap free, so that shouldn't be the problem. It only happens with optimizations on, and it happens during a simplifier. Any simpler expressions do work. It even happens when `[0..]` is replaced by `take 1 [0..]`, but it compiles with `take 0 [0..]`. A straightforward workaround is to replace `zipWith f [0..]` by `\xs -> zipWith f [0..length xs] xs`. I ran into this problem when updating to GHC 8.2.1 from 8.0.2. But the given program doesn't compile on older versions as well. GHC 7.10.3 was the lowest version I could run before running into other problems. All GHC versions I tested come from the Debian repo. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14272> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13