September 2013 - ghc-tickets

[GHC] #8315: Improve specialized Hoopl module
by GHC 18 Mar '15

18 Mar '15

#8315: Improve specialized Hoopl module ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: low | 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: | ------------------------------------+------------------------------------- GHC uses Hoopl to perform some of the Cmm-to-Cmm optimization passes, but instead of relying directly on Hoopl library GHC uses its own specialized module (see [[GhcFile(compiler/cmm/Hoopl/Dataflow.hs)]]). Interface of that module, as well as its internal implementation can be improved. Right now interface places responsibility of maintaining some of the invariants on user. It also ignores differences between forward and backward analysis. [http://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup This wiki page] gives full detail about proposed design changes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8315> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8274: Core pretty-printer doesn't print # on unboxed literals
by GHC 03 Mar '15

03 Mar '15

#8274: Core pretty-printer doesn't print # on unboxed literals ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I just noticed that Core pretty printer produces something like this (this is part of expected output for T3772 in testsuite): {{{ case GHC.Prim.<=# n# 0 of _ { __DEFAULT -> xs n#; 1 -> GHC.Tuple.() } }}} Both `0` (in scrutinee) and `1` (one of branch alternatives) are unboxed values, so they should be printed as `0#` and `1#` respectively. I haven't checked whether unboxed literals of other types (`Word`, `Double`, `Float`) are printed in that way, but I would guess that yes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8274> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8342: System.Directory.getPermissions does not work well on Windows 7
by GHC 02 Mar '15

02 Mar '15

#8342: System.Directory.getPermissions does not work well on Windows 7 ---------------------------------------+--------------------------------- Reporter: freizl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 7.4.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ---------------------------------------+--------------------------------- It works well for following code {{{ System.Directory.getPermissions "/path/to/somewhere" }}} However getting error with this: {{{ System.Directory.getPermissions "/path/to/somewhere/" *** Exception: getPermissions: does not exist (No such file or directory) }}} The only difference is the path name. It gets error when having extra trailing slash. It looks wired. Thanks your help. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8342> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8189: Default to infinite stack size?
by GHC 24 Feb '15

24 Feb '15

#8189: Default to infinite stack size? ------------------------------------+------------------------------------- Reporter: nh2 | 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: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- http://www.haskell.org/pipermail/haskell-cafe/2013-August/108570.html It looks like any code of the form {{{ ... = do x1 <- m1 x2 <- m2 [do something with x1 and m2] }}} will stack overflow when used with a strict monad (like IO) and sufficiently large data to deal with (a 1m element list is enough to exceed the default 8MB stack size limit). Other examples include: {{{ sequence (m:ms) = do x <- m xs <- sequence ms return (x:xs) }}} and {{{ liftM2, liftM3, ... }}} By slightly modifying your program to do the same thing via heap allocation (e.g. using a difference list in sequence), a stack-overflow rejected program turns into a valid program. This means that valid and idiomatic code like {{{ xs <- replicateM n someIOAction xs <- mapM someIOAction [1..n] }}} will eventually crash, which has an impact on practically all Haskell software and libraries out there. For examples, see https://github.com/ndmitchell/shake/blob/e0e0a43/Development/Shake/Database… https://github.com/haskell-suite/haskell-src-exts/issues/27 as well as the mapM usages in cabal, haddock, any database binding that allows querying a lists of results, etc. While some argue that ''"you shouldn't use lists of that size"'', ''"allocating a 150 MB list is wrong"'' or that they ''"carefully avoid any use of sequence/mapM due to the problem"'' pointed out above, I think that collecting a million results of a strict monadic action into a linked list using standard functions like mapM is a common pattern and valid use case. The stack based evaluation that GHC performs is an optimization and should be transparent to the user; it should not re-define some data to live in a fixed-size memory region, and it should work just as well as it does in GHCi. It seems that a default infinite stack size would mitigate this. A drawback might be that the stack space overflows we get so far to quickly spot a "wrong" program would not indicate certain errors any more. I currently doubt the usefulness of this debugging method, since it does not work reliably in the presence of optimization, doing the same thing via heap allocation makes the programs "correct", and it rejects valid programs if the input data is large enough. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35

[GHC] #8309: traceEvent truncates to 512 bytes
by GHC 23 Feb '15

23 Feb '15

#8309: traceEvent truncates to 512 bytes ------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: eventlog tracing | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The `Debug.Trace.traceEvent` (& `traceEventIO`) use a code path that unnecessarily uses printf format strings and uses a fixed size 512-byte buffer, hence truncating all user trace messages at that size. Here is the call path: * `Debug.Trace.traceEvent` (& `traceEventIO`) call `traceEvent#` primop * cmm impl of the primop `stg_traceEventzh` calls C RTS function `traceUserMsg` * `traceUserMsg` calls `traceFormatUserMsg(cap, "%s", msg);`, using the printf format string * `traceFormatUserMsg` uses `postUserMsg` which eventually calls `postLogMsg` * `postLogMsg` does the printf stuff Here's what `postLogMsg` does: {{{ #define BUF 512 void postLogMsg(EventsBuf *eb, EventTypeNum type, char *msg, va_list ap) { char buf[BUF]; nat size; size = vsnprintf(buf,BUF,msg,ap); if (size > BUF) { buf[BUF-1] = '\0'; size = BUF; } .... }}} This is obviously designed for RTS-internal users, not the user path. So the problem starts with this bit: {{{ void traceUserMsg(Capability *cap, char *msg) { traceFormatUserMsg(cap, "%s", msg); } }}} It just should not use that code path. It should call something that directly posts the message, without any silly printf strings. In fact, the code path from the primop down should really be changed to use an explicit given length, rather than using a null-terminated string and having to call strlen. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8309> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8362: Filesystem related tests failed on solaris (SmartOS)
by GHC 22 Feb '15

22 Feb '15

#8362: Filesystem related tests failed on solaris (SmartOS) --------------------------+------------------------------------------------ Reporter: leroux | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: | Version: 7.6.3 libraries (other) | Operating System: Solaris Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Getting filesystem (files/permissions) related test faiures on SmartOS (32bit). {{{ $ uname -a SunOS pkgx86 5.11 joyent_20130919T215407Z i86pc i386 i86pc Solaris }}} Unexpected failures: `TEST="openFile003 getPermissions001 processGroup002 user001 posix005"` The testsuite output is attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8362> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8280: Deriving Show for Word#
by GHC 20 Feb '15

20 Feb '15

#8280: Deriving Show for Word# ------------------------------------+------------------------------------- Reporter: monoidal | 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: | ------------------------------------+------------------------------------- {{{ {-# LANGUAGE MagicHash #-} import GHC.Prim data A = A Word# deriving Show }}} This works in 7.6.3, but 7.7 gives {{{ Can't find interface-file declaration for data constructor GHC.Types.W# Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error }}} The same file works if Word# is replaced by Int#. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8280> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8266: Dynamic linking on Mac
by GHC 04 Feb '15

04 Feb '15

#8266: Dynamic linking on Mac ------------------------------+-------------------------------------------- Reporter: kazu- | Owner: yamamoto | Status: new Type: bug | Milestone: Priority: highest | Version: 7.7 Component: Build | Operating System: MacOS X System | Type of failure: GHC doesn't work at all Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Many dynamic libraries refer to the build tree. (1) Every ".dylib" installed with GHC head refers to itself in its build directory. E.g. {{{ % otool -L libHSbase-4.7.0.0-ghc7.7.20130909.dylib | grep base libHSbase-4.7.0.0-ghc7.7.20130909.dylib: /Users/kazu/work/ghc/libraries/base/dist- install/build/libHSbase-4.7.0.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) }}} (2) Some ".dylib" installed with GHC head refers to other libraries in their build directories. E.g. {{{ % otool -L libHSvector-0.9.1-ghc7.7.20130909.dylib | grep /Users /Users/kazu/work/ghc/libraries/vector/dist- install/build/libHSvector-0.9.1-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/primitive/dist- install/build/libHSprimitive-0.4.0.1-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) }}} (3) All user installed libraries by cabal-install refer to other libraries in their build directories. E.g. {{{ % otool -L libHSghc-paths-0.1.0.9-ghc7.7.20130909.dylib| grep Users /Users/kazu/Library/Haskell/ghc-7.7.20130909/lib/ghc- paths-0.1.0.9/lib/libHSghc-paths-0.1.0.9-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/base/dist- install/build/libHSbase-4.7.0.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/integer-gmp/dist-install/build /libHSinteger-gmp-0.5.1.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/ghc-prim/dist-install/build /libHSghc-prim-0.3.1.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8266> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 59

[GHC] #8240: Better error messages for type family constraints
by GHC 11 Dec '14

11 Dec '14

#8240: Better error messages for type family constraints ------------------------------------+------------------------------------- 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: | ------------------------------------+------------------------------------- Consider this constraint {{{ F Int ~ Bool -- Arising (say) on line 5 F Int ~ Char -- Arising (say) on line 10 }}} At the moment we'll combine the two to {{{ F Int ~ Bool -- Arising on line 5 Bool ~ Char -- Arising on line 10 }}} The second of these errors is "insoluble" and is reported first. But it's totally misleading: nowhere in the program did we directly need `Int~Char`. Another variant of this came up in Trac #8227. There we get the constraint {{{ Scalar (V a) ~ t0 Scalar (V a) ~ t0 -> t0 }}} which leads to {{{ Scalar (V a) ~ t0 -> t0 t0 ~ t0 -> t0 -- Occurs check }}} which gives the confusing error {{{ T8227.hs:16:44: Occurs check: cannot construct the infinite type: t0 ~ t0 -> t0 Expected type: Scalar (V (t0 -> t0)) Actual type: Scalar (V a) }}} I think the solution is * Do not combine two Wanteds {{{ [W] F tys ~ t1 [W] F tys ~ t2 }}} unless t1 and t2 are both touchable unification variables. * Instead (perhaps) generate a Derived constraint {{{ [D] t1 ~ t2 }}} to express the fact that t1 and t2 had better end up equal. * To do this the inert set would need to contain many `CTyFunEq` constraints with the same LHS. I'm not very sure about this, and no time now, so I'm just making this ticket to record the issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8240> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8304: more lenient operator sections (RelaxedSections extension)
by GHC 01 Dec '14

01 Dec '14

#8304: more lenient operator sections (RelaxedSections extension) -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Parser) | 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: | -------------------------------------+------------------------------------- Some operator sections are rejected which could have some meaning. {{{ (a ++ b ++ ) could mean \x -> a ++ b ++ c (++ a ++) could mean \x y -> x ++ a ++ y }}} The attached quasiquoter implements this, but for various reasons it would be better if ghc supported this directly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2