March 2015 - ghc-tickets

Re: [GHC] #17: Separate warnings for unused local and top-level bindings
by GHC 03 Mar '15

03 Mar '15

#17: Separate warnings for unused local and top-level bindings -------------------------------------+------------------------------------- Reporter: magunter | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: None Resolution: fixed | Keywords: -fwarn- Operating System: Unknown/Multiple | unused-binds newcomer Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #3283 | Test Case: | Blocking: | Differential Revisions: Phab:D591 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: None => fixed Comment: Merged, thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/17#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6079: SEH exception handler not implemented on Win64
by GHC 03 Mar '15

03 Mar '15

#6079: SEH exception handler not implemented on Win64 -------------------------------------+------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: derefnull, Related Tickets: | divbyzero | Blocking: | Differential Revisions: Phab:D691 -------------------------------------+------------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"5200bdeb26c5ec98739b14b10fc8907296bceeb9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5200bdeb26c5ec98739b14b10fc8907296bceeb9" Replaced SEH handles with VEH handlers which should work uniformly across x86 and x64 Summary: On Windows, the default action for things like division by zero and segfaults is to pop up a Dr. Watson error reporting dialog if the exception is unhandled by the user code. This is a pain when we are SSHed into a Windows machine, or when we want to debug a problem with gdb (gdb will get a first and second chance to handle the exception, but if it doesn't the pop-up will show). veh_excn provides two macros, `BEGIN_CATCH` and `END_CATCH`, which will catch such exceptions in the entire process and die by printing a message and calling `stg_exit(1)`. Previously this code was handled using SEH (Structured Exception Handlers) however each compiler and platform have different ways of dealing with SEH. `MSVC` compilers have the keywords `__try`, `__catch` and `__except` to have the compiler generate the appropriate SEH handler code for you. `MinGW` compilers have no such keywords and require you to manually set the SEH Handlers, however because SEH is implemented differently in x86 and x64 the methods to use them in GCC differs. `x86`: SEH is based on the stack, the SEH handlers are available at `FS[0]`. On startup one would only need to add a new handler there. This has a number of issues such as hard to share handlers and it can be exploited. `x64`: In order to fix the issues with the way SEH worked in x86, on x64 SEH handlers are statically compiled and added to the .pdata section by the compiler. Instead of being thread global they can now be Image global since you have to specify the `RVA` of the region of code that the handlers govern. You can on x64 Dynamically allocate SEH handlers, but it seems that (based on experimentation and it's very under-documented) that the dynamic calls cannot override static SEH handlers in the .pdata section. Because of this and because GHC no longer needs to support < windows XP, the better alternative for handling errors would be using the in XP introduced VEH. The bonus is because VEH (Vectored Exception Handler) are a runtime construct the API is the same for both x86 and x64 (note that the Context object does contain CPU specific structures) and the calls are the same cross compilers. Which means this file can be simplified quite a bit. Using VEH also means we don't have to worry about the dynamic code generated by GHCi. Test Plan: Prior to this diff the tests for `derefnull` and `divbyzero` seem to have been disabled for windows. To reproduce the issue on x64: 1) open ghci 2) import GHC.Base 3) run: 1 `divInt` 0 which should lead to ghci crashing an a watson error box displaying. After applying the patch, run: make TEST="derefnull divbyzero" on both x64 and x86 builds of ghc to verify fix. Reviewers: simonmar, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D691 GHC Trac Issues: #6079 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6079#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10104: Show '#' on unboxed literals
by GHC 03 Mar '15

03 Mar '15

#10104: Show '#' on unboxed literals -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature | Status: new request | Milestone: 7.12.1 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: #8274 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently, unboxed literals are shown in the same way as boxed literals (without #): {{{ Prelude> :set -XMagicHash Prelude> :m GHC.Prim Prelude GHC.Prim> data T = MkT Int# deriving Show Prelude GHC.Prim> MkT 3# MkT 3 }}} It would be nice if this would show `MkT 3#` instead. I have a patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10104> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10003: integer-gmp2 tries to be GMP 4.x compatible but uses functions from GMP 5.x
by GHC 03 Mar '15

03 Mar '15

#10003: integer-gmp2 tries to be GMP 4.x compatible but uses functions from GMP 5.x -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.11 (other) | Operating System: Solaris Keywords: | Type of failure: Building GHC Architecture: sparc | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hello, recent HEAD is using integer-gmp2 wrapper around GMP library. This tries to be compatible with and use only functionality of GMP 4.x, but still it also uses some functions from GMP 5.x which makes this incompatible with GMP 4.x. The issue is for example shown on Solaris/SPARC platform where the OS provided library is GMP 4.3.2 and linking of stage2 binaries fails with: {{{ Undefined first referenced symbol in file __gmpn_andn_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries /integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) __gmpn_and_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries /integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) __gmpn_ior_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries /integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) __gmpn_xor_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries /integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) ld: fatal: symbol referencing errors. No output written to ghc/stage2/build/tmp/ghc-stage2 }}} the unresolve symbols are from GMP 5.x. GMP 4.x does not provide them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10003> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #2986: :info printing instances often isn't wanted
by GHC 03 Mar '15

03 Mar '15

#2986: :info printing instances often isn't wanted -------------------------------------+------------------------------------- Reporter: Remi | Owner: Remi Type: feature request | Status: new Priority: lowest | Milestone: 7.12.1 Component: GHCi | Version: 6.10.1 Resolution: | Keywords: :info Operating System: Unknown/Multiple | instances Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #1581 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #1581 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2986#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs
by GHC 03 Mar '15

03 Mar '15

#2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Compiler (NCG) | Milestone: 7.12.1 Resolution: | Version: 6.11 Operating System: Unknown/Multiple | Keywords: codegen Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2725#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs
by GHC 03 Mar '15

03 Mar '15

#2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Compiler (NCG) | Milestone: 7.12.1 Resolution: | Version: 6.11 Operating System: Unknown/Multiple | Keywords: codegen Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): I have just (2015/03/03) written a shell script (attached) that tests for binutils support for 64 bit pc-relative relocatons. The test passes on *all* modern linux systems, but fails on Mac OSX (Mavericks) and OpenBSD 5.5 (current is 5.6). The failure is one OpenBSD says: {{{ linkasm.s:3: Error: can not do 8 byte pc-relative relocation }}} OpenBSD has GNU binutils 2.15 but they are unlikely to upgrade to a later version because later versions are under GPLv3 instead of GPLv2. However, they may at some stage switch to some other linker. OSX has the linker from LLVM which theoretically could be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2725#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10129: emitCmmLitSwitch could be better
by GHC 03 Mar '15

03 Mar '15

#10129: emitCmmLitSwitch could be better -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is a spin off #10124. While looking at the code generated for {{{ f :: Int -> Bool f a = case a of 1 -> True 2 -> True 3 -> True 4 -> True 8 -> True 9 -> True 11 -> True 19 -> True _ -> False }}} I noticed this Cmm: {{{ c2tI: if (%MO_S_Lt_W64(_s2sJ::I64, 3)) goto c2tw; else goto c2tx; c2tw: if (%MO_S_Lt_W64(_s2sJ::I64, 2)) goto c2tq; else goto c2tr; c2tq: if (_s2sJ::I64 != 1) goto c2tg; else goto c2th; c2tr: if (_s2sJ::I64 != 2) goto c2tg; else goto c2th; }}} Note that when `c2tr` is reached, we know 2 ≤ _s2sJ < 3, so _s2sJ already is 2, and this check is redundant. `emitCmmLitSwitch` does not take that into account, probably because it also needs to work for floats. I wonder if it isn’t a bit shady to use an if-then-else tree for floats. Maybe for float types, a sequence of equality tests is more suitable. For all other cases, the code generator could make use of "2 ≤ x < 3 ⇒ x = 2" and skip one check. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10129> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[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] #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