September 2015 - ghc-tickets

[GHC] #9238: Negative zero broken
by GHC 03 Oct '15

03 Oct '15

#9238: Negative zero broken --------------------------+------------------------------------------------ Reporter: | Owner: augustss | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: | Operating System: Windows Compiler | Type of failure: Incorrect result at runtime Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Try the following program {{{ compareDouble :: Double -> Double -> Ordering compareDouble x y = case (isNaN x, isNaN y) of (True, True) -> EQ (True, False) -> LT (False, True) -> GT (False, False) -> -- Make -0 less than 0 case (x == 0, y == 0, isNegativeZero x, isNegativeZero y) of (True, True, True, False) -> LT (True, True, False, True) -> GT _ -> x `compare` y main = do let l = [-0, 0] print [ (x, y, compareDouble x y) | x <- l, y <- l ] }}} Compile and run with -O0 {{{ $ ghc -O0 D.hs [1 of 1] Compiling Main ( D.hs, D.o ) Linking D.exe ... $ ./D [(-0.0,-0.0,EQ),(-0.0,0.0,LT),(0.0,-0.0,GT),(0.0,0.0,EQ)] }}} This is the correct output. Compile and run with -O1 {{{ $ ghc -O1 D.hs [1 of 1] Compiling Main ( D.hs, D.o ) Linking D.exe ... $ ./D [(-0.0,-0.0,LT),(-0.0,0.0,LT),(0.0,-0.0,EQ),(0.0,0.0,EQ)] }}} This is wrong. Put a NOINLINE pragma on compareDouble: {{{ $ ghc -O1 D.hs [1 of 1] Compiling Main ( D.hs, D.o ) Linking D.exe ... $ ./D [(-0.0,-0.0,EQ),(-0.0,0.0,EQ),(0.0,-0.0,EQ),(0.0,0.0,EQ)] }}} This is wrong in a different way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9238> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10904: C finalizer may be called on re-used memory
by GHC 03 Oct '15

03 Oct '15

#10904: C finalizer may be called on re-used memory -------------------------------------+------------------------------------- Reporter: bherzog | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.4.1 System | Keywords: | Operating System: Linux Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- It seems that the runtime system sometimes reuses memory referred to by `ForeignPtr` values before the associated C finalizers have been run. At that's what it looks like to me. Maybe I'm interpreting the behavior of GHC's runtime system incorrectly, or it's a defect in my test program. To reproduce the defect, compile `finalizertest.hs` and `finalizerlib.c`, e.g. with {{{ ghc finalizertest.hs finalizerlib.c -threaded }}} Run the resulting program as {{{ ./finalizertest +RTS -N2 }}} After a while it prints a message like {{{ finalize_value: 80f69dc != 11223344 after 47393 calls Aborted }}} The C code prints this if the pointer passed to the finalizer does not point to the expected value. It's not necessary to link with the threaded runtime, nor is it necessary to run with more than one CPU. Doing so increases the likelihood of the defect to occur substantially, though. I've observed this with several different combinations of GHC and host- systems: * GHC 7.10.2 on a 64 bit Linux (Debian jessie) * GHC 7.10.1 on a 32 bit Linux (Debian wheezy) * GHC 7.4.1 on a 32 bit Linux (Debian wheezy) This GHC is the one packaged by Debian It's crucial for the defect that the memory is allocated with `mallocForeignPtrBytes`. Using `mallocBytes` instead and building a `ForeignPtr` with `finalizerFree` avoids the defect. I came across this defect while trying to debug a segmentation fault in the `zlib` package. This defect was reported on the libraries mailing list https://mail.haskell.org/pipermail/libraries/2015-June/025829.html (corresponding Agda ticket: https://github.com/agda/agda/issues/1518) I came across it in one of my own projects last week. My test program basically does what `zlib` does when allocating and initializing the `z_stream` value: it allocates memory with `mallocForeignPtrBytes` and later adds a finalizer with `addForeignPtrFinalizer`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10904> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10745: Error in fusion when compiling Data.Yaml
by GHC 02 Oct '15

02 Oct '15

#10745: Error in fusion when compiling Data.Yaml -----------------------------------------+--------------------------------- Reporter: nclarke | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- {{{ [2 of 7] Compiling Data.Yaml.Internal ( Data/Yaml/Internal.hs, dist/dist- sandbox-b22ce51e/build/Data/Yaml/Internal.o ) Data/Yaml/Internal.hs:28:1: Warning: The import of ‘Control.Applicative’ is redundant except perhaps to import instances from ‘Control.Applicative’ To import instances alone, use: import Control.Applicative() ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Tick in rule unstream @ a34_ayco @ Void @ m_aycm @ b_aycn (ConduitWithStream @ a34_ayco @ Void @ m_aycm @ b_aycn (let { $dApplicative_aycu :: Applicative (ConduitM a34_ayco Void m_aycm) [LclId, Str=DmdType] $dApplicative_aycu = $fApplicativeConduitM @ a34_ayco @ Void @ m_aycm ($fFunctorConduitM @ a34_ayco @ Void @ m_aycm) } in letrec { loop_aycv :: b_aycn -> ConduitM a34_ayco Void m_aycm b_aycn [LclId, Arity=1, Str=DmdType] loop_aycv = \ (accum_aycw :: b_aycn) -> $fMonadConduitM_$c>>= @ a34_ayco @ Void @ m_aycm $dApplicative_aycu @ (Maybe a34_ayco) @ b_aycn ((await @ a34_ayco @ m_aycm $dMonad1_aycq) @ Void) (maybe @ (ConduitM a34_ayco Void m_aycm b_aycn) @ a34_ayco ($fMonadConduitM_$creturn @ a34_ayco @ Void @ m_aycm $dApplicative_aycu @ b_aycn accum_aycw) (\ (a35_aycx :: a34_ayco) -> $fMonadConduitM_$c>>= @ a34_ayco @ Void @ m_aycm $dApplicative_aycu @ b_aycn @ b_aycn ($ @ (m_aycm b_aycn) @ (ConduitM a34_ayco Void m_aycm b_aycn) ($fMonadBasebaseConduitM_$clift @ a34_ayco @ Void @ m_aycm @ b_aycn $dMonad1_aycq) (f_aycs accum_aycw a35_aycx)) (\ (accum'_aycy :: b_aycn) -> case accum'_aycy of wild_aycz { __DEFAULT -> loop_aycv wild_aycz }))); } in loop_aycv b1_ayct) (foldMS @ b_aycn @ a34_ayco @ m_aycm $dMonad1_aycq f_aycs b1_ayct @ Void)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10745> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages
by GHC 02 Oct '15

02 Oct '15

#10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I've seen three different issues on Github about this: two in the stack repo for stack users, and one in the yesod repo for a cabal sandbox user: https://github.com/yesodweb/yesod/issues/1020 https://github.com/commercialhaskell/stack/issues/466 https://github.com/commercialhaskell/stack/issues/795 The problem comes down to this: Windows has a limit of 32k on the size of a command string, which can be tripped by GHC's link phase when using a large number of libraries. The ideal situation would be for GHC to have a different way of passing large argument lists to the linker; I don't know how feasible this is, but I wanted to open up a ticket before I started investigating myself in case others have seen this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10777> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10475: detabify User's Guide
by GHC 02 Oct '15

02 Oct '15

#10475: detabify User's Guide -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: task | Status: new Priority: low | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The User's Guide .xml files use a fairly random-looking mix of tabs and spaces for indentation. Let's get rid of the tabs and then enforce their absence with git hooks. Why do this? See #10425; apparently tabs within programlisting elements are rendered as some number of spaces other than 8 in the PDF version (only!) I briefly tried to find other instances of the same issue, but there are thousands of tab characters in the User's Guide and I'm too lazy to try to find only the ones within programlisting elements. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10475> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10215: Optimizer has bugs regarding handling of -0.0
by GHC 02 Oct '15

02 Oct '15

#10215: Optimizer has bugs regarding handling of -0.0 -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #9238 Differential Revisions: | -------------------------------------+------------------------------------- This is most likely related to https://ghc.haskell.org/trac/ghc/ticket/9238 Perhaps it can be merged into that if it is indeed the case, though it'd be good for an expert to take a look and make sure first that the culprit is indeed the same. In any case, the program in this ticket can at least serve as a test-case. I observed this on 7.8.3; though I suspect the same holds in the just released 7.10.1 as well. For the following program: {{{#!hs testF :: Float -> Bool testF x = x == 0 && not (isNegativeZero x) testD :: Double -> Bool testD x = x == 0 && not (isNegativeZero x) main :: IO () main = do print $ testF (-0.0) print $ testD (-0.0) }}} If I compile with no optimizations, then I get the correct answers: {{{ $ /bin/rm -f a.hi a.o a; ghc -O0 a; ./a [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... False False }}} But if I turn optimizations on, then I get: {{{ $ /bin/rm -f a.hi a.o a; ghc -O2 a; ./a [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... True True }}} which is just plain wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10215> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10392: typo in Debug.Trace.traceShowM example
by GHC 02 Oct '15

02 Oct '15

#10392: typo in Debug.Trace.traceShowM example -------------------------------------+------------------------------------- Reporter: sebastian | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- s/traceMShow/traceShowM The documentation for Debug.Trace.traceShowM has an example, where the function is called traceMShow instead of the correct traceShowM. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10392> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files
by GHC 30 Sep '15

30 Sep '15

#1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature request | Status: new Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 6.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D194 -------------------------------------+------------------------------------- Comment (by thomie): Sounds good to me. See also the other tests in `testsuite/tests/ghci/linking/Makefile`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1407#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files
by GHC 30 Sep '15

30 Sep '15

#1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature request | Status: new Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 6.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D194 -------------------------------------+------------------------------------- Comment (by archblob): I talked with @thomie on #ghc right after the ticked was opened again and the second problem was just a mistake and there is no problem with the patch, but there is indeed a problem with the test. I have looked into it then but I did not find a solution that was guaranteed not to break in the future(I looked for a library that was guaranteed to be present on both systems). What we could do instead is build one as part of the test and try to load that. If you think that is ok I'll go ahead and make a patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1407#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10878: Near doubling of generated code size for compiler/cmm/PprC.hs with commit 5d57087e31
by GHC 29 Sep '15

29 Sep '15

#10878: Near doubling of generated code size for compiler/cmm/PprC.hs with commit 5d57087e31 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- As noted in https://ghc.haskell.org/trac/ghc/ticket/7830#comment:28, changes to `compiler/utils/Pretty.hs` in commit 5d57087e31 results in a near doubling of the generated code size of compiler/cmm/PprC.hs` on x86_64/linux. On powerpc/linux this code growth caused this file to fail to build. At @rwbarton's suggestion, I added `NOINLINE` pragmas to `above_` and `beside_` of `compiler/utils/Pretty.hs` and that brought the generated code size down to be just a little more than 30% bigger than it was before commit 5d57087e31. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10878> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6