- ghc-tickets - Haskell.org

Re: [GHC] #5129: "evaluate" optimized away
by GHC 20 Mar '18

20 Mar '18

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: seq, evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Phab:D615, Wiki Page: | Phab:D4514 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"abaf43d9d88d6fdf7345b936a571d17cfe1fa140/ghc" abaf43d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="abaf43d9d88d6fdf7345b936a571d17cfe1fa140" Fix seq# case of exprOkForSpeculation This subtle patch fixes Trac #5129 (again; comment:20 and following). I took the opportunity to document seq# properly; see Note [seq# magic] in PrelRules, and Note [seq# and expr_ok] in CoreUtils. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5129: "evaluate" optimized away
by GHC 20 Mar '18

20 Mar '18

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: seq, evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Phab:D615, Wiki Page: | Phab:D4514 -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5129: "evaluate" optimized away
by GHC 20 Mar '18

20 Mar '18

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: seq, evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Phab:D615, Wiki Page: | Phab:D4514 -------------------------------------+------------------------------------- Comment (by tdammers): Just to be sure; will this also solve #13930? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5129: "evaluate" optimized away
by GHC 20 Mar '18

20 Mar '18

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: seq, evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Phab:D615, Wiki Page: | Phab:D4514 -------------------------------------+------------------------------------- Comment (by simonpj): > One way to fix this if we want to keep seq# as effect-free is avoiding inlining evaluate with {-# NOINLINE evaluate #-}. I'm very unhappy with this. It just sweeps the problem under the rug. What if the ''user'' wrote {{{ ..(case (seq# (throwIfNegative (I# -1#)) s) of <alts>)... }}} We don't want to discard the case. Moreover we shouldn't. The "plain-seq" transformation in `Simplify.hs` looks like {{{ | is_plain_seq , exprOkForSideEffects scrut = ... }}} Well, should `exprOkForSideEffects` return False (as it does) for `seq# (throwIfNegative (I# -1#)) s`? The comments in `CoreUtils` say {{{ -- Precisely, exprOkForSpeculation returns @True@ iff: -- a) The expression guarantees to terminate, -- b) soon, -- c) without causing a write side effect (e.g. writing a mutable variable) -- d) without throwing a Haskell exception -- e) without risking an unchecked runtime exception (array out of bounds, -- divide by zero) -- -- For @exprOkForSideEffects@ the list is the same, but omitting (e). }}} So clearly `exprOkForSideEffects` should return False! That's the real bug! Why does it return True? Because in `arg_ok` in `CoreUtils.app_ok` we see {{{ arg_ok (Anon ty) arg -- A term argument | isUnliftedType ty = expr_ok primop_ok arg | otherwise = True -- See Note [Primops with lifted arguments] }}} Uh oh! It never even looks at the argument `throwIfNegative minus_one`! I think that `seq#` is exception to the reasoning in `Note [Primops with lifted arguments]`, which says that a primop doesn't evaluate a lifted argument. In effect `seq#` does. So in the `PrimOpId` case of `app_ok` I think we want to add {{{ | SeqOp <- op -> all (expr_ok primop_ok) args }}} And sure enough that fixes it. I'll make a patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5129: "evaluate" optimized away
by GHC 20 Mar '18

20 Mar '18

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: seq, evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Phab:D615, Wiki Page: | Phab:D4514 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14508: Bring up Appveyor for Windows CI
by GHC 20 Mar '18

20 Mar '18

#14508: Bring up Appveyor for Windows CI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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: -------------------------------------+------------------------------------- The current plan is to move to Appveyor for CI on Windows. Mateusz has a first [[https://github.com/tweag/ghc/blob/tweag/circleci- macos/appveyor.yml|stab]] at a configuration. Unfortunately it looks like we will far-exceed the one-hour default build time limit. It appears they Appveyor [[https://github.com/appveyor/ci/issues/517 |does give]] extensions to open-source projects, but typically only extend to 1.5 hours. It's unlikely that this will be sufficient as even my local Windows builds take ~1.75 hours. It appears that Rust has found a way around this as their [[https://ci.appveyor.com/project/rust-lang/rust/history|builds]] routinely last ~2 hours. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14508> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13650: Implement KPush in types
by GHC 20 Mar '18

20 Mar '18

#13650: Implement KPush in types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 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 recent commit contributed a [https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/… Note] that explains why we need the dreaded KPush rule to be implemented in `splitTyConApp`. Without KPush there, it's possible that we can have two types t1 and t2 such that {{{t1 `eqType` t2}}} and yet they respond differently to `splitTyConApp`: t1 = `(T |> co1) (a |> co2)` and t2 = `T a`. Both t1 and t2 are well-kinded and can have the same kind. But one is a `TyConApp` and one is an `AppTy`. (Actually, looking at this, perhaps the magic will be in `mkAppTy`, not `splitTyConApp`.) But I have to look closer. This ticket serves as a reminder to do so. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13650> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14609: Per-instance UndecidableInstances
by GHC 20 Mar '18

20 Mar '18

#14609: Per-instance UndecidableInstances -------------------------------------+------------------------------------- Reporter: ryanreich | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- The LANGUAGE pragma OverlappingInstances is now a per-instance modifier specifying the manner of overlap. Can (or why can't) this also be done for UndecidableInstances? It gives me an icky feeling to put it at the top of a source file when I just want to allow one specific instance to be undecidable. My apologies if this request already exists. It is very difficult to find bugs about UndecidableInstances in particular as opposed merely to those containing code with this pragma, which appear to be numerous. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14609> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #5129: "evaluate" optimized away
by GHC 20 Mar '18

20 Mar '18

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: seq, evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Phab:D615, Wiki Page: | Phab:D4514 -------------------------------------+------------------------------------- Comment (by osa1): In comment:24 I say that the `case seq# ... of` is eliminated because the result is not used and `seq#` is effect-free. The reason why the result is not used is because `assertFailure` is a pure function with type `String -> a`. Just wanted to post this update because I was confused about this for a long time (I thought `assertFailure` was an IO function). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14876: Reading source files in text mode so that we get CRLF conversion under Windows?
by GHC 19 Mar '18

19 Mar '18

#14876: Reading source files in text mode so that we get CRLF conversion under Windows? -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- According to https://github.com/sol/interpolate/issues/9 the string passed to a quasi quoter contains CRLF line endings. I have observed the same things for Haddock comments (both in `haddock` and `doctest` when extracted through the GHC API). I haven't looked at any GHC code, but wouldn't the right thing be to read source files in text mode so that we get newline conversion? If we don't want / can't do that for some reason, then wouldn't we still want to handle this somewhere deep down the stack so that not every client has to deal with it separately? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14876> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3