October 2015 - ghc-tickets

Re: [GHC] #365: GHC dies silently with faulty preprocessor
by GHC 03 Oct '15

03 Oct '15

#365: GHC dies silently with faulty preprocessor ---------------------------------+---------------------------------------- Reporter: josefs | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T365 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1256 ---------------------------------+---------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/365#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #365: GHC dies silently with faulty preprocessor
by GHC 03 Oct '15

03 Oct '15

#365: GHC dies silently with faulty preprocessor ---------------------------------+---------------------------------------- Reporter: josefs | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T365 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1256 ---------------------------------+---------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"b6f76b9aaca49df0fb06d8bad2f7edc5b5b8c095/ghc" b6f76b9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b6f76b9aaca49df0fb06d8bad2f7edc5b5b8c095" Prevent GHC from silently dying when preprocessor is not found The Windows preprocessor code calls `runInteractiveProcess` but does not check if an exception is thrown. `runInteractiveProcess` calls `CreateProcess` which when given a format the system loader does not know about will throw an exception. This is what makes #9399 fail. Ultimately we should not use any `CreateProcess` based calls but instead `ShellExecuteEx` as this would allow us to run applications that the shell knows about instead of just the loader. More details on #365. This patch removes `PhaseFailed` and throws `ProgramError` instead. `PhaseFailed` was largely unneeded since it never gave very useful information aside from the `errorcode` which was almost always `1`. `IOErrors` have also been eliminated and `GhcExceptions` thrown in their place wherever possible. Updates haddock submodule. Test Plan: `./validate` to make sure anything didn't break and `make TESTS="T365"` to test that an error is now properly thrown Reviewers: austin, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1256 GHC Trac Issues: #365 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/365#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10342: Convert User Guide from DocBook to AsciiDoc
by GHC 03 Oct '15

03 Oct '15

#10342: Convert User Guide from DocBook to AsciiDoc -------------------------------------+------------------------------------- Reporter: dmbergey | Owner: dmbergey Type: task | Status: new Priority: normal | 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: | -------------------------------------+------------------------------------- See initial proposal and discussion on the mailing list: https://mail.haskell.org/pipermail/ghc-devs/2014-October/006599.html and the more recent call for volunteers: https://ghc.haskell.org/trac/ghc/blog/weekly20150414 Quoting the latter: the idea [is] that it will A) make life easier for people who frequently modify the users guide, and B) make life easier for people who add things irregularly, as a lower barrier to entry. I expect that asciidoc & DocBook can coexist while I work on this. After the initial changes to the build system, the docbook-to-HTML phase should read both the asciidoc-generated XML and the not-yet-converted XML files. This ticket will track progress on the task, as I plan to submit multiple patches, perhaps as many as one per file converted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10342> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #4370: Bring back monad comprehensions
by GHC 03 Oct '15

03 Oct '15

#4370: Bring back monad comprehensions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by Slavon8): * Attachment "d40bd6a41276ebb3795cb50422975481.jpg" added. [http://kidkraftaccessories.tumblr.com/ was] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4370> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10810: Data constructor operators mis-printed in Template Haskell
by GHC 03 Oct '15

03 Oct '15

#10810: Data constructor operators mis-printed in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template | Version: 7.10.2 Haskell | Keywords: newcomer | 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 TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices -dsuppress-uniques #-} module Bug where $([d| data Foo = (:!) |]) }}} I get {{{ Bug.hs:6:3-24: Splicing declarations [d| data Foo = :! |] ======> data Foo = :! }}} There are missing parentheses in that output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10810> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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

Re: [GHC] #7830: Error: operand out of range
by GHC 02 Oct '15

02 Oct '15

#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: closed Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by erikd): * milestone: 8.0.1 => 7.10.3 Comment: Building git HEAD (with @trommler's patch applied) using ghc-7.10.2 still fails because the stage-0 compiler (ghc-7.10.2) doesn't have this patch. However, building git HEAD with ghc-7.8.4 works fine. Therefore requesting a back port of this patch to the 7.10 branch. Unfortunately @trommler's patch doesn't apply to the 7.10 branch so I'll get something working and attach it here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10926: wrong signature of atomic builtins
by GHC 02 Oct '15

02 Oct '15

#10926: wrong signature of atomic builtins --------------------------------+---------------------------------------- Reporter: schwab | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: aarch64 | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | --------------------------------+---------------------------------------- {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -optc-fno-builtin -this-package-key ghcpr_8TmvWUcS1U1IKHT0levwg3 -hide- all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist- install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries /ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist- install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package-key rts -this-package-key ghc-prim -XHaskell2010 -O -no-user- package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim /dist-install/build -dynamic-too -c libraries/ghc-prim/dist- install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist- install/build/GHC/PrimopWrappers.o -dyno libraries/ghc-prim/dist- install/build/GHC/PrimopWrappers.dyn_o /tmp/ghc1492_0/ghc_1.hc: In function 'ghczmprim_GHCziPrimopWrappers_fetchXorIntArrayzh_entry': /tmp/ghc1492_0/ghc_1.hc:2844:25: warning: passing argument 1 of 'hs_atomic_xor64' makes pointer from integer without a cast [-Wint-conversion] _c1Ho = hs_atomic_xor64((*Sp) + (((Sp[1]) << 0x3UL) + 0x10UL), Sp[2]); ^ In file included from /home/abuild/rpmbuild/BUILD/ghc-7.10.2/includes/Stg.h:273:0: 0, from /tmp/ghc1492_0/ghc_1.hc:3: /home/abuild/rpmbuild/BUILD/ghc-7.10.2/includes/stg/Prim.h:41:11: note: expected 'volatile StgWord64 * {aka volatile long unsigned int *}' but argument is of type 'long unsigned int' StgWord64 hs_atomic_xor64(volatile StgWord64 *x, StgWord64 val); ^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10926> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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