August 2015 - ghc-tickets

[GHC] #10034: Regression in mapM_ performance
by GHC 16 Dec '15

16 Dec '15

#10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.10.1-rc2 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D632 | -------------------------------------+------------------------------------- The current `mapM_` is sometimes worse than the version in 7.8.3. This can be fixed easily by eta-expansion, matching `mapM`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9276: audit ghc floating point support for IEEE (non)compliance
by GHC 16 Dec '15

16 Dec '15

#9276: audit ghc floating point support for IEEE (non)compliance ------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: high | Milestone: 7.10.1 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: | ------------------------------------+------------------------------------- As best I can determine, ghc has never been closely audited for conformance to IEEE-754 (floating point) standard and currently is a bit far from providing a compliant implementation. This impacts both a number of other tasks i wish to do for ghc **and** much of my own use of haskell is in a floating point heavy workloads, I will do a bit of leg work to: a) improve test suite support for checking for compliance b) write some patches to provide portable compliant primops for the operations which need compiler support c) try to determine how to allow ghc optimizer to be a bit more aggressive in a sound way in the presence of floating point. (this may grow into a few subtickets, we'll see) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9304: Floating point woes; Different behavior on Mac vs Linux
by GHC 16 Dec '15

16 Dec '15

#9304: Floating point woes; Different behavior on Mac vs Linux ------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Keywords: floating point | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've the following snippet: {{{ x, y, r :: Double x = -4.4 y = 2.4999999999999956 r = x * y }}} Using GHC 7.8.3, on a Mac, I get the following response from ghci: {{{ *Main> decodeFloat r (-6192449487634421,-49) }}} Using GHC 7.8.3, on a Linux machine, I get the following response: {{{ *Main> decodeFloat r (-6192449487634422,-49) }}} Note that off-by-one difference in the first component of the output. I'm not 100% sure as to which one is actually correct; but the point is that these are IEEE floating point numbers running on the same architecture (Intel X86), and thus should decode in precisely the same way. While I observed this with 7.8.3; I don't think this is a new regression; I suspect it'll show up in older versions as well. Also, for full disclosure: I ran the Mac version naively; but the Linux version on top of a VirtualBox image. I'd very much doubt that would make a difference, but there might be 32/64-bit concerns. So, if someone can validate the Linux output on a true 64-bit Linux machine, that would really help track down the issue further. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 32

[GHC] #9306: Crash when shifting Integers too much
by GHC 16 Dec '15

16 Dec '15

#9306: Crash when shifting Integers too much ------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When shifting an Integer by `fromIntegral (maxBound::Int) + 2` or more, the RTS crashes. The attached program gives the following output (on x86_64, at least): [dfeuer@lemur src]$ ./shiftcrash Okay 0 gmp: overflow in mpz type Aborted I found the bug in 7.6.3, but it's been verified to be present also in 7.8.3. The crash also occurs when running similar code in GHCi. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9306> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8347: Add a Strict LANGUAGE pragma
by GHC 16 Dec '15

16 Dec '15

#8347: Add a Strict LANGUAGE pragma ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | 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: | ------------------------------------+------------------------------------- A `Strict` `LANGUAGE` pragma would allow us to experiment with writing in a strict sub-language. Since this pragma works on a per module basis, it needs to be modular. I propose the following semantics: * Patterns are strict at the top-level, as if they had a top-level bang, unless an explicit ~ is used to make the pattern lazy. * Functions evaluate their parameters to WHNF. * Data type fields are strict (as if they had a bang-pattern). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8347> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10639: Optimization changes concurrent program's behaviour
by GHC 16 Dec '15

16 Dec '15

#10639: Optimization changes concurrent program's behaviour -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Here is a program that spawns a thread from the main thread, which tries to constantly write out a message to the console. {{{#!hs module Main where import Control.Concurrent (forkIO) main :: IO () main = do _ <- forkIO $ runForever $ putStrLn "Hey" runForever $ return () runForever :: IO () -> IO () runForever action = action >> runForever action }}} If you compile it with 'ghc main', it works correctly - it prints out the message continuously, and you can terminate it by pressing Ctrl-C. However, if you compile it with 'ghc -O main' (or -O2, or -O3...), it doesn't print out anything, and the only way to exit is to kill the process from Task Manager. This was reproducable with GHC 7.10.1, on a Windows 7 x64 machine, with an AMD A4-5300 APU. ''(Disclaimer: this is my first bugreport, and I'm not sure what else can I do to investigate this issue.)'' -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10639> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8424: quasi-quotes have carriage returns on Windows
by GHC 16 Dec '15

16 Dec '15

#8424: quasi-quotes have carriage returns on Windows ------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: | ------------------------------------+------------------------------------- A Windows user rerported using Data.Text.IO.writeFile to write out quasi- quoted text. writeFile automatically translates '\r' to "\r\n", so the user ended up writing out "\r\r\n" to a file. Haskell seems to be adopting the policy or removing '\r' from Haskell land. Is there any reason why quasi-quotes should not automatically strip carriage returns? I asked this question on ghc-users and there was no response. I am willing to make this fix if it is deemed appropriate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8424> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9348: "Symbol not found" when using a shared library
by GHC 15 Dec '15

15 Dec '15

#9348: "Symbol not found" when using a shared library -----------------------------------+----------------------------------- Reporter: alex.davis | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+----------------------------------- I'm trying to make a shared library from a simple program. It works fine on my Windows box, but gives an error on Mac OS X. Furthermore, the error seems to be generated from one of GHC's shared libraries. What happens is this. I compile my shared library with GHC, which works fine. But when I try to use it from another program (specifically, R), I get an error message containing the following: Symbol not found: _stg_IND_STATIC_info Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib Expected in: flat namespace in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib More details: The program I'm trying to use is R. In R, you load a shared library with the command "dyn.load". When I try this, the command I use is "dyn.load('final.dylib')", and the full error message is what follows: --- Error in dyn.load("final.dylib") : unable to load shared object '/Users/alexanderdavis/Desktop/illustrate bug copy/final.dylib': dlopen(/Users/alexanderdavis/Desktop/illustrate bug copy/final.dylib, 6): Symbol not found: _stg_IND_STATIC_info Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib Expected in: flat namespace in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib --- As I said, I have done all of this with no trouble on Windows. I compiled into a DLL, loaded the program into R, and was able to use the functions in it. My Mac OS version is 10.9.4. My R version is 3.0.2. When loaded, it displays "Platform: x86_64-apple- darwin10.8.0 (64-bit)", but Sys.getev("R_ARCH") returns the empty string. Command used for compiler: ghc --make -dynamic -fPIC -shared SumRoots.hs StartEnd.c -o final.dylib The code is attached. It is from a blog post by Neil Mitchelll (author of HLint) about calling Haskell from R: http://neilmitchell.blogspot.com/2011/10/calling-haskell-from-r.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9348> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9378: Make unknown LANGUAGE pragmas a warning, not an error
by GHC 15 Dec '15

15 Dec '15

#9378: Make unknown LANGUAGE pragmas a warning, not an error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, if I say `{-# LANGUAGE Foo #-}` at the top of my file, it fails to compile. This failure seems unnecessary, especially because any new language feature `Foo` enables will fail to compile later on down the file. Is it possible to have a "stern warning" that is produced even when other parts of the file produce errors? The reason I'm bringing this up is that, when 7.8 came out with its role annotations, users needed CPP in two different places: both to protect the `RoleAnnotations` pragma and to protect the role annotations themselves. This may be unavoidable on the role annotations directly, but I think we can improve the situation around `LANGUAGE` pragmas. Is there a downside to this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9378> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10368: Armhf/Linux : test T7815 failing
by GHC 15 Dec '15

15 Dec '15

#10368: Armhf/Linux : test T7815 failing -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Incorrect result Test Case: | at runtime Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- During validation on armhf/linux, I found this test had failed. Unfortunately, it only fails intermittently on one quad core Arm board and not at all on another quad core Arm board. If I do 10 runs of the test like: {{{ for x in $(seq 1 10) ; do testsuite/tests/rts/T7815 50000 +RTS -N2 ; echo $? ; done }}} one will fail at least 4 or 5 times and ocassionally as many as 9 or 10 times. The two boards are: * Inforce Computing ifc6540 with a Qualcomm Snapdragon 805 CPU. * Radxa Rock with a Rockchip RK3199 CPU. The ifc6540 is the one that fails. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10368> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7