August 2015 - ghc-tickets

[GHC] #10498: "if ... then \case -> else ..." causes a "missing else clause" error
by GHC 22 Oct '15

22 Oct '15

#10498: "if ... then \case -> else ..." causes a "missing else clause" error -------------------------------------+------------------------------------- Reporter: | Owner: dramforever | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple (Parser) | Type of failure: Other Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following program: {{{#!hs {-# LANGUAGE LambdaCase #-} foo = if True then \case -> 1 -> 2 else id }}} Produces this message: {{{ problem.hs:4:5: parse error in if statement: missing required else clause }}} The problem in the code is that there's a -> after the \case. I don't know if a better error message can be generated, but this one is really unhelpful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10498> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10375: arm: ghci.debugger tests hit illegal instruction
by GHC 22 Oct '15

22 Oct '15

#10375: arm: ghci.debugger tests hit illegal instruction ---------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------+------------------------------------- Some GHCi tests on arm/linux ie: {{{ (cd testsuite ; make TEST="print018 print020 print021 print022 print025") }}} fail, all with the same error: {{{ Stderr: Illegal instruction }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10375> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 68

[GHC] #10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type
by GHC 22 Oct '15

22 Oct '15

#10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type -----------------------------------+--------------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+--------------------------------------- ghc: internal error: scavenge: unimplemented/strange closure type 0 @ 0xac103240 (GHC version 7.10.1 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted I can consistently get either this crash, or a segfault from ghc, building git-annex on an arm system. Seems about 50/50. In either case, it crashes either before ghc has printed out any "Compiling" lines, or within the first 1 or 2 files compiled. I got lucky and found out a way to avoid the crash.. cabal was passing -j2 to ghc. If I remove the -j2, the build proceeds without a crash. The hardware is a CubieTruck arm board, with 2 gb of ram, and 1 cpu core, running Debian armel unstable, with kernel 3.4.103. I was able to use cabal to install the entire dependencies of git-annex, all the way up to yesod, which takes hours on this hardware, and all that built ok.. so I think the hardware is pretty stable, but still cannot really rule out a hardware problem. Happy to debug further, although this machine is a bit resource constrained to do things like building ghc on it. ghc 7.8.4 and 7.10.1 both crash the same way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10469> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10014: Data.Array.Base.elems needlessly calls bounds.
by GHC 21 Oct '15

21 Oct '15

#10014: Data.Array.Base.elems needlessly calls bounds. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Core | Operating System: Unknown/Multiple Libraries | Type of failure: Runtime Keywords: | performance bug Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ elems arr = case bounds arr of (_l, _u) -> [unsafeAt arr i | i <- [0 .. numElements arr - 1]] }}} It never uses the result. I'd propose simplifying it to {{{ elems arr = [unsafeAt arr i | i <- [0 .. numElements arr - 1]] }}} It appears at some point someone optimized it to use the `unsafeAt`, but never removed the bounds check. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10014> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10049: Lower level memcpy primop
by GHC 21 Oct '15

21 Oct '15

#10049: Lower level memcpy primop -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm doing some really low-level buffer stuff, and it would be quite helpful if there were lower-level memcpy primitives. I'm thinking something like: {{{#!hs copyBytes# :: Addr# -> Addr# -> Int# -> State# s -> State# s copyBytes dst src size _ = ... }}} I would expect it to compile, on x86, into "rep movsb", which is frequently optimal on Ivy Bridge and Haswell. The other memcpy primitives use Array# or MutableArray#, and it's not clear how, if all you have is an Addr#, how to get the corresponding Array# or MutableArray#. (Can you just cast?) It may be appropriate to have corresponding 16-bit and 32-bit operations; "rep movsw" and "rep movsd", respectively. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10049> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10494: Representational equalities over AppTys are not hard failures
by GHC 21 Oct '15

21 Oct '15

#10494: Representational equalities over AppTys are not hard failures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If I say {{{ module App where import Data.Coerce foo :: Coercible (a b) (c d) => a b -> c d foo = undefined }}} I get {{{ App.hs:5:8: error: Couldn't match representation of type ‘a b’ with that of ‘c d’ Inaccessible code in the type signature for: foo :: Coercible (a b) (c d) => a b -> c d In the ambiguity check for the type signature for ‘foo’: foo :: forall (a :: * -> *) b (c :: * -> *) d. Coercible (a b) (c d) => a b -> c d To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ‘foo’: foo :: Coercible (a b) (c d) => a b -> c d }}} This is very silly, indeed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10494> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10817: Looping default associated type family without UndecidableInstances
by GHC 21 Oct '15

21 Oct '15

#10817: Looping default associated type family without UndecidableInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Proxy class C a where type F a type F a = F a instance C Bool x :: Proxy (F Bool) x = Proxy }}} GHC just loops. Setting a low `-ftype-function-depth` doesn't help. I actually don't terribly mind the looping (although aborting with an overflow would be better). But I don't like that it's possible without `UndecidableInstances` in sight. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10817> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10672: checkProddableBlock crash during Template Haskell linking
by GHC 21 Oct '15

21 Oct '15

#10672: checkProddableBlock crash during Template Haskell linking -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: #9297 #10563 Differential Revisions: | #8237 -------------------------------------+------------------------------------- When compiling an executable that uses Template Haskell against a library that contains C++ code, GHC crashes: {{{ [2 of 2] Compiling Main ( app\Main.hs, dist\build\main\main- tmp\Main.o ) ghc.exe: internal error: checkProddableBlock: invalid fixup in runtime linker: 0000000000360564 (GHC version 7.10.1 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I've boiled this down into a minimal reproduction of a library that includes a .cpp file, and an executable that depends on it. To test: {{{ git clone https://github.com/lukexi/cxx-link-fail-repro cabal run }}} The crash does not occur in the repro unless I use C++ exceptions in the library, and use Template Haskell in the executable, but in the project I boiled this down from (http://github.com/lukexi/bullet-mini) the problem occurs even with {{{cc-options: -fno-exceptions}}}. Some more details are at https://github.com/lukexi/cxx-link-fail-repro The platform is Windows 8.1 under MSYS2 (GHC is still using its inbuilt mingw). I've also tried 7.10.2-RC1 with the same result. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #10225: GHC does not specialize based on type equality
by GHC 21 Oct '15

21 Oct '15

#10225: GHC does not specialize based on type equality -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Based on my testing, it seems that if I have a function like f :: (v ~ V2) => v -> v this will be slower than f :: v -> v It would be great if GHC could do this optimization. The reason I want this is that I have written some very generic functions in my program, which are actually only used for one type. SPECIALIZE doesn't seem to do enough, as it's hard to get those GHC to "see" all of those types. As a compromise, I tried to tell GHC what those types actually are via type equalities, so that I can keep type constraints around for the future. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10225> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10258: internal error: evacuate: strange closure type 3269
by GHC 21 Oct '15

21 Oct '15

#10258: internal error: evacuate: strange closure type 3269 -------------------------------------------+------------------------------- Reporter: lukaramu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- When trying to load the attatched source into GHCi, it spit out the following error: {{{ ghc.exe: internal error: evacuate: strange closure type 3269 (GHC version 7.8.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} I could not reproduce the bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1