May 2013 - ghc-tickets

[GHC] #7684: cgrun071 segfaults
by GHC 03 May '13

03 May '13

#7684: cgrun071 segfaults --------------------------+------------------------------------------------- Reporter: tibbe | Owner: tibbe Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- I ran into this working on something unrelated today: {{{ =====> cgrun071(normal) 171 of 3449 [0, 0, 12] cd ./codeGen/should_run && '/Users/tibbe/src/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history -o cgrun071 cgrun071.hs >cgrun071.comp.stderr 2>&1 cd ./codeGen/should_run && ./cgrun071 </dev/null >cgrun071.run.stdout 2>cgrun071.run.stderr /bin/sh: line 1: 37450 Segmentation fault: 11 ./cgrun071 < /dev/null > cgrun071.run.stdout 2> cgrun071.run.stderr Wrong exit code (expected 0 , actual 139 ) Stdout: Stderr: *** unexpected failure for cgrun071(normal) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #7373: When building GHC: Failed to load interface for `GHC.Fingerprint'
by GHC 03 May '13

03 May '13

#7373: When building GHC: Failed to load interface for `GHC.Fingerprint' -------------------------------+-------------------------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by simonpj): Replying to [comment:3 igloo]: > OK, it looks like this goes wrong because of the way we interleave the building of packages when building GHC. GHC assumes that if we're building one package, then packages that it depends on have already been built and are complete. Therefore, even if a module in the other package has a `.hs- boot` file, the real `.hs` file will also have been compiled and there will be a full `.hi` file. > > That seems like a reasonable assumption to make, and it doesn't look like anything actually fails as a result of this, so I don't think we need to take any action. Ian I'm far from certain that your diagnosis here is correct, and indeed I don't really understand it. Yes, the assumption you describe seems a reasonable one. Does it not hold? Does not-holding have consequences of missing unfoldings? GHC is, I believe, happy to accept either a .hi file or a .hi-boot file. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7373#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7854: Constrained method type accepted in Haskell 98 mode
by GHC 03 May '13

03 May '13

#7854: Constrained method type accepted in Haskell 98 mode -----------------------------+---------------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- If I understand [http://www.haskell.org/ghc/docs/7.6.2/html/users_guide /type-class-extensions.html#class-method-types this paragraph] of the GHC manual correctly, the following code should be rejected in Haskell 98 mode: {{{ {-# LANGUAGE Haskell98 #-} module Main where class Compare a where comp :: Eq a => a -> a -> Bool }}} However, it compiles fine for me both with 7.4.2 and 7.6.1. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7854> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7865: SpecConstr duplicating computations
by GHC 03 May '13

03 May '13

#7865: SpecConstr duplicating computations ------------------------------------+--------------------------------------- Reporter: amosrobinson | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: | Keywords: SpecConstr Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- In some (very rare) cases, SpecConstr can actually duplicate let bindings. When SpecConstr sees something like {{{ let tuple = (let x = expensive in x, simple) case tuple of (a,b) -> a + a }}} it records the value of tuple, and replaces the case with {{{ (let x = expensive in x) + (let x = expensive in x) }}} Usually we wouldn't notice this, because the Simplifier would let-float expensive out of the tuple before SpecConstr runs. In some cases though, the tuple constructor will only be exposed after specialisation happens. To test, compile TSpecConstr_DoubleInline with {{{ ghc TSpecConstr_DoubleInline.hs -O2 -fspec-constr -dverbose-core2core -fforce-recomp -dppr-case-as-let -dsuppress-all | less }}} and search for the SpecConstr pass. The first specialisation is {{{ $srecursive_sf3 $srecursive_sf3 = \ sc_seR sc_seS sc_seT sc_seU -> let { a'_sep a'_sep = (let { I# x_adP ~ _ <- expensive sc_seR } in I# (*# x_adP 2), sc_seR) } in let { ds_seq ds_seq = recursive (: sc_seR (: sc_seR (: sc_seS sc_seT))) (sc_seR, let { I# x_adP ~ _ <- expensive sc_seR } in I# (*# x_adP 2)) } in (let { (p_XdA, q_Xdu) ~ _ <- ds_seq } in let { I# x_ae7 ~ _ <- p_XdA } in let { I# y_aeb ~ _ <- let { I# x_adP ~ _ <- expensive sc_seR } in I# (*# x_adP 2) } in I# (+# x_ae7 y_aeb), let { (p_adg, q_XdA) ~ _ <- ds_seq } in let { I# x_ae7 ~ _ <- q_XdA } in let { I# y_aeb ~ _ <- sc_seR } in I# (+# x_ae7 y_aeb)) }}} With three calls to expensive. If you look at the -ddump-prep, one of the calls is simplified out, but there is still one too many at the end. This is happening on at least 7.4.1 and head. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7865> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #2648: Report out of date interface files robustly
by GHC 03 May '13

03 May '13

#2648: Report out of date interface files robustly ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: GHCi | Version: 7.6.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHCi crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): As Ian says, I think we are stalled on fixing this until we have a test case. The scenario I wrote up at the start is a bit contrived, and I'm far from certain that it's what people are tripping over. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2648#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5902: Cannot tell from an exception handler whether the exception was asynchronous
by GHC 03 May '13

03 May '13

#5902: Cannot tell from an exception handler whether the exception was asynchronous ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): Any time there's a catch/rethrow inside an `unsafePerformIO` we'll have this problem. So in the specific case of the GHC API it would help to know where this is happening, and whether we can avoid it. One way I can think of that might help in general is to have a special kind of catch that doesn't catch asynchronous exceptions. So in cases like your example, `catchIOError` would use the special sync-only catch internally, and would ignore the async exception. However, this unfortunately doesn't help with `bracket` and `finally`, which need to do some cleanup in the exception handler, and I suspect these are more common than `catch`. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5902#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7862: Could not deduce (A) from the context (A, ...)
by GHC 03 May '13

03 May '13

#7862: Could not deduce (A) from the context (A, ...) --------------------------------------+------------------------------------- Reporter: alang9 | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.6.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- The following code doesn't compile and produces a strange error: {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts #-} module Numeric.AD.Internal.Tower () where type family Scalar t newtype Tower s a = Tower [a] type instance Scalar (Tower s a) = a class (Num (Scalar t), Num t) => Mode t where (<+>) :: t -> t -> t instance (Num a) => Mode (Tower s a) where Tower as <+> _ = undefined where _ = (Tower as) <+> (Tower as) instance Num a => Num (Tower s a) where }}} {{{ src/Numeric/AD/Internal/Tower.hs:17:24: Could not deduce (Num (Scalar (Tower s a))) arising from a use of `<+>' from the context (Num (Scalar (Tower s a)), Num (Tower s a), Num a) bound by the instance declaration at src/Numeric/AD/Internal/Tower.hs:14:10-36 Possible fix: add an instance declaration for (Num (Scalar (Tower s a))) In the expression: (Tower as) <+> (Tower as) In a pattern binding: _ = (Tower as) <+> (Tower as) In an equation for `<+>': (Tower as) <+> _ = undefined where _ = (Tower as) <+> (Tower as) }}} Furthermore, Removing the {{{Num (Scalar t)}}} constraint from the {{{Mode}}} class produces a different strange error: {{{ src/Numeric/AD/Internal/Tower.hs:17:24: Overlapping instances for Num (Tower s0 a) arising from a use of `<+>' Matching givens (or their superclasses): (Num (Tower s a)) bound by the instance declaration at src/Numeric/AD/Internal/Tower.hs:14:10-36 Matching instances: instance Num a => Num (Tower s a) -- Defined at src/Numeric/AD/Internal/Tower.hs:19:10 (The choice depends on the instantiation of `a, s0') In the expression: (Tower as) <+> (Tower as) In a pattern binding: _ = (Tower as) <+> (Tower as) In an equation for `<+>': (Tower as) <+> _ = undefined where _ = (Tower as) <+> (Tower as) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7862> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7873: A poly-kinded newtype existential crisis
by GHC 03 May '13

03 May '13

#7873: A poly-kinded newtype existential crisis --------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- The following code worked on older GHCs and on other compilers clear back to Hugs, but based on reports I'm getting from a half-dozen users appears to broken on GHC 7.6.1+ and in GHC HEAD. {{{ class Reifies s a | s -> a where reflect :: proxy s -> a data Proxy a = Proxy newtype Magic a r = Magic (forall s. Reifies s a => Proxy s -> r) }}} {{{ fast/Data/Reflection.hs:92:21: A newtype constructor cannot have an existential context, but `Magic' does In the definition of data constructor `Magic' }}} There doesn't appear to be anything existential going on there, but that said, this issue does only occur when PolyKinds are turned on, so perhaps the issue is with the desugaring into PolyKinds? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7873> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #7884: Cannot build hedgewars with new haskell 7.6
by GHC 03 May '13

03 May '13

#7884: Cannot build hedgewars with new haskell 7.6 -------------------------------+-------------------------------------------- Reporter: LocutusOfBorg | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: regression Os: Linux | Architecture: arm Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Hi All, I post here since this bug *CAN* be a regression between haskell 7.4 and 7.6. Please look at this log https://buildd.debian.org/status/fetch.php?pkg=hedgewars&arch=armhf&ver=0.9… Everything is fine with haskell 7.4 and this one https://launchpadlibrarian.net/138989726/buildlog_ubuntu-saucy- armhf.hedgewars_0.9.18-0.3_FAILEDTOBUILD.txt.gz this seems to be an uncorrent link with the new haskell -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7884> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7881: Warning for pointless ranges like [5..2]
by GHC 03 May '13

03 May '13

#7881: Warning for pointless ranges like [5..2] -----------------------------+---------------------------------------------- Reporter: mpe | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: beginner,warning Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Haskell beginners sometimes tend to write ranges like [3..1] or [5..2] and assume that the result will be [3,2,1] or [5,4,3,2]. This is not the case of course. I suggest that literals like [5..2] generate a warning at compile time, analogous to: "Foo.hs:32: Warning: Literal list [5..2] evaluates to [] because 5 > 2 and the default step size is +1. Replace the literal with the empty list or with [5,4..2] to suppress this warning." In my opinion this should only be a compile time warning, not a runtime warning. If a > 3 and b is < 3 and you write [a..b] the result is still [], but that mistake can only be caught at runtime, and requires an additional run-time check. In some cases it may even be the desired behaviour to let [a..b] evaluate to [] if a>b. On the other hand, a literal expression like [5..2] is most likely an error, because if the user would expect [5..2] to evaluate to [], he would simply write []. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7881> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1