- ghc-tickets - Haskell.org

[GHC] #15926: conversion from Integer to Double rounds differently depending on the value
by GHC 21 Nov '18

21 Nov '18

#15926: conversion from Integer to Double rounds differently depending on the value --------------------------------------+------------------------------------ Reporter: drvirgilio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------------ I'm not sure if this is intended behavior or a bug. For values less than 2^53^, the the Integer can be represented exactly as a Double so there is no issue. For values from 2^53^ to 2^63^, {{{fromInteger n}}} rounds to the nearest {{{Double}}}, where ties go toward the {{{Double}}} with even least significant bit. This matches the behavior of {{{read}}}. For values between 2^63^ and 2^1024^, {{{fromInteger n}}} ''rounds down'' to the next representable {{{Double}}}. Steps to reproduce: These values are all the same except the last one because it falls just below the threshold for the "round to nearest, ties to even" rule. In this example, (2^63^) and (2^63^-2^10^) are the consecutive values of type {{{Double}}}. {{{#!hs > fromInteger (2^63) :: Double -- exactly 9223372036854775808 9.223372036854776e18 > fromInteger (2^63 - 1) :: Double -- rounded up 9.223372036854776e18 > fromInteger (2^63 - 2^9) :: Double -- rounded up 9.223372036854776e18 > fromInteger (2^63 - 2^9 - 1) :: Double -- rounded down 9.223372036854775e18 > fromInteger (2^63 - 2^10) :: Double -- exactly 9223372036854774784 9.223372036854775e18 }}} Here you can see the behavior of {{{fromInteger}}} matches that of {{{read . show}}} {{{#!hs > (read . show) (2^63) :: Double -- exactly 9223372036854775808 9.223372036854776e18 > (read . show) (2^63 - 1) :: Double -- rounded up 9.223372036854776e18 > (read . show) (2^63 - 2^9) :: Double -- rounded up 9.223372036854776e18 > (read . show) (2^63 - 2^9 - 1) :: Double -- rounded down 9.223372036854775e18 > (read . show) (2^63 - 2^10) :: Double -- exactly 9223372036854774784 9.223372036854775e18 }}} Here you can see {{{fromInteger}}} is rounding down. In this example, (2^64^) and (2^64^-2^11^) are the consecutive values of type {{{Double}}}. {{{#!hs > fromInteger (2^64) :: Double -- exactly 18446744073709551616 1.8446744073709552e19 > fromInteger (2^64 - 1) :: Double -- rounded down 1.844674407370955e19 > fromInteger (2^64 - 2^10) :: Double -- rounded down 1.844674407370955e19 > fromInteger (2^64 - 2^10 - 1) :: Double -- rounded down 1.844674407370955e19 > fromInteger (2^64 - 2^11) :: Double -- exactly 18446744073709549568 1.844674407370955e19 }}} Here you can see the behavior of {{{fromInteger}}} does ''not'' match the behavior of {{{read . show}}} {{{#!hs > (read . show) (2^64) :: Double -- exactly 18446744073709551616 1.8446744073709552e19 > (read . show) (2^64 - 1) :: Double -- rounded up 1.8446744073709552e19 > (read . show) (2^64 - 2^10) :: Double -- rounded up 1.8446744073709552e19 > (read . show) (2^64 - 2^10 - 1) :: Double -- rounded down 1.844674407370955e19 > (read . show) (2^64 - 2^11) :: Double -- exactly 18446744073709549568 1.844674407370955e19 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15926> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15687: Type synonym unused binds no warning?
by GHC 21 Nov '18

21 Nov '18

#15687: Type synonym unused binds no warning? -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 (Parser) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was taken aback this was accepted {{{#!hs type Silly a b = Maybe b x :: Silly Int Bool x = Just True y :: Silly Char Bool y = Just False z = x == y -- returns False }}} What's with the `a` in `Silly`'s decl? That's not a phantom type. It's ignored and thrown away. So `x` and `y` are the same type, and can be compare for equality. I expected a rule: all tyvars in the `type`'s head must appear on rhs. Or at least a warning there was something silly. I tried `-Wall, -fwarn- unused-binds`, `-Wunused-type-patterns`. I was just checking up on [https://github.com/ghc-proposals/ghc- proposals/pull/173#issuecomment-424980779 a remark] that type synonyms are at the type level like implicit bidirectional pattern synonyms. For those, all vars must appear on both sides. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15687> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15674: GADT's displayed type is misleading
by GHC 21 Nov '18

21 Nov '18

#15674: GADT's displayed type is misleading -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Poor/confusing (amd64) | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHCi's `:t` alleges these three data constructors have the same type `:: Int -> T Int` (modulo name of the type constructor): {{{#!hs data DG a where MkDG :: Int -> DG Int MkDG2 :: (a ~ Int) => a -> DG a data family DF a data instance DF Int where MkDF :: Int -> DF Int }}} I tried switching on verbosity flags, but to no avail: `-fprint-explicit- foralls, -fprint-equality-relations`, and a few others. The `DG` constructors are GADTs, the `DF` constructor is not. So it's not hard to see different type-level behaviour: {{{#!hs f (MkDF x) = x -- accepted without a signature -- f :: DF Int -> Int -- inferred signature, or you can spec it -- f :: DF a -> a -- rejected: signature is too general/ -- a is a rigid type variable g (MkDG x) = x -- } without a signature, rejected g (MkDG2 x) = x -- } "untouchable" type (Note) -- g :: DG Int -> Int -- } g accepted with either sig -- g :: DG a -> a -- } ?but MkDG doesn't return DG a, allegedly }}} '''Note:''' at least the error message re `MkDG2` does show its type as `:: (forall a). (a ~ Int) => DG a -> a`. But doggedly `MkDG :: Int -> DG Int`. "Untouchable" error messages are a fertile source of questions on StackOverflow. The message does say `Possible fix: add a type signature for 'g'`, but gives no clue what the signature might be. If you've imported these data constructors from a library, such that you can't (easily) see they're GADTs, couldn't `:t` give you better help to show what's going on? Or should one of the verbosity flags already do this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15674> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15908: Hadrian: Spurious build failure on fresh build
by GHC 21 Nov '18

21 Nov '18

#15908: Hadrian: Spurious build failure on fresh build -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On a freshly checked-out (Windows10 64)ghc tree I was building with hadrian (`hadrian/build.bat -j`). It aborted here: | Run Ghc CompileHs Stage1: libraries/pretty/src/Text/PrettyPrint/Annotated.hs => _build/stage1/libraries/pretty/build/Text/PrettyPrint/Annotated.o | Run Ar Pack Stage1: _build/stage1/libraries/stm/build/Control/Concurrent/STM.p_o (and 9 more) => _build/stage1/libraries/stm/build/libHSstm-2.5.0.0_p.a C:/Users/ggreif/ghc/inplace/mingw/bin/ar.exe: creating _build/stage1/libraries/stm/build/libHSstm-2.5.0.0_p.a C:/Users/ggreif/ghc/inplace/mingw/bin/ar.exe: unable to rename '_build/stage1/libraries/stm/build/libHSstm-2.5.0.0_p.a'; reason: File exists shakeArgsWith 0.001s 0% Function shake 0.317s 0% Database read 0.468s 0% With database 0.013s 0% Running rules 3492.921s 99% ========================= Total 3493.720s 100% Error when running Shake build system: * _build/stage1/lib/package.conf.d/stm-2.5.0.0.conf * _build/stage1/libraries/stm/build/libHSstm-2.5.0.0_p.a user error (Development.Shake.cmd, system command failed Command: C:/Users/ggreif/ghc/inplace/mingw/bin/ar.exe q _build/stage1/libraries/stm/build/libHSstm-2.5.0.0_p.a @C:\Users\ggreif\AppData\Local\Temp\extA08E Exit code: 1 Stderr: C:/Users/ggreif/ghc/inplace/mingw/bin/ar.exe: creating _build/stage1/libraries/stm/build/libHSstm-2.5.0.0_p.a C:/Users/ggreif/ghc/inplace/mingw/bin/ar.exe: unable to rename '_build/stage1/libraries/stm/build/libHSstm-2.5.0.0_p.a'; reason: File exists ) Can this be a concurrency problem, while renaming archives? Anyway it healed after restarting Hadrian. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15908> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15754: Move free variable computation to after STG passes
by GHC 20 Nov '18

20 Nov '18

#15754: Move free variable computation to after STG passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15754> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #15660: source file modify race leads to inconsistent error message
by GHC 20 Nov '18

20 Nov '18

#15660: source file modify race leads to inconsistent error message -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I got this odd error message from ghc: {{{ Command/AddUrl.hs:120:32: error: lexical error in string/character literal at character '-' | 120 | BatchNull -> '\0' | ^ }}} Part of the error message says that '-' is the problem character, but the quoted line of code does not contain that. What happened is I started the build, noticed I had typoed '\-' and quickly corrected it in my editor and saved. It seems ghc must have read the source file twice, so I raced it and so experienced this inconsistency. I wonder if it could display the wrong line entirely if a larger change was made to the file? Thanks for your time with such a minor thing as this bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15660> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #1965: Allow unconstrained existential contexts in newtypes
by GHC 20 Nov '18

20 Nov '18

#1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ericson2314): Yes for @sgraf's reason I wish we used an equivalence relation on these internal notion of deep representations, and also {{{RuntimeRep}}}s. For example, given matching deep structure (not tracked in the kind/{{{RuntimeRep}}}): {{{ forall a t. exists t' t'. (t :: Kind a) ~R (t' :: Kind TupleRep [a]) ~R (t'' :: Kind SumRep [a]) }}} Maybe it's not worth the extra coercions in practice, but certainly I think its good teaching to pretend newtypes are always: {{{ newtype Foo (a :: k) :: TupleRep [k] = Foo (a :: k) }}} to explain {{{ newtype A :: TupleRep [LiftedRep] = A (Int :: LiftedRep) case undefined of A _ -> 1 }}} contrasted with pretend elaborated unpacked {{{!Int}}}: {{{ data A' :: LiftedRep = A' (!Int :: IntRep) case undefined of A' _ -> undefined }}} That the shallow representations of {{{A}}} and {{{A'}}} have different strictness, opposite what is contained inside, cleanly explains how the `case`-expression has different semantics despite the overall isomorphism of {{{A}}} and {{{A'}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10445: Wrong stack space size when using -Ksize
by GHC 20 Nov '18

20 Nov '18

#10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- After compiling the first example in https://wiki.haskell.org/Performance/Accumulating_parameter: {{{ $ cat Test.hs len :: [a] -> Int len [] = 0 len (x:xs) = len xs + 1 main :: IO () main = print $ len [1..1000000] }}} {{{ $ ghc Test.hs -rtsopts }}} and running {{{ ./Test +RTS -K10K }}} GHC 7.6.3 reports {{{ Stack space overflow: current size 10240 bytes. }}} GHC 7.8.4 reports {{{ Stack space overflow: current size 33632 bytes. }}} and GHC 7.10.1 reports {{{ Stack space overflow: current size 99136 bytes. }}} GHC 7.8.3 and 7.10.1 report an incorrect stack space size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10445> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15919: Deprecate split objects
by GHC 20 Nov '18

20 Nov '18

#15919: Deprecate split objects -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- For several reasons (see below) we now generally recommend users use split sections instead of split objects. Reasons: * SplitSections is quite a bit simpler * SplitSections may produce smaller binaries * SplitSections requires fewer assembler invocations, potentially improving compilation time (see #11285, #15051) * SplitSections is the approach used by most C compilers, meaning we may avoid edge cases that SplitObjects may turn up -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15919> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15917: GHC seems to re-read source of module to produce fancy error msgs
by GHC 19 Nov '18

19 Nov '18

#15917: GHC seems to re-read source of module to produce fancy error msgs -------------------------------------+------------------------------------- Reporter: Heimdell | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: 8.6.3 Component: Compiler | Version: 8.2.2 Keywords: re-reading | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Poor/confusing (amd64) | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I had a module with unused name `txFees` in it. I started compilation and in the same time edited code by renaming `txFees` -> `_txFees`. I got the following message: {{{ warning: [-Wunused-matches] Defined but not used: ‘txFees’ | 40 | } _txFees | ^^^^^^ <no location info>: error: Failing due to -Werror. }}} The screenshot is in the attachment. Notice that message part is about old code (`txFees`), and preview is about new code (`_txFees`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15917> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3