- ghc-tickets - Haskell.org

Re: [GHC] #4268: Warning for ANN pragmas when GHCi is not supported
by GHC 08 Nov '13

08 Nov '13

#4268: Warning for ANN pragmas when GHCi is not supported -------------------------------+------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Comment (by nomeata): According to #8312, Annotations will require a `-X` flag in the future, and in a non-GHCi-compiler, we still get an error (not a warning), requiring distributions to patch annotations out of the code. In light of #8312, do you still think that it should be a warning, and not an error? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4268#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4268: Warning for ANN pragmas when GHCi is not supported (was: Annotation extension needs a flag)
by GHC 08 Nov '13

08 Nov '13

#4268: Warning for ANN pragmas when GHCi is not supported -------------------------------+------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Changes (by simonmar): * priority: normal => high * milestone: 7.6.2 => 7.8.1 Comment: We don't want a flag for the ANN pragma, because pragmas don't normally have flags to enable them, they are unconditionally enabled. However, ANN might not be supported if GHC is built without GHCi support (say on a platform that doesn't have GHCi support), so in those cases we want to emit a warning. Therefore this ticket is now for adding a warning when an ANN pragma is being ignored. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4268#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8508: Inlining Unsaturated Function Applications
by GHC 07 Nov '13

07 Nov '13

#8508: Inlining Unsaturated Function Applications ------------------------------+-------------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime performance bug (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- After trying a simple test, I noticed some strange performance results from stylistic changes to the code. For example, {{{#!haskell import qualified Data.Vector.Unboxed as U {-# INLINE f #-} f :: U.Vector Int -> U.Vector Int -> U.Vector Int f = U.zipWith (+) -- version 1 --f x = U.zipWith (+) x -- version 2 --f x = (U.zipWith (+) x) . id -- version 3 --f x y = U.zipWith (+) x y -- version 4 main = do let iters = 100 dim = 221184 y = U.replicate dim 0 :: U.Vector Int let ans = iterate (f y) y !! iters putStr $ (show $ U.foldl1' (+) ans) }}} Versions 1 and 2 of `f` run in 1.6 seconds, while versions 3 and 4 run in 0.09 seconds (with vector-0.10.9.1 and GHC 7.6.2, compiling with -O2). According to an answer on the Vector trac (link below), this problem is because GHC only inlines on saturated function applications. Is there any way to expand the cases when GHC inlines to avoid having coding style affect performance? * [https://github.com/haskell/vector/issues/4 Vector Trac] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8508> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7200: template-haskell-2.7.0.0 fails to build with GHC 7.0.4 due to missing pragma
by GHC 07 Nov '13

07 Nov '13

#7200: template-haskell-2.7.0.0 fails to build with GHC 7.0.4 due to missing pragma -------------------------------------+------------------------------------ Reporter: tibbe | Owner: duncan Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Template Haskell | Version: 7.0.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * cc: hvr (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7200#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8506: misleading error message for duplicate type class instances
by GHC 07 Nov '13

07 Nov '13

#8506: misleading error message for duplicate type class instances -------------------------------------------+------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- In the following code I accidentally declared a type class more than once, and the error message had absolutely nothing to do with that! {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TemplateHaskell #-} module Numerical.Types.Nat(Nat(..),nat) where import Data.Typeable import Data.Data import Language.Haskell.TH hiding (reify) data Nat = S !Nat | Z deriving (Eq,Show,Read,Typeable,Data) nat :: Int -> TypeQ nat n | n >= 0 = localNat n | otherwise = error "nat: negative" where localNat 0 = conT 'Z localNat n = conT 'S `appT` localNat (n-1) ---------------------- ---------------------- {-# LANGUAGE PolyKinds #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE CPP #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoImplicitPrelude #-} module Numerical.Types.Shape where import Numerical.Types.Nat import Data.Data type N0 = Z type N1= S N0 type N2 = S N1 type N3 = S N2 type N4 = S N3 type N5 = S N4 type N6 = S N5 type N7 = S N6 type N8 = S N7 type N9 = S N8 type N10 = S N9 class Shapable (n :: Nat) where -- zero rank is boring but lets include it for completeness class Shapable Z where class Shapable One where {- I get the following error src/Numerical/Types/Shape.hs:97:17: Unexpected type `Z' where type variable expected In the declaration of `Shape Z' -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8506> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8286: fdToHandle docs are wrong about non-blocking mode
by GHC 07 Nov '13

07 Nov '13

#8286: fdToHandle docs are wrong about non-blocking mode ------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | 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: | ------------------------------------+------------------------------------- The docs for System.Posix.IO.fdToHandle state: {{{ fdToHandle :: Fd -> IO HandleSource Converts an Fd into a Handle that can be used with the standard Haskell IO library (see System.IO). GHC only: this function has the side effect of putting the Fd into non-blocking mode (O_NONBLOCK) due to the way the standard IO library implements multithreaded I/O. }}} The final paragraph is wrong. The code no longer does this. System.Posix.IO.fdToHandle ends up calling GHC.IO.Handle.FD.fdToHandle which has this comment: {{{ fdToHandle :: Posix.FD -> IO Handle fdToHandle fdint = do iomode <- Posix.fdGetMode fdint (fd,fd_type) <- FD.mkFD fdint iomode Nothing False{-is_socket-} -- NB. the is_socket flag is False, meaning that: -- on Windows we're guessing this is not a socket (XXX) False{-is_nonblock-} -- file descriptors that we get from external sources are -- not put into non-blocking mode, because that would affect -- other users of the file descriptor }}} So clearly, it is now deliberately not putting it into non-blocking mode. This can trip people up who expect that it does put it into non-blocking mode, when in fact they now have to do that manually. Fix is trivial: delete that paragraph from the docs for that function. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8286> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7359: unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1)
by GHC 07 Nov '13

07 Nov '13

#7359: unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1) -----------------------------------+---------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.6.3 Component: libraries/unix | Version: 7.4.1 Resolution: fixed | Keywords: unix package Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed Comment: This one is fixed by the workaround in [88bfec0cf55f8c9ad74881d48cf8756c9fe627aa/unix]; if there's still demand, I can also backport this and upload an `unix-2.6.0.2` package... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7359#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7912: Missing symbols from termios.h when linking on Android
by GHC 07 Nov '13

07 Nov '13

#7912: Missing symbols from termios.h when linking on Android ----------------------------------------+--------------------------- Reporter: neurocyte | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/unix | Version: 7.7 Resolution: fixed | Keywords: Android Operating System: Other | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7912#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7912: Missing symbols from termios.h when linking on Android
by GHC 07 Nov '13

07 Nov '13

#7912: Missing symbols from termios.h when linking on Android ----------------------------------------+--------------------------- Reporter: neurocyte | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.7 Resolution: | Keywords: Android Operating System: Other | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"7ca70fbf7b82bcca945669d043673a06973c1edf/unix"]: {{{ #!CommitTicketReference repository="unix" revision="7ca70fbf7b82bcca945669d043673a06973c1edf" Fix #7912 by using `CApiFFI` for `<termios.h>` imports On Android, the functions imported from `<termios.h>` are actually inlined functions, so we need to wrap them via the `capi` calling convention. Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7912#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7912: Missing symbols from termios.h when linking on Android
by GHC 07 Nov '13

07 Nov '13

#7912: Missing symbols from termios.h when linking on Android ----------------------------------------+--------------------------- Reporter: neurocyte | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.7 Resolution: | Keywords: Android Operating System: Other | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Changes (by hvr): * difficulty: => Unknown Comment: would the new `capi` calling convention help here? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7912#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0