March 2018 - ghc-tickets

[GHC] #14924: GHC 8.4.1 has wrong __GLASGOW_HASKELL__
by GHC 15 Mar '18

15 Mar '18

#14924: GHC 8.4.1 has wrong __GLASGOW_HASKELL__ -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- The title pretty much says it all. As following shell interaction shows, the macro expands into 804, but I expected that it should expand into 840. Was my expectation wrong? {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.1 $ cat /tmp/Test.hs {-# LANGUAGE CPP #-} hello = __GLASGOW_HASKELL__ $ cat /tmp/Test.hspp | sed -r '/^$/d' # preprocessed file has too much whitespace {-# LINE 1 "/tmp/Test.hs" #-} # 1 "/tmp/Test.hs" # 1 "<built-in>" # 1 "<command-line>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 17 "/usr/include/stdc-predef.h" 3 4 # 7 "<command-line>" 2 # 1 "/home/sergey/projects/haskell/ghc/local-8.4.1/lib/ghc-8.4.1/include/ghcversion.h" 1 # 7 "<command-line>" 2 # 1 "/tmp/ghc20375_0/ghc_2.h" 1 # 7 "<command-line>" 2 # 1 "/tmp/Test.hs" {-# LANGUAGE CPP #-} hello = 804 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14924> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14920: Flag reference doesn't include `-haddock` and `-haddock-opts`
by GHC 15 Mar '18

15 Mar '18

#14920: Flag reference doesn't include `-haddock` and `-haddock-opts` -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.4.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/14920> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14922: Add inductively-defined Nat to base
by GHC 15 Mar '18

15 Mar '18

#14922: Add inductively-defined Nat to base -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | Keywords: base | 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 proposed addition is simple, add the following to base: {{{#!hs data Nat = Zero | Succ Nat }}} I will list the pros/cons I see below. Pros: - Commonly defined throughout many packages, e.g. vinyl - The inductive definition of 'Nat' is useful for correctness (e.g. {{{#!hs safeHead :: Vec a (S n) -> a; safeHead (Cons a as) = a}}}) Cons: - '-XDependentHaskell' will most likely obviate any benefit brought about by type families involving Nat - Looking at base, I'm not sure where this would go. Having it in its own module seems a tad strange. I am open to criticism concerning the usefulness of the idea or if anyone sees a Pro(s)/Con(s) that I am missing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14922> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5361: regSpill: out of spill slots!
by GHC 15 Mar '18

15 Mar '18

#5361: regSpill: out of spill slots! -------------------------------------+------------------------------------- Reporter: markwright | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: regSpill | panic impossible Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: crash | http://hackage.haskell.org/package/SHA Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simons): This issue still occurs with GHC 8.2.2. It's clearly not "fixed", unless one applies a very special interpretation of what that term is supposed to mean. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5361#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11312: GHC inlining primitive string literals can affect program output
by GHC 14 Mar '18

14 Mar '18

#11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #11292 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First noted in #11292, this program, when compiled with `-O1` or higher: {{{#!hs {-# LANGUAGE MagicHash #-} module Main (main) where import GHC.Exts (Addr#, isTrue#) import GHC.Prim (eqAddr#) data A = A { runA :: Addr# } a :: A a = A "a"# main :: IO () main = print (isTrue# (eqAddr# (runA a) (runA a))) }}} will result in the following after inlining: {{{ Main.main2 = case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.eqAddr# "a"# "a"#) of _ [Occ=Dead] { GHC.Types.False -> GHC.Show.shows26; GHC.Types.True -> GHC.Show.shows24 } }}} As a result, there are two of the same string constant with different addresses, which causes `eqAddr#` to return `False`. If compiled without optimizations, `"a"#` is not inlined, and as a result, `eqAddr#` returns `True`. Two questions: 1. Is this okay semantics-wise? Or is this a necessary risk when working with primitive string literals, and should programmers judiciously use `{-# NOINLINE #-}` with them? 2. Is this okay from a code duplication standpoint? As Reid Barton noted in #11292, `"a"#` is duplicated due to inlining. In this example, not much is duplicated, but if it were a longer string constant, that could result in a noticeable increase in the object file size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11312> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8542: Suggest NegativeLiterals
by GHC 14 Mar '18

14 Mar '18

#8542: Suggest NegativeLiterals ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If we write -128 :: Int8, we get a useful warning (#7895), but it would be even better to suggest NegativeLiterals. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8542> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13257: out-of-range warnings for negative literals, without -XNegativeLiterals
by GHC 13 Mar '18

13 Mar '18

#13257: out-of-range warnings for negative literals, without -XNegativeLiterals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- By default (without `NegativeLiterals`) a negated literal `-1` is desugared as `negate (fromInteger 1)`. Hence the existing out-of-range literal warning doesn't trigger for `-1 :: Word`. But we could also recognize the pattern `negate (fromInteger lit)`, and give a warning when `-lit` is out-of-range (for `Word`, this is whenever `lit` is positive). Actually this could apply to signed integer types too: if we recognized `negate (fromInteger lit)` in preference to `fromInteger lit`, we could correctly not warn about `-128 :: Int8`, even when `NegativeLiterals` is not enabled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13257> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC
by GHC 12 Mar '18

12 Mar '18

#4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: kaiha Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | driver/T4114a,b,c,d Blocked By: | Blocking: Related Tickets: #2258 | Differential Rev(s): Phab:D2021 Wiki Page: | Phab:D2050 -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4114#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13366: addCStub doesn't allow control over compiler flags or source file file
by GHC 12 Mar '18

12 Mar '18

#13366: addCStub doesn't allow control over compiler flags or source file file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- Currently if you pass a C source file on the GHC command line you can control whether the compiler treats it as C or C++ via the it's extension: GCC will treat a file ending in `.c` as C, whereas `.cpp` is treated as C++. However, we currently have no means of controlling what language a stub added with in Template Haskell with `addCStub` will be treated as. Consequently it is currently impossible to compile a C++ source file with `addCStub` without using `-optc`. Moreover, you can't have mixed C/C++ stubs at all. It really seems like this interface should be amended to fix this before we release it in 8.2. Perhaps `addCStub` should accept both the source and a set of compiler flags which will be added to the usual flags (allowing one to pass `-x c++` to the compiler when compiling C++ files)? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13366> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #13543: Improve demand analysis for join points
by GHC 12 Mar '18

12 Mar '18

#13543: Improve demand analysis for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- Consider {{{ g :: (Int,Int) -> Int g (p,q) = p+q f :: Int -> Int -> Int f x p = g (join j y = (p,y) in case x of True -> j 3 False -> j 4) }}} If `j` was a vanilla function definition, we'd analyse its body with `evalDmd`, and think that it was lazy in `p`. But for a join point we can do better. We know that `j`'s body (if evaluated at all) will be evaluated with the demand that consumes the entire join-binding, in this case the argument demand from `g`. Whizzo! `g` evaluates both components of its arugment pair, so j is strict in `p`. So, when analysing a join point, we can analyse its body with the demand from the entire join-binding. Another win for join points! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13543> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7