May 2015 - ghc-tickets

[GHC] #9511: Remove deprecated -fglasgow-exts from NoFib suite
by GHC 14 Jun '15

14 Jun '15

#9511: Remove deprecated -fglasgow-exts from NoFib suite -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: low | Milestone: Component: NoFib benchmark | Version: 7.8.3 suite | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Someone on #ghc noted that replacing -fglasgow-exts with only the necessary options in each case may change compile times, which may be undesirable. I think a reasonable workaround would be to just put all the options on the command line, whether necessary or not. This will increase the time needed to parse the command lines, but presumably by a trivial amount. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9511> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

overlapping instances in 7.10.1
by Sergei Meshveliani 14 Jun '15

14 Jun '15

Dear GHC developers, This request overrides my previous one of "7.10.1-err..." (it is simpler and more precise). The archive http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may23-2… presents a question about ghc-7.10.1. Make it, please, with ghc-7.10.1 by ghc $doconCpOpt -O --make Main , $doconCpOpt = -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports -fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns -XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances -XTypeSynonymInstances -XFlexibleInstances -fcontext-stack=30 as it is written there in README.txt. README.txt explains which two instances are wrongly resolved -- as I expect. In ghc-7.8.2 they are resolved in a correct way (and there is a different pragma syntax). I conclude this from running the test in docon-2.12. Am I missing something? Please, advise, ------ Sergei

2 1

[GHC] #10152: Testsuite diffs can be misleading when normalisers are in use
by GHC 13 Jun '15

13 Jun '15

#10152: Testsuite diffs can be misleading when normalisers are in use -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: low | Milestone: Component: Test Suite | 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: | -------------------------------------+------------------------------------- When output fails to match, GHC will output the diff based on the original outputs. However, this is misleading: some "differences" will actually have been normalised by the whitespace and more substantive normalisers we apply. So you really have to compare the normalised output to see what the /real/ difference is. Unfortunately, the real normalised output is missing newlines, so it's not really suitable for diffing. So it's not really clear what an improved algorithm would be. This seems to not actually be a problem in practice, since SOP for messages which need heavy normalizing is that when the new message looks good, it's just 'make accept'ed. Can be a little confusing when you're developing normalisers. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10152> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8435: Do not copy stack after stack overflow
by GHC 13 Jun '15

13 Jun '15

#8435: Do not copy stack after stack overflow ------------------------------+-------------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I am not sure, but I was doing a close reading of `threadStackOverflow` and noticed that after we throw a stack overflow exception, we fall through to the code responsible for allocating a new stack and copying the code over. An old iteration of the stack overflow code (removed in the commit cited below) did return after throwing the exception, and I did not see anything in the commit message suggesting the change was intentional. It seems sound to copy the stack; it will just become dead immediately. The relevant commit: {{{ commit f30d527344db528618f64a25250a3be557d9f287 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Wed Dec 15 12:08:43 2010 +0000 Implement stack chunks and separate TSO/STACK objects }}} Suggested (untested) patch: {{{ diff --git a/rts/Threads.c b/rts/Threads.c index 742119d..ccd6b17 100644 --- a/rts/Threads.c +++ b/rts/Threads.c @@ -533,6 +533,7 @@ threadStackOverflow (Capability *cap, StgTSO *tso) // Send this thread the StackOverflow exception throwToSingleThreaded(cap, tso, (StgClosure *)stackOverflow_closure); + return; } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8435> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10468: debug test case fails on Windows
by GHC 13 Jun '15

13 Jun '15

#10468: debug test case fails on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: scpmw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Debugging) | Operating System: Windows Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: debug | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Here's the make output: {{{ $ make debug # Without optimisations, we should get annotations for basically # all expressions in the example program. echo == Dbg == == Dbg == 'C:/msys64/home/ezyang/ghc-validate/inplace/bin/ghc-stage2.exe' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs debug -fforce-recomp -g -dppr-ticks -ddump-cmm \ | grep -o src\<debug.hs:.*\> | sort -u C:\msys64\tmp\ghc21036_0\ghc21036_2.s: Assembler messages: C:\msys64\tmp\ghc21036_0\ghc21036_2.s:421: Error: junk at end of line, first unrecognized character is `,' C:\msys64\tmp\ghc21036_0\ghc21036_2.s:508: Error: junk at end of line, first unrecognized character is `,' C:\msys64\tmp\ghc21036_0\ghc21036_2.s:557: Error: junk at end of line, first unrecognized character is `,' C:\msys64\tmp\ghc21036_0\ghc21036_2.s:559: Error: junk at end of line, first unrecognized character is `,' src<debug.hs:(3,1)-(5,29)> src<debug.hs:3:9> src<debug.hs:4:9> src<debug.hs:5:13-17> src<debug.hs:5:14> src<debug.hs:5:21-29> src<debug.hs:5:25-29> src<debug.hs:5:26> src<debug.hs:5:9-17> src<debug.hs:5:9-29> src<debug.hs:6:1-21> ./debug make: ./debug: Command not found Makefile:9: recipe for target 'debug' failed make: *** [debug] Error 127 }}} Peter, can you take a look? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10468> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10175: User's Guide 7.4.4 ExplicitTypeOperators typo
by GHC 13 Jun '15

13 Jun '15

#10175: User's Guide 7.4.4 ExplicitTypeOperators typo -------------------------------------+------------------------------------- Reporter: Shou | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.4 Documentation | Operating System: Unknown/Multiple Keywords: typo | Type of failure: None/Unknown extension | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- > There is now some potential ambiguity in import and export lists; for example if you write import M( (+) ) do you mean the function (+) or the type constructor (+)? The default is the former, but with -XExplicitNamespaces (which is implied by -XExplicitTypeOperators) GHC allows you to specify the latter by preceding it with the keyword type, thus: [...] GHC lists no extension `-XExplicitTypeOperators`, so it is assumed to be a mistake intended to be `-XTypeOperators`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10175> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10239: Fragile CPP test for big endian in T7600
by GHC 12 Jun '15

12 Jun '15

#10239: Fragile CPP test for big endian in T7600 -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Blocked By: Test Case: T7600 | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In test T7600 the C pre-processor test for big endian is broken in older versions of glibc. I have a patch that replaces the fragile CPP test with an integer read, which will always be the correct endianness. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10239> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10211: Validate fails in RTS tests on Mac OS X
by GHC 12 Jun '15

12 Jun '15

#10211: Validate fails in RTS tests on Mac OS X -------------------------------------+------------------------------------- Reporter: dalaing | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #9389 rts/linker_unload | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The failure of rts/linker_unload is due to an #include <malloc.h> which isn't found on OS X. It appears to be needed for Windows. I think we can either use CPP to remove the include for Mac OS X or to conditionally do # include <malloc/malloc.h> instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10211> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9746: tests/ghci/scripts/T8172 is sensitive to drive name on Windows
by GHC 12 Jun '15

12 Jun '15

#9746: tests/ghci/scripts/T8172 is sensitive to drive name on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The test fails when the checkout is not on drive C:, like this: --- ./ghci/scripts/T8172.stdout-mingw32 2014-10-28 23:28:12.264410700 +0100 +++ ./ghci/scripts/T8172.run.stdout 2014-10-30 15:20:13.964595800 +0100 @@ -1,11 +1,11 @@ current working directory: - C:\ + K:\ module import search paths: . current working directory: - C:\ + K:\ module import search paths: none current working directory: - C:\ + K:\ module import search paths: / -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9746> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9252: Generalize hs-boot files to be more like module signatures
by GHC 11 Jun '15

11 Jun '15

#9252: Generalize hs-boot files to be more like module signatures ------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: backpack | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Right now, `hs-boot` is used solely to support mutually recursive modules. However, as [wiki:Backpack Backpack] has shown, signatures are an essential part of separate modular development, and since hs-boot files are essentially module signatures, it would be good to move away from "hs- boot as a technical mechanism to make mutual recursion to work" to "hsig as a module signature useful for separate modular development and mutual recursion." Here are some of the things that this would entail: 1. Introduce hsig as a valid alternate file suffix to hs-boot (similarly have hisig for hi-boot; the plan being to eventually deprecate the hs-boot prefix) 2. Given an hsig file corresponding to a module in the current package database (but not from the currently being compiled package), check if the corresponding module implements the signature (this is the reverse of the current check we do for hs-boot files, which occurs when we typecheck the module, as opposed to the hs-boot file.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9252> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9