December 2014 - ghc-tickets

[GHC] #9122: Make Lint check for bad uses of `unsafeCoerce`
by GHC 10 Mar '15

10 Mar '15

#9122: Make Lint check for bad uses of `unsafeCoerce` ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- I think it would be a great idea for Core Lint to check for uses of `unsafeCoerce` that don't obey the rules. It won't catch all cases, of course, but it would have caught #9035. Specficially, look for: * Coercions between lifted and unboxed types * Coercion between unboxed types of different sizes * Coercion between unboxed ints and floats. Would anyone like to make a patch for this? Anything that can be checked by Core Lint, should be checked! I'm afraid I don't know where to look for the reason for the int/float difficulty. I'd write a tiny function that exhibits the unsafe conversion and look the code it generates. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9122> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9524: GHC uses wrong linker when cross compiling
by GHC 09 Mar '15

09 Mar '15

#9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Building Blocked By: | GHC failed Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Greetings, I tried to compile a cross compiler for x86_64-w64-mingw32. Most of GHC compiles fine. However, after a while there's an error that ld can't find a reference to "GetModuleFileNameW". I tried compiling a dummy C program with that symbol and it compiles fine. My guess is that GHC is using the wrong linker during cross-compiling, whereas GCC uses the right one. But I may be totally wrong, so please don't rely on that judgement. The log of the make run is attached. Regards Sven -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9524> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8780: abs for IEEE floating point is slightly wrong.
by GHC 08 Mar '15

08 Mar '15

#8780: abs for IEEE floating point is slightly wrong. ------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | 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: | ------------------------------------+------------------------------------- Evaluating abs(-0) gives the answer -0. This unexpected since it breaks invariants like 1/(abs x) >= 0. So abs(-0) should be 0. This is also the norm for other languages. Together with this change, signum should also be changed so signum(-0) is -0. This maintains the invariant abs x * signum x == x. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8780> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable`
by GHC 07 Mar '15

07 Mar '15

#9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- comment:ticket:9111:16 explains that import-cycles containing `Data.Typeable.Internal` (which provides the `Typeable` class `AutoDeriveTypeable` needs to be loaded for being able to operate) inside `base` make it difficult to use `AutoDeriveTypeable`, as well as making it more difficult to de-cycle the `base` import-dependency graph (see also attachment:typeable_deps.pngtypeable_deps.png) This ticket is about trying to find a way to restructure `base` in order to allow to define the `Typeable` instances directly at the type's defining site (and thus allow the use of `AutoDeriveTypeable`) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9707> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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 03 Mar '15

03 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] #9044: createDirectoryIfMissing does not fail on unwritable parent dir
by GHC 02 Mar '15

02 Mar '15

#9044: createDirectoryIfMissing does not fail on unwritable parent dir -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/directory | Operating System: MacOS X Keywords: | Type of failure: Incorrect result Architecture: Unknown/Multiple | at runtime Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- On OSX, using `createDirectoryIfMissing` to create a new directory inside a directory for which we do not have write permissions does not throw any exception. Of course it should throw an exception, as it does under Linux. {{{ $ mkdir unwritable $ chmod ugo-w unwritable $ ghci > System.Directory.createDirectoryIfMissing True "unwritable/tst" > }}} On OSX (10.9.2) this does not fail. Under Linux (albeit with 7.6.3) this does throw an exception as expected: {{{ *** Exception: unwritable/tst: createDirectory: permission denied (Permission denied) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9044> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9901: Error message: f is applied to two arguments, but its type has only two (sic)
by GHC 02 Mar '15

02 Mar '15

#9901: Error message: f is applied to two arguments, but its type has only two (sic) -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I occasionally get type errors where the error message refers to a function’s arity in a contradictory way: > The function ‘X’ is applied to two arguments, […] but its type has only two. Here’s a full error message of this kind: lenstest.hs:89:12: Couldn't match type ‘Either String Int’ with ‘Maybe b0’ Expected type: [Char] -> Either String Int Actual type: [Char] -> Maybe b0 The function ‘preview’ is applied to two arguments, but its type ‘Getting (Data.Monoid.First b0) (Either b0 c0) b0 -> [Char] -> Maybe b0’ has only two In the second argument of ‘($)’, namely ‘(preview _Left "abc" :: Either String Int)’ In a stmt of a 'do' block: print $ (preview _Left "abc" :: Either String Int) Failed, modules loaded: none. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9901> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4
by GHC 02 Mar '15

02 Mar '15

#9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4 -------------------------------------+------------------------------------- Reporter: nich | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: aclocal.m4 find | Operating System: perm | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Easy (less than 1 | GHC failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- ./configure produces error message when building on current Fedora (20). According to find ver 4.5.11 the usage '-perm +XXX' has been deprecated since 2005 (use '-perm \XXX' instead). The message '/usr/bin/find: invalid mode '+111' ' is seen several times as a result. Whether this has any material impact I am not qualified to judge. I am actually trying to build HaLVM (from Galois) and first noticed the issue in their fork of GHC. However, this behaviour is also present in git HEAD (commit d7867810d5ffd08c77c30e928bb3dca21beae0b9). Making the obvious one line change in aclocal.m4 resolves the issue, and produces a clean build, for me at least. Patch attached -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9697> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9328: MINIMAL pragma should supprt negation
by GHC 02 Mar '15

02 Mar '15

#9328: MINIMAL pragma should supprt negation -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Consider this class declaration {{{ class Conv a where to :: Integer -> a from :: a -> Integer default to :: (Generic a) => Integer -> a to i = ... default from :: (Generic a) => a -> Integer from a = ... }}} The class provides default methods for the two methods using generics. An instance declaration for this type is likely to want to use the default for both methods or for none. So I'd like a MINIMAL pragma that can express this. E.g. {{{ {-# MINIMAL (to, from) | (!to, !from) #-} }}} I've used ! for negation (following the lead set by the MINIMAL pragma using a non-Haskell OR operator), so this says: either implement 'to' and 'from' or don't implement neither 'to' nor 'from'. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9328> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2