December 2015 - ghc-tickets

[GHC] #9237: GHC not recognizing "-llibrary" form in implicit linker scripts
by GHC 31 Dec '15

31 Dec '15

#9237: GHC not recognizing "-llibrary" form in implicit linker scripts ----------------------------------+--------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I have tried to build accelerate-llvm package and encountered an invalid behaviour of linker. I am using Arch Linux and GHC 7.8.2. I have installed llvm-general-3.4.2.2 and llvm-general-pure-3.4.2.2 from this branch: https://github.com/tvh/llvm- general/tree/curatedTargetMachine, and accelerate from HEAD to common sandbox. Then I tried to build accelerate-llvm using the sandbox and got this output during building: {{{ Building accelerate-llvm-0.15.0.0... Preprocessing library accelerate-llvm-0.15.0.0... [ 1 of 30] Compiling Data.Range.Range ( Data/Range/Range.hs, dist/build/Data/Range/Range.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package primitive-0.5.3.0 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package vector-0.10.11.0 ... linking ... done. Loading package mwc-random-0.13.1.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package transformers-0.4.1.0 ... linking ... done. Loading package mtl-2.2.1 ... linking ... done. Loading package text-1.1.1.3 ... linking ... done. Loading package parsec-3.1.5 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package setenv-0.1.1.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package llvm-general-pure-3.4.2.2 ... linking ... done. Loading package utf8-string-0.3.8 ... linking ... done. Loading package llvm-general-3.4.2.2 ... <command line>: can't load .so/.DLL for: /usr/lib/libcurses.so (-lncursesw: cannot open shared object file: No such file or directory) }}} After some searching I narrowed down the issue to `/usr/lib/libcurses.so` file. In Arch, this file contains `INPUT(-lncursesw)`. If I change it to `INPUT(libncursesw.so)` or `INPUT(/usr/lib/libncursesw.so)` it works fine. Symlinking `/usr/lib/libcurses.so` to `/usr/lib/libncursesw.so` also works. This bug seems to be connected to #2615. GHC still doesn't follow `INPUT` commands containing `-llibrary` form. Ld documentation allows this: {{{If you use `INPUT (-lfile)', ld will transform the name to libfile.a, as with the command line argument `-l'}}}. (https://sourceware.org/binutils/docs/ld/File-Commands.html) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9237> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS
by GHC 31 Dec '15

31 Dec '15

#9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS ----------------------------+--------------------------------------------- Reporter: jzellner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+--------------------------------------------- Hey there, I'm having trouble building vimus (https://github.com/vimus/vimus) on NixOS. The package builds fine locally for an x64 system, but is failing on i686 builds. On the NixOS builder: http://hydra.nixos.org/build/17512103/nixlog/2 {{{ [nix-shell:/tmp/build-17512103/vimus-0.2.0]$ ./Setup clean && ./Setup configure --enable-shared --enable-library-vanilla --enable-executable- dynamic --enable-tests --ghc- option=-optl=-Wl,-rpath=/nix/store/cgkfxxk1iz30fg0r3kf9dv2p550i5hn2-vimus-0.2.0/lib/ghc-7.8.3/vimus-0.2.0 --ghc-option=-j8 && ./Setup build cleaning... Configuring vimus-0.2.0... Building vimus-0.2.0... Preprocessing library vimus-0.2.0... [ 1 of 39] Compiling Constant ( dist/build/Constant.hs, dist/build/Constant.o ) [ 2 of 39] Compiling CursesUtil ( ncursesw/src/CursesUtil.hs, dist/build/CursesUtil.o ) [ 3 of 39] Compiling Timer ( src/Timer.hs, dist/build/Timer.o ) [ 4 of 39] Compiling UI.Curses.Type ( dist/build/UI/Curses/Type.hs, dist/build/UI/Curses/Type.o ) [ 5 of 39] Compiling Misc ( dist/build/Misc.hs, dist/build/Misc.o ) ncursesw/src/Misc.chs:7:1: Warning: The import of ‘Foreign.C.String’ is redundant except perhaps to import instances from ‘Foreign.C.String’ To import instances alone, use: import Foreign.C.String() ncursesw/src/Misc.chs:8:1: Warning: The import of ‘Foreign.Marshal.Alloc’ is redundant except perhaps to import instances from ‘Foreign.Marshal.Alloc’ To import instances alone, use: import Foreign.Marshal.Alloc() ncursesw/src/Misc.chs:9:1: Warning: The import of ‘Foreign.Storable’ is redundant except perhaps to import instances from ‘Foreign.Storable’ To import instances alone, use: import Foreign.Storable() ncursesw/src/Misc.chs:10:1: Warning: The import of ‘Foreign.ForeignPtr’ is redundant except perhaps to import instances from ‘Foreign.ForeignPtr’ To import instances alone, use: import Foreign.ForeignPtr() ncursesw/src/Misc.chs:12:1: Warning: The import of ‘Data.Char’ is redundant except perhaps to import instances from ‘Data.Char’ To import instances alone, use: import Data.Char() ncursesw/src/Misc.chs:29:1: Warning: Top-level binding with no type signature: cFromBool :: Bool -> Integer ncursesw/src/Misc.chs:29:13: Warning: Defaulting the following constraint(s) to type ‘Integer’ (Num a0) arising from a use of ‘fromBool’ In the expression: fromBool In an equation for ‘cFromBool’: cFromBool = fromBool ncursesw/src/Misc.chs:30:1: Warning: Top-level binding with no type signature: cToBool :: Integer -> Bool ncursesw/src/Misc.chs:30:13: Warning: Defaulting the following constraint(s) to type ‘Integer’ (Num a0) arising from a use of ‘toBool’ at ncursesw/src/Misc.chs:30:13-18 (Eq a0) arising from a use of ‘toBool’ at ncursesw/src/Misc.chs:30:13-18 In the expression: toBool In an equation for ‘cToBool’: cToBool = toBool ncursesw/src/Misc.chs:42:1: Warning: Top-level binding with no type signature: fromAttr :: Attr -> CInt ncursesw/src/Misc.chs:77:1: Warning: Top-level binding with no type signature: wcolor_set :: Window -> Int -> IO Status ncursesw/src/Misc.chs:86:1: Warning: Top-level binding with no type signature: wattr_off :: Window -> [Attribute] -> IO Status ncursesw/src/Misc.chs:90:1: Warning: Top-level binding with no type signature: wattr_on :: Window -> [Attribute] -> IO Status ncursesw/src/Misc.chs:98:1: Warning: Top-level binding with no type signature: wchgat :: Window -> Int -> [Attribute] -> Int -> IO Status ncursesw/src/Misc.chs:103:1: Warning: Top-level binding with no type signature: mvwchgat :: Window -> Int -> Int -> Int -> [Attribute] -> Int -> IO Status [ 6 of 39] Compiling CursesInput ( dist/build/CursesInput.hs, dist/build/CursesInput.o ) [ 7 of 39] Compiling Instances ( src/Instances.hs, dist/build/Instances.o ) [ 8 of 39] Compiling Data.List.Pointed ( src/Data/List/Pointed.hs, dist/build/Data/List/Pointed.o ) [ 9 of 39] Compiling Data.List.Zipper ( src/Data/List/Zipper.hs, dist/build/Data/List/Zipper.o ) [10 of 39] Compiling UI.Curses.Key ( dist/build/UI/Curses/Key.hs, dist/build/UI/Curses/Key.o ) [11 of 39] Compiling Vimus.Tab ( src/Vimus/Tab.hs, dist/build/Vimus/Tab.o ) [12 of 39] Compiling Vimus.Command.Parser ( src/Vimus/Command/Parser.hs, dist/build/Vimus/Command/Parser.o ) [13 of 39] Compiling Vimus.Key ( src/Vimus/Key.hs, dist/build/Vimus/Key.o ) [14 of 39] Compiling Paths_vimus ( dist/build/autogen/Paths_vimus.hs, dist/build/Paths_vimus.o ) [15 of 39] Compiling Vimus.Song ( src/Vimus/Song.hs, dist/build/Vimus/Song.o ) [16 of 39] Compiling Vimus.Song.Format ( src/Vimus/Song/Format.hs, dist/build/Vimus/Song/Format.o ) [17 of 39] Compiling Vimus.Queue ( src/Vimus/Queue.hs, dist/build/Vimus/Queue.o ) [18 of 39] Compiling Vimus.Util ( src/Vimus/Util.hs, dist/build/Vimus/Util.o ) [19 of 39] Compiling Option ( src/Option.hs, dist/build/Option.o ) [20 of 39] Compiling PlaybackState ( src/PlaybackState.hs, dist/build/PlaybackState.o ) [21 of 39] Compiling Curses ( dist/build/Curses.hs, dist/build/Curses.o ) ncursesw/src/Curses.chs:73:1: Warning: The import of ‘Foreign.C.String’ is redundant except perhaps to import instances from ‘Foreign.C.String’ To import instances alone, use: import Foreign.C.String() ncursesw/src/Curses.chs:76:1: Warning: The import of ‘chr’ from module ‘Data.Char’ is redundant ncursesw/src/Curses.chs:150:1: Warning: Defined but not used: ‘wnoutrefresh’ ncursesw/src/Curses.chs:151:1: Warning: Defined but not used: ‘doupdate’ ncursesw/src/Curses.chs:152:1: Warning: Defined but not used: ‘redrawwin’ ncursesw/src/Curses.chs:153:1: Warning: Defined but not used: ‘wredrawln’ ncursesw/src/Curses.chs:160:1: Warning: Defined but not used: ‘getparyx’ ncursesw/src/Curses.chs:207:1: Warning: Defined but not used: ‘cFromBool’ ncursesw/src/Curses.chs:207:1: Warning: Top-level binding with no type signature: cFromBool :: Bool -> Integer ncursesw/src/Curses.chs:207:13: Warning: Defaulting the following constraint(s) to type ‘Integer’ (Num a0) arising from a use of ‘fromBool’ In the expression: fromBool In an equation for ‘cFromBool’: cFromBool = fromBool ncursesw/src/Curses.chs:374:1: Warning: Defined but not used: ‘wnoutrefresh'_’ ncursesw/src/Curses.chs:377:1: Warning: Defined but not used: ‘doupdate'_’ ncursesw/src/Curses.chs:380:1: Warning: Defined but not used: ‘redrawwin'_’ ncursesw/src/Curses.chs:383:1: Warning: Defined but not used: ‘wredrawln'_’ ncursesw/src/Curses.chs:389:1: Warning: Defined but not used: ‘getparyx'_’ [22 of 39] Compiling UI.Curses ( ncursesw/src/UI/Curses.hs, dist/build/UI/Curses.o ) [23 of 39] Compiling Vimus.WindowLayout ( src/Vimus/WindowLayout.hs, dist/build/Vimus/WindowLayout.o ) [24 of 39] Compiling Vimus.Widget.Type ( src/Vimus/Widget/Type.hs, dist/build/Vimus/Widget/Type.o ) [25 of 39] Compiling Content ( src/Content.hs, dist/build/Content.o ) [26 of 39] Compiling Vimus.Input ( src/Vimus/Input.hs, dist/build/Vimus/Input.o ) [27 of 39] Compiling Vimus.Macro ( src/Vimus/Macro.hs, dist/build/Vimus/Macro.o ) [28 of 39] Compiling Vimus.Render ( src/Vimus/Render.hs, dist/build/Vimus/Render.o ) [29 of 39] Compiling Vimus.Ruler ( src/Vimus/Ruler.hs, dist/build/Vimus/Ruler.o ) [30 of 39] Compiling Vimus.Type ( src/Vimus/Type.hs, dist/build/Vimus/Type.o ) [31 of 39] Compiling Vimus.Command.Type ( src/Vimus/Command/Type.hs, dist/build/Vimus/Command/Type.o ) [32 of 39] Compiling Vimus.Command.Help ( src/Vimus/Command/Help.hs, dist/build/Vimus/Command/Help.o ) [33 of 39] Compiling Vimus.Command.Completion ( src/Vimus/Command/Completion.hs, dist/build/Vimus/Command/Completion.o ) [34 of 39] Compiling Vimus.Command.Core ( src/Vimus/Command/Core.hs, dist/build/Vimus/Command/Core.o ) [35 of 39] Compiling Vimus.Widget.ListWidget ( src/Vimus/Widget/ListWidget.hs, dist/build/Vimus/Widget/ListWidget.o ) [36 of 39] Compiling Vimus.Widget.TextWidget ( src/Vimus/Widget/TextWidget.hs, dist/build/Vimus/Widget/TextWidget.o ) [37 of 39] Compiling Vimus.Widget.HelpWidget ( src/Vimus/Widget/HelpWidget.hs, dist/build/Vimus/Widget/HelpWidget.o ) [38 of 39] Compiling Vimus.Command ( src/Vimus/Command.hs, dist/build/Vimus/Command.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package text-1.2.0.0 ... linking ... done. Loading package hashable-1.2.2.0 ... linking ... done. Loading package scientific-0.3.3.2 ... linking ... done. Loading package attoparsec-0.12.1.2 ... linking ... done. Loading package setlocale-1.0.0.1 ... linking ... done. Loading package utf8-string-0.3.8 ... linking ... done. Loading package wcwidth-0.0.2 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package directory-1.2.1.0 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package data-default-class-0.0.1 ... linking ... done. Loading package data-default-instances-base-0.0.1 ... linking ... done. Loading package data-default-instances-containers-0.0.1 ... linking ... done. Loading package dlist-0.7.1 ... linking ... done. Loading package data-default-instances-dlist-0.0.1 ... linking ... done. Loading package data-default-instances-old-locale-0.0.1 ... linking ... done. Loading package data-default-0.5.3 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package network-2.6.0.2 ... linking ... done. Loading package libmpd-0.9.0.1 ... linking ... done. <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for i386-unknown-linux): Loading temp shared object failed: /tmp/ghc6364_1/ghc6364_192.so: undefined symbol: nm_getyx Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [nix-shell:/tmp/build-17512103/vimus-0.2.0]$ nixos-version 14.11pre52840.c347f1c (Caterpillar) [nix-shell:/tmp/build-17512103/vimus-0.2.0]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 [nix-shell:/tmp/build-17512103/vimus-0.2.0]$ uname -a Linux ip-10-83-15-102.us-west-2.compute.internal 3.12.30 #1-NixOS SMP Thu Jan 1 00:00:01 UTC 1970 x86_64 GNU/Linux }}} Thanks for any help! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9825> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10761: GHC panic when compiling vimus: failed to map segment from shared object
by GHC 31 Dec '15

31 Dec '15

#10761: GHC panic when compiling vimus: failed to map segment from shared object -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When trying to build https://github.com/vimus/vimus I get a GHC panic on a specific module: {{{ λ cabal build Building vimus-0.2.1... Preprocessing library vimus-0.2.1... [38 of 39] Compiling Vimus.Command ( src/Vimus/Command.hs, dist/build/Vimus/Command.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc17990_0/libghc_39.so: failed to map segment from shared object Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I don't know why it's only this particular module of this particular library that fails. I'm running a kernel with GrSecurity and PaX enabled, and am using a hardened GCC toolchain (although Gentoo seems to automatically disable PIE for Haskell packages). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10761> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

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

30 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 30 Dec '15

30 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 30 Dec '15

30 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