January 2015 - ghc-tickets

[GHC] #8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8
by GHC 24 Aug '15

24 Aug '15

#8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8 -------------------------------------------+------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Changing type signature of comparison primops from `Bool` to `Int#` in GHC 7.8 (see #6135) caused a problem: type signatures of functions might be different for the bootstrapping compiler (if it is older than 7.8) than they are for the stage1 compiler. In order to solve this problem I introduced a compatibility module [[GhcFile(compiler/utils/ExtsCompat46)]] that provides different definition of primops for older versions of GHC (`__GLASGOW_HASKELL__ <= 706`) and different for newer versions (`__GLASGOW_HASKELL__ > 706`). However, once we set minimal version of GHC required for bootstrapping to be 7.8, we can (and should!) remove that compatibility module and go back to using GHC.Exts. This ticket is a reminder that we should do this after we release GHC 7.10 or 7.12. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8330> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8484: Compile-time panic
by GHC 20 Aug '15

20 Aug '15

#8484: Compile-time panic ----------------------------------+--------------------------------------- Reporter: Taymon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I attempted to build a program (using make) and got the following output: {{{ ghc -odir binaries -hidir binaries --make Main.hs -optl-w ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): While parsing "/home/taymonbeal/.ghc/x86_64-linux-7.6.3/package.conf.d/package.cache": too few bytes. Failed reading at byte position 8 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make: *** [build] Error 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8484> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9381: Implement rdynamic
by GHC 18 Aug '15

18 Aug '15

#9381: Implement rdynamic -------------------------------------+------------------------------------- Reporter: facundo.dominguez | Owner: Type: feature request | facundo.dominguez Priority: normal | Status: new Component: Compiler | Milestone: Keywords: | Version: 7.8.2 Architecture: Unknown/Multiple | Operating System: Difficulty: Unknown | Unknown/Multiple Blocked By: | Type of failure: Related Tickets: 7015 | None/Unknown | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently ghc ignores the `-rdynamic` flag. With a small effort it can be used as a synonym of `-optl -rdynamic` in linux and `-optl -export-all-symbols` in windows/mingw32. In other platforms, similar translations must be possible to get the symbols of an executable exported. This feature would improve usability of an upcoming implementation of #7015. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9381> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9903: GHCi produces a cryptic message when using HPC
by GHC 13 Aug '15

13 Aug '15

#9903: GHCi produces a cryptic message when using HPC -------------------------------------+------------------------------------- Reporter: facundo.dominguez | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.9 Keywords: hpc | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHCi crash Blocked By: | Test Case: Related Tickets: #9878, #9762 ? | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following test produces an impolite response from GHCi {{{ $ cat t.hs g :: Int g = 1 + 1 $ ghc-stage2 --interactive t.hs -fhpc GHCi, version 7.9.20141217: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( t.hs, interpreted ) Ok, modules loaded: Main. *Main> g ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20141217 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc25774_0/ghc25774_5.so: undefined symbol: _hpc_tickboxes_Main_hpc Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It has been noted elsewhere (#9878) that these kinds of messages are better avoided. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9903> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9218: Upgrade the version of MinGW shipped with GHC
by GHC 13 Aug '15

13 Aug '15

#9218: Upgrade the version of MinGW shipped with GHC ------------------------------------+--------------------------------- Reporter: komadori | Owner: komadori Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3390 | ------------------------------------+--------------------------------- The Windows binary distribution of GHC incorporates a version of MinGW which has not been updated for several releases and is now out-of-date. It should be upgraded. The previous time this was done appears to correlate with ticket #3390. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9218> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python
by GHC 12 Aug '15

12 Aug '15

#9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python -------------------------------------------+---------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------------+---------------------------- The released Windows 64 tarball available at https://www.haskell.org/ghc/dist/7.8.2/ghc-7.8.2-x86_64-unknown- mingw32.tar.xz includes the following under `mingw/bin`: * gfortran * gcj * python27.dll * The whole Python 2.7 standard library (`mingw/bin/lib`) These files have probably been included by mistake. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9014> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9143: feature request: way to set actual program argv
by GHC 12 Aug '15

12 Aug '15

#9143: feature request: way to set actual program argv ----------------------------------------------+---------------------------- Reporter: joeyhess | Owner: Type: feature request | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Keywords: | Version: 7.8.2 Architecture: Unknown/Multiple | Operating System: Linux Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- It's not currently possible to write a program with ghc that changes its argv, so as to change what the program name/parameters appear to be in ps. An example of a program that does this is sshd, which arranges for the process name to say which user it's serving. For example, "sshd: joey [priv]" I'd like to be able to write such programs using haskell too. Also, I have a haskell program that, due to the way it is executed, has a really horrible display in ps: /usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib64/ld-linux-x86-64.so.2 --library-path /usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib/x86_64-linux- gnu:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux- gnu:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib64:/usr/local/propellor/docker /android-git-annex- builder.orca.kitenet.net.propellor.shim/etc/ld.so.conf.d:/usr/local/propellor/docker /android-git-annex-builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64 -linux-gnu/audit:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux-gnu/gconv /usr/local/propellor/propellor That's enough motivation for me to dig into this. :) In rts/RtsMain.c, progargv is set to point to argv. However, it's static, so this cannot be (ab)used from the FFI to change argv. So, a minimal change would be to make progargv not be static, and perhaps give it a more formal name or minimal FFI binding. A GHC-specific library could then use this to modify argv. The haskell interface I'm considering would be: displayArgv :: [String] -> IO () It would need to truncate strings to fit within the available argv space. (This would not affect the argv used by System.Environment, which is a copy of argv.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9143> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages
by GHC 12 Aug '15

12 Aug '15

#9049: Expose srcLoc from the assertion architecture to allow better error messages ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Assertions give great error messages by including file name and line, but they are disabled for optimisation. While there is a compiler flag to turn them on even in presence of optimisation, this is an awkward external way to simply attach a useful error location to something like `error`. It would be great if we could decouple getting the current `srcLoc` from assertions, and making it available for good error messages. It is currently possible to do this using TemplateHaskell (e.g. the `placeholders` package) or `CPP`, but both are inconvenient for technical reasons (such as breaking tooling) and do not enjoy widespread use. It seems a shame that the architecture for annotated error messages is already there, but only available through a mechanism that is disabled for optimisation (or at least "intended" to be disabled for optimisation). Notably, we have the same architecture available for pattern mach failures: {{{ f x | x > 0 = "foo" main = putStrLn (f (-1)) -- gives srcLoc'd pattern match error message }}} {{{ f x | x > 0 = "foo" f _ = error "f needs a positive number" main = putStrLn (f (-1)) -- does not give a srcLoc'd error message }}} It seems non-sensical that your try to write a better error message (here using `error`) yields in fact a less-helpful error message. I completely agree that one can aid bug-fixing by writing globally unique arguments to `error` or using TH, but from an engineering perspective, a little bit of help from the language/compiler side can improve the situation a lot, and in other languages this is acknowledged and used to everybody's benefit. There are some alternatives we might consider, such as * exposing `srcLoc :: String` that gives an `assert`-style location at the lexical position of its occurrence * adding an `error`-like function that behaves like `error` but also prints a source location Arguably `srcLoc :: String` breaks equational reasoning on the ''syntactic'' level, as `let x = srcLoc in (x, x)` and `(srcLoc, srcLoc)` have different values. However, looking at it from a program execution point of view, referential transparency is preserved since once compiled, any function using `srcLoc` will always return the same location. I believe that offering ''some'' kind of improvement over the dreaded `error` or `Prelude: undefined` should be easy to implement, but let's hear what the people who actually know the compiler think about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9049> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 41

[GHC] #8178: Need TypeRep for Symbol and numeric type literals; and Typeable instances
by GHC 08 Aug '15

08 Aug '15

#8178: Need TypeRep for Symbol and numeric type literals; and Typeable instances ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Nicolas Trangez points out that we don't have a `TypeRep` for types involving literal strings or numerics. E.g. what is `(typeRep (undefined :: Proxy "foo"))`? Here is Nicolas's example: {{{ {-# LANGUAGE DataKinds, KindSignatures, DeriveFunctor, DeriveDataTypeable #-} module Main where import Data.Typeable import GHC.TypeLits data NoSymbol n a b = NoSymbol a b deriving (Typeable) data WithSymbol (n :: Symbol) a b = WithSymbol a b deriving (Typeable) data Sym deriving (Typeable) main :: IO () main = do print $ typeOf (undefined :: NoSymbol Sym Int Int) let d = undefined :: WithSymbol "sym" Int Int {- print $ typeOf d No instance for (Typeable Symbol "sym") arising from a use of ‛typeOf’ -} return () }}} Just as types contain literal strings and natural numbers, so too must `TypeRep`, in some way. Once we have a suitable `TypeRep` we can make built-in instance for `Typeable` that return the appropriate representation. At the moment we have (in `Data.Typeable.Internals`): {{{ data TypeRep = TypeRep {-# UNPACK #-} !Fingerprint TyCon [TypeRep] data TyCon = TyCon { tyConHash :: {-# UNPACK #-} !Fingerprint, tyConPackage :: String, tyConModule :: String, tyConName :: String } }}} with instances for Eq and Ord. Perhaps we need {{{ data TypeRep = TcApp {-# UNPACK #-} !Fingerprint TyCon [TypeRep] | TcSym String | TcNat Integer }}} or something like that? I'm not certain. I think Iavor is going to think about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8178> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9853: Stateful transformation causes non-termination in Hoopl analysis.
by GHC 08 Aug '15

08 Aug '15

#9853: Stateful transformation causes non-termination in Hoopl analysis. -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/hoopl | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It seems that Hoopl's analyses may apply rewrites to nodes multiple times without invoking the `restart` function between applications. This causes havoc for code transformations that have side-effects, for example a transformation that introduces a new variable to hold some intermediate result. In such an analysis, a transformation may introduce a new variable, which leads to a changed fact. Later the transformation may be run again, leading to a new fact, and so on (when there is a loop in the control flow. The attached example illustrates this problem. This example modifies the constant propagation pass provided in the testing directory of the hoopl library. The example added a new instruction called "Funny" that gets rewritten to an unconditional branch instruction and introduces a new variable. The main program P1 performs the analysis on a particular program that has a loop in the control flow graph and causes the hoopl analysis to run forever. Is this a bug in Hoopl? Ie. should analyses that have side-effects involving checkpointed state be supported? If not, could it be changed to support these analyses? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9853> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2