- ghc-tickets - Haskell.org

[GHC] #10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales
by GHC 31 Dec '15

31 Dec '15

#10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales -------------------------------------+------------------------------------- Reporter: hgolden | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime | Version: 7.8.4 System | Operating System: Unknown/Multiple Keywords: linker | Type of failure: Incorrect result script | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: 2615, 9237 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Please see ticket:2615#comment:40 and replies. This error only occurs on systems where linker scripts are used. The linker script patch (as it has evolved) assumes that the error messages it will receive are in English. This would be true if the locale (LC_MESSAGES) is C or en (or one of the en variants). However, in other locales, the message will be in a different language. Unfortunately, the semantics of POSIX dlerror() specify that the error is returned as a pointer to a human-readable text string, rather than an error code. The string returned depends on the locale. The code could be made more robust by momentarily changing the locale (LC_MESSAGES) to C before calling dlerror() and reverting it to its previous value immediately after. This has been tested on a zh_CN.utf-8 (see ticket:2615#comment:42) and works. The only concern I have is in the case of multithreaded code that _might_ be affected if it is running while the locale is changed. I don't know enough to know if this is a real issue or not, nor do I know how to deal with it if necessary. Also see ticket:9237 for another corner case in the linker script code that should be dealt with at the same time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10046> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #2496: Invalid Eq/Ord instances in Data.Version
by GHC 31 Dec '15

31 Dec '15

#2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 6.8.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): Phab:D395 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): https://prime.haskell.org/wiki/Libraries/Proposals contains the current set of actively worked on proposals. It currently focuses on things that affect Prelude at the moment, but we can broaden the mandate of the page to cover more API changes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2496#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11309: Warn on shady data constructor export
by GHC 31 Dec '15

31 Dec '15

#11309: Warn on shady data constructor export -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If a module defines a datatype and exports some, but not all, of the constructors, then modules importing the type will find it difficult to perform sensible and total case analyses. This is most likely to be a problem when a module that names exported constructors adds a new constructor. Could we get a warning for this, please? Note: this applies also to data family instances. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11309> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD
by GHC 30 Dec '15

30 Dec '15

#11239: GHC HEAD: cannot bootstrap HEAD with HEAD -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The first invocation of a freshly built `inplace/bin/deriveConstants` hangs when I am bootstrapping HEAD with HEAD. Last proven good git revision: d25f3c076e6c47bc7c8d0d27e724a3ad2b7d7399 Broken revision: 0dd61fe72144a829a9e5bb87a1094244e53cdebb There are only a few revisions in between. Notably: {{{ commit 8a506104d5b5b71d5640afc69c992e0af40f2213 Author: George Karachalias <george.karachalias(a)gmail.com> Date: Thu Dec 3 12:57:19 2015 +0100 Major Overhaul of Pattern Match Checking (Fixes #595) ... }}} Incidentally there are a few known performance regressions from that commit, so maybe the bootstrap process is bitten by it. I am not sure whether `deriveConstants` really hangs or just takes ages to complete. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11239> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #11310: Surprising accepted constructor for GADT instance of data family
by GHC 30 Dec '15

30 Dec '15

#11310: Surprising accepted constructor for GADT instance of data family -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs -- Accepted: data family Foo (x :: *) :: * -> * data instance Foo Int Char where Foo :: Foo Int Char -- Not accepted data Bar Char where Bar :: Bar Char }}} It seems the second example, using a simple GADT, is syntactically barred from having a specific type constructor in its "head". That syntactic restriction is relaxed, however, for ''all'' arguments of the data instance, even though I'd expect it only for the first argument. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11310> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5945: Lambda lifting
by GHC 30 Dec '15

30 Dec '15

#5945: Lambda lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11284 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #11284 Comment: This looks very similar to #11284. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5945#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7289: Mingw FPU init not Windows compatible.
by GHC 30 Dec '15

30 Dec '15

#7289: Mingw FPU init not Windows compatible. -----------------------------------+-------------------------------- Reporter: Lennart | Owner: Type: bug | Status: upstream Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------- Changes (by bgamari): * status: new => upstream * milestone: 8.0.1 => 8.2.1 Old description: > Mingw initializes the FPU top 80 bit precision instead of MSVC's 53 bits > (which is the standard). I suggest ghc linking on Windows should be > changed to that it uses 53 bits instead. This will make programs more > Windows compatible (and possibly faster). > > Here's a comment from Mingw's Float.h: > > /* > MSVCRT.dll _fpreset initializes the control register to 0x27f, > the status register to zero and the tag word to 0FFFFh. > This differs from asm instruction finit/fninit which set control > word to 0x37f (64 bit mantissa precison rather than 53 bit). > By default, the mingw version of _fpreset sets fp control as > per fninit. To use the MSVCRT.dll _fpreset, include CRT_fp8.o when > building your application. > */ New description: Mingw initializes the FPU top 80 bit precision instead of MSVC's 53 bits (which is the standard). I suggest ghc linking on Windows should be changed to that it uses 53 bits instead. This will make programs more Windows compatible (and possibly faster). Here's a comment from Mingw's Float.h: {{{#!c /* MSVCRT.dll _fpreset initializes the control register to 0x27f, the status register to zero and the tag word to 0FFFFh. This differs from asm instruction finit/fninit which set control word to 0x37f (64 bit mantissa precison rather than 53 bit). By default, the mingw version of _fpreset sets fp control as per fninit. To use the MSVCRT.dll _fpreset, include CRT_fp8.o when building your application. */ }}} -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7289#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7289: Mingw FPU init not Windows compatible.
by GHC 30 Dec '15

30 Dec '15

#7289: Mingw FPU init not Windows compatible. -----------------------------------+----------------------------- Reporter: Lennart | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+----------------------------- Comment (by Phyx-): Yeah it is, and it's also unlikely to be changed as they say it's wanted behavior http://article.gmane.org/gmane.comp.gnu.mingw.w64.general/10686. Even though it introduces some very odd/unexpected behavior https://github.com/numpy/numpy/issues/5194. It seems an easy solution/workaround is to indeed link in `CRT_fp8.o` or `CRT_fp10.o` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7289#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5834: Allow both INLINE and INLINABLE for the same function
by GHC 30 Dec '15

30 Dec '15

#5834: Allow both INLINE and INLINABLE for the same function -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Sometimes you really want both. Here is a small example: > > {{{ > module T where > > foo :: Num a => a -> a -> a > foo x y = x+y+1 > }}} > > {{{ > module U where > > import T > > appl :: (a -> b) -> a -> b > {-# NOINLINE appl #-} > appl f x = f x > > bar :: Int -> Int -> Int > bar x y = appl foo x y > }}} > > If I mark `foo` as `INLINE`, then GHC generates this code for `bar`: > > {{{ > bar1 :: Int -> Int -> Int > bar1 = foo @ Int $fNumInt > > bar :: Int -> Int -> Int > bar = \ (x_aa0 :: Int) (y_aa1 :: Int) -> appl @ Int @ (Int -> Int) bar1 > x_aa0 y_aa1 > }}} > > Whereas with `INLINABLE`, we get a nice specialisation but, of course, > not guarantees with respect to inlining. > > In general, it seems that requiring a function to inline when it is > saturated and requiring it two specialise when it isn't are two different > things and shouldn't be mutually exclusive. New description: Sometimes you really want both. Here is a small example: {{{#!hs module T where foo :: Num a => a -> a -> a foo x y = x+y+1 }}} {{{#!hs module U where import T appl :: (a -> b) -> a -> b {-# NOINLINE appl #-} appl f x = f x bar :: Int -> Int -> Int bar x y = appl foo x y }}} If I mark `foo` as `INLINE`, then GHC generates this code for `bar`: {{{#!hs bar1 :: Int -> Int -> Int bar1 = foo @ Int $fNumInt bar :: Int -> Int -> Int bar = \ (x_aa0 :: Int) (y_aa1 :: Int) -> appl @ Int @ (Int -> Int) bar1 x_aa0 y_aa1 }}} Whereas with `INLINABLE`, we get a nice specialisation but, of course, not guarantees with respect to inlining. In general, it seems that requiring a function to inline when it is saturated and requiring it to specialise when it isn't are two different things and shouldn't be mutually exclusive. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5834#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7367: float-out causes extra allocation
by GHC 30 Dec '15

30 Dec '15

#7367: float-out causes extra allocation -------------------------------------+------------------------------------- Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => Research needed Comment: As has been discussed in this ticket, GHC could in principle do better in optimizing imperative code such as this. However, exactly how this should be done is a topic that would require research. Setting the milestone appropriately. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7367#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0