November 2014 - ghc-tickets

[GHC] #9844: Bang pattern doesn't work on a newtype constructor
by GHC 28 Nov '14

28 Nov '14

#9844: Bang pattern doesn't work on a newtype constructor -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- According to the documentation, {{{f0}}} and {{{f1}}} in the following program should have the identical semantics: {{{#!hs {-# LANGUAGE BangPatterns #-} module Main where newtype N = N Int f0 :: N -> Int f0 n = case n of !(N _) -> 0 _ -> 1 f1 :: N -> Int f1 n = n `seq` case n of N _ -> 0 _ -> 1 main = do print $ f0 undefined print $ f1 undefined }}} However, ghc only compiles {{{f1}}} into a strict function: {{{ % ./bang-newtype 0 bang-newtype: Prelude.undefined }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9844> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5495: simple program fails with -shared on mac
by GHC 28 Nov '14

28 Nov '14

#5495: simple program fails with -shared on mac -------------------------------------+------------------------------------- Reporter: mwotton | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => new * os: MacOS X => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5495#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5266: Licensing requirements and copyright notices
by GHC 28 Nov '14

28 Nov '14

#5266: Licensing requirements and copyright notices -------------------------------------+------------------------------------- Reporter: houeland | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: Component: None | Keywords: copyright Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by bernalex): * cc: hvr, thoughtpolice (added) Comment: Austin, Herbert & I briefly expressed related concerns in another thread: https://www.haskell.org/pipermail/ghc-devs/2014-October/006959.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5266#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5443: Errors when shutting down the event manager loop
by GHC 28 Nov '14

28 Nov '14

#5443: Errors when shutting down the event manager loop -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: tibbe Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by basvandijk): > I can't tell at the moment whether this is still an issue or not. In my usb library it's not a problem anymore since I'm now using the system event manager. So closing this ticket is fine with me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5443#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault
by GHC 28 Nov '14

28 Nov '14

#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I am getting segfaults when a statically linked executable uses a GHC API. When the same executable is however dynamically linked it runs without error. In case of the statically-linked version, I think that one of GHC API functions that tries to do dynamic-linking is causing the segfault. The reason why I think this, is because the segfault shows up when Template-Haskell is used, or when {{{ {-# ANN ... #-} }}} annotations are used. An example of this strange behaviour can be shown using haddock, and running it on the source-code for the lens library [1]: {{{ ~/Documents/devel/lens/src (master *)$ haddock -v3 Control/Lens/Internal/ByteString.hs Creating interfaces... Haddock coverage: Checking module Control.Lens.Internal.Setter... Creating interface... 100% ( 3 / 3) in 'Control.Lens.Internal.Setter' <MORE LOG MESSAGE> Checking module Control.Lens.Reified... Creating interface... 100% ( 20 / 20) in 'Control.Lens.Reified' Checking module Control.Lens.Setter... Bus error: 10 <-- SEGFAULT }}} And the GDB output: {{{ (gdb) run -v3 Control/Lens/Internal/ByteString.hs Starting program: /Users/christiaan/.ghc- config/cabal/7.7.20130924/bin/haddock -v3 Control/Lens/Internal/ByteString.hs Reading symbols for shared libraries +++.............................. done Creating interfaces... Haddock coverage: Checking module Control.Lens.Internal.Setter... Creating interface... 100% ( 3 / 3) in 'Control.Lens.Internal.Setter' <MORE LOG MESSAGES> Checking module Control.Lens.Reified... Creating interface... 100% ( 20 / 20) in 'Control.Lens.Reified' Checking module Control.Lens.Setter... Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x000000010828b982 0x000000010828b982 in ?? () }}} I should note that until now I've been unable to produce a _small_ test case that shows the above behaviour. The statically linked haddock actually runs successfully on many packages. The lens[1] package is the first widely used library that I've been able to get haddock to exhibit the above behaviour. Also, when I built a dynamically-linked version of haddock, it runs succesfully for the above test-case (and the other test-cases where the statically-linked version would give a segfault). The source-code for lens[1] contains many {{{ {-# ANN ... #-} }}} annotations; removing all those annotations make the statically-linked version of haddock run successfully, with out segfaults. Halfway through removing the {{{ {-# ANN ... #-} }}} annotation, I also encountered the following error: {{{ Checking module Control.Lens.Fold... haddock: internal error: ARR_WORDS object entered! (GHC version 7.7.20130924 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 }}} I've also encountered the segfault while running the statically-linked haddock on my own clash library [2]. In this case I think it might have something to do with the use of template-haskell. Again, running the dynamically-linked version of haddock does not show any problems. Here is some extra information about my development environment:[[BR]] OS: OS X 10.8.5[[BR]] X-Code: XCode CL-Tools 4.6.2[[BR]] GHC: GHC-HEAD (commit 94ab5d2984514f92dd919fbf3611a07d32105546)[[BR]] Output of {{{make show VALUE=GhcLibWays}}}: v dyn[[BR]] build.mk: {{{ SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O2 -fasm GhcHcOpts = -Rghc-timing GhcLibHcOpts = -O2 HADDOCK_DOCS = NO }}} I create statically-linked binaries by setting {{{executable-dynamic}}} in {{{.cabal/config}}} to {{{False}}}[[BR]] I create dynamically-linked binaries by setting {{{executable-dynamic}}} in {{{.cabal/config}}} to {{{True}}}[[BR]] I created the {{{haddock}}} executables by running {{{cabal install}}} in {{{"up-to-date build tree of GHC"/utils/haddock}}} [1] https://github.com/ekmett/lens[[BR]] [2] http://hackage.haskell.org/package/clash-lib -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8376> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

Re: [GHC] #5495: simple program fails with -shared on mac
by GHC 28 Nov '14

28 Nov '14

#5495: simple program fails with -shared on mac -------------------------------------+------------------------------------- Reporter: mwotton | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): I'm not sure whether this is a bug at all. You need `-dynamic` also, to produce object files that can be linked dynamically. Granted, the way that `-shared` and `-dynamic` interact with make mode is, at best, not obvious. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5495#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5495: simple program fails with -shared on mac
by GHC 27 Nov '14

27 Nov '14

#5495: simple program fails with -shared on mac -------------------------------------+------------------------------------- Reporter: mwotton | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): I think so ... {{{ > cat "main=putStrLn \"hi\"" > ghc --make foo.hs -shared -fforce-recomp [1 of 1] Compiling Main ( foo.hs, foo.o ) Linking foo ... ld: illegal text reloc in '_c1Hl_info' to '_stg_ap_2_upd_info' for architecture x86_64 collect2: error: ld returned 1 exit status }}} a linker error seems to happen, though when GHC is configured to use clang, clang reports the error, whereas when using via GCC, its reported as a ld error -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5495#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9843: Add flag to infer undefined for variables with only types
by GHC 27 Nov '14

27 Nov '14

#9843: Add flag to infer undefined for variables with only types -------------------------------------+------------------------------------- Reporter: tempay | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It would be convenient to be able to write only type declarations for some or all variables and have the compiler assume that the definitions of those variables are 'undefined'. For example: {{{#!hs functionOne :: x -> y functionTwo :: y -> z functionThree :: x -> y functionThree = functionOne . functionTwo }}} would be equivalent to {{{#!hs functionOne :: x -> y functionOne = undefined functionTwo :: y -> z functionTwo = undefined functionThree :: x -> y functionThree = functionOne . functionTwo }}} I feel this would make type-driven development significantly more convenient/clean. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9843> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5388: ghcilink003 and ghcilink006 fail on OSX
by GHC 27 Nov '14

27 Nov '14

#5388: ghcilink003 and ghcilink006 fail on OSX -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.0.4 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: #9389 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: 7.10.1 => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5388#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5266: Licensing requirements and copyright notices
by GHC 27 Nov '14

27 Nov '14

#5266: Licensing requirements and copyright notices -------------------------------------+------------------------------------- Reporter: houeland | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: Component: None | Keywords: copyright Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: bernalex (added) * difficulty: => Unknown Comment: See also this mail from bernalex: https://www.haskell.org/pipermail/ghc- devs/2014-September/006235.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5266#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0