July 2018 - ghc-tickets

[GHC] #14247: Fails to coerce between newtypes directly
by GHC 29 Jul '18

29 Jul '18

#14247: Fails to coerce between newtypes directly -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- {{{#!hs import Data.Coerce import Data.Type.Coercion newtype W a = W a newtype A = MkA (W A) a :: Coercion A A a = Coercion b :: Coercion a a' -> Coercion a (W a') b Coercion = Coercion c :: Coercion A (W A) c = b a }}} works just fine but the following fail: {{{#!hs -- • Couldn't match representation of type ‘A’ with that of ‘W A’ -- arising from a use of ‘Coercion’ -- • In the expression: Coercion -- In an equation for ‘d’: d = Coercion d :: Coercion A (W A) d = Coercion -- • Couldn't match representation of type ‘A’ with that of ‘W A’ -- arising from a use of ‘coerce’ -- • In the expression: coerce -- In an equation for ‘e’: e = coerce e :: A -> W A e = coerce }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14247> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768
by GHC 28 Jul '18

28 Jul '18

#15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 --------------------------------------+------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.4.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- compiling files in ghci on MacOS eventually results in a panic with error: {{{ malformed mach-o: load commands size (32800) > 32768 }}} I can reproduce this problem by repeatedly compiling (and loading) a file and then deleting the .o file. I understand that this an OS limitation but why does repeatedly doing the same thing results in this? i.e. why don't I get it on the first compile (and load). It seems that successive loads are being appended to something eventually resulting in the error. To duplicate: ghci -ignore-dot-ghci -fobject-code < ghci.sh >& ghci.out & If you look for the first "panic" in the .out file you'll see {{{ Prelude Main> ghc: panic! (the 'impossible' happened) (GHC version 8.6.0.20180714 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib, 5): no suitable image found. Did find: /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib: malformed mach-o: load commands size (32800) > 32768 /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib: stat() failed with errno=25 }}} The critical part being {{{ malformed mach-o: load commands size (32800) > 32768 }}} My understanding from https://stackoverflow.com/questions/44902695/too- many-commands-dyld-message-malformed-mach-o-load-commands-size is that this has to do with sizeofcmds but if I understand the output of otool 0l this is only 512 so I don't understand what is causing the errror. {{{ otool -l c.o|head c.o: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags 0xfeedfacf 16777223 3 0x00 1 4 512 0x00002000 }}} This is irritating but perhaps the priority should be low rather than normal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15446> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15452: [GHCi] Add an option to make tab completion case-insensitive
by GHC 28 Jul '18

28 Jul '18

#15452: [GHCi] Add an option to make tab completion case-insensitive -------------------------------------+------------------------------------- Reporter: f-a | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 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: -------------------------------------+------------------------------------- There should be a ghci-option to have {{{ λ> readf<tab> }}} (notice the lowercase `f`) complete to {{{ λ> readFile }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15452> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9936: Data.Fixed truncates 5.17 to 5.16
by GHC 28 Jul '18

28 Jul '18

#9936: Data.Fixed truncates 5.17 to 5.16 -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 libraries/base | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `(realToFrac (5.17 :: Double) :: Centi) == 5.16` is true -- it should be false. The offender seems to be the assumption in `fromRational`: `fromRational r = withResolution (\res -> MkFixed (floor (r * (toRational res))))` Uses `floor` assuming that the underlying floating point value is stored purely and not as 0.999999 or similar -- switching it to `round` fixes this issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9936> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10919: ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised
by GHC 28 Jul '18

28 Jul '18

#10919: ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: recursion- | Owner: ninja | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: panic | Operating System: Linux impossible linker initialized | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- When trying to build the CUDA accelerate backend I get the following "complier panic": {{{ me@box:~/accelerate-cuda-0.15.0.0$ cabal build Building accelerate-cuda-0.15.0.0... Preprocessing library accelerate-cuda-0.15.0.0... Data/Array/Accelerate/CUDA/CodeGen/Base.hs:5:14: Warning: -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS [ 7 of 33] Compiling Data.Array.Accelerate.CUDA.CodeGen.Type ( Data/Array/Accelerate/CUDA/CodeGen/Type.hs, dist/build/Data/Array/Accelerate/CUDA/CodeGen/Type.o ) <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [ 9 of 33] Compiling Data.Array.Accelerate.CUDA.Debug ( Data/Array/Accelerate/CUDA/Debug.hs, dist/build/Data/Array/Accelerate/CUDA/Debug.o ) <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [10 of 33] Compiling Data.Array.Accelerate.CUDA.Analysis.Launch ( Data/Array/Accelerate/CUDA/Analysis/Launch.hs, dist/build/Data/Array/Accelerate/CUDA/Analysis/Launch.o ) <no location info>: <command line>: can't load .so/.DLL for: /home/me/.cabal/lib/x86_64 -linux-ghc-7.10.2/cuda-0.6.7.0-EMlxEWvymgZGXnLSaVKypt/libHScuda-0.6.7.0 -EMlxEWvymgZGXnLSaVKypt-ghc7.10.2.so (libcudart.so.7.5: cannot open shared object file: No such file or directory) }}} This is the accelerate cuda package version 0.15.0.0: https://hackage.haskell.org/package/accelerate-cuda I changed the constraints from base==4.7.* to base==4.8.* to allow for compilation with GHC 7.10.2. After installing the dependencies through cabal and attempting to manually build the package manuall with cabal build I get the above mentioned compiler panics. GHC instructed me to report the issue as a bug (defect) so I did. I'd like to get this library to build with the newest version of GHC so please let me know how to proceed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10919> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15340: Investigate using Ward on RTS
by GHC 27 Jul '18

27 Jul '18

#15340: Investigate using Ward on RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- While debugging a locking issue a few weeks ago I found myself pining for static analysis tooling. Today I briefly looked at the options and one stood out: [[https://github.com/evincarofautumn/Ward|Ward]] It sits in a very nice point in the design space, allowing the user to specify the universe of privileges and annotate functions using standard C attributes. I think this would be a very helpful tool for GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15340> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12694: GHC HEAD no longer reports inaccessible code
by GHC 27 Jul '18

27 Jul '18

#12694: GHC HEAD no longer reports inaccessible code -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- Given this A.hs: {{{ {-# LANGUAGE GADTs #-} module A where f :: Bool ~ Int => a -> b f x = x }}} I get: {{{ ezyang@sabre:~$ ghc-head --version The Glorious Glasgow Haskell Compilation System, version 8.1.20161010 ezyang@sabre:~$ ghc-head --make A.hs [1 of 1] Compiling A ( A.hs, A.o ) A.hs:4:1: warning: [-Woverlapping-patterns] Pattern match is redundant In an equation for ‘f’: f x = ... }}} In contrast: {{{ ezyang@sabre:~$ ghc-8.0 --make A.hs [1 of 1] Compiling A ( A.hs, A.o ) A.hs:3:6: error: • Couldn't match type ‘Bool’ with ‘Int’ Inaccessible code in the type signature for: f :: Bool ~ Int => a -> b • In the ambiguity check for ‘f’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: f :: Bool ~ Int => a -> b }}} Is this expected? I'd expect at least a warning! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12694> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13766: Confusing "reudundant pattern match" in 8.0, no warning at all in 8.2
by GHC 27 Jul '18

27 Jul '18

#13766: Confusing "reudundant pattern match" in 8.0, no warning at all in 8.2 -------------------------------------+------------------------------------- Reporter: edsko | 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: -------------------------------------+------------------------------------- I couldn't find an existing ticket about this, so I figured I'd file this even though it's probably an instance of a more general problem. Consider {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -Wall -Woverlapping-patterns #-} module T where class C a where c :: a -> a instance Int ~ Bool => C Int where c = id }}} yields {{{ T.hs:10:3: warning: [-Woverlapping-patterns] Pattern match is redundant In an equation for ‘c’: c = ... }}} which I suppose makes _some_ amount of sense but is highly confusing nonetheless :) Now in 8.2 I don't get this warning, but in fact I don't get any warning at all, which I'm not entirely sure is better. In the real code obviously the superclass constraint was far more complicated and it was nice of ghc to warn me (albeit in a roundabout way) that it was unsatisfiable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13766> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14949: Perform builds on non-Debian-based systems on Circle CI
by GHC 27 Jul '18

27 Jul '18

#14949: Perform builds on non-Debian-based systems on Circle CI -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- I could not find already existing ticket and so I'm creating this one. Ben mentioned (in his latest status update on GHC devops mailing list) that we need to do building on non-Debian-based systems on CI. To quote: > e. Support for building on non-Debian-based systems (e.g. Fedora), which is necessary if we want to produce our binary distributions via CI. So this ticket is to track progress on that. I'm planning to start working on this tomorrow perhaps. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14949> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15448: Allow execution of stage2 compiler to happen later
by GHC 27 Jul '18

27 Jul '18

#15448: Allow execution of stage2 compiler to happen later -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14949 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently cross-compiled bindists are rather incomplete since we can't run the stage2 compiler to build various utilities (e.g. `hp2ps` and `haddock`). Ideally we would be able to run a build up to the point where we need to run host code, package up the build tree, and finish the build on the host. There are a number of challenges that this brings, but it will ultimately make it far easier to build proper non-Linux/amd64 bindists on CircleCI (#14949). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15448> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0