From ghc-devs at haskell.org Sat Mar 1 00:16:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Mar 2014 00:16:37 -0000 Subject: [GHC] #8741: `System.Directory.getPermissions` fails on read-only filesystem In-Reply-To: <042.41e003931db44554a93be772501d4d70@haskell.org> References: <042.41e003931db44554a93be772501d4d70@haskell.org> Message-ID: <057.2e5f2de98a254c150a044c3e1c3100d5@haskell.org> #8741: `System.Directory.getPermissions` fails on read-only filesystem -------------------------------------+------------------------------------- Reporter: hvr | Owner: AlainODea Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: libraries/unix | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by AlainODea): Quick curiousity: why is this merged to 7.8 instead of a bugfix on 7.6.3? This makes cabal unusable on SmartOS when the packages being installed need to do native builds since it crashes on getPermissions to /usr/bin/ld. Haskell Platform 2013.2.0.0 has GHC 7.6.3. I think this means I can't use Haskell Platform on SmartOS without manually patching the unix library which seems hackish. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 1 02:13:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Mar 2014 02:13:38 -0000 Subject: [GHC] #4102: Bit manipulation built-ins In-Reply-To: <049.9814fd052d90f7d2841adf98c6e4a213@haskell.org> References: <049.9814fd052d90f7d2841adf98c6e4a213@haskell.org> Message-ID: <064.6e811589ea3cee2ba50563353e4ab191@haskell.org> #4102: Bit manipulation built-ins -------------------------------------+------------------------------------ Reporter: uzytkownik | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 6.12.2 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 erikd): * cc: mle+hs@? (added) * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 1 07:15:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Mar 2014 07:15:30 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.ac7d291835ec04fee39b4cb430df6bac@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Marlow ): In [changeset:"3fba87599378afbcf425a0fc2a5a61d21e3719d4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3fba87599378afbcf425a0fc2a5a61d21e3719d4" add missing files (#8124) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 1 07:20:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Mar 2014 07:20:40 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.1d483652bdffff63be42ac652014dc57@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): Sorry about this. It should be fixed now: 3fba87599378afbcf425a0fc2a5a61d21e3719d4/ghc and 176205cf0b89f76d904d381bdcd61e8685116bb7/ghc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 1 09:30:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Mar 2014 09:30:26 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.12ddba92c95b2000a6f2fe683a6cd9e4@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Thanks, travis is green again for master. This still needs to be merged into ghc-7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 1 10:42:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Mar 2014 10:42:39 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.1f9539b8e89e2d8e505722906be56085@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc1 Type of failure: None/Unknown | Keywords: Safe Test Case: | Architecture: should_fail/TcCoercibleFailSafe | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"44dec750a618a89202f80dcd695e5eb9fb74a74f/base"]: {{{ #!CommitTicketReference repository="base" revision="44dec750a618a89202f80dcd695e5eb9fb74a74f" Tweak documentation and update changelog.md This adds release note entries to changelog and tweaks Haddock comments with respect to the recent commits 1a9abe7a1a3c7 (re #8797) and f932b79948f0 (re #8745) Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 1 10:42:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Mar 2014 10:42:40 -0000 Subject: [GHC] #8797: Generics instances for monoid and applicative newtypes In-Reply-To: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> References: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> Message-ID: <064.faa6201a0ef216e171e1f8044e897cf0@haskell.org> #8797: Generics instances for monoid and applicative newtypes -------------------------------+------------------------------------------- Reporter: jcristovao | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: normal | Version: 7.8.1-rc1 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"44dec750a618a89202f80dcd695e5eb9fb74a74f/base"]: {{{ #!CommitTicketReference repository="base" revision="44dec750a618a89202f80dcd695e5eb9fb74a74f" Tweak documentation and update changelog.md This adds release note entries to changelog and tweaks Haddock comments with respect to the recent commits 1a9abe7a1a3c7 (re #8797) and f932b79948f0 (re #8745) Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 1 19:08:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Mar 2014 19:08:46 -0000 Subject: [GHC] #8678: Derivin `Functor` complains about existential type In-Reply-To: <048.aa0a7629fe983b0a09239bcee6c385f2@haskell.org> References: <048.aa0a7629fe983b0a09239bcee6c385f2@haskell.org> Message-ID: <063.cde0ddfe24fca15a9681af2718db6d67@haskell.org> #8678: Derivin `Functor` complains about existential type -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by heisenbug): Replying to [comment:3 monoidal]: > My guess is that the type of `Standard` is rewritten to `m ~ S n => a -> NonStandard m a` (which is existential in `n`). Simpler test case: `data A t a where A :: A Int a deriving Functor`. Yeah, this is Henry Ford polymorphism ("you can have your car in any color as long as it is black"). But still, `deriving Functor` should only concern itself with the last parameter, which is manifestly not existential. Also, the parameter referred to has kind `Nat`, and thus is irrelevant for endofunctors on `*`. Furthermore even your example establishes a //functional dependency// between `t ~ Int`, so it should not count as existential. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 1 19:11:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Mar 2014 19:11:18 -0000 Subject: [GHC] #8678: Deriving `Functor` complains about existential type (was: Derivin `Functor` complains about existential type) In-Reply-To: <048.aa0a7629fe983b0a09239bcee6c385f2@haskell.org> References: <048.aa0a7629fe983b0a09239bcee6c385f2@haskell.org> Message-ID: <063.f103b58d53dd89a202b537e541463859@haskell.org> #8678: Deriving `Functor` complains about existential type -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 1 22:01:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Mar 2014 22:01:03 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` Message-ID: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` ------------------------------+-------------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- While implementing `zeroBits` (see [83bd2f5fc7e/base]) I noticed that constant folding of the expression `clearBit (bit 0) 0` regressed (and improved at the same time) from GHC 7.6.3 to GHC 7.8.1, specifically, the following module {{{#!haskell {-# LANGUAGE CPP #-} module M where import Data.Bits import Data.Int import Data.Word #define T(s,T) \ s :: T ; \ s = clearBit (bit 0) 0 ; \ T(i,Int) T(i8,Int8) T(i16,Int16) T(i32,Int32) T(i64,Int64) T(w,Word) T(w8,Word8) T(w16,Word16) T(w32,Word32) T(w64,Word64) T(z,Integer) }}} compiled with GHC 7.8.1RC2 results in the following Core output: {{{#!haskell -- GHC 7.8.1RC2 i = I# (andI# 1 (notI# 1)) i8 = I8# 0 i16 = I16# 0 i32 = I32# 0 i64 = I64# 0 w = W# (__word 0) w8 = W8# (__word 0) w16 = W16# (__word 0) w32 = W32# (__word 0) w64 = W64# (__word 0) z2 = $w$cbit 0 z1 = complementInteger z2 z = andInteger z2 z1 }}} Thus, `i` and `z` are not properly constant-folded in GHC 7.8.1RC2. With GHC 7.6.3, however, `i` and `z` were properly folded to `0`: {{{#!haskell -- GHC 7.6.3 i = I# 0 i8 = case $fBitsInt8_$cbit i of _ { I8# x#_aDf -> case $fBitsInt8_$cbit i of _ { I8# x#1_aDr -> I8# (word2Int# (and# (int2Word# x#_aDf) (xor# (int2Word# x#1_aDr) (__word 18446744073709551615)))) } } i16,i32,i64 -- equivalent to i8 w = W# (__word 0) w8 = case $fBitsWord8_$cbit i of _ { W8# x#_aEV -> case $fBitsWord8_$cbit i of _ { W8# x#1_aF5 -> W8# (and# x#_aEV (xor# x#1_aF5 (__word 255))) } } w16,w32,w64 -- equivalent to w8 z = __integer 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 2 04:30:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Mar 2014 04:30:25 -0000 Subject: [GHC] #8833: GHC (compilation mode) crashes Message-ID: <044.2af677b3d4a2a13d2e8b023bf15580e4@haskell.org> #8833: GHC (compilation mode) crashes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Compile-time Difficulty: Moderate (less | crash than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{ module Main where { newtype Rec a b = Rec {deRec :: Rec a b -> a}; infixl 1 >|>; infixl 1 <|<; (>|>) = Rec; (<|<) (Rec x) = x; fix f = (\x -> f (x <|< x)) (Rec (\x -> f (x <|< x))); factorial = fix (\f x -> if x<=1 then 1 else x*f(x-1)); main = do { x <- getLine; putStrLn (show (factorial (read x))) } } }}} GHC crashes with this error: {{{ [1 of 1] Compiling Main ( /Users/iOne/Documents/Test.hs, /Users/iOne/Documents/Test.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone a_sMx{v} [lid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 7121 }}} (This works fine in GHCi). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 2 05:11:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Mar 2014 05:11:55 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.3deeb47eb5b3a07675e913945d1c06cd@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): hrmm, so in theory if we wanna clean up the cruft, we'd want to make it --with-cc rather than --with-gcc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 2 16:09:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Mar 2014 16:09:59 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC Message-ID: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+--------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: None | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- `cabal.exe` built with 64-bit windows GHC segfaults doing `cabal configure` or `cabal install` or probably something else. This occurs *both* for cabal-install 1.18.0.2 built against Cabal 1.18.1.2 and for cabal-install 1.18.0.3 built against Cabal 1.18.1.3. This occurs only for 64-bit build, 32-bit build is fine. 64-bit GHC-7.6.3 build is also fine. During debugging I see segfault occurs inside `evacuate` somewhere near `get_itbl` call I guess. If I make `cabal.exe` to not trigger some presumably bad GC compiling it with `-rtsopts` and running it as (for example) {{{cabal +RTS -H256m -m50 -RTS ...}}} the problem disappears. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 2 16:19:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Mar 2014 16:19:35 -0000 Subject: [GHC] #8835: 7.6.3 vs 7.8-RC performance regression Message-ID: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> #8835: 7.6.3 vs 7.8-RC performance regression ------------------------------+-------------------------------------------- Reporter: cbm80 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime performance bug (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- '''NOTE: code for this is on github [https://github.com/cbm80/Minimal]''' I have a program that uses xml-conduit to parse nzb files, a file format commonly found on Usenet. Running the program `./mini demo1.nzb +RTS -sstderr` compiled with GHC 7.6.3 yields: {{{ 37,827,736 bytes allocated in the heap 703,392 bytes copied during GC 172,040 bytes maximum residency (2 sample(s)) 35,024 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 71 colls, 0 par 0.00s 0.00s 0.0000s 0.0001s Gen 1 2 colls, 0 par 0.00s 0.00s 0.0003s 0.0005s TASKS: 3 (1 bound, 2 peak workers (2 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.00s ( 0.00s elapsed) MUT time 0.01s ( 0.01s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.02s ( 0.02s elapsed) Alloc rate 2,603,976,578 bytes per MUT second Productivity 84.1% of total user, 86.9% of total elapsed }}} The same program, same libraries but compiled with `GHC 7.8.0.20140228` gives: {{{ 11,217,541,448 bytes allocated in the heap 31,184,656 bytes copied during GC 6,540,288 bytes maximum residency (178 sample(s)) 597,248 bytes maximum slop 19 MB total memory in use (5 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 20623 colls, 0 par 0.50s 0.41s 0.0000s 0.0008s Gen 1 178 colls, 0 par 0.04s 0.05s 0.0003s 0.0009s''' TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.00s ( 0.00s elapsed) MUT time 3.41s ( 3.50s elapsed) GC time 0.55s ( 0.45s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 3.96s ( 3.96s elapsed) Alloc rate 3,293,236,224 bytes per MUT second Productivity 86.1% of total user, 86.1% of total elapsed }}} While total memory usage always stays around 2 to 3 mb when compiled with GHC 7.6.3, even if using bigger nzb files (try demo2.nzb), the 7.8-RC compiled program eats huge amounts of memory and becomes very slow. Using +RTS -S shows even more worrying GC differences. Unfortunately I can't tell whether the culprit is in one of the libraries or in the compiler. GHC 7.8-RC used was `ghc-7.8.0.20140228-x86_64-unknown-linux-deb7.tar.xz` from [http://www.haskell.org/ghc/dist/7.8.1-rc2] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 2 16:53:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Mar 2014 16:53:40 -0000 Subject: [GHC] #5273: error and undefined should print a location In-Reply-To: <047.0c5631d5110d7e8dd17fdeae86e25a82@haskell.org> References: <047.0c5631d5110d7e8dd17fdeae86e25a82@haskell.org> Message-ID: <062.15ab8f7bd30e5a10c935a7cecd5b214b@haskell.org> #5273: error and undefined should print a location -------------------------------------+------------------------------------ Reporter: augustss | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.1 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 MikolajKonarski): * difficulty: => Unknown Comment: While we are at it, adding source position information to Debug.trace & Co would be very useful too (how often did you write 'trace "1" ... trace "2"', etc.?). This is done (in a hacky way, by passing assert as an argument) in the package loch from 2007, together with hacks for 'error' and exceptions. BTW, some support for locations in exceptions, without the need to profile for stack traces, would be very valuable too. Perhaps something can be done cheaply? Even just one random location sometimes? This is all needed by people for years, because at least 3 packages contain relevant basic hacks (in addition to other stuff): http://hackage.haskell.org/package/loch http://hackage.haskell.org/package/assert-failure http://hackage.haskell.org/package/assert plus there are some more that use TH for that. *shudder* Thank you in advance! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 2 17:19:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Mar 2014 17:19:17 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.b3bbf0acab6bf6eea681457cc298b4fd@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ---------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: None | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Comment (by awson): Probably, it's worth to add that I observed this problem since I was able to build 64-bit windows GHC 7.7+ (a month or so). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 2 20:43:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Mar 2014 20:43:25 -0000 Subject: [GHC] #8836: ghc 7.6.3 (Linux) hangs on -O2 Message-ID: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> #8836: ghc 7.6.3 (Linux) hangs on -O2 ------------------------------+-------------------------------------------- Reporter: tsuraan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC doesn't work at all Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I haven't had any luck finding a minimal test case for this, but the following replicates the issue on my two Linux machines running ghc 7.6.3: git clone https://github.com/tsuraan/optimal-blocks cd optimal-blocks git checkout bceee69f9f03d2e559f96cdf58412ada09c96a8c cabal sandbox init cabal install --only-dependencies cabal configure cabal build Cabal build will successfully build Algorithm.OptimalBlocks.SipHash and Algorithm.OptimalBlocks.BuzzHash, and it will attempt to build Algorithm.OptimalBlocks, but it will hang forever, using 100% of a single core. I have no idea how to debug this, but in src/Algorithm/OptimalBlocks.hs, if you replace the "in Blocks (reverse rlist) end" with "in Blocks [] bs", it will compile. Also, if that same file starts with the line "{-# OPTIONS_GHC -O1 #-}" it will compile. This also happens on my Mac running OSX 10.8.5 and ghc 7.4.2 without llvm; I have to tweak the .cabal file a little to drop the lower bound on base and to get rid of the "-fllvm" flag, but if I do that I see the exact same behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 2 20:43:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Mar 2014 20:43:59 -0000 Subject: [GHC] #8836: ghc 7.6.3 and 7.4.2 hang on -O2 (was: ghc 7.6.3 (Linux) hangs on -O2) In-Reply-To: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> References: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> Message-ID: <061.eb92465887babb515f16ffa18a62e681@haskell.org> #8836: ghc 7.6.3 and 7.4.2 hang on -O2 --------------------------------------------+------------------------------ Reporter: tsuraan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 2 21:09:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Mar 2014 21:09:33 -0000 Subject: [GHC] #8836: ghc 7.6.3 and 7.4.2 hang on -O2 In-Reply-To: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> References: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> Message-ID: <061.540c5d44a943a01da59af6154b0f87fd@haskell.org> #8836: ghc 7.6.3 and 7.4.2 hang on -O2 --------------------------------------------+------------------------------ Reporter: tsuraan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by gelisam): I can reproduce the issue with 7.6.3 (removing the -fllvm flag), but not with 7.8.20140130 (also removing the upper bound on base). Must have been fixed already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 2 21:18:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Mar 2014 21:18:31 -0000 Subject: [GHC] #8836: ghc 7.6.3 and 7.4.2 hang on -O2 In-Reply-To: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> References: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> Message-ID: <061.6937c6f013562ff11b509fb23912a463@haskell.org> #8836: ghc 7.6.3 and 7.4.2 hang on -O2 --------------------------------------------+------------------------------ Reporter: tsuraan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by thoughtpolice): This looks similar to #7944 and #5550 - can you see where the compiler halts during compilation using `-v3` or something? In any case, if it's fixed by 7.8, all the better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 2 21:22:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Mar 2014 21:22:31 -0000 Subject: [GHC] #8836: ghc 7.6.3 and 7.4.2 hang on -O2 In-Reply-To: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> References: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> Message-ID: <061.48b1a8bd12cb99c6b0c13088191808c9@haskell.org> #8836: ghc 7.6.3 and 7.4.2 hang on -O2 --------------------------------------------+------------------------------ Reporter: tsuraan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by gelisam): You are right, it hangs at the same spot as #7944: {{{ ... *** SpecConstr: Result size of SpecConstr }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 2 21:27:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Mar 2014 21:27:59 -0000 Subject: [GHC] #8836: ghc 7.6.3 and 7.4.2 hang on -O2 In-Reply-To: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> References: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> Message-ID: <061.1d40f42c9f713d18ee7517894a46dd75@haskell.org> #8836: ghc 7.6.3 and 7.4.2 hang on -O2 --------------------------------------------+------------------------------ Reporter: tsuraan | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by thoughtpolice): * status: new => closed * resolution: => duplicate Comment: Right, then we know what's wrong. Unfortunately, there isn't really a good 'fix' that's possible to backport to fix `SpecConstr` for 7.6 users - in the mean time, you'll have to get by with `-O1` or (`-O2 -fno-spec- constr`, I suppose). Alternatively, you can also try tuning the constructor specialisation threshold as noted in #7944. There won't be a 7.6.4 release, and as this is fixed in HEAD, I'm marking this as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 2 21:38:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Mar 2014 21:38:17 -0000 Subject: [GHC] #8833: GHC (compilation mode) crashes In-Reply-To: <044.2af677b3d4a2a13d2e8b023bf15580e4@haskell.org> References: <044.2af677b3d4a2a13d2e8b023bf15580e4@haskell.org> Message-ID: <059.78f9953445a27739ffd19ad8adc8dc92@haskell.org> #8833: GHC (compilation mode) crashes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time | Difficulty: Moderate (less crash | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by goldfire): * version: 7.6.3 => 7.8.1-rc2 Comment: I've confirmed that this bug still happens with 7.8.1 RC 2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 03:47:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 03:47:00 -0000 Subject: [GHC] #8835: 7.6.3 vs 7.8-RC performance regression In-Reply-To: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> References: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> Message-ID: <059.873e958e0fff2157f0061b0cc75eff21@haskell.org> #8835: 7.6.3 vs 7.8-RC performance regression --------------------------------------------+------------------------------ Reporter: cbm80 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by carter): could you compile the program with 7.8 using -fno-full-laziness and give us the perf info then? (theres 1-2 example programs we've seen where adding -fno-full-laziness will resolve the change in performance characteristics) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 04:51:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 04:51:58 -0000 Subject: [GHC] #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib Message-ID: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib --------------------------------+------------------------------------------ Reporter: awick | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Installing GHC failed (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | --------------------------------+------------------------------------------ It looks like a homebrew (or something else?) dependency snuck into the RC2 build: {{{ % ./configure --prefix=/Users/awick/tools/ghc7.8.0 checking for path to top of build tree... dyld: Library not loaded: /usr/local/lib/libgmp.10.dylib Referenced from: /Users/awick/tools/ghc-7.8.0.20140228/utils/ghc-pwd /dist-install/build/tmp/ghc-pwd Reason: image not found configure: error: cannot determine current directory }}} As not all of us use homebrew, it'd be lovely if the binary installer only required base Mac libraries to be installed rather than homebrew/macports/whatever. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 05:08:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 05:08:25 -0000 Subject: [GHC] #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib In-Reply-To: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> References: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> Message-ID: <059.83191d7e3ae15c58bb34923e4888b20e@haskell.org> #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib ------------------------------------------+-------------------------------- Reporter: awick | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC failed | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by carter): who's RC2 mac build did you use? Mine or austins? Mine is unofficial and has that brew dep. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 05:10:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 05:10:27 -0000 Subject: [GHC] #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib In-Reply-To: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> References: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> Message-ID: <059.c8d387095ee3f4d3472b1f7a40808922@haskell.org> #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib ------------------------------------------+-------------------------------- Reporter: awick | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC failed | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by awick): I pulled the one from here: http://www.haskell.org/ghc/dist/7.8.1-rc2/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 05:21:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 05:21:56 -0000 Subject: [GHC] #8835: 7.6.3 vs 7.8-RC performance regression In-Reply-To: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> References: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> Message-ID: <059.7759d09389ebbf589d711690d4be49f4@haskell.org> #8835: 7.6.3 vs 7.8-RC performance regression --------------------------------------------+------------------------------ Reporter: cbm80 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by thoughtpolice): `-fno-full-laziness` makes exactly 0 difference on this program. I can see some of the differences in Core, but I haven't made out exactly what the problem is yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 08:17:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 08:17:14 -0000 Subject: [GHC] #8838: Allow running bash shell commands Message-ID: <048.45d5636007cfb5c906cb5fa0eb0bba59@haskell.org> #8838: Allow running bash shell commands --------------------------+------------------------------------------------ Reporter: | Owner: jstolarek | Status: new Type: | Milestone: 7.10.1 feature request | Version: 7.8.1-rc2 Priority: normal | Operating System: Linux Component: | Type of failure: Incorrect result at runtime libraries/process | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: #8802 | --------------------------+------------------------------------------------ Current implementation of `process` library has limited usability. `CreateProcess` record stores `CmdSpec` field, which is either a `RawCommand` or `ShellCommand`. The problem is that: * `RawCommand` command quotes and escapes the command parameters * `ShellCommand` does no escaping but it runs command in `sh` shell Corollary: there is no way to run `bash` command with unescaped parameters. As a result there is no way to run this command (and many others): {{{ diff <(echo $ENV_FOO) <(echo $ENV_BAR) }}} Running it as a `RawCommand` (using `proc` function) fails because command line parameters are escaped and become incorrect. Running it as `ShellCommand` (using `shell` function) fails because this is not valid `sh` syntax. I propose to create function that allows user to run `bash` commands without escaping the parameters (or even better, run any shell the user wants). In other words this program: {{{ import System.Exit import System.Process main :: IO () main = do (_, _, _, pid) <- createProcess (SOME_NEW_FUNCTION "diff" ["<(echo $FOO)", "<(echo $BAR)"] ) { env = Just [("FOO","Foo"),("BAR","Bar")] } ecode <- waitForProcess pid case ecode of ExitSuccess -> putStrLn "All?s right with the world!" ExitFailure _ -> putStrLn ":-(" }}} should produce: {{{ 1c1 < Foo --- > Bar }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 08:25:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 08:25:07 -0000 Subject: [GHC] #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory Message-ID: <044.398377c33d022955e6b200df91088795@haskell.org> #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory ----------------------------------+---------------------------------- Reporter: awson | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.2 Component: Runtime System | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- Consider this: {{{ -- t.hs import System.Environment main :: IO () main = do n <- fmap (read . head) getArgs print $ foldr (+) (0::Int) [0 .. n] }}} Compiled with ghc-7.6.3 and ran thus: {{{ ghc -O2 -rtsopts --make -o t.exe t.hs t.exe +RTS -K4G -RTS 250000000 }}} it works fine! But compiled with 7.8rc2 it segfaults when amount of memory allocated crosses 4G mark. I've discovered this trying to use Agda built with ghc-7.8rc2 but quickly understood this is a general problem and extremely nasty one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 08:30:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 08:30:33 -0000 Subject: [GHC] #8838: Allow running bash shell commands In-Reply-To: <048.45d5636007cfb5c906cb5fa0eb0bba59@haskell.org> References: <048.45d5636007cfb5c906cb5fa0eb0bba59@haskell.org> Message-ID: <063.fa04189053cb6f82c4040d66a7327734@haskell.org> #8838: Allow running bash shell commands ------------------------------------------------+-------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/process | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: #8802 ------------------------------------------------+-------------------------- Comment (by nomeata): Use {{{ import System.Exit import System.Process main :: IO () main = do (_, _, _, pid) <- createProcess (proc "bash" ["-c", "diff <(echo $FOO) <(echo $BAR)"] ) { env = Just [("FOO","Foo"),("BAR","Bar")] } ecode <- waitForProcess pid case ecode of ExitSuccess -> putStrLn "All?s right with the world!" ExitFailure _ -> putStrLn ":-(" }}} I don?t think `System.Process` needs any special support for `bash` features, just like there is no special way to invoke `perl -e` or `sed` or `ghc -e`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 08:40:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 08:40:21 -0000 Subject: [GHC] #8838: Allow running bash shell commands In-Reply-To: <048.45d5636007cfb5c906cb5fa0eb0bba59@haskell.org> References: <048.45d5636007cfb5c906cb5fa0eb0bba59@haskell.org> Message-ID: <063.614dfceb292e086583f5f9798f9cb4e6@haskell.org> #8838: Allow running bash shell commands ------------------------------------------------+-------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/process | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: #8802 ------------------------------------------------+-------------------------- Comment (by jstolarek): > I don?t think System.Process needs any special support for bash features Well, there is a built in support for running `sh`... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 08:44:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 08:44:58 -0000 Subject: [GHC] #8838: Allow running bash shell commands In-Reply-To: <048.45d5636007cfb5c906cb5fa0eb0bba59@haskell.org> References: <048.45d5636007cfb5c906cb5fa0eb0bba59@haskell.org> Message-ID: <063.2d01c2096a65280a48b15ecb0fa8dad4@haskell.org> #8838: Allow running bash shell commands ------------------------------------------------+-------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/process | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: #8802 ------------------------------------------------+-------------------------- Comment (by nomeata): > Well, there is a built in support for running sh... Correct, because a POSIX shell is, by specification, part of a unix system; random and exotic bash features are not. In any case, I?d advise against using shell commands in serious projects, especially with untrusted data, the risks are just too great. Is `proc "bash" ["-c", "..."]` not sufficient for your use cases? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 09:31:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 09:31:42 -0000 Subject: [GHC] #8835: 7.6.3 vs 7.8-RC performance regression In-Reply-To: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> References: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> Message-ID: <059.b69841d1b2fb9f1f3d160c9a02defdb3@haskell.org> #8835: 7.6.3 vs 7.8-RC performance regression --------------------------------------------+------------------------------ Reporter: cbm80 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by cbm80): I have simplified and smallified the code on github a bit, and compiled with `-fno-full-laziness`. While memory usage is down to the 7.6.3 version the GC problems remained. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 10:51:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 10:51:04 -0000 Subject: [GHC] #8840: standalone 'let' in do notation does not parse Message-ID: <045.3a9faeb0b782e77436e4e1ec36319398@haskell.org> #8840: standalone 'let' in do notation does not parse ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- When describing to a friend "do notation" syntactic equivalence some days ago I picked the following example: {{{ -- valid for ghc main = do let z = 1 print z }}} and tried to make it one-line for lambdabot: {{{ -- seems to be allowed explicitly by the spec -- http://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-470003.14 main = do { let z = 1; print z } }}} Bug neither ghc-7.6.3 nor ghc-7.8.1-rc2 seem to accept it as valid: {{{ [1 of 1] Compiling Main ( a.hs, a.o ) a.hs:1:32: parse error on input ?}? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 12:17:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 12:17:40 -0000 Subject: [GHC] #8840: standalone 'let' in do notation does not parse In-Reply-To: <045.3a9faeb0b782e77436e4e1ec36319398@haskell.org> References: <045.3a9faeb0b782e77436e4e1ec36319398@haskell.org> Message-ID: <060.84093f6be6a6d708f6f071734489352b@haskell.org> #8840: standalone 'let' in do notation does not parse -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): This is because `let` is a block-opening syntax element just like `do`; c.f. [http://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-210002.7 Haskell Report 2010: Lexical Structure] If you write instead {{{#!hs do { let { z = 1 }; print z } }}} it should work... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 13:37:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 13:37:56 -0000 Subject: [GHC] #8840: standalone 'let' in do notation does not parse In-Reply-To: <045.3a9faeb0b782e77436e4e1ec36319398@haskell.org> References: <045.3a9faeb0b782e77436e4e1ec36319398@haskell.org> Message-ID: <060.105fbe21c86cf7173706eaeb03702d5f@haskell.org> #8840: standalone 'let' in do notation does not parse -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by slyfox): * status: new => closed * resolution: => invalid Comment: Oh, see. Didn't know {{{ f x = let a = 1; b = 2 g y = exp2 in exp1 }}} is a valid construct. My code did translated to {{{ main = do { let z = 1 print z } -- stray '}' }}} Closign as INVALID then. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 14:48:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 14:48:23 -0000 Subject: [GHC] #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory In-Reply-To: <044.398377c33d022955e6b200df91088795@haskell.org> References: <044.398377c33d022955e6b200df91088795@haskell.org> Message-ID: <059.0e95260420c0010ecc135904913fa9d5@haskell.org> #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory -----------------------------------+---------------------------------- Reporter: awson | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.2 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by awson): Initial problem was that darcs Agda 2.3.3 compiled with ghc-7.8rc2 segfaulted checking https://github.com/crypto-agda/crypto- agda/blob/master/Control/Protoco/Reduction.agda right after the amount of allocated memory crossed 4G mark. If I tried to check this file with `+RTS -H4G` option it segfaulted almost immediately. At the same time, the same Agda compiled with ghc-7.6.3 successfully allocated much more than 4G while checking this file. And I've ran it with default stack (no `+RTS -K...` option). So, perhaps, stack size is not essential here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 14:51:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 14:51:25 -0000 Subject: [GHC] #8838: Allow running bash shell commands In-Reply-To: <048.45d5636007cfb5c906cb5fa0eb0bba59@haskell.org> References: <048.45d5636007cfb5c906cb5fa0eb0bba59@haskell.org> Message-ID: <063.59a829e87184150b77b3472e34f97d24@haskell.org> #8838: Allow running bash shell commands ------------------------------------------------+-------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/process | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: #8802 ------------------------------------------------+-------------------------- Comment (by jstolarek): > Is proc "bash" ["-c", "..."] not sufficient for your use cases? Yes, it is. I wonder why this works? I mean parameters are escaped. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 14:51:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 14:51:38 -0000 Subject: [GHC] #8838: Allow running bash shell commands In-Reply-To: <048.45d5636007cfb5c906cb5fa0eb0bba59@haskell.org> References: <048.45d5636007cfb5c906cb5fa0eb0bba59@haskell.org> Message-ID: <063.a9e00c6b4e1e0367c76f072ba7e0d4b1@haskell.org> #8838: Allow running bash shell commands ------------------------------------------------+-------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/process | Version: Resolution: invalid | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: #8802 ------------------------------------------------+-------------------------- Changes (by jstolarek): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 14:57:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 14:57:17 -0000 Subject: [GHC] #8838: Allow running bash shell commands In-Reply-To: <048.45d5636007cfb5c906cb5fa0eb0bba59@haskell.org> References: <048.45d5636007cfb5c906cb5fa0eb0bba59@haskell.org> Message-ID: <063.034407dce5fefeb9bd90f55436466363@haskell.org> #8838: Allow running bash shell commands ------------------------------------------------+-------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/process | Version: Resolution: invalid | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: #8802 ------------------------------------------------+-------------------------- Comment (by nomeata): Replying to [comment:4 jstolarek]: > > Is proc "bash" ["-c", "..."] not sufficient for your use cases? > Yes, it is. I wonder why this works? I mean parameters are escaped. No, they are not ? `translate` is not used here! (as mentioned in ticket:8802#comment:6). But that explains the confusion :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 15:16:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 15:16:21 -0000 Subject: [GHC] #8838: Allow running bash shell commands In-Reply-To: <048.45d5636007cfb5c906cb5fa0eb0bba59@haskell.org> References: <048.45d5636007cfb5c906cb5fa0eb0bba59@haskell.org> Message-ID: <063.1c1290b16c50dfa85fa6c1790b947670@haskell.org> #8838: Allow running bash shell commands ------------------------------------------------+-------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/process | Version: Resolution: invalid | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: #8802 ------------------------------------------------+-------------------------- Comment (by jstolarek): Oh, I completely missed your [[ticket:8802#comment:8]] comment! My bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 15:51:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 15:51:43 -0000 Subject: [GHC] #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory In-Reply-To: <044.398377c33d022955e6b200df91088795@haskell.org> References: <044.398377c33d022955e6b200df91088795@haskell.org> Message-ID: <059.49a3cd556e460a3f5b449aab7c5d84a9@haskell.org> #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory -----------------------------------+---------------------------------- Reporter: awson | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.2 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by simonmar): Does it work on a non-Windows platform? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 16:48:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 16:48:38 -0000 Subject: [GHC] #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory In-Reply-To: <044.398377c33d022955e6b200df91088795@haskell.org> References: <044.398377c33d022955e6b200df91088795@haskell.org> Message-ID: <059.e36808e096c7d5962c6b230b708b7318@haskell.org> #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory -----------------------------------+---------------------------------- Reporter: awson | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.2 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by hvr): Replying to [comment:2 simonmar]: > Does it work on a non-Windows platform? seems so; I've tried the example on Linux/x86_64 with GHC 7.8.0.20140228: {{{ $ ghc -O2 -rtsopts --make t.hs [1 of 1] Compiling Main ( t.hs, t.o ) Linking t ... $ ./t +RTS -s -K4G -RTS 257000000 33024500128500000 4,268,393,264 bytes allocated in the heap 172,568 bytes copied during GC 2,146,986,848 bytes maximum residency (12 sample(s)) 21,224 bytes maximum slop 4203 MB total memory in use (65 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 8130 colls, 0 par 2.98s 2.98s 0.0004s 0.0004s Gen 1 12 colls, 0 par 1.69s 1.70s 0.1414s 0.7621s INIT time 0.00s ( 0.00s elapsed) MUT time 2.20s ( 2.20s elapsed) GC time 4.67s ( 4.68s elapsed) EXIT time 0.17s ( 0.17s elapsed) Total time 7.04s ( 7.05s elapsed) %GC time 66.3% (66.4% elapsed) Alloc rate 1,936,992,267 bytes per MUT second Productivity 33.7% of total user, 33.7% of total elapsed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 17:06:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 17:06:36 -0000 Subject: [GHC] #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib In-Reply-To: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> References: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> Message-ID: <059.2bde8e421506da4a6f1f782d09aa8627@haskell.org> #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib ------------------------------------------+-------------------------------- Reporter: awick | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC failed | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by thoughtpolice): Hmmmm... So, this was an error on my part, but it makes me think of something I'm not sure we considered: - Right now, if you *don't* have GMP available at build time, and you use the in-tree GMP, GHC will link it statically into your applications. That is, GHC will build GMP locally to use it, and resulting applications won't have a dynamic link to `libgmp.so`. - If you have an external GMP at build time, then it will link resulting binaries against that. Since GHC self-bootstraps as you can see, this includes GHC itself. This happened to me because I did `brew install gmp` to test something. Adam, I can provide another binary in the mean time with the caveat it statically links to GMP. Is this acceptable? For some people I know (out of principle or otherwise) this isn't, and they will want to dynamically link, so perhaps there should be two for now. Frankly, the binary proliferation here is a bit silly almost... we should really carefully evaluate what to do with GMP etc in a discussion in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 17:13:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 17:13:14 -0000 Subject: [GHC] #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib In-Reply-To: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> References: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> Message-ID: <059.93d1aeb90eed608acbd47e9c3be62f29@haskell.org> #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib ------------------------------------------+-------------------------------- Reporter: awick | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC failed | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by thoughtpolice): On second thought, I wonder how much effort it would be to just fix the build system to install a dynamic version of the in-tree GMP instead for the final release... It looks like there's some code to already do this, but it's commented out and slightly bitrotted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 18:10:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 18:10:04 -0000 Subject: [GHC] #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib In-Reply-To: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> References: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> Message-ID: <059.2e953351e068a70032e535cb4325602b@haskell.org> #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib ------------------------------------------+-------------------------------- Reporter: awick | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC failed | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by awick): Just to get things working, I just symlinked my MacPorts copy over to /usr/local/lib, for now. Personally, I'd much prefer GHC to include an "extra" version of GMP than assume the right one is around on a Mac. From my point of view, either using a statically linked set of binaries or just including a copy of libgmp.10.dylib are equally fine. Ideally, it'd be nifty if the installer did a check for a local version. If there was one, it'd point the installed binaries to that. If not, then it'd have a spare copy it could install for GHC. But I don't know how hard that redirection would be, and for now, I suspect just always including GMP would be easier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 18:18:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 18:18:50 -0000 Subject: [GHC] #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib In-Reply-To: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> References: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> Message-ID: <059.258dda0520969c3654289b385c013109@haskell.org> #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib ------------------------------------------+-------------------------------- Reporter: awick | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC failed | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by carter): I think that "install time" detection is totally doable, its just someone would have to do it.... (and likely need different tricks per platform perhaps) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 18:35:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 18:35:10 -0000 Subject: [GHC] #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib In-Reply-To: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> References: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> Message-ID: <059.76a88ba3cdcad9d3cd9b15fc6e659708@haskell.org> #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib ------------------------------------------+-------------------------------- Reporter: awick | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC failed | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Changes (by thoughtpolice): * cc: hvr (added) Comment: It's not easily possible to do it at install time because it all depends on how GHC itself was built, not how it's going to be installed. Theoretically you could do something I gues to change the rpath (perhaps `nix` does this for OS X already) but that seems fragile to incorporate right now - plus we need to ensure GHC itself does the right thing once this is detected. It sounds like a bit of work. I think the better thing to do would be to investigate cleaning up the in- tree GMP build to install a `.dylib` which we can fall back on, since we need the in-tree build for Windows and generally OS X (as it doesn't come along). Linux is not so much of a problem. In the mean time - I've updated the binaries for the RC2 download. They link statically just like RC1. Do give them a go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 3 21:31:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Mar 2014 21:31:03 -0000 Subject: [GHC] #8841: PatternSynonyms error gives wrong source locations Message-ID: <051.266a2b6688dc36204387024e5fd153b2@haskell.org> #8841: PatternSynonyms error gives wrong source locations -------------------------+------------------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: bug | Milestone: 7.8.1 Priority: low | Version: 7.8.1-rc2 Component: | Operating System: Linux Compiler | Type of failure: Incorrect warning at Keywords: | compile-time PatternSynonyms | Test Case: Architecture: x86 | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Using an example from the [http://www.haskell.org/ghc/docs/7.8.1-rc1/html/users_guide/syntax- extns.html GHC user's guide] but omitting the argument to `Maybe` {{{ {-# LANGUAGE PatternSynonyms #-} data Type = App String [Type] pattern Maybe = App "Maybe" [t] }}} gives the following error without the correct source locations {{{ ghci> :load /tmp/failure.hs [1 of 1] Compiling Main ( /tmp/failure.hs, interpreted ) /tmp/failure.hs:1:1: Right-hand side of bidirectional pattern synonym cannot be used as an expression App "Maybe" [t] Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 01:38:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 01:38:34 -0000 Subject: [GHC] #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib In-Reply-To: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> References: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> Message-ID: <059.c32a0ca727405f82617eef2b9f132a4e@haskell.org> #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib ------------------------------------------+-------------------------------- Reporter: awick | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC failed | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by awick): Hmmm. Which binaries did you update, and where did you put them? I grabbed: {{{ ghc-7.8.0.20140228-x86_64-apple-darwin-mavericks.tar.bz2 }}} from http://www.haskell.org/ghc/dist/7.8.1-rc2/ and got the same problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 01:49:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 01:49:38 -0000 Subject: [GHC] #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib In-Reply-To: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> References: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> Message-ID: <059.0a6903575aa77d14f74371e5b73b5584@haskell.org> #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib ------------------------------------------+-------------------------------- Reporter: awick | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC failed | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by thoughtpolice): I downloaded the same binary from that URL, sha1 hash `b3e68ae11d5438442cafacfaef729d80cc948cb3`. There is no dynamic link to `libgmp.dylib`, nor do I have it in my system: {{{ $ find /usr/local/lib/ | grep gmp $ $ otool -L ./utils/ghc-pwd/dist-install/build/tmp/ghc-pwd | grep gmp @rpath/libHSinteger-gmp-0.5.1.0-ghc7.8.0.20140228.dylib (compatibility version 0.0.0, current version 0.0.0) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 04:14:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 04:14:54 -0000 Subject: [GHC] #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib In-Reply-To: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> References: <044.1d04bdf4125543e00bf54b950d8264ea@haskell.org> Message-ID: <059.011427b301787f36ddee00bcf34099f6@haskell.org> #8837: GHC 7.8.1-rc2 requires /usr/local/lib/libgmp10.10.dylib ------------------------------------------+-------------------------------- Reporter: awick | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC failed | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Changes (by awick): * status: new => closed * resolution: => fixed Comment: Ah, apologies. Looks like I downloaded the new one but unpacked the old one. Having now unpacked the right one, the update worked for me, so I'll close the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 04:44:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 04:44:54 -0000 Subject: [GHC] #8738: msys2 fails cabal01 test In-Reply-To: <045.e5b4b4cce287d04bf2354c1ec173d94b@haskell.org> References: <045.e5b4b4cce287d04bf2354c1ec173d94b@haskell.org> Message-ID: <060.8d56df638bbc9492891cd09b86ca1d4a@haskell.org> #8738: msys2 fails cabal01 test ------------------------------------------------+-------------------------- Reporter: ezyang | Owner: refold Type: bug | Status: new Priority: low | Milestone: Component: Test Suite | Version: Resolution: | 7.8.1-rc1 Operating System: Windows | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: cabal01 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by refold): Looks like this has to do with cross-compilation changes in 1.18, which changed the default install locations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 06:15:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 06:15:52 -0000 Subject: [GHC] #8842: Make sure msys2 builds non emulating binaries Message-ID: <046.86a6364bab91651953306fe81692398f@haskell.org> #8842: Make sure msys2 builds non emulating binaries ------------------------------------+--------------------------------- Reporter: schyler | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- I came across this in my own project. MSys2 doesn't enter #ifdef blocks which test for _WIN32. Instead, it pretends to be Linux and has a set of headers which emulate things like mmap. These emulation functions are really really slow -- in my personal tests about 10x slower than calling the WINAPI -- so this ticket is just a reminder (it may already be done) for someone to check that MSys2 builds things non-emulated in GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 07:04:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 07:04:41 -0000 Subject: [GHC] #8738: msys2 fails cabal01 test In-Reply-To: <045.e5b4b4cce287d04bf2354c1ec173d94b@haskell.org> References: <045.e5b4b4cce287d04bf2354c1ec173d94b@haskell.org> Message-ID: <060.cb644f563ee201606106d967673eedf2@haskell.org> #8738: msys2 fails cabal01 test ------------------------------------------------+-------------------------- Reporter: ezyang | Owner: refold Type: bug | Status: new Priority: low | Milestone: Component: Test Suite | Version: Resolution: | 7.8.1-rc1 Operating System: Windows | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: cabal01 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by refold): Passes now on my machine with the attached patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 07:05:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 07:05:14 -0000 Subject: [GHC] #8738: msys2 fails cabal01 test In-Reply-To: <045.e5b4b4cce287d04bf2354c1ec173d94b@haskell.org> References: <045.e5b4b4cce287d04bf2354c1ec173d94b@haskell.org> Message-ID: <060.6e2d888c1fe7e875dc3e90727fe908bb@haskell.org> #8738: msys2 fails cabal01 test ------------------------------------------------+-------------------------- Reporter: ezyang | Owner: refold Type: bug | Status: patch Priority: low | Milestone: Component: Test Suite | Version: Resolution: | 7.8.1-rc1 Operating System: Windows | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: cabal01 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by refold): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 08:32:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 08:32:14 -0000 Subject: [GHC] #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o In-Reply-To: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> References: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> Message-ID: <060.1d3a5291dddd797906314b8b0ee9bf96@haskell.org> #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o ----------------------------------------+---------------------------------- Reporter: mrothe | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by octoploid): See: https://sourceware.org/bugzilla/show_bug.cgi?id=16341 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 08:57:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 08:57:15 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.65b4cfee461d072242bce94a099e21e5@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -----------------------------+---------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by teuffy): is "ppa:hvr/ghc" still working to install ghc 7.8.1 ? Replying to [comment:16 hvr]: > Replying to [comment:12 teuffy]: > > I installed ghc-7.8.1 and ghc --version still showing 7.6.3. What should I do to test my code under ghc 7.8.1? > > Fyi, when using the `ppa:hvr/ghc` PPAs you need to put e.g. `/opt/ghc/7.8.1/bin` early enough in your PATH. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 09:09:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 09:09:40 -0000 Subject: [GHC] #8843: Maverick GHC --make problem - linking problem Message-ID: <045.7aef55c0386e202f1a9a5c0da91c24b7@haskell.org> #8843: Maverick GHC --make problem - linking problem ----------------------------------+--------------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- Hi when I runghc code_x.hs --> program is running when I ghc --make code_x.hs --> I got this error message. Do you know where the problem is coming from? Undefined symbols for architecture x86_64: "_iconv", referenced from: _hs_iconv in libHSbase-4.6.0.1.a(iconv.o) (maybe you meant: _base_GHCziIOziEncodingziIconv_iconvEncoding11_info, _base_GHCziIOziEncodingziIconv_iconvEncoding10_info , _base_GHCziIOziEncodingziIconv_iconvEncoding11_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_info , _base_GHCziIOziEncodingziIconv_iconvEncoding9_closure , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding12_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding7_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_info , _base_GHCziIOziEncodingziIconv_iconvEncoding8_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding4_closure , _hs_iconv_open , _hs_iconv , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc_info , _base_GHCziIOziEncodingziIconv_iconvEncoding3_info , _base_GHCziIOziEncodingziIconv_iconvEncoding3_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding5_info , _base_GHCziIOziEncodingziIconv_iconvEncoding12_info , _base_GHCziIOziEncodingziIconv_iconvEncoding9_info , _hs_iconv_close , _base_GHCziIOziEncodingziIconv_iconvEncoding10_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding6_info , _base_GHCziIOziEncodingziIconv_iconvEncoding7_info , _base_GHCziIOziEncodingziIconv_iconvEncoding6_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding5_closure ) "_iconv_close", referenced from: _hs_iconv_close in libHSbase- 4.6.0.1.a(iconv.o) (maybe you meant: _hs_iconv_close) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.6.0.1.a(iconv.o) (maybe you meant: _hs_iconv_open) "_locale_charset", referenced from: _localeEncoding in libHSbase-4.6.0.1.a(PrelIOUtils.o) ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 09:54:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 09:54:01 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.934503712d29c03879152c69303a7f27@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by simonpj): Thanks for the recipe. Alas, it works fine for me, when I tried with HEAD. I followed those exact steps, except that you didn't supply the patch to use in the second- last file, so I just modified `Data.List` by adding and exporting a couple of new functions. (I suppose it is just about possible that the exact patch is important.) Then when I typed `make` (still in `libraries/base`) it re-built the base- library just fine. NB: I did not add `build.mk` because that's not in the recipe above. This is all on Linux. What architecture are you on? Does it reproduce for you on Linux? The first few lines of output after the final `make` look like this. Same for you? {{{ simonpj at cam-05-unx:~/code/ghc-8374/libraries/base$ make make -C ../.. all_libraries/base libraries/base_dist_NO_BUILD_DEPS=YES libraries/base_dist-boot_NO_BUILD_DEPS=YES libraries/base_dist- install_NO_BUILD_DEPS=YES NO_GENERATED_MAKEFILE_RULES=YES OMIT_PHASE_0=YES OMIT_PHASE_1=YES stage=0 make[1]: Entering directory `/home/simonpj/code/ghc-8374' ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all_libraries/base "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist- install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base /dist-install/build/autogen -Ilibraries/base/include -optP- DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist- install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist- install/build -split-objs -dynamic-too -c libraries/base/./Data/List.hs -o libraries/base/dist-install/build/Data/List.o -dyno libraries/base/dist- install/build/Data/List.dyn_o "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist- install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base /dist-install/build/autogen -Ilibraries/base/include -optP- DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist- install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist- install/build -split-objs -dynamic-too -c libraries/base/./Foreign/Marshal/Pool.hs -o libraries/base/dist- install/build/Foreign/Marshal/Pool.o -dyno libraries/base/dist- install/build/Foreign/Marshal/Pool.dyn_o }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 12:14:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 12:14:46 -0000 Subject: [GHC] #8831: Cannot use Template Haskell splice in ghci In-Reply-To: <047.1688ea3628125d840e5d96b182466527@haskell.org> References: <047.1688ea3628125d840e5d96b182466527@haskell.org> Message-ID: <062.fd5de8039bfddf5272a0f1f14a6725da@haskell.org> #8831: Cannot use Template Haskell splice in ghci -------------------------------------+---------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by simonpj): * priority: normal => highest * milestone: => 7.8.1 Comment: This looks bad. When did it start to happen? I'm surprised a regression test doesn't catch it. Austin can you investigate? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 13:05:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 13:05:13 -0000 Subject: [GHC] #8844: Pseudo terminal and process-1.2.0.0 Message-ID: <049.4e9c2e6d1c0aa3bbcf4607dd7d51c8fd@haskell.org> #8844: Pseudo terminal and process-1.2.0.0 -------------------------------------+------------------------------------- Reporter: ksamborski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 7.6.3 Keywords: pty | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Hello, I'm writing simple app which execute process and communicate with it via pseudo terminal. Here is some sample code: import System.Posix.Terminal import System.Process main = do (master, slave) <- openPseudoTerminal hslave <- fdToHandle slave hSetBuffering hslave NoBuffering (_,_,_,ph) <- createProcess (shell "mc"){ env = Just [("TERM", "xterm")] , std_in = UseHandle hslave , std_out = UseHandle hslave , std_err = UseHandle hslave , close_fds = True } forkIO $ readTerm master -- my function which reads output from process waitForProcess ph The problem is that mc still wants some input from stdin but not from slave terminal. But when I changed function runIteractiveProcess from runProcess.c like this: ... /* Reset the SIGINT/SIGQUIT signal handlers in the child, if requested */ if (reset_int_quit_handlers) { struct sigaction dfl; (void)sigemptyset(&dfl.sa_ mask); dfl.sa_flags = 0; dfl.sa_handler = SIG_DFL; (void)sigaction(SIGINT, &dfl, NULL); (void)sigaction(SIGQUIT, &dfl, NULL); } /********************************************************************************/ setsid(); //Make the current process a new session leader ioctl(0, TIOCSCTTY, 1); //As the child is a session leader, set the controlling terminal to be the slave side of the PTY /********************************************************************************/ /* the child */ if (environment) { // XXX Check result execvpe(args[0], args, environment); } else { // XXX Check result execvp(args[0], args); } childFailed(forkCommunicationFds[1], forkExecFailed); ... it worked as expected, I'm not proposing patch or solution but is there any chance to add support for pseudo terminals in the process library? Maybe just add another record field in CreateProcess like pty :: Bool and then call these two additional instructions in runIteractiveProcess? Best regards, Karol Samborski -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 13:31:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 13:31:53 -0000 Subject: [GHC] #8845: weight lose tips 2071 Message-ID: <050.3e926d5c7eadbcd7810943f502fe854c@haskell.org> #8845: weight lose tips 2071 ------------------------------------------+-------------------------------- Reporter: GloriaClark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: Raspberry Ultra Ketone | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ------------------------------------------+-------------------------------- Need to be in perfect forge this summer? Losing a few artifact pounds can be a great helpfulness to assure the perfect beach body. [http://tryraspberryultraketone.com/ Raspberry Ultra Ketone] There are both born construction to regress metric. There are a few all innate coefficient experience supplements that can supply you retrogress unit without any support effects. Hoodia is the most well-known craving drug. Gordnoii Hoodia is a cactus communicate that grows in the Desert Biome in Southerly Africa. One of the most arresting features of this organism is that it can bit your appetence and reduce nutrient cravings. Mortal group Kalahari hit been using it for hundreds of years to curb your craving. Food can be very meager for specified disagreeable windward conditions and hoodia can eliminate you go without ingestion or uptake anything from a lengthen of a couplet of days. Tho' nearly 13 varieties of this lay, it is exclusive the Hoodia Gordonii that can actually forget the appetite. All others are honourable pointless. Documented hoodia pills can forbear you retrograde up to 5 pounds in 7 life without any surface personalty. Notwithstanding, you score to explicitly play trusty that you buy Hoodia pills are cypher but 100% processed hoodia gordonii pulverisation without any fillers or binders. Top Location Hoodia pills are insane by CITES which is of such pills proofs legitimacy. Slimming Tea This is added natural prize for you to retrograde coefficient and I mortal to say that it is one of the primo distance to worsen a few spare pounds, as wellspring as to secure meliorate boilersuit welfare and well-being. Prc is a tea manufacturing hub for hundreds of period. Prc and remaining Inhabitant countries, fill change been drunkenness tea for ages, not only to prepare yourself in influence, but also turn your overall health. Raspberry Ultra Ketone There are galore types of weight amount tea but the most efficacious ones are predictable breeds, much as Pu-erh, Sencha and Oolong WUYI rock mix. This tea gives a more needed hike to your metabolism, helping your body to reflex out all the toxins and other untoward chemicals. Not only this, such tea also prevents the give of insulin in the body after it was carbs. This prevents the increase of fat in the body, since Insulin is the corticosteroid that regulates fat growth in the embody. Different effects of this tea is that it can serve throttle cravings and suppresses the appetence, thusly helping you to reach telling suppress of nutrient, which is rattling primal to secure metric sum. Favourable calibre small tea can supply you lose up to 15 pounds in a month and all you poorness to do is retributive hold a few cups of tea a day.Domestic people Kalahari soul been using it for hundreds of years to curbing your appetency. Content can be really meagre for much disagreeable endure conditions and hoodia can accomplish you go without consumption or intake anything from a stretching of a mates of life. Not exclusive this, such as tea can also lessen your cholesterol levels and surpass cardiac role. One of the most consequential advantages of this tea is that it can also improve thin articulate significantly. Inflection is a educatee problem these life, and there is conclude for galore health problems, including metric departure. http://tryraspberryultraketone.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 14:39:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 14:39:37 -0000 Subject: [GHC] #8846: GHC panic with Template Haskell Message-ID: <046.7d0bb7e81eb2370f95f549b02e4f17bb@haskell.org> #8846: GHC panic with Template Haskell ----------------------------------+--------------------------------------- Reporter: Gothmog | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I get a panic when compiling the attached files with "ghc --make test": ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): nameModule a{v a14p} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 14:58:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 14:58:13 -0000 Subject: [GHC] #8846: GHC panic with Template Haskell In-Reply-To: <046.7d0bb7e81eb2370f95f549b02e4f17bb@haskell.org> References: <046.7d0bb7e81eb2370f95f549b02e4f17bb@haskell.org> Message-ID: <061.f948b4e4fbbcd4310a11f149930b4a62@haskell.org> #8846: GHC panic with Template Haskell ---------------------------------------+---------------------------------- Reporter: Gothmog | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by Gothmog): P.S.: As I see it, there is a type error as the return value of the splice should be Q [Dec] but is Q Exp. However, I figure GHC shouldn't panic anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 17:30:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 17:30:17 -0000 Subject: [GHC] #8847: Int64 ^ Int64 broken by optimization on SPARC Message-ID: <046.255c7bf5dd7528953840f835ce810cc7@haskell.org> #8847: Int64 ^ Int64 broken by optimization on SPARC --------------------------+------------------------------------------------ Reporter: | Owner: kgardas | Status: new Type: bug | Milestone: Priority: normal | Version: Component: | Operating System: Solaris Compiler (NCG) | Type of failure: Incorrect result at runtime Keywords: | Test Case: Architecture: sparc | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ The T7507 test is broken on SPARC NCG, I've more simplified it to {{{ module Main where import Data.Int main = print ( ( 2 :: Int64 ) ^ ( 6 :: Int64 ) ) }}} it does not matter if it's run with two Int64 or just with one: {{{ main = print ( 2 ^ 6 :: Int64 ) }}} the result with -O is still 0. The result without -O is correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 17:32:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 17:32:20 -0000 Subject: [GHC] #8816: Make SPARC registerised again. In-Reply-To: <046.8f4303f65c2a90c038068e79195aaef6@haskell.org> References: <046.8f4303f65c2a90c038068e79195aaef6@haskell.org> Message-ID: <061.24deb71dc8c6d37f66459ee027941ed4@haskell.org> #8816: Make SPARC registerised again. ------------------------------------+--------------------------- Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8847 Blocking: | Related Tickets: ------------------------------------+--------------------------- Changes (by kgardas): * blockedby: => 8847 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 18:02:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 18:02:16 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.a596876ddb1a820d9210e8c981f2a92b@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Changes (by carter): * priority: normal => highest * version: 7.7 => 7.8.1-rc2 Comment: We need this or something very much like it to get into 7.8.1/7.8.2, or we'll have some pain transparently supporting a range of mac OS versions in OS X, future weird config situations, or even nicely baking CPPHS into ghc distro as a near term solution setting priority higher accordingly. I will try to make time this week to fix things up, but I've a few other professional obligations that might block that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 18:25:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 18:25:57 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar Message-ID: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> #8848: Warning: Rule too complicated to desugar ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've a very very modest application of Specialize to fixed sized lists in some of my code which seems to trip up the specialization machinery. Is there any flags I can pass GHC to make sure it doesn't give up on these specialize calls? is the only work around to write my own monomorphic versions and add some hand written rewrite rules?! {{{ rc/Numerical/Types/Shape.hs:225:1: Warning: RULE left-hand side too complicated to desugar let { $dFunctor_a3XB :: Functor (Shape ('S 'Z)) [LclId, Str=DmdType] $dFunctor_a3XB = Numerical.Types.Shape.$fFunctorShape @ 'Z $dFunctor_a3Rn } in map2 @ a @ b @ c @ ('S ('S 'Z)) (Numerical.Types.Shape.$fApplicativeShape @ ('S 'Z) (Numerical.Types.Shape.$fFunctorShape @ ('S 'Z) $dFunctor_a3XB) (Numerical.Types.Shape.$fApplicativeShape @ 'Z $dFunctor_a3XB Numerical.Types.Shape.$fApplicativeShape0)) src/Numerical/Types/Shape.hs:226:1: Warning: RULE left-hand side too complicated to desugar let { $dFunctor_a3XG :: Functor (Shape ('S 'Z)) [LclId, Str=DmdType] $dFunctor_a3XG = Numerical.Types.Shape.$fFunctorShape @ 'Z $dFunctor_a3Rn } in let { $dFunctor_a3XF :: Functor (Shape ('S ('S 'Z))) [LclId, Str=DmdType] $dFunctor_a3XF = Numerical.Types.Shape.$fFunctorShape @ ('S 'Z) $dFunctor_a3XG } in map2 @ a @ b @ c @ ('S ('S ('S 'Z))) (Numerical.Types.Shape.$fApplicativeShape @ ('S ('S 'Z)) (Numerical.Types.Shape.$fFunctorShape @ ('S ('S 'Z)) $dFunctor_a3XF) (Numerical.Types.Shape.$fApplicativeShape @ ('S 'Z) $dFunctor_a3XF (Numerical.Types.Shape.$fApplicativeShape @ 'Z $dFunctor_a3XG Numerical.Types.Shape.$fApplicativeShape0))) }}} the associated code (smashed into a single module ) is {{{ {-# LANGUAGE DataKinds, GADTs, TypeFamilies, ScopedTypeVariables #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE CPP #-} {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoImplicitPrelude #-} module Numerical.Types.Shape where import GHC.Magic import Data.Data import Data.Typeable() import Data.Type.Equality import qualified Data.Monoid as M import qualified Data.Functor as Fun import qualified Data.Foldable as F import qualified Control.Applicative as A import Prelude hiding (foldl,foldr,init,scanl,scanr,scanl1,scanr1) data Nat = S !Nat | Z deriving (Eq,Show,Read,Typeable,Data) #if defined(__GLASGOW_HASKELL_) && (__GLASGOW_HASKELL__ >= 707) deriving instance Typeable 'Z deriving instance Typeable 'S #endif type family n1 + n2 where Z + n2 = n2 (S n1') + n2 = S (n1' + n2) -- singleton for Nat data SNat :: Nat -> * where SZero :: SNat Z SSucc :: SNat n -> SNat (S n) --gcoerce :: (a :~: b) -> ((a ~ b) => r) -> r --gcoerce Refl x = x --gcoerce = gcastWith -- inductive proof of right-identity of + plus_id_r :: SNat n -> ((n + Z) :~: n) plus_id_r SZero = Refl plus_id_r (SSucc n) = gcastWith (plus_id_r n) Refl -- inductive proof of simplification on the rhs of + plus_succ_r :: SNat n1 -> Proxy n2 -> ((n1 + (S n2)) :~: (S (n1 + n2))) plus_succ_r SZero _ = Refl plus_succ_r (SSucc n1) proxy_n2 = gcastWith (plus_succ_r n1 proxy_n2) Refl 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 {- Need to sort out packed+unboxed vs generic approaches see ShapeAlternatives/ for -} infixr 3 :* {- the concern basically boils down to "will it specialize / inline well" -} newtype At a = At a deriving (Eq, Ord, Read, Show, Typeable, Functor) data Shape (rank :: Nat) a where Nil :: Shape Z a (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a --deriving (Show) #if defined(__GLASGOW_HASKELL_) && (__GLASGOW_HASKELL__ >= 707) deriving instance Typeable Shape #endif instance Eq (Shape Z a) where (==) _ _ = True instance (Eq a,Eq (Shape s a))=> Eq (Shape (S s) a ) where (==) (a:* as) (b:* bs) = (a == b) && (as == bs ) instance Show (Shape Z a) where show _ = "Nil" instance (Show a, Show (Shape s a))=> Show (Shape (S s) a) where show (a:* as) = show a ++ " :* " ++ show as -- at some point also try data model that -- has layout be dynamicly reified, but for now -- keep it phantom typed for sanity / forcing static dispatch. -- NB: may need to make it more general at some future point --data Strided r a lay = Strided { getStrides :: Shape r a } {-# INLINE reverseShape #-} reverseShape :: Shape n a -> Shape n a reverseShape Nil = Nil reverseShape list = go SZero Nil list where go :: SNat n1 -> Shape n1 a-> Shape n2 a -> Shape (n1 + n2) a go snat acc Nil = gcastWith (plus_id_r snat) acc go snat acc (h :* (t :: Shape n3 a)) = gcastWith (plus_succ_r snat (Proxy :: Proxy n3)) (go (SSucc snat) (h :* acc) t) instance Fun.Functor (Shape Z) where fmap = \ _ Nil -> Nil --{-# INLINE fmap #-} instance (Fun.Functor (Shape r)) => Fun.Functor (Shape (S r)) where fmap = \ f (a :* rest) -> f a :* Fun.fmap f rest --{-# INLINE fmap #-} instance A.Applicative (Shape Z) where pure = \ _ -> Nil --{-# INLINE pure #-} (<*>) = \ _ _ -> Nil --{-# INLINE (<*>) #-} instance A.Applicative (Shape r)=> A.Applicative (Shape (S r)) where pure = \ a -> a :* (A.pure a) --{-# INLINE pure #-} (<*>) = \ (f:* fs) (a :* as) -> f a :* (inline (A.<*>)) fs as --{-# INLINE (<*>) #-} instance F.Foldable (Shape Z) where foldMap = \ _ _ -> M.mempty --{-# fold #-} foldl = \ _ init _ -> init foldr = \ _ init _ -> init foldr' = \_ !init _ -> init foldl' = \_ !init _ -> init instance (F.Foldable (Shape r)) => F.Foldable (Shape (S r)) where foldMap = \f (a:* as) -> f a M.<> F.foldMap f as foldl' = \f !init (a :* as) -> let next = f init a in next `seq` F.foldl f next as foldr' = \f !init (a :* as ) -> f a $! F.foldr f init as foldl = \f init (a :* as) -> let next = f init a in F.foldl f next as foldr = \f init (a :* as ) -> f a $ F.foldr f init as -- map2 :: (A.Applicative (Shape r))=> (a->b ->c) -> (Shape r a) -> (Shape r b) -> (Shape r c ) map2 = \f l r -> A.pure f A.<*> l A.<*> r {-# SPECIALIZE map2 :: (a->b->c)-> (Shape Z a )-> Shape Z b -> Shape Z c #-} {-# SPECIALIZE map2 :: (a->b->c)-> (Shape (S Z) a )-> Shape (S Z) b -> Shape (S Z) c #-} {-# SPECIALIZE map2 :: (a->b->c)-> (Shape (S (S Z)) a )-> Shape (S (S Z)) b -> Shape (S (S Z)) c #-} {-# SPECIALIZE map2 :: (a->b->c)-> (Shape (S (S(S Z))) a )-> Shape (S (S (S Z))) b -> Shape (S (S(S Z))) c #-} -- {-# INLINABLE map2 #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 19:09:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 19:09:38 -0000 Subject: [GHC] #8741: `System.Directory.getPermissions` fails on read-only filesystem In-Reply-To: <042.41e003931db44554a93be772501d4d70@haskell.org> References: <042.41e003931db44554a93be772501d4d70@haskell.org> Message-ID: <057.235b1856fd802c27c00bdb7270c8981a@haskell.org> #8741: `System.Directory.getPermissions` fails on read-only filesystem -------------------------------------+------------------------------------- Reporter: hvr | Owner: AlainODea Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: libraries/unix | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by duncan): Replying to [comment:8 AlainODea]: > Quick curiousity: why is this merged to 7.8 instead of a bugfix on 7.6.3? I don't think there's any plan for another 7.6.x release (so no HP either), so there's not a lot of value in doing the extra work to backport it. If it's a particular problem for you and you can patch it then go ahead, it's perfectly reasonable to do so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 19:19:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 19:19:51 -0000 Subject: [GHC] #8741: `System.Directory.getPermissions` fails on read-only filesystem In-Reply-To: <042.41e003931db44554a93be772501d4d70@haskell.org> References: <042.41e003931db44554a93be772501d4d70@haskell.org> Message-ID: <057.59761beb5e67553dfc0b208869fa2ceb@haskell.org> #8741: `System.Directory.getPermissions` fails on read-only filesystem -------------------------------------+------------------------------------- Reporter: hvr | Owner: AlainODea Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: libraries/unix | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by AlainODea): Replying to [comment:9 duncan]: > Replying to [comment:8 AlainODea]: > > Quick curiousity: why is this merged to 7.8 instead of a bugfix on 7.6.3? > > I don't think there's any plan for another 7.6.x release (so no HP either), so there's not a lot of value in doing the extra work to backport it. If it's a particular problem for you and you can patch it then go ahead, it's perfectly reasonable to do so. That makes sense. I'll patch manually. A new Haskell Platform is likely on deck with 7.8 nearing release now anyway so I'll focus my effort on making sure that works on SmartOS instead :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 19:45:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 19:45:02 -0000 Subject: [GHC] #8847: Int64 ^ Int64 broken by optimization on SPARC In-Reply-To: <046.255c7bf5dd7528953840f835ce810cc7@haskell.org> References: <046.255c7bf5dd7528953840f835ce810cc7@haskell.org> Message-ID: <061.386642e4cec1861608c4f11f14c7ea85@haskell.org> #8847: Int64 ^ Int64 broken by optimization on SPARC ------------------------------------------------+-------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: Resolution: | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: Incorrect result at runtime | Difficulty: Test Case: | Unknown Blocking: 8816 | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by kgardas): {{{ main = print ( 2 ^ 5 :: Int64 ) }}} runs fine and returns correct result. The problem is with optimization of {{{2 ^ X, X > 5}}}. Also I've though the problem may be with a call to ghc-prim hs_timesInt64, but this call is also presented and used in {{{2 ^ 5}}} optimized version, so this does not seems like a culprit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 20:20:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 20:20:52 -0000 Subject: [GHC] #8831: Cannot use Template Haskell splice in ghci In-Reply-To: <047.1688ea3628125d840e5d96b182466527@haskell.org> References: <047.1688ea3628125d840e5d96b182466527@haskell.org> Message-ID: <062.226d6cbd1c2471d8320e917547b2d61e@haskell.org> #8831: Cannot use Template Haskell splice in ghci -------------------------------------+---------------------------------- Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by thoughtpolice): * owner: => thoughtpolice Comment: I'm also extremely surprised a test didn't seem to catch this. I'm looking into it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 20:31:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 20:31:41 -0000 Subject: [GHC] #8844: Pseudo terminal and process-1.2.0.0 In-Reply-To: <049.4e9c2e6d1c0aa3bbcf4607dd7d51c8fd@haskell.org> References: <049.4e9c2e6d1c0aa3bbcf4607dd7d51c8fd@haskell.org> Message-ID: <064.eae2f7522abf506bf2af08461b5760bc@haskell.org> #8844: Pseudo terminal and process-1.2.0.0 --------------------------------------+------------------------------------ Reporter: ksamborski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 7.6.3 Resolution: | Keywords: pty Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Old description: > Hello, > > I'm writing simple app which execute process and communicate with it > via pseudo terminal. Here is some sample code: > > import System.Posix.Terminal > import System.Process > > main = do > (master, slave) <- openPseudoTerminal > hslave <- fdToHandle slave > hSetBuffering hslave NoBuffering > (_,_,_,ph) <- createProcess (shell "mc"){ env = Just [("TERM", > "xterm")] > , std_in = UseHandle hslave > , std_out = UseHandle hslave > , std_err = UseHandle hslave > , close_fds = True > } > forkIO $ readTerm master -- my function which reads output from process > waitForProcess ph > > The problem is that mc still wants some input from stdin but not > from slave terminal. > But when I changed function runIteractiveProcess from runProcess.c like > this: > > ... > /* Reset the SIGINT/SIGQUIT signal handlers in the child, if > requested > */ > if (reset_int_quit_handlers) { > struct sigaction dfl; > (void)sigemptyset(&dfl.sa_ > mask); > dfl.sa_flags = 0; > dfl.sa_handler = SIG_DFL; > (void)sigaction(SIGINT, &dfl, NULL); > (void)sigaction(SIGQUIT, &dfl, NULL); > } > > /********************************************************************************/ > setsid(); //Make the current process a new session leader > ioctl(0, TIOCSCTTY, 1); //As the child is a session leader, > set the controlling terminal to be the slave side of the PTY > /********************************************************************************/ > /* the child */ > if (environment) { > // XXX Check result > execvpe(args[0], args, environment); > } else { > // XXX Check result > execvp(args[0], args); > } > > childFailed(forkCommunicationFds[1], forkExecFailed); > ... > > it worked as expected, I'm not proposing patch or solution but is there > any chance to add support for pseudo terminals in the process library? > Maybe just add another record field in CreateProcess like pty :: Bool and > then call these two additional instructions in runIteractiveProcess? > > Best regards, > Karol Samborski New description: Hello, I'm writing simple app which execute process and communicate with it via pseudo terminal. Here is some sample code: {{{#!haskell import System.Posix.Terminal import System.Process main = do (master, slave) <- openPseudoTerminal hslave <- fdToHandle slave hSetBuffering hslave NoBuffering (_,_,_,ph) <- createProcess (shell "mc"){ env = Just [("TERM", "xterm")] , std_in = UseHandle hslave , std_out = UseHandle hslave , std_err = UseHandle hslave , close_fds = True } forkIO $ readTerm master -- my function which reads output from process waitForProcess ph }}} The problem is that mc still wants some input from stdin but not from slave terminal. But when I changed function `runIteractiveProcess` from `runProcess.c` like this: {{{#!c ... /* Reset the SIGINT/SIGQUIT signal handlers in the child, if requested */ if (reset_int_quit_handlers) { struct sigaction dfl; (void)sigemptyset(&dfl.sa_ mask); dfl.sa_flags = 0; dfl.sa_handler = SIG_DFL; (void)sigaction(SIGINT, &dfl, NULL); (void)sigaction(SIGQUIT, &dfl, NULL); } /********************************************************************************/ setsid(); //Make the current process a new session leader ioctl(0, TIOCSCTTY, 1); //As the child is a session leader, set the controlling terminal to be the slave side of the PTY /********************************************************************************/ /* the child */ if (environment) { // XXX Check result execvpe(args[0], args, environment); } else { // XXX Check result execvp(args[0], args); } childFailed(forkCommunicationFds[1], forkExecFailed); ... }}} it worked as expected, I'm not proposing patch or solution but is there any chance to add support for pseudo terminals in the process library? Maybe just add another record field in `CreateProcess` like `pty :: Bool` and then call these two additional instructions in `runIteractiveProcess`? Best regards, Karol Samborski -- Comment (by hvr): improved wiki markup of description -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 20:36:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 20:36:25 -0000 Subject: [GHC] #8849: Unregisterised compiler: arithmetic failure Message-ID: <047.9ee4d36bdad2511c808fcc03f7b6b140@haskell.org> #8849: Unregisterised compiler: arithmetic failure --------------------------+------------------------------------------------ Reporter: | Owner: trommler | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.1-rc2 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Incorrect result at runtime Keywords: | Test Case: arith005 Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: #8819 | --------------------------+------------------------------------------------ Compiling the following with RC2 on powerpc 64 downloaded from haskell.org: {{{ main = putStr $ show (-1.0000000001 :: Double) }}} Setting {{{-O}}} yields: {{{ 0.0 }}} Without optimization the correct result is displayed. I prepared an unregisterised compiler on amd64 and see the same issue and more arithmetic tests fail in testsuite. In fact I took the above from arith005. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 20:37:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 20:37:36 -0000 Subject: [GHC] #8849: Unregisterised compiler: arithmetic failure In-Reply-To: <047.9ee4d36bdad2511c808fcc03f7b6b140@haskell.org> References: <047.9ee4d36bdad2511c808fcc03f7b6b140@haskell.org> Message-ID: <062.6c095c1746b91b36383b5baec0b1c408@haskell.org> #8849: Unregisterised compiler: arithmetic failure ------------------------------------------------+-------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: arith005 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: #8819 ------------------------------------------------+-------------------------- Changes (by trommler): * os: Unknown/Multiple => Linux Comment: I should add I ran the tests on Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 20:48:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 20:48:52 -0000 Subject: [GHC] #8820: 7.8 RC1 unregisterised fails selfbootstrap on 64 bit Linux In-Reply-To: <047.c9cafcbd66749475d94d7cc187f50c16@haskell.org> References: <047.c9cafcbd66749475d94d7cc187f50c16@haskell.org> Message-ID: <062.67e67454c21dcf178f1294f5ed97f99d@haskell.org> #8820: 7.8 RC1 unregisterised fails selfbootstrap on 64 bit Linux ----------------------------------------+---------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8819 ----------------------------------------+---------------------------------- Changes (by trommler): * status: new => closed * resolution: => fixed Comment: This seems to be fixed in the official RC2. Selfbootstrap, however, fails now at a later step. I will close this ticket and file a new ticket against RC2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 4 23:51:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Mar 2014 23:51:46 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.db0f84102c6103eb731ba4c70c4e56e3@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonpj): * cc: jstolarek (added) Comment: Jan might you look at this? It seems to be in the general area you were working in. Yell if you can't. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 5 06:21:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Mar 2014 06:21:14 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.30f3aa2607058f8e1316d0f47cafb0e6@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8763 --------------------------------------------+------------------------------ Comment (by bos): I wrote a [https://github.com/bos/attoparsec/commit/b9a21b8e265949ec2d9541409b0a252aad3f638a workaround for this problem] that makes this particular performance regression vanish. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 5 07:31:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Mar 2014 07:31:03 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.79452f583c706c31e754288671868db7@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by jstolarek): Sorry Simon, but I don't have enough time to look into this one. I'm working on #8707 at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 5 09:57:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Mar 2014 09:57:45 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.c95b251a06ddac5a8893b3d5f79ea699@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Sorry, me again. On one of my development machines, I get {{{ Compile failed (status 256) errors were: [1 of 1] Compiling T8124 ( T8124.hs, T8124.o ) Linking T8124 ... Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. /usr/bin/ld: T8124_c.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5' /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status *** unexpected failure for T8124(normal) }}} Any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 5 10:32:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Mar 2014 10:32:16 -0000 Subject: [GHC] #8850: (Compositional) function mkWeakChan Message-ID: <045.3d3ee9b3fbd2ed27796cea6f43168286@haskell.org> #8850: (Compositional) function mkWeakChan ------------------------------------+------------------------------------- Reporter: bholst | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7285 | ------------------------------------+------------------------------------- Following the existing functions mkWeakIORef and mkWeakMVar, I'd like to have a function mkWeakChan with the following type signature, similar to that of mkWeakMVar requested by ticket #7285: {{{ mkWeakChan :: Chan a -> v -> Maybe (IO ()) -> IO (Weak v) }}} The implementation of '''Chan''' is private, so it is not easily possible to implement it yourself. The implementation of both functions may look like the following: {{{ mkWeakMVar :: MVar a -> v -> Maybe (IO ()) -> IO (Weak v) mkWeakMVar (MVar m#) v (Just f) = IO $ \s -> case mkWeak# m# v f s of (# s1, w #) -> (# s1, Weak w #) mkWeakMVar (MVar m#) v Nothing = IO $ \s -> case mkWeakNoFinalizer# m# v s of { (# s1, w #) -> (# s1, Weak w #) } mkWeakChan :: Chan a -> v -> Maybe (IO ()) -> IO (Weak v) mkWeakChan c@(Chan readVar writeVar) v f = do _ <- mkWeakMVar readVar writeVar Nothing mkWeakMVar writeVar v f }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 5 12:40:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Mar 2014 12:40:37 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.71a2fa96d335dd761b2c9e36c13f6fc8@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): Could you try adding `-optl-lpthread` after `-no-hs-main` and see if that helps? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 5 12:56:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Mar 2014 12:56:58 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.17afd449b9a58b7da45d81e702be02cf@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): No, doesn?t help, sorry. Note that it does succeeds in the `threaded` ways: {{{ ====> Scanning ./all.T =====> T8124(normal) 47 of 48 [0, 0, 0] cd . && $MAKE -s --no-print-directory T8124_setup cd . && '/data1/breitner/ghc/ghc-T7994/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o T8124 T8124.hs T8124_c.c -no-hs-main -optl- lpthread >T8124.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 1] Compiling T8124 ( T8124.hs, T8124.o ) Linking T8124 ... Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. /usr/bin/ld: T8124_c.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5' /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status *** unexpected failure for T8124(normal) =====> T8124(hpc) 47 of 48 [0, 1, 0] cd . && $MAKE -s --no-print-directory T8124_setup cd . && '/data1/breitner/ghc/ghc-T7994/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o T8124 T8124.hs -O -fhpc -hpcdir .hpc.T8124 T8124_c.c -no-hs-main -optl-lpthread >T8124.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 1] Compiling T8124 ( T8124.hs, T8124.o ) Linking T8124 ... Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. /usr/bin/ld: T8124_c.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5' /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status *** unexpected failure for T8124(hpc) =====> T8124(optasm) 47 of 48 [0, 2, 0] cd . && $MAKE -s --no-print-directory T8124_setup cd . && '/data1/breitner/ghc/ghc-T7994/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o T8124 T8124.hs -O -fasm T8124_c.c -no-hs- main -optl-lpthread >T8124.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 1] Compiling T8124 ( T8124.hs, T8124.o ) Linking T8124 ... Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. /usr/bin/ld: T8124_c.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5' /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status *** unexpected failure for T8124(optasm) =====> T8124(threaded1) 47 of 48 [0, 3, 0] cd . && $MAKE -s --no-print-directory T8124_setup cd . && '/data1/breitner/ghc/ghc-T7994/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o T8124 T8124.hs -threaded -debug T8124_c.c -no-hs-main -optl-lpthread >T8124.comp.stderr 2>&1 cd . && ./T8124 T8124.run.stdout 2>T8124.run.stderr =====> T8124(threaded2) 47 of 48 [0, 3, 0] cd . && $MAKE -s --no-print-directory T8124_setup cd . && '/data1/breitner/ghc/ghc-T7994/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o T8124 T8124.hs -O -threaded -eventlog T8124_c.c -no-hs-main -optl-lpthread >T8124.comp.stderr 2>&1 cd . && ./T8124 +RTS -N2 -ls -RTS T8124.run.stdout 2>T8124.run.stderr =====> T8124(dyn) 47 of 48 [0, 3, 0] cd . && $MAKE -s --no-print-directory T8124_setup cd . && '/data1/breitner/ghc/ghc-T7994/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o T8124 T8124.hs -O -dynamic T8124_c.c -no-hs- main -optl-lpthread >T8124.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 1] Compiling T8124 ( T8124.hs, T8124.o ) Linking T8124 ... Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. /usr/bin/ld: T8124_c.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5' /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status *** unexpected failure for T8124(dyn) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 5 13:30:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Mar 2014 13:30:36 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.d0734ed9878fac9b103334123911324f@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by bernalex): The patch is available here: . I did not add build.mk either. I posted my architecture in comment 20: : {{{ https://ghc.haskell.org/trac/ghc/ticket/8374#comment:20 }}} Here's the head of my make output: {{{ make -C ../.. all_libraries/base make[1]: Entering directory `/home/alexander/git/ghc2' ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[2]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[2]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all_libraries/base "rm" -f libraries/base/dist-install/build/.depend-v-p-dyn.haskell.tmp }}} I have uploaded the entire build log for you at: . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 5 13:47:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Mar 2014 13:47:41 -0000 Subject: [GHC] #8835: 7.6.3 vs 7.8-RC performance regression In-Reply-To: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> References: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> Message-ID: <059.6a05f4fc04a607cf3bd5955f85b21466@haskell.org> #8835: 7.6.3 vs 7.8-RC performance regression --------------------------------------------+------------------------------ Reporter: cbm80 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by cbm80): * status: new => closed * resolution: => fixed Comment: The bug was in `attoparsec` and has been fixed in the latest release `0.11.2.1` For reference see: https://github.com/bos/attoparsec/issues/56 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 5 14:05:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Mar 2014 14:05:29 -0000 Subject: [GHC] #8835: 7.6.3 vs 7.8-RC performance regression In-Reply-To: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> References: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> Message-ID: <059.8b0ed7075c08cbe11d78aeb32f24ab64@haskell.org> #8835: 7.6.3 vs 7.8-RC performance regression --------------------------------------------+------------------------------ Reporter: cbm80 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by tibbe): * status: closed => new * resolution: fixed => Comment: I don't think it's a bug in attoparsec. bos did add a workaround (removing an INLINE), but I think it's a bug in the GHC. I don't expect a order-of- magnitude performance regression in a release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 5 14:27:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Mar 2014 14:27:27 -0000 Subject: [GHC] #8835: 7.6.3 vs 7.8-RC performance regression In-Reply-To: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> References: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> Message-ID: <059.d48360bf3cfa693f0f501a397d3ace26@haskell.org> #8835: 7.6.3 vs 7.8-RC performance regression --------------------------------------------+------------------------------ Reporter: cbm80 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8814 --------------------------------------------+------------------------------ Changes (by cbm80): * related: => #8814 Comment: I agree that it is something in the GHC. This bug and #8814 are the same however, and should be merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 5 19:29:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Mar 2014 19:29:03 -0000 Subject: [GHC] #8846: GHC panic with Template Haskell In-Reply-To: <046.7d0bb7e81eb2370f95f549b02e4f17bb@haskell.org> References: <046.7d0bb7e81eb2370f95f549b02e4f17bb@haskell.org> Message-ID: <061.ae9775b69e45c28a1b299ead269e63a8@haskell.org> #8846: GHC panic with Template Haskell ---------------------------------------+---------------------------------- Reporter: Gothmog | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: This is fixed in the 7.8 release candidate (but I was able to reproduce for 7.6.3). Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 5 21:10:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Mar 2014 21:10:33 -0000 Subject: [GHC] #8849: Unregisterised compiler: arithmetic failure In-Reply-To: <047.9ee4d36bdad2511c808fcc03f7b6b140@haskell.org> References: <047.9ee4d36bdad2511c808fcc03f7b6b140@haskell.org> Message-ID: <062.6d434d1cc7ff2e7601887fe24744c940@haskell.org> #8849: Unregisterised compiler: arithmetic failure ------------------------------------------------+-------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: arith005 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: #8819 ------------------------------------------------+-------------------------- Comment (by trommler): I produced the attached files on my amd64 machine. In line 26 of mini.hc (with {{{-O}}} optimization) we see a constant {{{0.0}}} whereas line 32 in mini-noopt.hc there is {{{1.0000000001}}} and a call to {{{GHC.Num.negate}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 5 21:32:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Mar 2014 21:32:25 -0000 Subject: [GHC] #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) In-Reply-To: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> References: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> Message-ID: <068.b16bed9e496184a2454d66f973ba6eba@haskell.org> #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ---------------------------------------+---------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by dmbergey): I'm encountering the same error. I'm running debian sid. * ghc-7.8.1-rc2 * gcc-4.8.2-2 * binutils 2.24-3 Let me know if there's anything else I can do to help diagnose this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 5 21:32:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Mar 2014 21:32:40 -0000 Subject: [GHC] #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) In-Reply-To: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> References: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> Message-ID: <068.5a44d6804c01b4249ec0997545c19bd3@haskell.org> #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ---------------------------------------+---------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by dmbergey): * version: 7.8.1-rc1 => 7.8.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 5 22:52:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Mar 2014 22:52:02 -0000 Subject: [GHC] #8024: Dynamic linking not working on PowerPC Linux. In-Reply-To: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> References: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> Message-ID: <059.696138205228d10fbc6cb8e0a2f8c2c7@haskell.org> #8024: Dynamic linking not working on PowerPC Linux. ----------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by erikd): In mk/config.mk.in tried changing {{{ PIC = pic }}} to {{{ PIC = PIC }}} ran the whole process from `perl boot` onwards and that didn't help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 09:14:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 09:14:10 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.73b9b6fca56dd7482fa4ac0d2bfebcf3@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8763 --------------------------------------------+------------------------------ Comment (by simonpj): We're a bit stalled here. There is something mysterious going on, which a single INLINE pragma (Bryan's patch) fixes. But why? My guess is that it's something to do with the interaction between inlning and attoparsec's RULES. For example if a rule optimises `(f (g x))`, and `g` gets inlined, the rule won't fire. Or, if {{{ h x = f x + 1 }}} then the expression `h (g x)` won't fire the rule unless `h` is first inlined. The "phase" annotations on INLINE pragmas and RULES let you control this stuff. So the bug might not be in GHC; it might just be a missing phase annotation. Or there might be a bug in GHC. We won't know until someone digs further. Apart from lack of time, the difficulty is that I have no clue how attoparsec's RULES are supposed to work. So I think we are stalled unless/until someone feels able to do some digging to isolate what is going on. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 09:19:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 09:19:27 -0000 Subject: [GHC] #8835: 7.6.3 vs 7.8-RC performance regression In-Reply-To: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> References: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> Message-ID: <059.a49d6f72742b006f6977f5e47e38790a@haskell.org> #8835: 7.6.3 vs 7.8-RC performance regression --------------------------------------------+------------------------------ Reporter: cbm80 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8814 --------------------------------------------+------------------------------ Comment (by simonpj): Are you sure that this bug is the same as #8814? When I look at the git repo in the Description at the top, the cabal file doesn't mention attoparsec. Can anyone take the time to find out why the performance differs so much, and to boil out a test case? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 09:52:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 09:52:16 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently Message-ID: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> #8851: Standalone deriving and GND behave differently ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Sergey Tromimovich writes: Trying to build random packages with fresh ghc-7.8.1-rc2 I've come up with a strange bit: https://github.com/trofi/Idris- dev/commit/9f93122ba1aa075c2fa1555fea68a6c403697e04 Is it an intended behaviour that standalone deriving (A) {{{ deriving instance Parsing IdrisInnerParser }}} is capable of doing more, than a deriving clause (B) {{{ newtype IdrisInnerParser a = IdrisInnerParser { runInnerParser :: Parser a } deriving (Parsing) }}} where the class is defined thus {{{ class Alternative m => Parsing m where .... notFollowedBy :: (Monad m, Show a) => m a -> m () notFollowedBy p = try ((try p >>= unexpected . show) <|> pure ()) }}} The error message from the (B) is {{{ [50 of 75] Compiling Idris.ParseHelpers ( src/Idris/ParseHelpers.hs, dist/build/Idris/ParseHelpers.o ) src/Idris/ParseHelpers.hs:40:97: Could not coerce from ?Monad Parser? to ?Monad IdrisInnerParser? because the first type argument of ?Monad? has role Nominal, but the arguments ?Parser? and ?IdrisInnerParser? differ arising from the coercion of the method ?notFollowedBy? from type ?forall a. (Monad Parser, Show a) => Parser a -> Parser ()? to type ?forall a. (Monad IdrisInnerParser, Show a) => IdrisInnerParser a -> IdrisInnerParser ()? Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Parsing IdrisInnerParser) }}} Answer: no they should not behave differently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 10:18:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 10:18:33 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.91536b0f2e24408c8477e4adda8f9644@haskell.org> #8851: Standalone deriving and GND behave differently --------------------------------------------+------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * cc: mail@? (added) * version: 7.6.3 => 7.8.1-rc1 * component: Compiler => Compiler (Type checker) Comment: I?m trying to wrap my head around which of the two behaviours is correct. Richard, can you enlighten me? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 10:28:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 10:28:52 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.cf73880f336d830b1637efe46a3e8069@haskell.org> #8851: Standalone deriving and GND behave differently --------------------------------------------+------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): To me rejection (B) looks right. After all, is it safe to coerce between `(Monad Parser)` to `(Monad InnerIdrisParser)`? They might have very different instances. See Section 3.4 of the [http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/ Safe Coercions paper]. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 10:31:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 10:31:21 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.9ad4f68bd0ccef2b38f68058451f0e42@haskell.org> #8851: Standalone deriving and GND behave differently --------------------------------------------+------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): That?s my gut feeling as well. But what if the type checker resolves the constraints in `forall a. (Monad IdrisInnerParser, Show a) => IdrisInnerParser a -> IdrisInnerParser ()?` before coerce is being called, so that it would only have to coerce `forall a. (Show a) => IdrisInnerParser a -> IdrisInnerParser ()?, and that would be fine. This is probably what is happening in case (A) (otherwise the result would not role-type-check). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 11:11:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 11:11:07 -0000 Subject: [GHC] #8569: ASSERT in testcase type-rep, only in some ways: In-Reply-To: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> References: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> Message-ID: <061.393ba634dae3bb9c3a050b5e3210fdd1@haskell.org> #8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 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 simonpj): * status: closed => new * resolution: wontfix => Comment: I?m seeing this assertion failure when using the stage1 compiler (built with ?DDEBUG) to compile the stage2 compiler. {{{ ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 7.9.20140227 for i386-unknown-mingw32): ASSERT failed! file compiler\basicTypes\Demand.lhs line 445 3 [U] }}} Turns out that it's another instance of this ticket, but now the bug is now biting GHC itself! However the `type-rep` test is a much easier version to debug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 12:09:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 12:09:47 -0000 Subject: [GHC] #8841: PatternSynonyms error gives wrong source locations In-Reply-To: <051.266a2b6688dc36204387024e5fd153b2@haskell.org> References: <051.266a2b6688dc36204387024e5fd153b2@haskell.org> Message-ID: <066.ce1fabcb44c88648c09f7d1c20033c6e@haskell.org> #8841: PatternSynonyms error gives wrong source locations -------------------------------------------------+------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect warning at | PatternSynonyms compile-time | Architecture: x86 Test Case: patsyn/unidir | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * testcase: => patsyn/unidir -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 12:17:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 12:17:13 -0000 Subject: [GHC] #8569: ASSERT in testcase type-rep, only in some ways: In-Reply-To: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> References: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> Message-ID: <061.4fc02eab473d50a6d096a61758f748ee@haskell.org> #8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"4b355cd21a190e3d2c2d3a830ba2337d1c442dfe/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4b355cd21a190e3d2c2d3a830ba2337d1c442dfe" Make the demand on a binder compatible with type (fixes Trac #8569) Because of GADTs and casts we were getting binders whose demand annotation was more deeply nested than made sense for its type. See Note [Trimming a demand to a type], in Demand.lhs, which I reproduce here: Note [Trimming a demand to a type] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider this: f :: a -> Bool f x = case ... of A g1 -> case (x |> g1) of (p,q) -> ... B -> error "urk" where A,B are the constructors of a GADT. We'll get a U(U,U) demand on x from the A branch, but that's a stupid demand for x itself, which has type 'a'. Indeed we get ASSERTs going off (notably in splitUseProdDmd, Trac #8569). Bottom line: we really don't want to have a binder whose demand is more deeply-nested than its type. There are various ways to tackle this. When processing (x |> g1), we could "trim" the incoming demand U(U,U) to match x's type. But I'm currently doing so just at the moment when we pin a demand on a binder, in DmdAnal.findBndrDmd. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 12:17:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 12:17:15 -0000 Subject: [GHC] #8841: PatternSynonyms error gives wrong source locations In-Reply-To: <051.266a2b6688dc36204387024e5fd153b2@haskell.org> References: <051.266a2b6688dc36204387024e5fd153b2@haskell.org> Message-ID: <066.4fdebe81736933af26191622e28e4880@haskell.org> #8841: PatternSynonyms error gives wrong source locations -------------------------------------------------+------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect warning at | PatternSynonyms compile-time | Architecture: x86 Test Case: patsyn/unidir | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones ): In [changeset:"bf9bf602399eca30ca522ae5bae52d4f3ec1ab88/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bf9bf602399eca30ca522ae5bae52d4f3ec1ab88" Test for Trac #8841 now works }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 12:17:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 12:17:14 -0000 Subject: [GHC] #8841: PatternSynonyms error gives wrong source locations In-Reply-To: <051.266a2b6688dc36204387024e5fd153b2@haskell.org> References: <051.266a2b6688dc36204387024e5fd153b2@haskell.org> Message-ID: <066.c05ac68ceb5e1ade30bd648f4621a830@haskell.org> #8841: PatternSynonyms error gives wrong source locations -------------------------------------------------+------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect warning at | PatternSynonyms compile-time | Architecture: x86 Test Case: patsyn/unidir | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones ): In [changeset:"96daafc3305a691590b88c1175a8f45e5d327471/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="96daafc3305a691590b88c1175a8f45e5d327471" Attach the right location to pattern synonym error message (fixes Trac #8841) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 12:17:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 12:17:17 -0000 Subject: [GHC] #8569: ASSERT in testcase type-rep, only in some ways: In-Reply-To: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> References: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> Message-ID: <061.c509963dd74766398f4cfd7fc1a99cc7@haskell.org> #8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"7fa6c67bcc9970ce2fa4b3f3a7f17042b9b4fd0e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7fa6c67bcc9970ce2fa4b3f3a7f17042b9b4fd0e" Trac #8569 fixed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 12:24:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 12:24:07 -0000 Subject: [GHC] #8569: ASSERT in testcase type-rep, only in some ways: In-Reply-To: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> References: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> Message-ID: <061.8699c5f93ff306e8d9017d5ebfa41ead@haskell.org> #8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: gadt/type-rep | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * testcase: => gadt/type-rep * resolution: => fixed Comment: OK I think I've fixed this. Should we merge the change to 7.8 branch? Perhaps not unless it actually bites someone. The trouble it that "bite" has only shown up so far as an ASSERT failure, and I'm not 100% sure that it won't have some other bad consequence if the assert is omitted and we proceed regardless. But nothing has so far. So I'll close for now. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 12:24:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 12:24:29 -0000 Subject: [GHC] #8841: PatternSynonyms error gives wrong source locations In-Reply-To: <051.266a2b6688dc36204387024e5fd153b2@haskell.org> References: <051.266a2b6688dc36204387024e5fd153b2@haskell.org> Message-ID: <066.c85d32a70e78578b61336da784b2ef7a@haskell.org> #8841: PatternSynonyms error gives wrong source locations -------------------------------------------------+------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: low | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect warning at | PatternSynonyms compile-time | Architecture: x86 Test Case: patsyn/unidir | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => merge Comment: Easy fix, happily. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 12:30:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 12:30:39 -0000 Subject: [GHC] #8835: 7.6.3 vs 7.8-RC performance regression In-Reply-To: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> References: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> Message-ID: <059.21b827252bf1535aeadf216cbf8522af@haskell.org> #8835: 7.6.3 vs 7.8-RC performance regression --------------------------------------------+------------------------------ Reporter: cbm80 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8814 --------------------------------------------+------------------------------ Comment (by cbm80): In my code I'm using xml-conduit for parsing, which has a dependency on attoparsec. Also the workaround bos made fixed not only the GC behavior, but also memory consumption is again what is was in 7.6.3. So yes, I think it is indeed the same bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 14:14:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 14:14:33 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.f765ebf7affe40eb19ad2e1de695872c@haskell.org> #8851: Standalone deriving and GND behave differently --------------------------------------------+------------------------------ Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by goldfire): * owner: => goldfire Comment: I took a briefish look at this yesterday and am somewhat confused, but I'll take a closer look and submit a fix in the next few days. I actually think acceptance is correct because of Joachim's (nomeata's) reasoning. It is indeed unsafe to convert a ''dictionary'' for `Monad Parser` to a ''dictionary'' for `Monad InnerIdrisParser`. But, the `notFollowedBy` function takes this dictionary as a parameter, and so coherence is somehow not an issue. Even as I'm writing this, I don't fully believe it, but my hunch is still that "accept" is the right answer. I'll elaborate more when I can put some more consecutive cycles into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 14:45:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 14:45:32 -0000 Subject: [GHC] #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) In-Reply-To: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> References: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> Message-ID: <068.7540390ff92bfcb263ce19cfa47f4f58@haskell.org> #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ---------------------------------------+---------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by octoploid): See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60436 Adding "-nostdinc" to the gcc invocation is a workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 15:23:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 15:23:43 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.040b78a53a7dfe6502c1c45ed86d05c6@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Simon M and I took a look today. We added a few notes to the github thing ?https://github.com/scpmw/ghc/commit/d233ea4da0a5725d4d29a3fb68b9b8f7c9bc6d32 #diff-8b5b79c6cb1af2b387fa2d814cd0d3f6R1638 The major stumbling block is giving a really clear description of what each of the various predicates on ticks means: `tickishScoped`, `tickishSoftScoped`, `tickishCounts`, `tickishIsCode` etc. We might want to rename some of them. Eg `tickisScoped` and `tickishSoftScoped` might be replaced by `canFloatCodeInsideThisTick` and `canFloatCodeOutsideThisTick`, perhaps. Each call site has asks a question about the equivalence of two pieces of code, and the predicates should probably have an example drawn from every call site. That might make the correct generalisation clear. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 16:37:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 16:37:32 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.1e8d882bc65f482b3e652132cabd6e38@haskell.org> #8851: Standalone deriving and GND behave differently --------------------------------------------+------------------------------ Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Aha. Right. Suppose we have {{{ class C r where op :: forall a. theta => op_ty newtype T a = MkT rep_ty deriving( C ) }}} Then the both newtype deriving and standalone deriving should succeed if this will typecheck {{{ instance C rep_ty => C (T a) where op = coerce (op :: op_ty[rep_ty/r] }}} When will this typecheck? Notice that we instantiate `op` (like any other variable occurrence) at its occurrence site, which throws the instantiated `theta` into the constraints to be solved. Answer: when * `Coercible (op_ty[rep_ty/r]) (op_ty[N a/r])` holds * Assuming `C rep_ty` and `theta[T a/r]`, we can prove `theta[rep_ty/r]` In this case, `theta[rep_ty/r]` is simply `Monad IdrisInlineParser` which holds from a top-level instance, not from any of the local "assuming.." parts. So I think the `deriving` mechanism should check this second bullet. I believe that "standalone deriving" is deliberately [http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html #stand-alone-deriving more gung-ho]: it simply generates the boilerplate and tries to typecheck it. The `deriving` clause makes checks up-front so that the generated code is certain to typecheck. We just need to fix those up-front checks. Thanks for looking at this Richard. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 16:50:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 16:50:42 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.ba9d0a7062c41d98b511052683d0eaee@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8763 --------------------------------------------+------------------------------ Comment (by joelteon): I still think this bug is in GHC. It shouldn't take 15GB of RAM to compile a program with a large chain of `<|>`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 16:54:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 16:54:21 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.0a48d4cc6dd9343569ab3a7ffa8715db@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8763 --------------------------------------------+------------------------------ Comment (by simonpj): But this ticket is about the ''run-time'' of the particular program given in the description of this ticket. There may well be another bug, to do with the ''compile-time'' of an entirely different program. If so, could you open a ticket for that, including a way to reproduce? (Having checked that there isn't one already.) It's confusing to mix up two bugs into one ticket! Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 17:29:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 17:29:12 -0000 Subject: [GHC] #8351: Arrays are always allocated out-of-line In-Reply-To: <044.2c5aaa81ba255a3d6b78466b46ee259f@haskell.org> References: <044.2c5aaa81ba255a3d6b78466b46ee259f@haskell.org> Message-ID: <059.b0dfb13759e54447b1bd2e7ea213480b@haskell.org> #8351: Arrays are always allocated out-of-line -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 5925 -------------------------------------+------------------------------------ Changes (by jberryman): * related: => 5925 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 17:34:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 17:34:01 -0000 Subject: [GHC] #5925: Add inline version of newArray# In-Reply-To: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> References: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> Message-ID: <059.3dbcafb8f33f71f82441c6f3129e0aa9@haskell.org> #5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by jberryman): * cc: brandon.m.simmons@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 17:46:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 17:46:00 -0000 Subject: [GHC] #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> Message-ID: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> -------------------------+------------------------------------------------- Reporter: | Owner: joelteon | Status: new Type: bug | Milestone: Priority: | Version: 7.8.1-rc2 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- To reproduce, install a pre-`0.11.2.1` version of attoparsec. This bug was worked around in 0.11.2.1 by removing the `INLINE` on `plus` in attoparsec. With this test program: {{{#!haskell {-# LANGUAGE OverloadedStrings #-} import Control.Applicative import Data.Attoparsec.Text import Data.Text (Text) parser :: Parser Text parser = string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" main :: IO () main = parseTest parser "a" }}} and using GHC 7.8.1.rc2: Compiling using `-O2`, GHC tops out at ~1GB of RAM and takes 25s. Using `-O0`, GHC takes 0.47s and uses <150MB of RAM. Compare this with GHC 7.6.3: Compiling using `-O2`, GHC uses <150MB and takes 3.7s. Memory usage is similar with `-O0` although compile time goes down to 0.36s. An extreme version of this bug can be found in the `thyme` package here: https://github.com/liyang/thyme/blob/master/src/Data/Thyme/Format.hs#L589-L693. Compiling that module with an unfixed attoparsec makes GHC use all available memory and stall out, forcing kill -9. Replacing the function body with `undefined` makes the package compile as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 17:46:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 17:46:26 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.935648d020eb62c1b5ca44ffdd7743e6@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8763 --------------------------------------------+------------------------------ Comment (by joelteon): My apologies. I've created #8852 for the compile-time bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 18:01:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 18:01:04 -0000 Subject: [GHC] #5925: Add inline version of newArray# In-Reply-To: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> References: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> Message-ID: <059.3ec4fdf29e0af913e8fb136251dbfd18@haskell.org> #5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): I've done some work on this branch: [https://github.com/tibbe/ghc/tree /alloc-inline]. I've also attached the changes to this ticket so they don't get lost if I lose the branch. The current status is that I have something that seems to generate the assembly I want, but I haven't managed to write a benchmark that shows any speed-up, even though I've eliminated two branches and one function call, if I recall correctly. So the task at this point is to come up with some good benchmarks. There are essentially two ways to attack that problem. Either we can try to show a speed-up in allocation or we can try to show a speed-up due to the better locality (e.g. constructor wrapping an array can now be allocated next to the array.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 18:15:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 18:15:59 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.315d11d631108679f502f76461d7243c@haskell.org> #8851: Standalone deriving and GND behave differently --------------------------------------------+------------------------------ Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by slyfox): * cc: slyfox@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 19:03:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 19:03:34 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.ef8188fabc0b010b4a5ba20ab7b21ed7@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8763 --------------------------------------------+------------------------------ Comment (by bos): Replying to [comment:11 simonpj]: > We're a bit stalled here. There is something mysterious going on, which a single INLINE pragma (Bryan's patch) fixes. But why? My guess is that it's something to do with the interaction between inlining and attoparsec's RULES. I assume you're referring to text's RULES, as attoparsec doesn't contain any (it does contain a lot of inlining, though). The goal behind the RULES in text is to expose opportunities to perform stream fusion and, if the rewrite phases do not reveal any, to drop from the fusion style of programming back to thwacking directly on an array (which is typically a lot faster). For example, here are the two main RULES that you spotted in the output above: {{{ {-# RULES "TEXT append -> fused" [~1] forall t1 t2. append t1 t2 = unstream (S.append (stream t1) (stream t2)) "TEXT append -> unfused" [1] forall t1 t2. unstream (S.append (stream t1) (stream t2)) = append t1 t2 #-} }}} If we see an unadorned use of `append` in an early phase, we rewrite it so that a fusion rule can have a chance to transform it. Once we get closer to the end of our phases, if we find that a fusion-style append hasn't yet been gobbled up, we transform it back to the direct style. There's a tangential wrinkle here: for the longest time, the definition of `append` had an `INLINE` annotation, [https://github.com/bos/text/commit/109941228d16cc873a08da9924cb881c51be853b which I just removed]. I don't believe this is implicated in the slowdown. Please let me know what else it would be helpful to explain. As you know, forests of rewrite rules are rather fragile affairs, so it's entirely possible that there's been a longstanding bug in those rules (and perhaps ''not in the compiler'') that is merely now being exposed in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 19:41:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 19:41:38 -0000 Subject: [GHC] #8853: Alarming looking warning about non-exhaustive pattern Message-ID: <054.e34ba59485cfdd347886b35308e8a5bc@haskell.org> #8853: Alarming looking warning about non-exhaustive pattern -------------------------+------------------------------------------------- Reporter: | Owner: MikolajKonarski | Status: new Type: bug | Milestone: Priority: | Version: 7.8.1-rc2 normal | Operating System: Linux Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: x86_64 (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- The attached code produces this alarming warning: ~/waste$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228 ~/waste$ ghc -Wall --make AlarmingPattern.hs -fforce-recomp [1 of 1] Compiling Main ( AlarmingPattern.hs, AlarmingPattern.o ) AlarmingPattern.hs:6:7: Warning: Pattern match(es) are non-exhaustive In an equation for ?takeFromInv?: Patterns not matched: (GHC.Types.I# _) (GHC.Types.I# (#x)) with #x `notElem` [0#] Linking AlarmingPattern ... ~/waste$ ./AlarmingPattern AlarmingPattern: AlarmingPattern.hs:(6,7)-(7,26): Non-exhaustive patterns in function takeFromInv -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 20:31:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 20:31:37 -0000 Subject: [GHC] #8854: Missing class method not caught at compile time, program freezes when missing method is called. Message-ID: <051.272b1d0411d3e8c7d535548822314c11@haskell.org> #8854: Missing class method not caught at compile time, program freezes when missing method is called. ----------------------------------+---------------------------------- Reporter: RaminHAL9001 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7633 | ----------------------------------+---------------------------------- I created a type class where two of four functions must be satisfied for a minimal complete definition. GHC did not catch an instance where the minimal complete definition was not satisfied, the program compiled without an error or warning. When running the compiled program it would freeze when calling the missing method. Also when running the program in GHCi and stepping up to the use of the missing method, GHCi would freeze before reaching the missing function. This made it very difficult to debug. It '''did not''' throw a "NoMethodError" exception, and there '''was no''' segment violation caught by the operating system, nor does the program terminate with the "<>" message output on the command line. Compiling with language extensions: {{{ -XTemplateHaskell -XScopedTypeVariables -XRankNTypes -XMultiParamTypeClasses -XFunctionalDependencies -XFlexibleInstances -XFlexibleContexts -XDeriveDataTypeable }}} Using compiler flags: {{{ -prof -fprof-auto -threaded -Wall -fno-warn-name-shadowing -fno-warn- unused-do-bind -fno-warn-auto-orphans }}} '''To Reproduce the Issue''' I tried to reproduce the issue with a miniature program that isolates the problem, but GHC successfully detects a problem and terminates with the "<>" message written on the command line. My program is much larger and simply froze. However the code I wrote looks similar to the following situation... First I tried this, which gave me no problems at all: {{{ class A x where f1 :: x f1 = f2 f2 :: x f2 = f1 }}} We have two functions f1 and f2, if f1 is not defined it defaults to f2, if f2 is not defined it defaults to f1, so you must define either f1 or f2, or you could also define both. Then I add two more methods: {{{ class A x where f1 :: x f1 = f2 f2 :: x f2 = f1 g1 :: x g1 = g2 g2 :: x g2 = g1 }}} Just like with f1 f2, the g1 g2 functions each use their counterpart to define their default method. But this caused a huge problem. The minimal complete definition should be (f1 | f2) & (g1 | g2), but the compiler does not report any warning when I have not satisfied the minimal complete definition. Maybe one of my compiler flags disabled a would-be warning, I don't know yet. This was a red-flag to me, but I went on to test my program. As it turns out, there was a place in my code where I forgot to write an instance for g1 or g2 but I had not realize it. I only found out when I ran my test program and it froze. No "unsatisfied method" exception, not segment violations, it just froze. Although the program was still running and consuming a small amount of CPU resources, and I could cancel with CTRL-C in the command line. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 21:05:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 21:05:29 -0000 Subject: [GHC] #8854: Missing class method not caught at compile time, program freezes when missing method is called. In-Reply-To: <051.272b1d0411d3e8c7d535548822314c11@haskell.org> References: <051.272b1d0411d3e8c7d535548822314c11@haskell.org> Message-ID: <066.ec082c7ef25b2373d9ce866d3c0560cd@haskell.org> #8854: Missing class method not caught at compile time, program freezes when missing method is called. ----------------------------------+---------------------------------- Reporter: RaminHAL9001 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7633 ----------------------------------+---------------------------------- Comment (by simonpj): If you specify the minimal complete definition, using the MINIMAL pragma (which is part of 7.8, but not 7.6) then it should warn. If it doesn't, that's a bug. Can you give the complete source code for a program that exhibits the bug... if we can't reproduce it we can't fix it. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 21:28:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 21:28:01 -0000 Subject: [GHC] #8853: Alarming looking warning about non-exhaustive pattern In-Reply-To: <054.e34ba59485cfdd347886b35308e8a5bc@haskell.org> References: <054.e34ba59485cfdd347886b35308e8a5bc@haskell.org> Message-ID: <069.c2e225949aa454700be3064b98b92be5@haskell.org> #8853: Alarming looking warning about non-exhaustive pattern -------------------------------------------------+------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | x86_64 (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nomeata): Is the bug about the compiler message, or the behaviour at run-time (which looks correct to me)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 21:28:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 21:28:14 -0000 Subject: [GHC] #8854: Missing class method not caught at compile time, program freezes when missing method is called. In-Reply-To: <051.272b1d0411d3e8c7d535548822314c11@haskell.org> References: <051.272b1d0411d3e8c7d535548822314c11@haskell.org> Message-ID: <066.3aed6861c4e5f5432a5e0e11335f214c@haskell.org> #8854: Missing class method not caught at compile time, program freezes when missing method is called. ----------------------------------+---------------------------------- Reporter: RaminHAL9001 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7633 ----------------------------------+---------------------------------- Comment (by RaminHAL9001): My full source code repository is here: https://github.com/RaminHAL9001/dao You can clone the repository and just run "make" on Linux, it should compile fine with GHC 7.6.1. It will produce two executable programs, "./dao" and "./debug/test". In the "Dao.Interpreter" module, there is an instance: {{{ instance HasRandGen [Comment] where { randO = return []; defaultO = return []; } }}} If you remove the "defaultO" instance and re-compile, that should reproduce the bug, This was the exact instance I had not defined that was causing it to freeze. To run the test suite to cause the error to occur, change to the "debug" directory and run the "test" program. It works a bit like QuickCheck, but you can specify random seed values on the command line to produce the same random test cases every time, for example: {{{ ./test 8 14 }}} I found seeds 8 and 14 crashed reliably, both compiled and in GHCi. But I don't know if the random number generator will produce the same test cases on your hardware as it will on mine so you may have to run a few dozen tests before you find one that freezes. {{{ ./test $(seq 1 100) }}} The source code is under active development, so things may change. However for the time being I don't expect there to be any changes to the part of the code that lets you reproduce the bug. I did see the {-# MINIMAL #-} pragma in #7633, but I am using GHC 7.6.1 for now. Replying to [comment:1 simonpj]: > If you specify the minimal complete definition, using the MINIMAL pragma (which is part of 7.8, but not 7.6) then it should warn. If it doesn't, that's a bug. Can you give the complete source code for a program that exhibits the bug... if we can't reproduce it we can't fix it. > > Thanks > > Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 21:31:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 21:31:04 -0000 Subject: [GHC] #8853: Alarming looking warning about non-exhaustive pattern In-Reply-To: <054.e34ba59485cfdd347886b35308e8a5bc@haskell.org> References: <054.e34ba59485cfdd347886b35308e8a5bc@haskell.org> Message-ID: <069.19d5f73b6f7155f261ff266a791850d7@haskell.org> #8853: Alarming looking warning about non-exhaustive pattern -------------------------------------------------+------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | x86_64 (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by MikolajKonarski): Runtime is OK. Probably the message is OK, too (I gave up trying to understand it, though:), just alarming. BTW, sorry for the bad formatting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 21:39:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 21:39:57 -0000 Subject: [GHC] #8854: Missing class method not caught at compile time, program freezes when missing method is called. In-Reply-To: <051.272b1d0411d3e8c7d535548822314c11@haskell.org> References: <051.272b1d0411d3e8c7d535548822314c11@haskell.org> Message-ID: <066.f8b67938e680ff5eec56bfa00b9a48d5@haskell.org> #8854: Missing class method not caught at compile time, program freezes when missing method is called. ----------------------------------+---------------------------------- Reporter: RaminHAL9001 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7633 ----------------------------------+---------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Oh well, that's easy! This situation is precisely what the MINIMAL pragma is for. There is not, and never was, the slightest guarantee that anything else will work. If you get `<>` you are just lucky! It's not a bug in 7.6; it just a feature that doesn't exist, but now does. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 21:49:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 21:49:33 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.fc520e9c41ffe9244d283efc6c0ccf46@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8763 --------------------------------------------+------------------------------ Comment (by simonpj): What would be really helpful would be if you, or someone else, could diagnose exactly why the slow-down is happening. If you compile with `-ticky` you can very quickly zero in on the code that is taking more time, and compare one with the other. It would be remarkable if fusion was really responsible for such an enormous change in time, but perhpas it is. Maybe it would be worth commenting out RULES one at a time, to see which (if any) is responsible, and to reduce accidental differences between the two. Maybe the test case can be boiled down quite a lot further. You can switch off ALL rule rewrites with `-fno-enable-rewrite-rules`. Switching off full laziness might also be a good thing to try `-fno-full- laziness`. Reducing the inlining threshold (which doesn't affect INLINE pragmas) would mean less looking at inlined code. `-funfolding-use-threshold=N` (default is 60) It's a bit fiddly and time consuming, which is why I was appealing for help. I'll gladly explain anything you (or whoever) wants to know about the GHC end of things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 21:52:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 21:52:04 -0000 Subject: [GHC] #8853: Alarming looking warning about non-exhaustive pattern In-Reply-To: <054.e34ba59485cfdd347886b35308e8a5bc@haskell.org> References: <054.e34ba59485cfdd347886b35308e8a5bc@haskell.org> Message-ID: <069.d12f269e157bf844412c13af7abdbd10@haskell.org> #8853: Alarming looking warning about non-exhaustive pattern -------------------------------------------------+------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | x86_64 (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Description changed by ezyang: Old description: > The attached code produces this alarming warning: > > ~/waste$ ghc --version > The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228 > ~/waste$ ghc -Wall --make AlarmingPattern.hs -fforce-recomp > [1 of 1] Compiling Main ( AlarmingPattern.hs, > AlarmingPattern.o ) > > AlarmingPattern.hs:6:7: Warning: > Pattern match(es) are non-exhaustive > In an equation for ?takeFromInv?: > Patterns not matched: > (GHC.Types.I# _) (GHC.Types.I# (#x)) with #x `notElem` [0#] > Linking AlarmingPattern ... > ~/waste$ ./AlarmingPattern > AlarmingPattern: AlarmingPattern.hs:(6,7)-(7,26): Non-exhaustive patterns > in function takeFromInv New description: The attached code produces this alarming warning: {{{ ~/waste$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228 ~/waste$ ghc -Wall --make AlarmingPattern.hs -fforce-recomp [1 of 1] Compiling Main ( AlarmingPattern.hs, AlarmingPattern.o ) AlarmingPattern.hs:6:7: Warning: Pattern match(es) are non-exhaustive In an equation for ?takeFromInv?: Patterns not matched: (GHC.Types.I# _) (GHC.Types.I# (#x)) with #x `notElem` [0#] Linking AlarmingPattern ... ~/waste$ ./AlarmingPattern AlarmingPattern: AlarmingPattern.hs:(6,7)-(7,26): Non-exhaustive patterns in function takeFromInv }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 21:53:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 21:53:09 -0000 Subject: [GHC] #8853: Alarming looking warning about non-exhaustive pattern In-Reply-To: <054.e34ba59485cfdd347886b35308e8a5bc@haskell.org> References: <054.e34ba59485cfdd347886b35308e8a5bc@haskell.org> Message-ID: <069.6162d55ebaaa5f2820483c65e5c3b66e@haskell.org> #8853: Alarming looking warning about non-exhaustive pattern -------------------------------------------------+------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | x86_64 (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by ezyang): To be clear, the error message is alarming because it refers to unboxed integers, but the source code does not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 22:54:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 22:54:06 -0000 Subject: [GHC] #8853: Surprising mention of unboxed integers in pattern exhaustiveness warning (was: Alarming looking warning about non-exhaustive pattern) In-Reply-To: <054.e34ba59485cfdd347886b35308e8a5bc@haskell.org> References: <054.e34ba59485cfdd347886b35308e8a5bc@haskell.org> Message-ID: <069.1aff762dc64926dcf8b8d3af36a0f442@haskell.org> #8853: Surprising mention of unboxed integers in pattern exhaustiveness warning -------------------------------------------------+------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | x86_64 (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nomeata): > To be clear, the error message is alarming because it refers to unboxed integers, but the source code does not. Ok, that was my guess as well, adjusting ticket title (unfortunately, I can?t change the ticket body to remove the distracting runtime output). I agree that the compiler would ideally not talk about unboxed integers if the code is not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 23:44:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 23:44:03 -0000 Subject: [GHC] #5925: Add inline version of newArray# In-Reply-To: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> References: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> Message-ID: <059.f7cbd497faade88e9d8c507d950f8331@haskell.org> #5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by jberryman): Replying to [comment:12 tibbe]: > ...So the task at this point is to come up with some good benchmarks. There are essentially two ways to attack that problem. Either we can try to show a speed-up in allocation or we can try to show a speed-up due to the better locality (e.g. constructor wrapping an array can now be allocated next to the array.) I don't understand this issue very well, but I wonder if you'd see any difference in running something like this through criterion: {{{ do let payload = P.newArray 32 0 :: IO (P.MutableArray (PrimState IO) Int) x <- newEmptyMVar y <- newEmptyMVar forkIO $ (replicateM_ 500 payload) >> putMVar x () forkIO $ (replicateM_ 500 payload) >> putMVar y () -- ... etc, for number of cores - 1 or so takeMVar x takeMVar y }}} ..using `payload = return ()` as the baseline measurement? Or maybe microbenchmark newArray followed by a read? Re. better locality, I have a real application: a Chan-like IORef linked list of small `MutableArray`s. Maybe creating/traversing a structure like that would show some improvement? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 23:50:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 23:50:21 -0000 Subject: [GHC] #8855: LLVM backend needs to use `-globalopt` explicitly Message-ID: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> #8855: LLVM backend needs to use `-globalopt` explicitly ------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- While `-O1` and `-O2` includes a `-globalopt` pass, for reasons I don't entirely understand the location of the pass is such that not all aliases are eliminated. My `ghc-7.8` branch includes a patch fixing this (as well as removing ARM from the dynamic linking blacklist)[1]. [1] https://github.com/bgamari/ghc/commits/ghc-7.8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 6 23:50:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Mar 2014 23:50:53 -0000 Subject: [GHC] #8855: LLVM backend needs to use `-globalopt` explicitly In-Reply-To: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> References: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> Message-ID: <061.cd260076e661bf2f38555312c4d996e9@haskell.org> #8855: LLVM backend needs to use `-globalopt` explicitly -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 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 bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 01:58:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 01:58:12 -0000 Subject: [GHC] #7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) In-Reply-To: <052.b5316a423cedc87fa6cecb2672f617b3@haskell.org> References: <052.b5316a423cedc87fa6cecb2672f617b3@haskell.org> Message-ID: <067.a86411096415a094d406209b9dc1b2e2@haskell.org> #7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by George): wrt building GHC on Mac sometimes fails, see #8620, building in parallel on Mavericks is failing for some users -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 02:27:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 02:27:14 -0000 Subject: [GHC] #7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) In-Reply-To: <052.b5316a423cedc87fa6cecb2672f617b3@haskell.org> References: <052.b5316a423cedc87fa6cecb2672f617b3@haskell.org> Message-ID: <067.c8388b124456310959464342fcba06a3@haskell.org> #7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): Which does "fail" mean, freeze (non stopping) or stop with an error? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 04:32:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 04:32:55 -0000 Subject: [GHC] #8856: ScopedTypeVariables & PolyKinds lead to weird error message Message-ID: <047.c1ddeb6dbc8d4cc1a8ee203edc0ceccf@haskell.org> #8856: ScopedTypeVariables & PolyKinds lead to weird error message ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I try to compile {{{ {-# LANGUAGE ScopedTypeVariables, RankNTypes, PolyKinds #-} module Bug where import Data.Proxy foo = (undefined :: Proxy a) :: forall a. Proxy a }}} I get {{{ Bug.hs:7:27: Kind variable ?k? used as a type In an expression type signature: Proxy a In the expression: (undefined :: Proxy a) :: forall a. Proxy a In an equation for ?foo?: foo = (undefined :: Proxy a) :: forall a. Proxy a }}} This is all the more odd given that `k` does not appear in my code! This bug happens both in HEAD and in 7.8.1 RC 2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 05:44:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 05:44:36 -0000 Subject: [GHC] #7316: GHC segfaults on ARM In-Reply-To: <044.80d09029baede03deac2ad7b7fbe42af@haskell.org> References: <044.80d09029baede03deac2ad7b7fbe42af@haskell.org> Message-ID: <059.da47b90c213a972907d3a39c49936e20@haskell.org> #7316: GHC segfaults on ARM -------------------------------------+--------------------------- Reporter: laney | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: 7623 | Related Tickets: -------------------------------------+--------------------------- Changes (by bgamari): * priority: high => normal Comment: At this point it seems like dynamic linking works pretty well with the LLVM backend on ARM. We can keep this bug open as the bug likely still lurks in GHC's linker, but it's not nearly as critical now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 05:56:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 05:56:54 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.9bba4d68e962a01af68bccba9bb2338d@haskell.org> #8851: Standalone deriving and GND behave differently --------------------------------------------+------------------------------ Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by goldfire): I agree fully with Simon's analysis. But, the solution to this problem gets involved with areas of GHC that I'm not terribly familiar with, and I need some guidance before proceeding. The interesting bit is `simplifyDeriv` in !TcDeriv, which has this chunk: {{{ ; wanted <- mapM (\(PredOrigin t o) -> newFlatWanted o (substTy skol_subst t)) theta ; (residual_wanted, _ev_binds1) <- solveWantedsTcM (mkFlatWC wanted) }}} I can understand quite clearly what this is doing. It's creating a new `wanted` constraint for each (skolemised) predicate in `theta`. Then, we throw the set of wanteds into the constraint solver and see what comes out. Processing that happens below here figures out if `residual_wanted` indicates success or failure. The problem is that we now wish to do all of the above with some assumptions. My first thought was to create an implication constraint for this, but it's not clear to me the right way to set it up. I found `checkConstraints`, which seems quite relevant, but I'm not sure what to pass for its `thing_inside`. Change the `newFlatWanted` to something that ''emits'' the wanteds? Then, what do I pass to `solveWantedsTcM`? Do I really want `solveWantedsTcMWithEvBinds`? But, that functions takes an `EvBindsVar`, and `checkConstraints` gives me a `TcEvBinds`, which may or may not contain the `EvBindsVar`. (I believe that, in this case, it ''will'' always contain the `EvBindsVar`, but this seems like a silly thing to rely on.) In any case, I'm not sure which lever will drive the ship to safety and which knob will sink the whole lot. Any advice is appreciated, or if you're short of time, you're welcome to yank this bug from me and fix it yourself. In any case, I will need to learn about these interactions quite soon in other work, so the timing is perfect. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 06:00:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 06:00:31 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.58e74079ae7955f20be05404f7491d51@haskell.org> #8851: Standalone deriving and GND behave differently --------------------------------------------+------------------------------ Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Richard Eisenberg ): In [changeset:"1ac91146dc3431742eafd33ed4afc552ca17fb64/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1ac91146dc3431742eafd33ed4afc552ca17fb64" Test #8851. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 06:01:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 06:01:07 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.5bbd27fa91b8ee5fc9e29da394058acd@haskell.org> #8851: Standalone deriving and GND behave differently -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | goldfire Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: Resolution: | Version: Operating System: Unknown/Multiple | 7.8.1-rc1 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: deriving/should_compile/T8851 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by goldfire): * testcase: => deriving/should_compile/T8851 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 08:26:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 08:26:26 -0000 Subject: [GHC] #8857: Sparc needs to be on the NoSharedLibsPlatformList Message-ID: <046.258abaf74ed428bef525e7078c75e6a0@haskell.org> #8857: Sparc needs to be on the NoSharedLibsPlatformList -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: sparc | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I see build failures with GHC-7.8 RC2 on sparc: https://buildd.debian.org/status/logs.php?pkg=ghc&ver=7.8.20140228-1&arch=sparc These go away if I apply this patch, as suggested by Karel Gardas: {{{ Index: ghc-7.8.20140228/mk/config.mk.in =================================================================== --- ghc-7.8.20140228.orig/mk/config.mk.in 2014-03-06 09:48:52.000000000 +0000 +++ ghc-7.8.20140228/mk/config.mk.in 2014-03-06 09:49:55.000000000 +0000 @@ -98,7 +98,8 @@ NoSharedLibsPlatformList = arm-unknown-linux \ powerpc-unknown-linux \ x86_64-unknown-mingw32 \ - i386-unknown-mingw32 + i386-unknown-mingw32 \ + sparc-unknown-linux ifeq "$(SOLARIS_BROKEN_SHLD)" "YES" NoSharedLibsPlatformList += i386-unknown-solaris2 }}} Please consider applying this fix before next RC or the final release. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 10:05:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 10:05:43 -0000 Subject: [GHC] #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory In-Reply-To: <044.398377c33d022955e6b200df91088795@haskell.org> References: <044.398377c33d022955e6b200df91088795@haskell.org> Message-ID: <059.7c4e144cfab2788551db8276708e4d1b@haskell.org> #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory -----------------------------------+---------------------------------- Reporter: awson | Owner: simonmar Type: bug | Status: patch Priority: highest | Milestone: 7.8.2 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by awson): * status: new => patch Comment: Oh, after another painful bug hunting I've found the [https://github.com/ghc/ghc/commit/36b042fbf60210ab6859d96e5b4b5e121085816d culprit]. `unsigned long` is 32 bit in Windows 64-bit ABI. I've attached the patch forcing block size to be `unsigned long long` on x86_64. Perhaps, it may be narrowed to 64-bit windows only, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 10:14:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 10:14:48 -0000 Subject: [GHC] #8858: Wrong maxStkSize calculation Message-ID: <044.8f6377e95db4a409b74bd6c341de1406@haskell.org> #8858: Wrong maxStkSize calculation ------------------------------------+------------------------------------- Reporter: awson | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When fighting with #8839, I've found what I think is a bug in `maxStkSize` calculation: if `getPhysicalMemorySize` succeeds, we set `maxStkSize` in bytes, not words. It did not manifest itself yet, but I've decided to provide a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 10:15:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 10:15:19 -0000 Subject: [GHC] #8858: Wrong maxStkSize calculation In-Reply-To: <044.8f6377e95db4a409b74bd6c341de1406@haskell.org> References: <044.8f6377e95db4a409b74bd6c341de1406@haskell.org> Message-ID: <059.3e1c8a914ff709043932d489fdeb5970@haskell.org> #8858: Wrong maxStkSize calculation -------------------------------------+------------------------------------ Reporter: awson | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.8.1-rc2 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 awson): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 10:20:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 10:20:33 -0000 Subject: [GHC] #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory In-Reply-To: <044.398377c33d022955e6b200df91088795@haskell.org> References: <044.398377c33d022955e6b200df91088795@haskell.org> Message-ID: <059.4aa3cdf94a9949f6c2d276d360d1210a@haskell.org> #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory -----------------------------------+---------------------------------- Reporter: awson | Owner: simonmar Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by awson): * milestone: 7.8.2 => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 10:38:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 10:38:06 -0000 Subject: [GHC] #8857: Sparc needs to be on the NoSharedLibsPlatformList In-Reply-To: <046.258abaf74ed428bef525e7078c75e6a0@haskell.org> References: <046.258abaf74ed428bef525e7078c75e6a0@haskell.org> Message-ID: <061.14e6d3959a5c5eb8093011b169f9ecca@haskell.org> #8857: Sparc needs to be on the NoSharedLibsPlatformList -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: sparc Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by kgardas): Something like this is also needed for sparc/solaris. I've done that manually for building rc2 but if this patch is going to be merged, then please rather with solaris change too. Patch attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 10:39:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 10:39:15 -0000 Subject: [GHC] #8857: Sparc needs to be on the NoSharedLibsPlatformList In-Reply-To: <046.258abaf74ed428bef525e7078c75e6a0@haskell.org> References: <046.258abaf74ed428bef525e7078c75e6a0@haskell.org> Message-ID: <061.ea4e3b66234b62fff66ecb21753ee780@haskell.org> #8857: Sparc needs to be on the NoSharedLibsPlatformList -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: sparc Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by kgardas): * cc: karel.gardas@? (added) * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 11:06:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 11:06:28 -0000 Subject: [GHC] #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory In-Reply-To: <044.398377c33d022955e6b200df91088795@haskell.org> References: <044.398377c33d022955e6b200df91088795@haskell.org> Message-ID: <059.e0e411f4430e69219e7be2c68b3f9049@haskell.org> #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory -----------------------------------+---------------------------------- Reporter: awson | Owner: simonmar Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by simonmar): Good catch, I suspected it might have been something to do with that patch. Though I don't like the fix much. Something like this would be better: {{{ #if SIZEOF_LONG == SIZEOF_VOID_P #define UNIT 1UL #elif SIZEOF_LONGLONG == SIZEOF_VOID_P #define UNIT 1ULL #else #error ... #endif }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 12:36:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 12:36:09 -0000 Subject: [GHC] #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory In-Reply-To: <044.398377c33d022955e6b200df91088795@haskell.org> References: <044.398377c33d022955e6b200df91088795@haskell.org> Message-ID: <059.ac7fa5d350c4d68250f5af658631a660@haskell.org> #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory -----------------------------------+---------------------------------- Reporter: awson | Owner: simonmar Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by awson): Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 14:53:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 14:53:20 -0000 Subject: [GHC] #8824: cloning from https://github.com/ghc/ghc.git is broken In-Reply-To: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> References: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> Message-ID: <062.a23480ed6a68537f53cba6daedfa9d7d@haskell.org> #8824: cloning from https://github.com/ghc/ghc.git is broken -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.9 Resolution: | Keywords: sync-all Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * keywords: => sync-all * owner: => hvr * component: Build System => Trac & Git -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 15:06:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 15:06:34 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.34fb015d111ffd876a93223ebf22516c@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Set ways appropriately in [0014fb3]; please merge that as well so that we have a reliable test suite on the stable branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 15:15:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 15:15:33 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.f723fe31db8df4c2b44e403796a41f08@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by simonpj): Since I can't reproduce this, can you try some experiments for me? * Once the crash happens, copy/paste and re-run the last command line of the log. In the log you uploaded in comment 24, this was {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist- install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base /dist-install/build/autogen -Ilibraries/base/include -optP- DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist- install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist- install/build -split-objs -dynamic-too -c libraries/base/./Control/Applicative.hs -o libraries/base/dist- install/build/Control/Applicative.o -dyno libraries/base/dist- install/build/Control/Applicative.dyn_o }}} Does re-running that one line crash in the same way? I hope so! * Re-run that same command again, this time adding `-ddump-if-trace` to the end of the command line, and upload the result. * Does `libraries/base/dist-install/build/Control/Applicative.hi` exist? Do an `ls -l` on that directory so we can see the timestamps. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 15:25:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 15:25:52 -0000 Subject: [GHC] #8620: make -j3 build of head on Mac 10.9 with xcode 5 fails In-Reply-To: <045.6b8d5402d68421f521d87e4314812585@haskell.org> References: <045.6b8d5402d68421f521d87e4314812585@haskell.org> Message-ID: <060.d3a688fbb6368f18932624dd254cc950@haskell.org> #8620: make -j3 build of head on Mac 10.9 with xcode 5 fails ----------------------------------------+---------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.2 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by AndreasVoellmy): * cc: andreas.voellmy@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 15:28:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 15:28:29 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.b9a76c775707c5317a4f32c0a7314fc5@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by bernalex): Sure. https://secure.plaimi.net/~alexander/tmp/ghc-bork-stage1.log https://secure.plaimi.net/~alexander/tmp/ghc-bork-stage1ddump.log https://secure.plaimi.net/~alexander/tmp/ghc-bork-lsl.log Have fun! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 15:31:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 15:31:47 -0000 Subject: [GHC] #8855: LLVM backend needs to use `-globalopt` explicitly In-Reply-To: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> References: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> Message-ID: <061.051f02fdafe05350e852eea62888cb33@haskell.org> #8855: LLVM backend needs to use `-globalopt` explicitly -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by scpmw): The issue here is that GHC code somewhat randomly refuses to compile with LLVM 3.4, with an error along the lines of: {{{ LLVM ERROR: .LnewCAF$alias: Target doesn't support aliases to declarations }}} These `$alias` definitions are forward references used by the LLVM backend where it can not derive the exact type of a symbol yet due to it either being a global symbol. That can happen because either the symbol is external, or because it is part of another `CmmGroup` (which we can't see due to streaming). In either case we rely on these aliases getting eliminated by the `-globalopt` optimisation pass, much in the same way we are relying on `-mem2reg` to remove `alloca`s. This is the reason we already pass `-globalopt` explicitly for `-O0`. For `-O1` and `-O2` the `-globalopt` pass is always active, so we don't run it twice. What seems to happen here that in spite of the `-globalopt` pass getting run, a few `$alias$` definitions survive: {{{ $ llvm-3.4-build/bin/opt bgamari/History.ll -O1 -S -o - | grep \$alias @"base_GHCziChar_chr2_info$alias" = alias private i8* @base_GHCziChar_chr2_info }}} Especially note that we only find a definition, but no usage site. So it might simply be dead code detection not doing its job to completion. Notably, this behaviour doesn't happen for any of the previous LLVM versions: {{{ $ llvm-3.3-build/bin/opt bgamari/History.ll -O1 -S -o - | grep \$alias $ llvm-3.2-build/bin/opt bgamari/History.ll -O1 -S -o - | grep \$alias $ llvm-3.1-build/bin/opt bgamari/History.ll -O1 -S -o - | grep \$alias $ llvm-3.0-build/bin/opt bgamari/History.ll -O1 -S -o - | grep \$alias $ llvm-2.9-build/bin/opt bgamari/History.ll -O1 -S -o - | grep \$alias $ llvm-2.8-build/bin/opt bgamari/History.ll -O1 -S -o - | grep \$alias $ llvm-2.7-build/bin/opt bgamari/History.ll -O1 -S -o - | grep \$alias }}} And it vanishes for both `-O1 -globalopt` as well as `-O2` for LLVM 3.4: {{{ $ llvm-3.4-build/bin/opt bgamari/History.ll -O1 -globalopt -S -o - | grep \$alias $ llvm-3.4-build/bin/opt bgamari/History.ll -O2 -S -o - | grep \$alias }}} Bottom line is that `-O1 -globalopt` is positively needed for LLVM 3.4. On the other hand, it's up for discussion whether we want it 1. for `-O2`. I would vote no, it probably does multiple passes already, at which point we should *really* except all remainders to be gone. 2. for other LLVM versions. Unsure about that one. It only started happening very recently, and that a lone definition survives with `-O1` smells like a bug. On the other hand, without having any numbers I would estimate that `-globalopt` is one of the cheaper optimization passes. In the end, I would favour doing: {{{ llvmOpts = ["-mem2reg -globalopt" , if ver >= 34 then "-O1 -globalopt" else "-O1" -- LLVM 3.4 -O1 doesn't eliminate aliases reliably , "-O2"] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 15:45:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 15:45:54 -0000 Subject: [GHC] #8855: LLVM backend needs to use `-globalopt` explicitly In-Reply-To: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> References: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> Message-ID: <061.ce9258b4088f8cb1b4286f5a77a8f288@haskell.org> #8855: LLVM backend needs to use `-globalopt` explicitly -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bgamari): I'll update my patch accordingly. Thanks for the analysis! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 15:50:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 15:50:23 -0000 Subject: [GHC] #8620: make -j3 build of head on Mac 10.9 with xcode 5 fails In-Reply-To: <045.6b8d5402d68421f521d87e4314812585@haskell.org> References: <045.6b8d5402d68421f521d87e4314812585@haskell.org> Message-ID: <060.73d35e4e8fa2bb3cf343dd794a8baeb2@haskell.org> #8620: make -j3 build of head on Mac 10.9 with xcode 5 fails ----------------------------------------+---------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.2 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by nomeata): Just run `make` again. I believe this is a known and old problem: [wiki:Building/Troubleshooting#Makehasrestarteditself3timesisthereamakefilebug] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 15:54:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 15:54:20 -0000 Subject: [GHC] #8824: cloning from https://github.com/ghc/ghc.git is broken In-Reply-To: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> References: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> Message-ID: <062.169288a542f4481e1da59fa131e4ebbd@haskell.org> #8824: cloning from https://github.com/ghc/ghc.git is broken -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.9 Resolution: | Keywords: sync-all Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"3efcb0a7d147e05f86501783144bcd0ad3757e93/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3efcb0a7d147e05f86501783144bcd0ad3757e93" Make sync-all handle all github protocols correctly This fixes #8824. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 15:54:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 15:54:35 -0000 Subject: [GHC] #8824: cloning from https://github.com/ghc/ghc.git is broken In-Reply-To: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> References: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> Message-ID: <062.ca8b331e1b11330fe3f9abb2623d04cd@haskell.org> #8824: cloning from https://github.com/ghc/ghc.git is broken -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 7.9 Resolution: fixed | Keywords: sync-all Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 15:55:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 15:55:46 -0000 Subject: [GHC] #8855: LLVM backend needs to use `-globalopt` explicitly In-Reply-To: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> References: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> Message-ID: <061.9a7b3aea9a55b8458109752dfe1759c1@haskell.org> #8855: LLVM backend needs to use `-globalopt` explicitly -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bgamari): How does this[1] look? https://github.com/bgamari/ghc/compare/ghc:ghc-7.8...fixes?expand=1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 16:52:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 16:52:45 -0000 Subject: [GHC] #8678: Deriving `Functor` complains about existential type In-Reply-To: <048.aa0a7629fe983b0a09239bcee6c385f2@haskell.org> References: <048.aa0a7629fe983b0a09239bcee6c385f2@haskell.org> Message-ID: <063.717341e09d1cae11c251f8ec9ce5b8f4@haskell.org> #8678: Deriving `Functor` complains about existential type -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"cdac487bcd9928d77738f6e79ead7b9bb4bc00fd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cdac487bcd9928d77738f6e79ead7b9bb4bc00fd" Make -XDeriveFunctor more generous about non-last arguments (Trac #8678) When deriving Functor, Foldable, Traversable, we need only look at the way that the last type argument is treated. It's fine for there to be existentials etc, provided they don't affect the last type argument. See Note [Check that the type variable is truly universal] in TcDeriv. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 16:52:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 16:52:45 -0000 Subject: [GHC] #8856: ScopedTypeVariables & PolyKinds lead to weird error message In-Reply-To: <047.c1ddeb6dbc8d4cc1a8ee203edc0ceccf@haskell.org> References: <047.c1ddeb6dbc8d4cc1a8ee203edc0ceccf@haskell.org> Message-ID: <062.b05fcecb55678ca183a75627e40bce52@haskell.org> #8856: ScopedTypeVariables & PolyKinds lead to weird error message -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"cf1a0f971966af633fbd932ad012ce716680465b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cf1a0f971966af633fbd932ad012ce716680465b" Fix the treatment of lexically scoped kind variables (Trac #8856) The issue here is described in Note [Binding scoped type variables] in TcPat. When implementing this fix I was able to make things quite a bit simpler: * The type variables in a type signature now never unify with each other, and so can be straightfoward skolems. * We only need the SigTv stuff for signatures in patterns, and for kind variables. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 16:56:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 16:56:42 -0000 Subject: [GHC] #8678: Deriving `Functor` complains about existential type In-Reply-To: <048.aa0a7629fe983b0a09239bcee6c385f2@haskell.org> References: <048.aa0a7629fe983b0a09239bcee6c385f2@haskell.org> Message-ID: <063.c05fa4cbdbc61f2d11a2ee36d240436f@haskell.org> #8678: Deriving `Functor` complains about existential type -------------------------------------------------+------------------------- Reporter: heisenbug | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple deriving/should_compile/T8678 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => closed * testcase: => deriving/should_compile/T8678 * resolution: => fixed Comment: Good idea. I have liberalise what `deriving Functor` will do, so that it looks only at the way in which the last type parameter is used. This makes perfect sense. Let's not merge this; it's a new feature. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 17:11:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 17:11:07 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.17283fe644763be6aba326f68c687f85@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by simonpj): Interesting * Can you add `-ddump-tc-trace -dppr-debug`? * Can you try with `-fno-warn-amp`? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 17:15:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 17:15:32 -0000 Subject: [GHC] #8856: ScopedTypeVariables & PolyKinds lead to weird error message In-Reply-To: <047.c1ddeb6dbc8d4cc1a8ee203edc0ceccf@haskell.org> References: <047.c1ddeb6dbc8d4cc1a8ee203edc0ceccf@haskell.org> Message-ID: <062.99a9853f74b7c0c1fb581e51dde4af4d@haskell.org> #8856: ScopedTypeVariables & PolyKinds lead to weird error message -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"062391be4f06aa408187582c4a40f1cea80429c3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="062391be4f06aa408187582c4a40f1cea80429c3" Test Trac #8856 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 17:16:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 17:16:19 -0000 Subject: [GHC] #8856: ScopedTypeVariables & PolyKinds lead to weird error message In-Reply-To: <047.c1ddeb6dbc8d4cc1a8ee203edc0ceccf@haskell.org> References: <047.c1ddeb6dbc8d4cc1a8ee203edc0ceccf@haskell.org> Message-ID: <062.df6b1fb9a1b0d2c7d1e1687f5d958c3f@haskell.org> #8856: ScopedTypeVariables & PolyKinds lead to weird error message -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple typecheck/should_compile/T8856 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_compile/T8856 Comment: Good point, thank you. This is a real bug and should probably be merged to 7.8 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 17:28:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 17:28:25 -0000 Subject: [GHC] #8620: make -j3 build of head on Mac 10.9 with xcode 5 fails In-Reply-To: <045.6b8d5402d68421f521d87e4314812585@haskell.org> References: <045.6b8d5402d68421f521d87e4314812585@haskell.org> Message-ID: <060.459b89a8eaae64a7d1e7ce148f41fc35@haskell.org> #8620: make -j3 build of head on Mac 10.9 with xcode 5 fails ----------------------------------------+---------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.2 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by AndreasVoellmy): FWIW, I just built 7.8.1 rc2 using "make -j3" on OS X 10.9.2 and Xcode 5.0.2 and it went through fine for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 22:46:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 22:46:42 -0000 Subject: [GHC] #8824: cloning from https://github.com/ghc/ghc.git is broken In-Reply-To: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> References: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> Message-ID: <062.e2aa3aec3ead6f57627f7bf1fc2bfa93@haskell.org> #8824: cloning from https://github.com/ghc/ghc.git is broken -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 7.9 Resolution: fixed | Keywords: sync-all Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): i'm still having issues with this... ` fatal: repository 'https://github.com/ghc/packages/base.git/' ` and friends.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 22:46:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 22:46:55 -0000 Subject: [GHC] #8824: cloning from https://github.com/ghc/ghc.git is broken In-Reply-To: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> References: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> Message-ID: <062.9d763f5a3fa3ed3d460830f374b6739c@haskell.org> #8824: cloning from https://github.com/ghc/ghc.git is broken -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 7.9 Resolution: fixed | Keywords: sync-all Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): the maddening bit is i'm using http! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 22:51:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 22:51:09 -0000 Subject: [GHC] #8824: cloning from https://github.com/ghc/ghc.git is broken In-Reply-To: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> References: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> Message-ID: <062.4c1facc61f3ec3913c8393f59bb9d17a@haskell.org> #8824: cloning from https://github.com/ghc/ghc.git is broken -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 7.9 Resolution: fixed | Keywords: sync-all Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): i did `git clone http://github.com/ghc/ghc http-ghc ` will try ` git clone http://github.com/ghc/ghc.git http-ghc ` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 7 22:57:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Mar 2014 22:57:13 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.53cb9fd8151e32bd03ca4f6404607a01@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by bernalex): Hm. OK, this is interesting. Running with --dump-tc-trace -dppr-debug gives this: https://secure.plaimi.net/~alexander/tmp/ghc-bork-if-tc-debug.log If I now try to run with -fno-warn-amp, or indeed without any additional arguments at all, this happens: {{{ $ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist- install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base /dist-install/build/autogen -Ilibraries/base/include -optP- DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist- install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist- install/build -split-objs -dynamic-too -c libraries/base/./Control/Applicative.hs -o libraries/base/dist- install/build/Control/Applicative.o -dyno libraries/base/dist- install/build/Control/Applicative.dyn_o -fno-warn-amp compilation IS NOT required }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 00:06:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 00:06:22 -0000 Subject: [GHC] #8824: cloning from https://github.com/ghc/ghc.git is broken In-Reply-To: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> References: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> Message-ID: <062.b9ad8cb56f2fd25ec21e4e5834d6e2ad@haskell.org> #8824: cloning from https://github.com/ghc/ghc.git is broken -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 7.9 Resolution: fixed | Keywords: sync-all Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): I cannot reproduce here. Both {{{ git clone https://github.com/ghc/ghc.git --reference ~/build/haskell/ghc cd ghc ./sync-all get }}} and {{{ git clone https://github.com/ghc/ghc --reference ~/build/haskell/ghc cd ghc ./sync-all get }}} work. I?m not claiming that sync-all cleans up old wrong submodule paths, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 00:08:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 00:08:53 -0000 Subject: [GHC] #8824: cloning from https://github.com/ghc/ghc.git is broken In-Reply-To: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> References: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> Message-ID: <062.dd9f4ebec78454cca81013e328083f4f@haskell.org> #8824: cloning from https://github.com/ghc/ghc.git is broken -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 7.9 Resolution: fixed | Keywords: sync-all Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): Carter is cloning from `http://` not `https://` (I didn't know that that even worked until tonight). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 00:11:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 00:11:46 -0000 Subject: [GHC] #8824: cloning from https://github.com/ghc/ghc.git is broken In-Reply-To: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> References: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> Message-ID: <062.701941040bb724709d85474a1a60c3da@haskell.org> #8824: cloning from https://github.com/ghc/ghc.git is broken -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 7.9 Resolution: fixed | Keywords: sync-all Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"d246c62afd7312185aee9433b065ea99e4fa4054/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d246c62afd7312185aee9433b065ea99e4fa4054" Also allow http://github.com (#8824) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 00:12:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 00:12:03 -0000 Subject: [GHC] #8824: cloning from https://github.com/ghc/ghc.git is broken In-Reply-To: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> References: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> Message-ID: <062.a400c12d2978ea30a63ff10832e33f8e@haskell.org> #8824: cloning from https://github.com/ghc/ghc.git is broken -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 7.9 Resolution: fixed | Keywords: sync-all Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Ok, made the regex a bit more liberal ? shoudn?t hurt. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 01:54:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 01:54:07 -0000 Subject: [GHC] #8859: import conditionalization in System.Posix.Files.Common is wrong Message-ID: <047.ea86c023b4962335e095d1f92b0177e9@haskell.org> #8859: import conditionalization in System.Posix.Files.Common is wrong ------------------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.8.1-rc2 Keywords: | Operating System: Other Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- `System/Posix/Files/Common.hsc` imports `Data.Int` and `Data.Ratio` conditionally, to avoid "unused import" compiler warnings: {{{ #if defined(HAVE_STRUCT_STAT_ST_CTIM) || \ defined(HAVE_STRUCT_STAT_ST_MTIM) || \ defined(HAVE_STRUCT_STAT_ST_ATIM) || \ defined(HAVE_STRUCT_STAT_ST_ATIMESPEC) || \ defined(HAVE_STRUCT_STAT_ST_MTIMESPEC) || \ defined(HAVE_STRUCT_STAT_ST_CTIMESPEC) import Data.Int import Data.Ratio #endif }}} but those modules are actually used in functions like {{{ accessTimeHiRes (FileStatus stat) = unsafePerformIO $ withForeignPtr stat $ \stat_ptr -> do sec <- (#peek struct stat, st_atime) stat_ptr :: IO EpochTime #ifdef HAVE_STRUCT_STAT_ST_ATIM nsec <- (#peek struct stat, st_atim.tv_nsec) stat_ptr :: IO (#type long) let frac = toInteger nsec % 10^(9::Int) #elif HAVE_STRUCT_STAT_ST_ATIMESPEC nsec <- (#peek struct stat, st_atimespec.tv_nsec) stat_ptr :: IO (#type long) let frac = toInteger nsec % 10^(9::Int) #elif HAVE_STRUCT_STAT_ST_ATIMENSEC nsec <- (#peek struct stat, st_atimensec) stat_ptr :: IO (#type long) let frac = toInteger nsec % 10^(9::Int) #elif HAVE_STRUCT_STAT_ST_ATIME_N nsec <- (#peek struct stat, st_atime_n) stat_ptr :: IO (#type int) let frac = toInteger nsec % 10^(9::Int) #elif HAVE_STRUCT_STAT_ST_UATIME usec <- (#peek struct stat, st_uatime) stat_ptr :: IO (#type int) let frac = toInteger usec % 10^(6::Int) #else let frac = 0 #endif return $ fromRational $ toRational sec + frac }}} so there should be additional tests for `defined(HAVE_STRUCT_STAT_ST_ATIMENSEC)`, `defined(HAVE_STRUCT_STAT_ST_ATIME_N)`, ... (15 total). Or, maybe there's a better alternative, since this is very long-winded and fragile... This breaks the build on Android, which has `st_atimensec`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 02:43:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 02:43:28 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.0d12986cc0932120d60e343d082010fc@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.8.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by dmcclean): * cc: douglas.mcclean@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 08:33:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 08:33:06 -0000 Subject: [GHC] #8860: Optimized Cmm isn't Message-ID: <044.d8a17d1b07c8c531c3d4d1cbd7ad96ef@haskell.org> #8860: Optimized Cmm isn't ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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 optimizer seems to miss very basic optimizations. For example, look at this segment (full source below): {{{ _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); }}} I'd expect all these temporaries (that are only used ones) to be inlined, but they are not and thus we fail to see the static arguments to the `MO_Memset` call, which leads to further missed optimizations. This used to work in the old codegen. Furthermore, there are useless basic blocks in the output: {{{ c1Cm: goto c1C4; c1C4: }}} I'd expect them to be eliminated. .dump-cmm file: {{{ ==================== Cmm produced by new codegen ==================== 2014-03-08 08:25:31.728672 UTC [section "data" { a_r1za_closure: const a_r1za_info; }, a_r1za_entry() // [] { info_tbl: [(c1Cm, label: a_r1za_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 3} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c1Cm: goto c1C4; c1C4: if ((old + 0) - < SpLim) goto c1Cp; else goto c1Cq; c1Cq: goto c1C3; c1C3: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; goto c1Ch; c1Ch: _s1C1::P64 = _s1BY::P64; goto c1Ck; c1Ck: R1 = ()_closure+1; call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; } }] ==================== Post control-flow optimisations ==================== 2014-03-08 08:25:31.729764 UTC {offset c1Cm: if ((old + 0) - < SpLim) goto c1Cp; else goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; } ==================== Layout Stack ==================== 2014-03-08 08:25:31.730253 UTC {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } ==================== CAFEnv ==================== 2014-03-08 08:25:31.73074 UTC [(c1C8, {}), (c1C9, {}), (c1Ca, {}), (c1Cm, {}), (c1Cp, {}), (c1Cq, {}), (c1Cr, {}), (c1Cs, {})] ==================== after setInfoTableStackMap ==================== 2014-03-08 08:25:31.730895 UTC a_r1za_entry() // [] { info_tbl: [(c1Cm, label: a_r1za_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 3} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } } ==================== Post control-flow optimisations ==================== 2014-03-08 08:25:31.731383 UTC a_r1za_entry() // [] { info_tbl: [(c1Cm, label: a_r1za_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 3} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } } ==================== Post CPS Cmm ==================== 2014-03-08 08:25:31.731772 UTC [section "data" { a_r1za_closure: const a_r1za_info; }, a_r1za_entry() // [] { info_tbl: [(c1Cm, label: a_r1za_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 3} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }] ==================== Output Cmm ==================== 2014-03-08 08:25:31.73228 UTC [section "data" { a_r1za_closure: const a_r1za_info; }, a_r1za_entry() // [] { info_tbl: [(c1Cm, label: a_r1za_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 3} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }] }}} .dump-opt-cmm file: {{{ ==================== Optimised Cmm ==================== 2014-03-08 08:25:31.732971 UTC a_r1za_entry() // [] { [(c1Cm, a_r1za_info: const 4294967299; const 0; const 15;)] } {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > I64[BaseReg + 856]) goto c1Cs; else goto c1Cr; c1Cs: I64[BaseReg + 904] = 152; goto c1Cp; c1Cp: R1 = PicBaseReg + a_r1za_closure; call (I64[BaseReg - 8])(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info at GOTPCREL]; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: I64[_c1C7::I64] = PicBaseReg + (()_closure+1); _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; // nop _s1C1::P64 = _s1BY::P64; R1 = PicBaseReg + (()_closure+1); call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 08:35:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 08:35:30 -0000 Subject: [GHC] #8860: Optimized Cmm isn't In-Reply-To: <044.d8a17d1b07c8c531c3d4d1cbd7ad96ef@haskell.org> References: <044.d8a17d1b07c8c531c3d4d1cbd7ad96ef@haskell.org> Message-ID: <059.ef9984ec1e80863c5b778e156a424580@haskell.org> #8860: Optimized Cmm isn't -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 slyfox): * cc: slyfox@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 08:37:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 08:37:08 -0000 Subject: [GHC] #5925: Add inline version of newArray# In-Reply-To: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> References: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> Message-ID: <059.192c3e79108c36264f653320eb49d3da@haskell.org> #5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): I got this working I think, except that the Cmm optimizer does such a poor job on the Cmm I generate (which is simple) that I'm not sure if we can get anywhere here without first fixing that problem. See e.g #8860. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 08:46:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 08:46:57 -0000 Subject: [GHC] #8860: Optimized Cmm isn't In-Reply-To: <044.d8a17d1b07c8c531c3d4d1cbd7ad96ef@haskell.org> References: <044.d8a17d1b07c8c531c3d4d1cbd7ad96ef@haskell.org> Message-ID: <059.abe80263dd06044687cb262fc2529bed@haskell.org> #8860: Optimized Cmm isn't -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by tibbe: Old description: > The optimizer seems to miss very basic optimizations. For example, look > at this segment (full source below): > > {{{ > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, > _c1Cf::I64); > }}} > > I'd expect all these temporaries (that are only used ones) to be inlined, > but they are not and thus we fail to see the static arguments to the > `MO_Memset` call, which leads to further missed optimizations. > > This used to work in the old codegen. > > Furthermore, there are useless basic blocks in the output: > > {{{ > c1Cm: > goto c1C4; > c1C4: > }}} > > I'd expect them to be eliminated. > > .dump-cmm file: > > {{{ > ==================== Cmm produced by new codegen ==================== > 2014-03-08 08:25:31.728672 UTC > > [section "data" { > a_r1za_closure: > const a_r1za_info; > }, > a_r1za_entry() // [] > { info_tbl: [(c1Cm, > label: a_r1za_info > rep:HeapRep static { Fun {arity: 1 fun_type: > ArgSpec 3} })] > stack_info: arg_space: 8 updfr_space: Just 8 > } > {offset > c1Cm: > goto c1C4; > c1C4: > if ((old + 0) - < SpLim) goto c1Cp; else goto c1Cq; > c1Cq: > goto c1C3; > c1C3: > Hp = Hp + 152; > if (Hp > HpLim) goto c1Cs; else goto c1Cr; > c1Cs: > HpAlloc = 152; > goto c1Cp; > c1Cp: > R1 = a_r1za_closure; > call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; > c1Cr: > I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; > I64[Hp - 136] = 16; > I64[Hp - 128] = 16; > _c1C6::I64 = Hp - 144; > _c1C7::I64 = _c1C6::I64 + 24; > goto c1C8; > c1C8: > if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto > c1C9; > c1Ca: > P64[_c1C7::I64] = ()_closure+1; > _c1C7::I64 = _c1C7::I64 + 8; > goto c1C8; > c1C9: > _c1Cb::I64 = _c1C6::I64 + 24; > _c1Cc::I64 = _c1Cb::I64 + 128; > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, > _c1Cf::I64); > _s1BY::P64 = _c1C6::I64; > _s1BY::P64 = _s1BY::P64; > goto c1Ch; > c1Ch: > _s1C1::P64 = _s1BY::P64; > goto c1Ck; > c1Ck: > R1 = ()_closure+1; > call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; > } > }] > > ==================== Post control-flow optimisations ==================== > 2014-03-08 08:25:31.729764 UTC > > {offset > c1Cm: > if ((old + 0) - < SpLim) goto c1Cp; else goto c1Cq; > c1Cq: > Hp = Hp + 152; > if (Hp > HpLim) goto c1Cs; else goto c1Cr; > c1Cs: > HpAlloc = 152; > goto c1Cp; > c1Cp: > R1 = a_r1za_closure; > call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; > c1Cr: > I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; > I64[Hp - 136] = 16; > I64[Hp - 128] = 16; > _c1C6::I64 = Hp - 144; > _c1C7::I64 = _c1C6::I64 + 24; > goto c1C8; > c1C8: > if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; > c1Ca: > P64[_c1C7::I64] = ()_closure+1; > _c1C7::I64 = _c1C7::I64 + 8; > goto c1C8; > c1C9: > _c1Cb::I64 = _c1C6::I64 + 24; > _c1Cc::I64 = _c1Cb::I64 + 128; > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); > _s1BY::P64 = _c1C6::I64; > _s1BY::P64 = _s1BY::P64; > _s1C1::P64 = _s1BY::P64; > R1 = ()_closure+1; > call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; > } > > ==================== Layout Stack ==================== > 2014-03-08 08:25:31.730253 UTC > > {offset > c1Cm: > goto c1Cq; > c1Cq: > Hp = Hp + 152; > if (Hp > HpLim) goto c1Cs; else goto c1Cr; > c1Cs: > HpAlloc = 152; > goto c1Cp; > c1Cp: > R1 = a_r1za_closure; > call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; > c1Cr: > I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; > I64[Hp - 136] = 16; > I64[Hp - 128] = 16; > _c1C6::I64 = Hp - 144; > _c1C7::I64 = _c1C6::I64 + 24; > goto c1C8; > c1C8: > if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; > c1Ca: > P64[_c1C7::I64] = ()_closure+1; > _c1C7::I64 = _c1C7::I64 + 8; > goto c1C8; > c1C9: > _c1Cb::I64 = _c1C6::I64 + 24; > _c1Cc::I64 = _c1Cb::I64 + 128; > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); > _s1BY::P64 = _c1C6::I64; > _s1BY::P64 = _s1BY::P64; > _s1C1::P64 = _s1BY::P64; > R1 = ()_closure+1; > call (P64[Sp])(R1) args: 8, res: 0, upd: 8; > } > > ==================== CAFEnv ==================== > 2014-03-08 08:25:31.73074 UTC > > [(c1C8, {}), (c1C9, {}), (c1Ca, {}), (c1Cm, {}), (c1Cp, {}), > (c1Cq, {}), (c1Cr, {}), (c1Cs, {})] > > ==================== after setInfoTableStackMap ==================== > 2014-03-08 08:25:31.730895 UTC > > a_r1za_entry() // [] > { info_tbl: [(c1Cm, > label: a_r1za_info > rep:HeapRep static { Fun {arity: 1 fun_type: > ArgSpec 3} })] > stack_info: arg_space: 8 updfr_space: Just 8 > } > {offset > c1Cm: > goto c1Cq; > c1Cq: > Hp = Hp + 152; > if (Hp > HpLim) goto c1Cs; else goto c1Cr; > c1Cs: > HpAlloc = 152; > goto c1Cp; > c1Cp: > R1 = a_r1za_closure; > call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; > c1Cr: > I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; > I64[Hp - 136] = 16; > I64[Hp - 128] = 16; > _c1C6::I64 = Hp - 144; > _c1C7::I64 = _c1C6::I64 + 24; > goto c1C8; > c1C8: > if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; > c1Ca: > P64[_c1C7::I64] = ()_closure+1; > _c1C7::I64 = _c1C7::I64 + 8; > goto c1C8; > c1C9: > _c1Cb::I64 = _c1C6::I64 + 24; > _c1Cc::I64 = _c1Cb::I64 + 128; > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); > _s1BY::P64 = _c1C6::I64; > _s1BY::P64 = _s1BY::P64; > _s1C1::P64 = _s1BY::P64; > R1 = ()_closure+1; > call (P64[Sp])(R1) args: 8, res: 0, upd: 8; > } > } > > ==================== Post control-flow optimisations ==================== > 2014-03-08 08:25:31.731383 UTC > > a_r1za_entry() // [] > { info_tbl: [(c1Cm, > label: a_r1za_info > rep:HeapRep static { Fun {arity: 1 fun_type: > ArgSpec 3} })] > stack_info: arg_space: 8 updfr_space: Just 8 > } > {offset > c1Cm: > goto c1Cq; > c1Cq: > Hp = Hp + 152; > if (Hp > HpLim) goto c1Cs; else goto c1Cr; > c1Cs: > HpAlloc = 152; > goto c1Cp; > c1Cp: > R1 = a_r1za_closure; > call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; > c1Cr: > I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; > I64[Hp - 136] = 16; > I64[Hp - 128] = 16; > _c1C6::I64 = Hp - 144; > _c1C7::I64 = _c1C6::I64 + 24; > goto c1C8; > c1C8: > if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; > c1Ca: > P64[_c1C7::I64] = ()_closure+1; > _c1C7::I64 = _c1C7::I64 + 8; > goto c1C8; > c1C9: > _c1Cb::I64 = _c1C6::I64 + 24; > _c1Cc::I64 = _c1Cb::I64 + 128; > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); > _s1BY::P64 = _c1C6::I64; > _s1BY::P64 = _s1BY::P64; > _s1C1::P64 = _s1BY::P64; > R1 = ()_closure+1; > call (P64[Sp])(R1) args: 8, res: 0, upd: 8; > } > } > > ==================== Post CPS Cmm ==================== > 2014-03-08 08:25:31.731772 UTC > > [section "data" { > a_r1za_closure: > const a_r1za_info; > }, > a_r1za_entry() // [] > { info_tbl: [(c1Cm, > label: a_r1za_info > rep:HeapRep static { Fun {arity: 1 fun_type: > ArgSpec 3} })] > stack_info: arg_space: 8 updfr_space: Just 8 > } > {offset > c1Cm: > goto c1Cq; > c1Cq: > Hp = Hp + 152; > if (Hp > HpLim) goto c1Cs; else goto c1Cr; > c1Cs: > HpAlloc = 152; > goto c1Cp; > c1Cp: > R1 = a_r1za_closure; > call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; > c1Cr: > I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; > I64[Hp - 136] = 16; > I64[Hp - 128] = 16; > _c1C6::I64 = Hp - 144; > _c1C7::I64 = _c1C6::I64 + 24; > goto c1C8; > c1C8: > if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto > c1C9; > c1Ca: > P64[_c1C7::I64] = ()_closure+1; > _c1C7::I64 = _c1C7::I64 + 8; > goto c1C8; > c1C9: > _c1Cb::I64 = _c1C6::I64 + 24; > _c1Cc::I64 = _c1Cb::I64 + 128; > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, > _c1Cf::I64); > _s1BY::P64 = _c1C6::I64; > _s1BY::P64 = _s1BY::P64; > _s1C1::P64 = _s1BY::P64; > R1 = ()_closure+1; > call (P64[Sp])(R1) args: 8, res: 0, upd: 8; > } > }] > > ==================== Output Cmm ==================== > 2014-03-08 08:25:31.73228 UTC > > [section "data" { > a_r1za_closure: > const a_r1za_info; > }, > a_r1za_entry() // [] > { info_tbl: [(c1Cm, > label: a_r1za_info > rep:HeapRep static { Fun {arity: 1 fun_type: > ArgSpec 3} })] > stack_info: arg_space: 8 updfr_space: Just 8 > } > {offset > c1Cm: > goto c1Cq; > c1Cq: > Hp = Hp + 152; > if (Hp > HpLim) goto c1Cs; else goto c1Cr; > c1Cs: > HpAlloc = 152; > goto c1Cp; > c1Cp: > R1 = a_r1za_closure; > call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; > c1Cr: > I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; > I64[Hp - 136] = 16; > I64[Hp - 128] = 16; > _c1C6::I64 = Hp - 144; > _c1C7::I64 = _c1C6::I64 + 24; > goto c1C8; > c1C8: > if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto > c1C9; > c1Ca: > P64[_c1C7::I64] = ()_closure+1; > _c1C7::I64 = _c1C7::I64 + 8; > goto c1C8; > c1C9: > _c1Cb::I64 = _c1C6::I64 + 24; > _c1Cc::I64 = _c1Cb::I64 + 128; > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, > _c1Cf::I64); > _s1BY::P64 = _c1C6::I64; > _s1BY::P64 = _s1BY::P64; > _s1C1::P64 = _s1BY::P64; > R1 = ()_closure+1; > call (P64[Sp])(R1) args: 8, res: 0, upd: 8; > } > }] > }}} > > .dump-opt-cmm file: > {{{ > ==================== Optimised Cmm ==================== > 2014-03-08 08:25:31.732971 UTC > > a_r1za_entry() // [] > { [(c1Cm, > a_r1za_info: > const 4294967299; > const 0; > const 15;)] > } > {offset > c1Cm: > goto c1Cq; > c1Cq: > Hp = Hp + 152; > if (Hp > I64[BaseReg + 856]) goto c1Cs; else goto c1Cr; > c1Cs: > I64[BaseReg + 904] = 152; > goto c1Cp; > c1Cp: > R1 = PicBaseReg + a_r1za_closure; > call (I64[BaseReg - 8])(R1) args: 8, res: 0, upd: 8; > c1Cr: > I64[Hp - 144] = I64[PicBaseReg + > stg_MUT_ARR_PTRS_DIRTY_info at GOTPCREL]; > I64[Hp - 136] = 16; > I64[Hp - 128] = 16; > _c1C6::I64 = Hp - 144; > _c1C7::I64 = _c1C6::I64 + 24; > goto c1C8; > c1C8: > if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; > c1Ca: > I64[_c1C7::I64] = PicBaseReg + (()_closure+1); > _c1C7::I64 = _c1C7::I64 + 8; > goto c1C8; > c1C9: > _c1Cb::I64 = _c1C6::I64 + 24; > _c1Cc::I64 = _c1Cb::I64 + 128; > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); > _s1BY::P64 = _c1C6::I64; > // nop > _s1C1::P64 = _s1BY::P64; > R1 = PicBaseReg + (()_closure+1); > call (P64[Sp])(R1) args: 8, res: 0, upd: 8; > } > } > }}} New description: The optimizer seems to miss very basic optimizations. For example, look at this segment (full source below): {{{ _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); }}} I'd expect all these temporaries (that are only used once) to be inlined, but they are not and thus we fail to see the static arguments to the `MO_Memset` call, which leads to further missed optimizations. This used to work in the old codegen. Furthermore, there are useless basic blocks in the output: {{{ c1Cm: goto c1C4; c1C4: }}} I'd expect them to be eliminated. .dump-cmm file: {{{ ==================== Cmm produced by new codegen ==================== 2014-03-08 08:25:31.728672 UTC [section "data" { a_r1za_closure: const a_r1za_info; }, a_r1za_entry() // [] { info_tbl: [(c1Cm, label: a_r1za_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 3} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c1Cm: goto c1C4; c1C4: if ((old + 0) - < SpLim) goto c1Cp; else goto c1Cq; c1Cq: goto c1C3; c1C3: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; goto c1Ch; c1Ch: _s1C1::P64 = _s1BY::P64; goto c1Ck; c1Ck: R1 = ()_closure+1; call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; } }] ==================== Post control-flow optimisations ==================== 2014-03-08 08:25:31.729764 UTC {offset c1Cm: if ((old + 0) - < SpLim) goto c1Cp; else goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; } ==================== Layout Stack ==================== 2014-03-08 08:25:31.730253 UTC {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } ==================== CAFEnv ==================== 2014-03-08 08:25:31.73074 UTC [(c1C8, {}), (c1C9, {}), (c1Ca, {}), (c1Cm, {}), (c1Cp, {}), (c1Cq, {}), (c1Cr, {}), (c1Cs, {})] ==================== after setInfoTableStackMap ==================== 2014-03-08 08:25:31.730895 UTC a_r1za_entry() // [] { info_tbl: [(c1Cm, label: a_r1za_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 3} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } } ==================== Post control-flow optimisations ==================== 2014-03-08 08:25:31.731383 UTC a_r1za_entry() // [] { info_tbl: [(c1Cm, label: a_r1za_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 3} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } } ==================== Post CPS Cmm ==================== 2014-03-08 08:25:31.731772 UTC [section "data" { a_r1za_closure: const a_r1za_info; }, a_r1za_entry() // [] { info_tbl: [(c1Cm, label: a_r1za_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 3} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }] ==================== Output Cmm ==================== 2014-03-08 08:25:31.73228 UTC [section "data" { a_r1za_closure: const a_r1za_info; }, a_r1za_entry() // [] { info_tbl: [(c1Cm, label: a_r1za_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 3} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }] }}} .dump-opt-cmm file: {{{ ==================== Optimised Cmm ==================== 2014-03-08 08:25:31.732971 UTC a_r1za_entry() // [] { [(c1Cm, a_r1za_info: const 4294967299; const 0; const 15;)] } {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > I64[BaseReg + 856]) goto c1Cs; else goto c1Cr; c1Cs: I64[BaseReg + 904] = 152; goto c1Cp; c1Cp: R1 = PicBaseReg + a_r1za_closure; call (I64[BaseReg - 8])(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info at GOTPCREL]; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: I64[_c1C7::I64] = PicBaseReg + (()_closure+1); _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; // nop _s1C1::P64 = _s1BY::P64; R1 = PicBaseReg + (()_closure+1); call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } } }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 08:50:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 08:50:42 -0000 Subject: [GHC] #8860: Optimized Cmm isn't In-Reply-To: <044.d8a17d1b07c8c531c3d4d1cbd7ad96ef@haskell.org> References: <044.d8a17d1b07c8c531c3d4d1cbd7ad96ef@haskell.org> Message-ID: <059.c356bc389cef8109c4232d3e7c43b409@haskell.org> #8860: Optimized Cmm isn't -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by tibbe: Old description: > The optimizer seems to miss very basic optimizations. For example, look > at this segment (full source below): > > {{{ > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, > _c1Cf::I64); > }}} > > I'd expect all these temporaries (that are only used once) to be inlined, > but they are not and thus we fail to see the static arguments to the > `MO_Memset` call, which leads to further missed optimizations. > > This used to work in the old codegen. > > Furthermore, there are useless basic blocks in the output: > > {{{ > c1Cm: > goto c1C4; > c1C4: > }}} > > I'd expect them to be eliminated. > > .dump-cmm file: > > {{{ > ==================== Cmm produced by new codegen ==================== > 2014-03-08 08:25:31.728672 UTC > > [section "data" { > a_r1za_closure: > const a_r1za_info; > }, > a_r1za_entry() // [] > { info_tbl: [(c1Cm, > label: a_r1za_info > rep:HeapRep static { Fun {arity: 1 fun_type: > ArgSpec 3} })] > stack_info: arg_space: 8 updfr_space: Just 8 > } > {offset > c1Cm: > goto c1C4; > c1C4: > if ((old + 0) - < SpLim) goto c1Cp; else goto c1Cq; > c1Cq: > goto c1C3; > c1C3: > Hp = Hp + 152; > if (Hp > HpLim) goto c1Cs; else goto c1Cr; > c1Cs: > HpAlloc = 152; > goto c1Cp; > c1Cp: > R1 = a_r1za_closure; > call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; > c1Cr: > I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; > I64[Hp - 136] = 16; > I64[Hp - 128] = 16; > _c1C6::I64 = Hp - 144; > _c1C7::I64 = _c1C6::I64 + 24; > goto c1C8; > c1C8: > if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto > c1C9; > c1Ca: > P64[_c1C7::I64] = ()_closure+1; > _c1C7::I64 = _c1C7::I64 + 8; > goto c1C8; > c1C9: > _c1Cb::I64 = _c1C6::I64 + 24; > _c1Cc::I64 = _c1Cb::I64 + 128; > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, > _c1Cf::I64); > _s1BY::P64 = _c1C6::I64; > _s1BY::P64 = _s1BY::P64; > goto c1Ch; > c1Ch: > _s1C1::P64 = _s1BY::P64; > goto c1Ck; > c1Ck: > R1 = ()_closure+1; > call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; > } > }] > > ==================== Post control-flow optimisations ==================== > 2014-03-08 08:25:31.729764 UTC > > {offset > c1Cm: > if ((old + 0) - < SpLim) goto c1Cp; else goto c1Cq; > c1Cq: > Hp = Hp + 152; > if (Hp > HpLim) goto c1Cs; else goto c1Cr; > c1Cs: > HpAlloc = 152; > goto c1Cp; > c1Cp: > R1 = a_r1za_closure; > call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; > c1Cr: > I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; > I64[Hp - 136] = 16; > I64[Hp - 128] = 16; > _c1C6::I64 = Hp - 144; > _c1C7::I64 = _c1C6::I64 + 24; > goto c1C8; > c1C8: > if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; > c1Ca: > P64[_c1C7::I64] = ()_closure+1; > _c1C7::I64 = _c1C7::I64 + 8; > goto c1C8; > c1C9: > _c1Cb::I64 = _c1C6::I64 + 24; > _c1Cc::I64 = _c1Cb::I64 + 128; > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); > _s1BY::P64 = _c1C6::I64; > _s1BY::P64 = _s1BY::P64; > _s1C1::P64 = _s1BY::P64; > R1 = ()_closure+1; > call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; > } > > ==================== Layout Stack ==================== > 2014-03-08 08:25:31.730253 UTC > > {offset > c1Cm: > goto c1Cq; > c1Cq: > Hp = Hp + 152; > if (Hp > HpLim) goto c1Cs; else goto c1Cr; > c1Cs: > HpAlloc = 152; > goto c1Cp; > c1Cp: > R1 = a_r1za_closure; > call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; > c1Cr: > I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; > I64[Hp - 136] = 16; > I64[Hp - 128] = 16; > _c1C6::I64 = Hp - 144; > _c1C7::I64 = _c1C6::I64 + 24; > goto c1C8; > c1C8: > if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; > c1Ca: > P64[_c1C7::I64] = ()_closure+1; > _c1C7::I64 = _c1C7::I64 + 8; > goto c1C8; > c1C9: > _c1Cb::I64 = _c1C6::I64 + 24; > _c1Cc::I64 = _c1Cb::I64 + 128; > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); > _s1BY::P64 = _c1C6::I64; > _s1BY::P64 = _s1BY::P64; > _s1C1::P64 = _s1BY::P64; > R1 = ()_closure+1; > call (P64[Sp])(R1) args: 8, res: 0, upd: 8; > } > > ==================== CAFEnv ==================== > 2014-03-08 08:25:31.73074 UTC > > [(c1C8, {}), (c1C9, {}), (c1Ca, {}), (c1Cm, {}), (c1Cp, {}), > (c1Cq, {}), (c1Cr, {}), (c1Cs, {})] > > ==================== after setInfoTableStackMap ==================== > 2014-03-08 08:25:31.730895 UTC > > a_r1za_entry() // [] > { info_tbl: [(c1Cm, > label: a_r1za_info > rep:HeapRep static { Fun {arity: 1 fun_type: > ArgSpec 3} })] > stack_info: arg_space: 8 updfr_space: Just 8 > } > {offset > c1Cm: > goto c1Cq; > c1Cq: > Hp = Hp + 152; > if (Hp > HpLim) goto c1Cs; else goto c1Cr; > c1Cs: > HpAlloc = 152; > goto c1Cp; > c1Cp: > R1 = a_r1za_closure; > call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; > c1Cr: > I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; > I64[Hp - 136] = 16; > I64[Hp - 128] = 16; > _c1C6::I64 = Hp - 144; > _c1C7::I64 = _c1C6::I64 + 24; > goto c1C8; > c1C8: > if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; > c1Ca: > P64[_c1C7::I64] = ()_closure+1; > _c1C7::I64 = _c1C7::I64 + 8; > goto c1C8; > c1C9: > _c1Cb::I64 = _c1C6::I64 + 24; > _c1Cc::I64 = _c1Cb::I64 + 128; > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); > _s1BY::P64 = _c1C6::I64; > _s1BY::P64 = _s1BY::P64; > _s1C1::P64 = _s1BY::P64; > R1 = ()_closure+1; > call (P64[Sp])(R1) args: 8, res: 0, upd: 8; > } > } > > ==================== Post control-flow optimisations ==================== > 2014-03-08 08:25:31.731383 UTC > > a_r1za_entry() // [] > { info_tbl: [(c1Cm, > label: a_r1za_info > rep:HeapRep static { Fun {arity: 1 fun_type: > ArgSpec 3} })] > stack_info: arg_space: 8 updfr_space: Just 8 > } > {offset > c1Cm: > goto c1Cq; > c1Cq: > Hp = Hp + 152; > if (Hp > HpLim) goto c1Cs; else goto c1Cr; > c1Cs: > HpAlloc = 152; > goto c1Cp; > c1Cp: > R1 = a_r1za_closure; > call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; > c1Cr: > I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; > I64[Hp - 136] = 16; > I64[Hp - 128] = 16; > _c1C6::I64 = Hp - 144; > _c1C7::I64 = _c1C6::I64 + 24; > goto c1C8; > c1C8: > if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; > c1Ca: > P64[_c1C7::I64] = ()_closure+1; > _c1C7::I64 = _c1C7::I64 + 8; > goto c1C8; > c1C9: > _c1Cb::I64 = _c1C6::I64 + 24; > _c1Cc::I64 = _c1Cb::I64 + 128; > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); > _s1BY::P64 = _c1C6::I64; > _s1BY::P64 = _s1BY::P64; > _s1C1::P64 = _s1BY::P64; > R1 = ()_closure+1; > call (P64[Sp])(R1) args: 8, res: 0, upd: 8; > } > } > > ==================== Post CPS Cmm ==================== > 2014-03-08 08:25:31.731772 UTC > > [section "data" { > a_r1za_closure: > const a_r1za_info; > }, > a_r1za_entry() // [] > { info_tbl: [(c1Cm, > label: a_r1za_info > rep:HeapRep static { Fun {arity: 1 fun_type: > ArgSpec 3} })] > stack_info: arg_space: 8 updfr_space: Just 8 > } > {offset > c1Cm: > goto c1Cq; > c1Cq: > Hp = Hp + 152; > if (Hp > HpLim) goto c1Cs; else goto c1Cr; > c1Cs: > HpAlloc = 152; > goto c1Cp; > c1Cp: > R1 = a_r1za_closure; > call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; > c1Cr: > I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; > I64[Hp - 136] = 16; > I64[Hp - 128] = 16; > _c1C6::I64 = Hp - 144; > _c1C7::I64 = _c1C6::I64 + 24; > goto c1C8; > c1C8: > if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto > c1C9; > c1Ca: > P64[_c1C7::I64] = ()_closure+1; > _c1C7::I64 = _c1C7::I64 + 8; > goto c1C8; > c1C9: > _c1Cb::I64 = _c1C6::I64 + 24; > _c1Cc::I64 = _c1Cb::I64 + 128; > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, > _c1Cf::I64); > _s1BY::P64 = _c1C6::I64; > _s1BY::P64 = _s1BY::P64; > _s1C1::P64 = _s1BY::P64; > R1 = ()_closure+1; > call (P64[Sp])(R1) args: 8, res: 0, upd: 8; > } > }] > > ==================== Output Cmm ==================== > 2014-03-08 08:25:31.73228 UTC > > [section "data" { > a_r1za_closure: > const a_r1za_info; > }, > a_r1za_entry() // [] > { info_tbl: [(c1Cm, > label: a_r1za_info > rep:HeapRep static { Fun {arity: 1 fun_type: > ArgSpec 3} })] > stack_info: arg_space: 8 updfr_space: Just 8 > } > {offset > c1Cm: > goto c1Cq; > c1Cq: > Hp = Hp + 152; > if (Hp > HpLim) goto c1Cs; else goto c1Cr; > c1Cs: > HpAlloc = 152; > goto c1Cp; > c1Cp: > R1 = a_r1za_closure; > call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; > c1Cr: > I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; > I64[Hp - 136] = 16; > I64[Hp - 128] = 16; > _c1C6::I64 = Hp - 144; > _c1C7::I64 = _c1C6::I64 + 24; > goto c1C8; > c1C8: > if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto > c1C9; > c1Ca: > P64[_c1C7::I64] = ()_closure+1; > _c1C7::I64 = _c1C7::I64 + 8; > goto c1C8; > c1C9: > _c1Cb::I64 = _c1C6::I64 + 24; > _c1Cc::I64 = _c1Cb::I64 + 128; > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, > _c1Cf::I64); > _s1BY::P64 = _c1C6::I64; > _s1BY::P64 = _s1BY::P64; > _s1C1::P64 = _s1BY::P64; > R1 = ()_closure+1; > call (P64[Sp])(R1) args: 8, res: 0, upd: 8; > } > }] > }}} > > .dump-opt-cmm file: > {{{ > ==================== Optimised Cmm ==================== > 2014-03-08 08:25:31.732971 UTC > > a_r1za_entry() // [] > { [(c1Cm, > a_r1za_info: > const 4294967299; > const 0; > const 15;)] > } > {offset > c1Cm: > goto c1Cq; > c1Cq: > Hp = Hp + 152; > if (Hp > I64[BaseReg + 856]) goto c1Cs; else goto c1Cr; > c1Cs: > I64[BaseReg + 904] = 152; > goto c1Cp; > c1Cp: > R1 = PicBaseReg + a_r1za_closure; > call (I64[BaseReg - 8])(R1) args: 8, res: 0, upd: 8; > c1Cr: > I64[Hp - 144] = I64[PicBaseReg + > stg_MUT_ARR_PTRS_DIRTY_info at GOTPCREL]; > I64[Hp - 136] = 16; > I64[Hp - 128] = 16; > _c1C6::I64 = Hp - 144; > _c1C7::I64 = _c1C6::I64 + 24; > goto c1C8; > c1C8: > if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; > c1Ca: > I64[_c1C7::I64] = PicBaseReg + (()_closure+1); > _c1C7::I64 = _c1C7::I64 + 8; > goto c1C8; > c1C9: > _c1Cb::I64 = _c1C6::I64 + 24; > _c1Cc::I64 = _c1Cb::I64 + 128; > _c1Cd::I64 = 0; > _c1Ce::I64 = 0; > _c1Cf::I64 = 8; > call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); > _s1BY::P64 = _c1C6::I64; > // nop > _s1C1::P64 = _s1BY::P64; > R1 = PicBaseReg + (()_closure+1); > call (P64[Sp])(R1) args: 8, res: 0, upd: 8; > } > } > }}} New description: The optimizer seems to miss very basic optimizations. For example, look at this segment (full source below): {{{ _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); }}} I'd expect all these temporaries (that are only used once) to be inlined, but they are not and thus we fail to see the static arguments to the `MO_Memset` call, which leads to further missed optimizations. This used to work in the old codegen. Furthermore, there are useless basic blocks in the output: {{{ c1Cm: goto c1C4; c1C4: }}} I'd expect them to be eliminated. Here's another non-sensical sequence: {{{ _s1BY::P64 = _c1C6::I64; // nop _s1C1::P64 = _s1BY::P64; }}} Neither of these temporaries are ever used. .dump-cmm file: {{{ ==================== Cmm produced by new codegen ==================== 2014-03-08 08:25:31.728672 UTC [section "data" { a_r1za_closure: const a_r1za_info; }, a_r1za_entry() // [] { info_tbl: [(c1Cm, label: a_r1za_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 3} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c1Cm: goto c1C4; c1C4: if ((old + 0) - < SpLim) goto c1Cp; else goto c1Cq; c1Cq: goto c1C3; c1C3: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; goto c1Ch; c1Ch: _s1C1::P64 = _s1BY::P64; goto c1Ck; c1Ck: R1 = ()_closure+1; call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; } }] ==================== Post control-flow optimisations ==================== 2014-03-08 08:25:31.729764 UTC {offset c1Cm: if ((old + 0) - < SpLim) goto c1Cp; else goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; } ==================== Layout Stack ==================== 2014-03-08 08:25:31.730253 UTC {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } ==================== CAFEnv ==================== 2014-03-08 08:25:31.73074 UTC [(c1C8, {}), (c1C9, {}), (c1Ca, {}), (c1Cm, {}), (c1Cp, {}), (c1Cq, {}), (c1Cr, {}), (c1Cs, {})] ==================== after setInfoTableStackMap ==================== 2014-03-08 08:25:31.730895 UTC a_r1za_entry() // [] { info_tbl: [(c1Cm, label: a_r1za_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 3} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } } ==================== Post control-flow optimisations ==================== 2014-03-08 08:25:31.731383 UTC a_r1za_entry() // [] { info_tbl: [(c1Cm, label: a_r1za_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 3} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } } ==================== Post CPS Cmm ==================== 2014-03-08 08:25:31.731772 UTC [section "data" { a_r1za_closure: const a_r1za_info; }, a_r1za_entry() // [] { info_tbl: [(c1Cm, label: a_r1za_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 3} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }] ==================== Output Cmm ==================== 2014-03-08 08:25:31.73228 UTC [section "data" { a_r1za_closure: const a_r1za_info; }, a_r1za_entry() // [] { info_tbl: [(c1Cm, label: a_r1za_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 3} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > HpLim) goto c1Cs; else goto c1Cr; c1Cs: HpAlloc = 152; goto c1Cp; c1Cp: R1 = a_r1za_closure; call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = stg_MUT_ARR_PTRS_DIRTY_info; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: P64[_c1C7::I64] = ()_closure+1; _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; _s1BY::P64 = _s1BY::P64; _s1C1::P64 = _s1BY::P64; R1 = ()_closure+1; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }] }}} .dump-opt-cmm file: {{{ ==================== Optimised Cmm ==================== 2014-03-08 08:25:31.732971 UTC a_r1za_entry() // [] { [(c1Cm, a_r1za_info: const 4294967299; const 0; const 15;)] } {offset c1Cm: goto c1Cq; c1Cq: Hp = Hp + 152; if (Hp > I64[BaseReg + 856]) goto c1Cs; else goto c1Cr; c1Cs: I64[BaseReg + 904] = 152; goto c1Cp; c1Cp: R1 = PicBaseReg + a_r1za_closure; call (I64[BaseReg - 8])(R1) args: 8, res: 0, upd: 8; c1Cr: I64[Hp - 144] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info at GOTPCREL]; I64[Hp - 136] = 16; I64[Hp - 128] = 16; _c1C6::I64 = Hp - 144; _c1C7::I64 = _c1C6::I64 + 24; goto c1C8; c1C8: if (_c1C7::I64 < (_c1C6::I64 + 128)) goto c1Ca; else goto c1C9; c1Ca: I64[_c1C7::I64] = PicBaseReg + (()_closure+1); _c1C7::I64 = _c1C7::I64 + 8; goto c1C8; c1C9: _c1Cb::I64 = _c1C6::I64 + 24; _c1Cc::I64 = _c1Cb::I64 + 128; _c1Cd::I64 = 0; _c1Ce::I64 = 0; _c1Cf::I64 = 8; call MO_Memset(_c1Cc::I64, _c1Cd::I64, _c1Ce::I64, _c1Cf::I64); _s1BY::P64 = _c1C6::I64; // nop _s1C1::P64 = _s1BY::P64; R1 = PicBaseReg + (()_closure+1); call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } } }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 10:11:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 10:11:18 -0000 Subject: [GHC] #8860: Optimized Cmm isn't In-Reply-To: <044.d8a17d1b07c8c531c3d4d1cbd7ad96ef@haskell.org> References: <044.d8a17d1b07c8c531c3d4d1cbd7ad96ef@haskell.org> Message-ID: <059.d26ab62c4b65e0d5ec9d3dd30e9144f0@haskell.org> #8860: Optimized Cmm isn't -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Are you sure you were compiling with -O? I don't see the output of `CmmSink` here, which is where most optimisations are performed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 10:23:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 10:23:04 -0000 Subject: [GHC] #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory In-Reply-To: <044.398377c33d022955e6b200df91088795@haskell.org> References: <044.398377c33d022955e6b200df91088795@haskell.org> Message-ID: <059.f2238b8fefbdfef5104aade332bb1e9b@haskell.org> #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory -----------------------------------+---------------------------------- Reporter: awson | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by simonmar): * owner: simonmar => thoughtpolice Comment: Looks good! Austin, could you commit + merge? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 10:23:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 10:23:47 -0000 Subject: [GHC] #8860: Optimized Cmm isn't In-Reply-To: <044.d8a17d1b07c8c531c3d4d1cbd7ad96ef@haskell.org> References: <044.d8a17d1b07c8c531c3d4d1cbd7ad96ef@haskell.org> Message-ID: <059.2b7fafdffb20f00d9e0b46312c24482c@haskell.org> #8860: Optimized Cmm isn't -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tibbe): * status: new => closed * resolution: => invalid Comment: Apologies for being stupid. I wasn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 16:03:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 16:03:55 -0000 Subject: [GHC] #8861: Use commas to separate thousands when printing memory stats Message-ID: <046.e21545148e081f7f07857eb0bed3fa24@haskell.org> #8861: Use commas to separate thousands when printing memory stats -------------------------------------------+------------------------------- Reporter: ErlendH | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- In GHCi, by enabling printing of timing/memory stats after each evaluation (`:set +s`), the memory stats is printed in bytes. When this number is quite large, it's hard to see ? at a glance ? how much memory was used. It would be nicer if this was printed as ?1,200,000 bytes? instead of ?1200000 bytes? as is the case now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 16:05:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 16:05:29 -0000 Subject: [GHC] #8861: Use commas to separate thousands when printing memory stats In-Reply-To: <046.e21545148e081f7f07857eb0bed3fa24@haskell.org> References: <046.e21545148e081f7f07857eb0bed3fa24@haskell.org> Message-ID: <061.66672d454ecc9689fe5f22eb964a762a@haskell.org> #8861: Use commas to separate thousands when printing memory stats -------------------------------+------------------------------------------- Reporter: ErlendH | Owner: Type: feature | Status: patch request | Milestone: Priority: lowest | Version: 7.6.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by ErlendH): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 16:17:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 16:17:11 -0000 Subject: [GHC] #8861: Use commas to separate thousands when printing memory stats In-Reply-To: <046.e21545148e081f7f07857eb0bed3fa24@haskell.org> References: <046.e21545148e081f7f07857eb0bed3fa24@haskell.org> Message-ID: <061.35534f3e53360e6922d31c1ec8cb2be6@haskell.org> #8861: Use commas to separate thousands when printing memory stats -------------------------------+------------------------------------------- Reporter: ErlendH | Owner: Type: feature | Status: patch request | Milestone: Priority: lowest | Version: 7.6.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by tibbe): I believe there are tools (e.g. nofib-analyse) that rely on the current format. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 16:47:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 16:47:27 -0000 Subject: [GHC] #8861: Use commas to separate thousands when printing memory stats In-Reply-To: <046.e21545148e081f7f07857eb0bed3fa24@haskell.org> References: <046.e21545148e081f7f07857eb0bed3fa24@haskell.org> Message-ID: <061.f48d4b16bb21074f187575693f48c1d2@haskell.org> #8861: Use commas to separate thousands when printing memory stats -------------------------------+------------------------------------------- Reporter: ErlendH | Owner: Type: feature | Status: patch request | Milestone: Priority: lowest | Version: 7.6.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by rwbarton): `./prog +RTS -s` already prints the memory stats with commas, can you reuse whatever code does the formatting there? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 17:17:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 17:17:04 -0000 Subject: [GHC] #8861: Use commas to separate thousands when printing memory stats In-Reply-To: <046.e21545148e081f7f07857eb0bed3fa24@haskell.org> References: <046.e21545148e081f7f07857eb0bed3fa24@haskell.org> Message-ID: <061.16a87cb615fbea9ea892792a6ce01888@haskell.org> #8861: Use commas to separate thousands when printing memory stats -------------------------------+------------------------------------------- Reporter: ErlendH | Owner: Type: feature | Status: patch request | Milestone: Priority: lowest | Version: 7.6.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by ErlendH): tibbe: Good point. I did a quick check, running nofib and looking at the output. The file's `<` blocks still had memory usage printed without the commas, e.g. `<`. I haven't looked at nofib before, though, so take this with a grain of salt. rwbarton: Thanks for the tip. I'll have a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 17:22:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 17:22:17 -0000 Subject: [GHC] #8862: forkProcess does not play well with heap or time profiling Message-ID: <046.14699df7590583195621e0368f3a21c0@haskell.org> #8862: forkProcess does not play well with heap or time profiling --------------------------+------------------------------------------------ Reporter: | Owner: simonmar bennofs | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Runtime System | Type of failure: Incorrect result at runtime Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ This is similar to #4512. When doing heap or time profiling, the forked process and the parent process both write to the same `.hp` or `.prof` file. I think this also applies to program coverage using hpc (didn't test this). I was able to reproduce the bug with the attached source code, but some other people were not. Just run `space-profiling +RTS -h` and try to convert the generated heap profile using `hp2ps`, I get the following error message: {{{ hp2ps: space-profiling.hp, line 186: integer must follow identifier }}} I attached the generated hp file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 17:27:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 17:27:04 -0000 Subject: [GHC] #8862: forkProcess does not play well with heap or time profiling In-Reply-To: <046.14699df7590583195621e0368f3a21c0@haskell.org> References: <046.14699df7590583195621e0368f3a21c0@haskell.org> Message-ID: <061.f33dd8573428e14ee065afe3f6ece814@haskell.org> #8862: forkProcess does not play well with heap or time profiling ------------------------------------------------+-------------------------- Reporter: bennofs | Owner: Type: bug | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Resolution: | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by bennofs): Side-note: I compiled the program without profiling enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 17:27:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 17:27:48 -0000 Subject: [GHC] #8862: forkProcess does not play well with heap or time profiling In-Reply-To: <046.14699df7590583195621e0368f3a21c0@haskell.org> References: <046.14699df7590583195621e0368f3a21c0@haskell.org> Message-ID: <061.020e9998bf855f82177c12b3ae9518ce@haskell.org> #8862: forkProcess does not play well with heap or time profiling ------------------------------------------------+-------------------------- Reporter: bennofs | Owner: Type: bug | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Resolution: | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by rwbarton): Are you using the threaded runtime? Maybe it would make sense for the profiling subsystem to use `pthread_atfork` to ensure that the `.hp` file is closed in any child processes? (Does that exist on Windows?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 18:14:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 18:14:01 -0000 Subject: [GHC] #8862: forkProcess does not play well with heap or time profiling In-Reply-To: <046.14699df7590583195621e0368f3a21c0@haskell.org> References: <046.14699df7590583195621e0368f3a21c0@haskell.org> Message-ID: <061.a59ccfdb15882abc5acef44d8b38655d@haskell.org> #8862: forkProcess does not play well with heap or time profiling ------------------------------------------------+-------------------------- Reporter: bennofs | Owner: Type: bug | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Resolution: | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by bennofs): I'm not using the threaded runtime. I think this is more difficult than just closing the .hp file. Wouldn't it make sense that the current cost centre stack is discarded in the child process, such that it behaves just like if the `IO` action passed to `forkProcess` was `main` ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 18:41:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 18:41:56 -0000 Subject: [GHC] #5925: Add inline version of newArray# In-Reply-To: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> References: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> Message-ID: <059.81d4ee6b72696afa09aacaf7d786eb75@haskell.org> #5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): I have something that works. I will post a patch later tonight. Benchmark: allocating 100,000,000 `MutableArray# ()` of size 16 in a loop. Best out of three runs for old implementation: {{{ $ time ./NewArraySlow real 0m2.741s user 0m2.696s sys 0m0.043s }}} Best out of three runs for new implementation: {{{ $ time ./NewArrayNew real 0m1.490s user 0m1.449s sys 0m0.041s }}} That's almost 2x faster. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 19:30:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 19:30:43 -0000 Subject: [GHC] #5925: Add inline version of newArray# In-Reply-To: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> References: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> Message-ID: <059.fb941b903129be9c4186ff1857c64a3b@haskell.org> #5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tibbe): * owner: => simonmar Comment: Simon, if you could point out any opportunities to break out code from `doNewArrayOp` into reusable allocation primitives that would be great. After this patch I want to support inline allocation in the clone array family of primops, so the more reusable the pieces are the better the code will look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 19:30:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 19:30:51 -0000 Subject: [GHC] #5925: Add inline version of newArray# In-Reply-To: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> References: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> Message-ID: <059.fbdf6af68d912ea9399704cf320c8501@haskell.org> #5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tibbe): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 19:36:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 19:36:36 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.f161938ebbee80c8afbaec2a6262f533@haskell.org> #8851: Standalone deriving and GND behave differently -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple deriving/should_compile/T8851 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by goldfire): * owner: goldfire => * milestone: => 7.8.1 Comment: I'm giving up ownership of this ticket as I'm not sure how to proceed without guidance. With some advice in hand, I'm happy to take this on again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 20:15:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 20:15:57 -0000 Subject: [GHC] #8863: ghc 7.6.3: type parser accepts => as -> (sometimes) Message-ID: <046.e79248f100ae76cb85a2a667cffc6322@haskell.org> #8863: ghc 7.6.3: type parser accepts => as -> (sometimes) --------------------------+------------------------------------------------ Reporter: | Owner: patrikj | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: | Operating System: Linux Compiler | Type of failure: GHC accepts invalid program Keywords: | Test Case: Architecture: x86_64 | Blocking: (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ The following examples are all parsed and type checked even though they don't seem to be conforming to the Haskell standard syntax: a :: Int => Int a = (1+) b :: a -> a => a b = const c :: Num a => [a => a => a] c = [(+)] Slight variations fail (as the should) - for example b' :: a -> b => a b' = const /Patrik ---- Linux cse-814009 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 20:33:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 20:33:39 -0000 Subject: [GHC] #8863: ghc 7.6.3: type parser accepts => as -> (sometimes) In-Reply-To: <046.e79248f100ae76cb85a2a667cffc6322@haskell.org> References: <046.e79248f100ae76cb85a2a667cffc6322@haskell.org> Message-ID: <061.912a1760ea830240e79b8ae494c30228@haskell.org> #8863: ghc 7.6.3: type parser accepts => as -> (sometimes) ------------------------------------------------+-------------------------- Reporter: patrikj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by hvr): * status: new => closed * os: Linux => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple * milestone: => 7.8.1 * resolution: => fixed Old description: > The following examples are all parsed and type checked even though they > don't seem to be conforming to the Haskell standard syntax: > > a :: Int => Int > a = (1+) > > b :: a -> a => a > b = const > > c :: Num a => [a => a => a] > c = [(+)] > > Slight variations fail (as the should) - for example > > b' :: a -> b => a > b' = const > > /Patrik > > ---- > > Linux cse-814009 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC > 2014 x86_64 x86_64 x86_64 GNU/Linux New description: The following examples are all parsed and type checked even though they don't seem to be conforming to the Haskell standard syntax: {{{#!haskell a :: Int => Int a = (1+) b :: a -> a => a b = const c :: Num a => [a => a => a] c = [(+)] }}} Slight variations fail (as the should) - for example {{{#!haskell b' :: a -> b => a b' = const }}} /Patrik ---- {{{ Linux cse-814009 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux }}} -- Comment: GHC 7.8.1-RC2 correctly detects all 3 cases as invalid grammar: {{{ t8863.hs:1:6: Expected a constraint, but ?Int? has kind ?*? In the type signature for ?a?: a :: Int => Int t8863.hs:4:11: Expected a constraint, but ?a? has kind ?*? In the type signature for ?b?: b :: a -> a => a t8863.hs:7:16: Expected a constraint, but ?a? has kind ?*? In the type signature for ?c?: c :: Num a => [a => a => a] }}} I'm therefore closing this as fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 21:32:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 21:32:35 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.e40baa24e46e5d9ec27c641711893e4f@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ---------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: None | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Comment (by awson): 1. I've reduced this case to the following: {{{ import qualified Data.ByteString.Char8 as BSS main :: IO () main = do cache <- BSS.readFile "00-index.cache" print (length $ BSS.lines cache) }}} `00-index.cache` is hackage packages cache file. Even truncated to 12000 lines it gives segfault. 2. After bisecting I've found the [https://github.com/ghc/ghc/commit/ad15c2b4bd37082ce989268b3d2f86a2cd34386a problematic commit]. I don't understand what is going here. I think I've made absolutely my best in this situation. Please, someone fix this! I feel myself completely alone fighting with numerous win64 bugs which nobody ever bother to look into. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 21:35:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 21:35:20 -0000 Subject: [GHC] #7478: setSessionDynFlags does not always work In-Reply-To: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> References: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> Message-ID: <059.1a09e1a80d545325219730f37a2dc9d7@haskell.org> #7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghc-api/T7478 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bennofs): Replying to [comment:11 MikolajKonarski]: > BTW, right now (I don't know how it was before) calling `setSessionDynFlags` causes significant memory leaks, visible already in tests with a couple hundred modules and calls. If anybody is interested, I can try to extract a test from my code that uses GHC API, but it's GHC version dependent, etc., so I'd rather not do it until anybody is actively looking at this. But it's straightforward: basically, in a loop: > > {{{ > setSessionDynFlags flags > setTargets yetAnotherSIngleModule > load LoadAllTargets > }}} > > > > Even if we load 100 of modules and then just keep reloading the same module, memory will increase all the time. I can confirm this. I have a workaround for that problem in https://github.com/bennofs/ghc- server/blob/master/src/Server/Configure.hs#L117, which suggests that the problem is with reloading the package database. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 23:08:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 23:08:19 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.e28855b2d5ec5f9e352317c5cc3335da@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by simonpj): Can you just try from scratch with `-fno-warm-amp`? I think that'll cure it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 8 23:25:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Mar 2014 23:25:03 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.a19d2fd83bfffe0587e8cf97350b4ee5@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ---------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: None | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Comment (by awson): Since things were changed since that commit, I've revised it and made manual reversal. This commit was mainly a set of comments, relevant changes were more or less local and I've created this reversal patch mechanically. I still don't understand underlying machinery, but it looks this patch makes things work again on win64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 07:09:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 07:09:38 -0000 Subject: [GHC] #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout Message-ID: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Documentation | 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: | ------------------------------------+------------------------------------- I'm having a hard time using the heap allocation functions in `StgCmmMonad` and `StgCmmLayout`, as they lack documentation. I'd be very grateful if someone could at least document: * `getHpRelOffset` * `setVirtHp` * `getVirtHp` To get an idea which questions I'm struggling with, I need to e.g. understand if the value returned by `getHpRelOffset` is affected by later calls to `setVirtHp`. This is probably obvious to some, but reading the code alone is not enough to get a good understanding how all the heap allocation code hangs together. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 07:15:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 07:15:04 -0000 Subject: [GHC] #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout In-Reply-To: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> References: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> Message-ID: <059.3a1582d836e0bd093d8005158dd2f253@haskell.org> #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Another question to help the documentation effort along: which functions change the real `Hp`? Knowing that would allow the programmer to reason about how long the value (a `CmmExpr`) returned by `getHpRelOffset` is valid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 07:18:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 07:18:34 -0000 Subject: [GHC] #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout In-Reply-To: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> References: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> Message-ID: <059.3059af3f85d1d04814d102c13b5fbcfa@haskell.org> #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Perhaps the writing from http://blog.ezyang.com/2013/09/of-monadic- fixpoints-and-heap-offsets/ could be integrated into the Haddocks? Having tutorial style material "to the side" is great, but GHC could use more API docs to make it more accessible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 08:36:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 08:36:49 -0000 Subject: [GHC] #8861: Use commas to separate thousands when printing memory stats In-Reply-To: <046.e21545148e081f7f07857eb0bed3fa24@haskell.org> References: <046.e21545148e081f7f07857eb0bed3fa24@haskell.org> Message-ID: <061.c4a5361a7423ed599d4bade06522c0e0@haskell.org> #8861: Use commas to separate thousands when printing memory stats -------------------------------+------------------------------------------- Reporter: ErlendH | Owner: Type: feature | Status: patch request | Milestone: Priority: lowest | Version: 7.6.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by ErlendH): The formatting code that prints bytes used when passing the `-s` switch to the RTS is in the RTS C code (`showStgWord64()` in `rts/RtsUtils.c`), so that code would probably be difficult to reuse. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 08:50:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 08:50:00 -0000 Subject: =?utf-8?q?=5BGHC=5D_=238865=3A_Cannot_derive_well-kinded_instanc?= =?utf-8?q?e_of_form_=E2=80=98Category?= Message-ID: <048.9835e0581238f6f4bbded51439894fae@haskell.org> #8865: Cannot derive well-kinded instance of form ?Category ----------------------------+---------------------------------------------- Reporter: | Owner: adinapoli | Status: new Type: bug | Milestone: 7.8.1 Priority: normal | Version: 7.8.1-rc2 Component: Compiler | Operating System: MacOS X Keywords: | Type of failure: GHC rejects valid program Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Hello everyone, sorry if this was already reported somewhere. I'm playing with GHC 7.8.1 RC2 and I'm updating hsenv to support GHC 7.8. This is a real code snippet, which was compiling fine in GHC 7.6.x {{{ newtype ArgArrow a b = ArgArrow (StaticArrowT KnownArgs (Kleisli (ReaderT Args IO)) a b) deriving (Category, Arrow, ArrowChoice) }}} but that yields the following in GHC 7.8.1-RC2 {{{ Cannot derive well-kinded instance of form ?Category (ArgArrow ...)? Class ?Category? expects an argument of kind ?k -> k -> *? In the newtype declaration for ?ArgArrow? }}} This might be related to the new feature of GHC 7.8, namely "kind variables" (you get the idea, even if the name is not 100% accurate). To make the code compile I had to enable {{{ StandaloneDeriving }}} and write the following: {{{ newtype ArgArrow a b = ArgArrow (StaticArrowT KnownArgs (Kleisli (ReaderT Args IO)) a b) deriving (Arrow, ArrowChoice) deriving instance Category ArgArrow }}} Is this by design or is a genuine bug? Thanks! Alfredo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 09:01:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 09:01:54 -0000 Subject: [GHC] #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" Message-ID: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" ----------------------------------+---------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- Hello everyone, sorry if this was reported somewhere else. I know that the dreadful "scavenge_stack" is nothing new, but it's the first time I see it on Mac OS X (I'm on Maverick, OS X 10.9.2). This is a "stacktrace" of the problem. It seems to happen almost consistently if I try to do a parallel installation: {{{ [hsenv]? ~HSENV cabal install -j snap Resolving dependencies... Configuring HUnit-1.2.5.2... Downloading MonadRandom-0.1.13... Downloading logict-0.6.0.2... cabal: internal error: scavenge_stack: weird activation record found on stack: 415597384 (GHC version 7.8.0.20140228 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [1] 2328 abort cabal install -j snap [hsenv]? ~HSENV }}} The concerning thing is that it doesn't seem to be deterministic. After issuing that command, I have tried again and it worked this time: {{{ [hsenv]? ~HSENV cabal install -j snap Resolving dependencies... Configuring HUnit-1.2.5.2... Downloading MonadRandom-0.1.13... Configuring SHA-1.6.4... Downloading logict-0.6.0.2... Downloading process-1.1.0.2... [...] }}} It seems to happen with every package and I have tried to install snap just for the sake of reproducing it. Thanks! ps. Cross-posted on Github into the cabal issue tracker: https://github.com/haskell/cabal/issues/1716 Alfredo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 09:02:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 09:02:18 -0000 Subject: [GHC] #5925: Add inline version of newArray# In-Reply-To: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> References: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> Message-ID: <059.d0c769387560d82a47a31a1b726df0e5@haskell.org> #5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): I've updated the patch to try to split out the array closure allocation code into a helper function. I'm currently trying to get validate to pass. If it helps reviewing, here's an output example. Input function: {{{#!haskell newArray :: IO () newArray = IO $ \s -> case newArray# 16# () s of (# s', arr #) -> (# s', () #) }}} Output Cmm: {{{ Main.newArray1_entry() // [] { [(c3fD, Main.newArray1_info: const 4294967299; const 0; const 15;)] } {offset c3fD: Hp = Hp + 160; if (Hp > I64[BaseReg + 856]) goto c3fH; else goto c3fG; c3fH: I64[BaseReg + 904] = 160; R1 = PicBaseReg + Main.newArray1_closure; call (I64[BaseReg - 8])(R1) args: 8, res: 0, upd: 8; c3fG: I64[Hp - 152] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info at GOTPCREL]; I64[Hp - 144] = 16; I64[Hp - 136] = 17; _c3fr::I64 = Hp - 152; _c3fs::I64 = _c3fr::I64 + 24; goto c3ft; c3ft: if (_c3fs::I64 < (_c3fr::I64 + 128)) goto c3fv; else goto c3fu; c3fv: I64[_c3fs::I64] = PicBaseReg + (GHC.Tuple.()_closure+1); _c3fs::I64 = _c3fs::I64 + 8; goto c3ft; c3fu: call MO_Memset(_c3fs::I64, 0, 1, 8); R1 = PicBaseReg + (GHC.Tuple.()_closure+1); call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 10:16:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 10:16:43 -0000 Subject: [GHC] #8867: newArray# fails to initialize card table correctly Message-ID: <044.37e67357715cbf019ab4d4ce4384fe21@haskell.org> #8867: newArray# fails to initialize card table correctly ------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | 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: | ------------------------------------+------------------------------------- `newArray#` doesn't initialize the card table correctly. It writes the init value to the card table instead of a zero. That happens to be harmless, but slightly inefficient. Consider the implementation of `newArray#` in [[GhcFile(rts/PrimOps.cmm)]]: {{{ stg_newArrayzh ( W_ n /* words */, gcptr init ) { W_ words, size; gcptr p, arr; again: MAYBE_GC(again); // the mark area contains one byte for each 2^MUT_ARR_PTRS_CARD_BITS words // in the array, making sure we round up, and then rounding up to a whole // number of words. size = n + mutArrPtrsCardWords(n); words = BYTES_TO_WDS(SIZEOF_StgMutArrPtrs) + size; ("ptr" arr) = ccall allocate(MyCapability() "ptr",words); TICK_ALLOC_PRIM(SIZEOF_StgMutArrPtrs, WDS(n), 0); SET_HDR(arr, stg_MUT_ARR_PTRS_DIRTY_info, CCCS); StgMutArrPtrs_ptrs(arr) = n; StgMutArrPtrs_size(arr) = size; // Initialise all elements of the the array with the value in R2 p = arr + SIZEOF_StgMutArrPtrs; for: if (p < arr + WDS(words)) { W_[p] = init; p = p + WDS(1); goto for; } // Initialise the mark bits with 0 for2: if (p < arr + WDS(size)) { W_[p] = 0; p = p + WDS(1); goto for2; } return (arr); } }}} The second for-loop never gets executed, as `size` < `words`. The first predicate should check `p < arr + SIZEOF_StgMutArrPtrs + WDS(n)` and the second should be `p < arr + WDS(words)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 10:35:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 10:35:49 -0000 Subject: [GHC] #5925: Add inline version of newArray# In-Reply-To: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> References: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> Message-ID: <059.0b4242d9764c87dbf89cb36cfa1dfef7@haskell.org> #5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): I managed to replicate a bug (#8867) in the out-of-line implementation. I've updated the attachment so the inline version doesn't have this bug. Now the Cmm generated for the example Haskell code above is: {{{ Main.newArray1_entry() // [] { [(c3fD, Main.newArray1_info: const 4294967299; const 0; const 15;)] } {offset c3fD: Hp = Hp + 160; if (Hp > I64[BaseReg + 856]) goto c3fH; else goto c3fG; c3fH: I64[BaseReg + 904] = 160; R1 = PicBaseReg + Main.newArray1_closure; call (I64[BaseReg - 8])(R1) args: 8, res: 0, upd: 8; c3fG: I64[Hp - 152] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info at GOTPCREL]; I64[Hp - 144] = 16; I64[Hp - 136] = 17; _c3fr::I64 = Hp - 152; _c3fs::I64 = _c3fr::I64 + 24; goto c3ft; c3ft: if (_c3fs::I64 < (_c3fr::I64 + 152)) goto c3fv; else goto c3fu; c3fv: I64[_c3fs::I64] = PicBaseReg + (GHC.Tuple.()_closure+1); _c3fs::I64 = _c3fs::I64 + 8; goto c3ft; c3fu: call MO_Memset(_c3fs::I64, 0, 1, 8); R1 = PicBaseReg + (GHC.Tuple.()_closure+1); call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } } }}} One question: even if the card table only uses one byte, do I have to zero out the whole word allocated for it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 12:13:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 12:13:35 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.24ed4777fb0c044a4f06ba86ec112cd6@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ---------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: None | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Changes (by awson): * status: new => patch Comment: I've tested this reversal patch and all works fine. Moreover, it is not platform-specific, so it probably fix other weird segfaults on other platforms. That [https://github.com/ghc/ghc/commit/ad15c2b4bd37082ce989268b3d2f86a2cd34386a problematic commit] is particularly suspicious because if gets rid of `callerSaves` - the only explicitly platform-specific function used in `CmmSink.hs`. That looks very strange. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 14:28:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 14:28:18 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.52ac79eabca86d07aff189149b0a34b1@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by awson): * failure: None/Unknown => Runtime crash * component: None => Compiler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 14:34:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 14:34:51 -0000 Subject: [GHC] #8867: newArray# fails to initialize card table correctly In-Reply-To: <044.37e67357715cbf019ab4d4ce4384fe21@haskell.org> References: <044.37e67357715cbf019ab4d4ce4384fe21@haskell.org> Message-ID: <059.fd61b1942494e5cbba5525da92065c3e@haskell.org> #8867: newArray# fails to initialize card table correctly -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): A possible second bug: we (should) set all mark bits to zero. Why do we then mark the array as dirty by using thr `stg_MUT_ARR_PTRS_DIRTY_info` info pointer? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 14:55:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 14:55:06 -0000 Subject: [GHC] #8868: Old information in Extensions to data types and type synonyms Message-ID: <048.c300fb88d6d104dbe2190663e186986f@haskell.org> #8868: Old information in Extensions to data types and type synonyms ------------------------------------+-------------------------------------- Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- The Release notes for version 7.6.1 says http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/release-7-6-1.html The behavior of the TypeOperator extension has changed: previously, only type operators starting with ":" were considered type constructors, and other operators were treated as type variables. Now type operators are always constructors. But this change isn't reflected in the User's Guide. http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/data-type- extensions.html http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/data-type- extensions.html http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/data-type- extensions.html A type variable can be an (unqualified) operator e.g. +. The lexical syntax is the same as that for variable operators, excluding "(.)", "(!)", and "(*)". In a binding position, the operator must be parenthesised. For example: ... I think this paragraph should be removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 15:19:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 15:19:46 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.a31b08cdc9211f0d4da4ae9f3a4aa80b@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by refold): Would be nice if @jstolarek (the author of that commit) could comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 16:03:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 16:03:32 -0000 Subject: [GHC] #8868: Old information in Extensions to data types and type synonyms In-Reply-To: <048.c300fb88d6d104dbe2190663e186986f@haskell.org> References: <048.c300fb88d6d104dbe2190663e186986f@haskell.org> Message-ID: <063.c7ea7efac0fa888bd4b7a2b937216503@haskell.org> #8868: Old information in Extensions to data types and type synonyms --------------------------------------+------------------------------------ Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by carter): * version: 7.6.1 => 7.8.1-rc2 * milestone: => 7.8.1 Comment: It looks like this isn't reflected in the new documention http://www.haskell.org/ghc/docs/7.8.1-rc1/html/users_guide/data-type- extensions.html#type-operators how would you propose changing the language? Or is the language correct as is? see eg ` A type constructor or class can be an operator, beginning with a colon; e.g. :*:. The lexical syntax is the same as that for data constructors. ` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 16:17:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 16:17:45 -0000 Subject: [GHC] #5925: Add inline version of newArray# In-Reply-To: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> References: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> Message-ID: <059.e42cbe1ad48f8da1ffe0e9657a6c8723@haskell.org> #5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Also added a version for byte arrays. See second patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 16:55:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 16:55:46 -0000 Subject: [GHC] #8869: External preprocessor not used after TH name quote Message-ID: <044.78a0e759e53b632af74576f5fba0eb9c@haskell.org> #8869: External preprocessor not used after TH name quote ----------------------------------+-------------------------- Reporter: myrix | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+-------------------------- Module {{{ {-# LANGUAGE CPP, TemplateHaskell #-} module Main where main = do putStrLn $ show 'id putStrLn __FILE__ }}} fails to compile with external preprocessor: {{{ > ghc -pgmP cpphs -optP --cpp Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:7:12: Not in scope: `__FILE__' }}} {{{__FILE__}}} is not expanded: {{{ > ghc -E -pgmP cpphs -optP --cpp Main.hs > cat Main.hspp {-# LINE 1 "Main.hs" #-} #line 1 "Main.hs" {-# LANGUAGE CPP, TemplateHaskell #-} module Main where main = do putStrLn $ show 'id putStrLn __FILE__ }}} Without external preprocessor (just {{{ghc Main.hs}}}) module compiles successfully. Move name quote after {{{__FILE__}}}, like this: {{{ {-# LANGUAGE CPP, TemplateHaskell #-} module Main where main = do putStrLn __FILE__ putStrLn $ show 'id }}} and it work with external preprocessor just fine: {{{ > ghc -pgmP cpphs -optP --cpp Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... > ./Main Main.hs GHC.Base.id }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 19:46:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 19:46:32 -0000 Subject: [GHC] #8867: newArray# fails to initialize card table correctly In-Reply-To: <044.37e67357715cbf019ab4d4ce4384fe21@haskell.org> References: <044.37e67357715cbf019ab4d4ce4384fe21@haskell.org> Message-ID: <059.0d3e33483dc82e88848486b3e2934299@haskell.org> #8867: newArray# fails to initialize card table correctly -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): the mark bits and the header are irrelevant for newly allocated arrays, so we could probably omit the initialisation of the card table altogether. I'll look into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 19:49:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 19:49:53 -0000 Subject: [GHC] #5925: Add inline version of newArray# In-Reply-To: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> References: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> Message-ID: <059.ba813cfc47500514eb28215f73389ed4@haskell.org> #5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Thanks, I started refactoring this yesterday. I want to move the knowledge about the array layout into `SMRep` (where the other heap- representation stuff is) as well as sharing the heap allocation code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 20:51:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 20:51:38 -0000 Subject: [GHC] #5925: Add inline version of newArray# In-Reply-To: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> References: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> Message-ID: <059.7183581a6e3ee90ec2b8229fc7613627@haskell.org> #5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Replying to [comment:21 simonmar]: > Thanks, I started refactoring this yesterday. I want to move the knowledge about the array layout into `SMRep` (where the other heap- representation stuff is) as well as sharing the heap allocation code. Great. If you refactor the code I wrote, make sure you get the latest patch as I fixed some bugs. The `newArray#` code now validates (haven't validated the `newByteArray#` version yet). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 21:42:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 21:42:23 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.f567fa7b62ef94d90041a8fa9ddca8f3@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by simonpj): * cc: simonmar, jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 9 21:46:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Mar 2014 21:46:40 -0000 Subject: [GHC] #8869: External preprocessor not used after TH name quote In-Reply-To: <044.78a0e759e53b632af74576f5fba0eb9c@haskell.org> References: <044.78a0e759e53b632af74576f5fba0eb9c@haskell.org> Message-ID: <059.92f699c10eeaa583f4187e74d05451ee@haskell.org> #8869: External preprocessor not used after TH name quote -----------------------------+---------------------------------- Reporter: myrix | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: I suspect that cpp treats the `'id` as opening a quotation, and doesn't interpret the __FILE__ inside that quote. So this isn't a bug in GHC, more just that cpp isn't doing what you want. Reopen if you think it's a bug in GHC Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 01:49:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 01:49:28 -0000 Subject: [GHC] #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" In-Reply-To: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> References: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> Message-ID: <063.77b4638c2c78efd13243979b17f8484e@haskell.org> #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" ----------------------------------+---------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by carter): which build of GHC did you use? Austin's official RC2 build? whats the output of your `ghc --info` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 04:33:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 04:33:16 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits Message-ID: <047.501c103c18990d0c768d860839513abc@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ----------------------------+--------------------------------------- Reporter: facundoq | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------------- Windows shows a window that says "GHC has stopped working" when compiling a simple hello world. Steps to reproduce 1) Download GHC 7.8 RC2 (http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-i386 -unknown-mingw32.tar.bz2) 2) Extract the contents of the tar to folder $GHC$ 3) Add $GHC$\bin and $GHC$\mingw\bin folder to the PATH, add env var "LANG=C". 4) Create file test.hs with contents: main = putStrLn "Hello, World!" 5) run "ghc test.hs". Interestingly, the error is not deterministic, ie, after running the command several times the program gets compiled. When that happens, and ff the file test.o is not deleted, further attempts to compile run succesfully. GHCi appears to work normally (when doing simple tests). More details: http://stackoverflow.com/questions/22291739/cant-install-packages-with- cabal-using-ghc-7-8rc2-and-windows-7 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 06:05:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 06:05:47 -0000 Subject: [GHC] #8868: Old information in Extensions to data types and type synonyms In-Reply-To: <048.c300fb88d6d104dbe2190663e186986f@haskell.org> References: <048.c300fb88d6d104dbe2190663e186986f@haskell.org> Message-ID: <063.feaa8c3999f35d072f2a863cce158311@haskell.org> #8868: Old information in Extensions to data types and type synonyms --------------------------------------+------------------------------------ Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Documentation | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by Kinokkory): * version: 7.8.1-rc2 => 7.6.1 * milestone: 7.8.1 => ? Comment: I just would like to make the User's Guide faithful to the behavior of the GHC 7.6.*. I'm not talking about the behavior of the release candidate. (I believe ''symbol infix type variables'' should be legal, but I'm not sure.) The problem is whether the GHC accepts this code. {{{ type T (+) = Int + Int f :: T Either f = Left 3 liftA2 :: Arrow (~>) => (a -> b -> c) -> (e ~> a) -> (e ~> b) -> (e ~> c) liftA2 = ... }}} The User's Guide of GHC 7.8.1-rc1 says http://www.haskell.org/ghc/docs/7.8.1-rc1/html/users_guide/data-type- extensions.html#type-operators In types, an operator symbol like (+) is normally treated as a type variable, just like a. ... As you can see, using operators in this way is not very useful, and Haskell 98 does not even allow you to write them infix. So it seems that the new version's documentation have reflected the change. If GHC isn't willing to change the documentations of released versions, close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 07:21:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 07:21:18 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.f6448b1e1feac425155bca3e97df0988@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+----------------------------- Reporter: facundoq | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+----------------------------- Comment (by dreixel): I can reproduce this, and it actually always fails for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 07:48:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 07:48:21 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.5dcd0376c9d64fa0841d1b50f151c797@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): @awson thanks for all the diagnosis, sorry you have to be the one to do all this. I don't think there are any other regular developers building and testing on 64-bit Windows. I hope that when we get nightly builds working again things will improve. I think your analysis is right, that it is the change to `okToInline` that is at fault. Would you mind doing one more test for me? I'd like to know whether it still works if you don't revert the changes to `isTrivial`, which I believe should be fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 08:18:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 08:18:38 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.685c60c6cb523a05d89e9aa030064a59@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonpj): Could this account for #8870? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 08:23:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 08:23:30 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.ce674d81a7f4c5a3be7588404e304253@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+----------------------------- Reporter: facundoq | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+----------------------------- Comment (by simonpj): This looks serious. And it looks like it's the same as the problem I've been encountering when building on Window: http://www.haskell.org/pipermail/ghc-devs/2014-March/004189.html. Notice the crash happens for me after a couple of `CPSZ` messages have come out, same as reported above on !StackOverflow. But hello-world failing is much easier to track down than GHC itself failing. Could anyone git-bisect their way to the commit that did this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 08:34:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 08:34:06 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238865=3A_Cannot_derive_well-kinded_i?= =?utf-8?q?nstance_of_form_=E2=80=98Category?= In-Reply-To: <048.9835e0581238f6f4bbded51439894fae@haskell.org> References: <048.9835e0581238f6f4bbded51439894fae@haskell.org> Message-ID: <063.f513189823de3cc4ddfafcd44a5a5b49@haskell.org> #8865: Cannot derive well-kinded instance of form ?Category ----------------------------------------------+---------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: MacOS X | Keywords: Type of failure: GHC rejects valid program | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): I'd like to reproduce this, but need definition for `StaticArrowT`, `KnownArgs` etc. Can you add those definitions to the module, and give the complete source code for a module that shows the problem? Ideally, not depending on other libraries. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 08:36:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 08:36:17 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.ac6b1e5ff0f2f759293fd2f329d8ce85@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by jstolarek): awson, great bisecting job here! The intention behind the faulty commit is that both older and newer implementations are semantically identical (which turns out not to be the case) but the newer one avoids code duplication. > I think your analysis is right, that it is the change to okToInline that is at fault. Two other possibilities include: 1. `conflict` function 2. instance definition for `GlobalReg` datatype in [[GhcFile(compiler/cmm/CmmNode.hs)]] in the `DefinerOfRegs`. That's the place were we say what global registers are defined (and therefore clobbered) by each Cmm node. awson, to pin this bug we have to know the difference between correct and incorrect Cmm. Could you compile your minimal example with GHC HEAD (which will give us the segfaulting Cmm) and with your patched version (which will give us working Cmm) and upload them here? Dump the Cmm with `-ddump- cmm` flag. I see that you're calling `print` in your example. My experience is that it adds a lot of extra Cmm to analyse. Could you see if splitting your code into two modules also causes the bug: {{{ module T8834 where import qualified Data.ByteString.Char8 as BSS T8834 :: IO Int T8834 = do cache <- BSS.readFile "00-index.cache" return (length $ BSS.lines cache) }}} {{{ module Main where import T8834 main :: IO () main = T8834 >>= print }}} If this also causes the bug then most likely we only need Cmm dump for `T8834` module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 08:37:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 08:37:50 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238865=3A_Cannot_derive_well-kinded_i?= =?utf-8?q?nstance_of_form_=E2=80=98Category?= In-Reply-To: <048.9835e0581238f6f4bbded51439894fae@haskell.org> References: <048.9835e0581238f6f4bbded51439894fae@haskell.org> Message-ID: <063.c51d877026420cbe8e0888e09bd10aa1@haskell.org> #8865: Cannot derive well-kinded instance of form ?Category ----------------------------------------------+---------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: MacOS X | Keywords: Type of failure: GHC rejects valid program | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): Oh, don't worry, I can reproduce it with {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} module T8865 where import Control.Category newtype T a b = MkT (Either a b) deriving( Category ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 08:56:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 08:56:11 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.9fb4746b9d082d05a40a4c3b2dd23bff@haskell.org> #8851: Standalone deriving and GND behave differently -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple deriving/should_compile/T8851 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): I've reflected on this some more. First, standalone deriving has always been more aggressive than a deriving clause: * A deriving clause makes conservative checks that should ensure that the generated boilerplate code never fails to type check. * Standalone deriving makes weaker checks (enough to ensure that the boilerplate code can be generated in the first place), but then generates the code and risks that it might not typecheck. The reason for this is that it's too hard to predict exactly what will succeed; see #3102 for the origin of this change. The only down-side of the standalone-deriving story is that the error message may refer to (generated boilerplate) code that you didn't write. You could also argue that it's confusing to conflate (a) standalone vs attached-to-decl, with (b) conservative vs aggressive. Well, yes. After all, as you'll see from the description of this ticket, it confused even me and I wrote the implementation! Second, a deriving clause is not given the context of the instance declaration, so it has to infer it: {{{ data T a = T1 [a] | T2 (Tree a) deriving( Ord ) generates instance ( ??? ) => Ord (T a) where ... }}} We have to infer the `???`. It does this by generating (in this example) an `Ord` constraint for each constructor argument (in this case `(Ord [a], Ord (Tree a))`) and simplifying. But what we want for this `Coercible` case is not to ''infer'' a context, but rather to ''check'' that certain wanted constraints can be deduced from other given constraints, and to do so method-by-method. There is no code path to do this right now. Bottom line: we can always make the (necessarily-conservative) deriving- clause checks more permissive, but doing so adds code and complexity. I'm inclined instead to declare this case to be an example of where you must use a standalone-deriving clause. In short I propose no action. I'll update the user manual (which does mention this point) be more explicit. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 09:07:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 09:07:16 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.04d7c92318aab8f2becda16ec73de405@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): Well, separating to modules also causes the bug. I put Cmm dumps here. But is this enough? Could the bug manifest itself somewhere else (e. g. `base` or `bytestring` libraries)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 09:36:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 09:36:17 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238865=3A_Cannot_derive_well-kinded_i?= =?utf-8?q?nstance_of_form_=E2=80=98Category?= In-Reply-To: <048.9835e0581238f6f4bbded51439894fae@haskell.org> References: <048.9835e0581238f6f4bbded51439894fae@haskell.org> Message-ID: <063.13feb6b93102202ad4637a9cef4c091f@haskell.org> #8865: Cannot derive well-kinded instance of form ?Category ----------------------------------------------+---------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: MacOS X | Keywords: Type of failure: GHC rejects valid program | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by adinapoli): Just as well :) If you need the full source, just out of curiosity, it can be found, together with all the definitions, here: https://github.com/tmhedberg/hsenv -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 09:38:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 09:38:12 -0000 Subject: [GHC] #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" In-Reply-To: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> References: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> Message-ID: <063.a771f8816832f472fd784895f008ce7e@haskell.org> #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" ----------------------------------+---------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by adinapoli): Replying to [comment:1 carter]: > which build of GHC did you use? Austin's official RC2 build? Yes, it was Austin's official RC2 build for Mavericks. > whats the output of your `ghc --info` I don't have access to that machine now, I'll edit the ticket this evening adding the relevant info :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 09:47:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 09:47:28 -0000 Subject: [GHC] #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm Message-ID: <046.9e3184b9c42741faf5afebe36355ed9b@haskell.org> #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm ------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hello, on SPARC and I also guess on PPC it's possible to get following line in optimized Cmm code: {{{ I64[BaseReg + 784] = I64[BaseReg + 784]; }}} this line is then translated by NCG wasting 5 isns on SPARC at least. Don't know PPC. I'm not sure if this is possible to duplicate this on i386 due to fewer regs. Generally speaking you need to have 32bit target with more regs available. Interesting fact is that such line is not presented in non-optimized Cmm, but is presented in optimized one. Both optimized and non-optimized Cmms attached. Both get from compiling T7507 testcase by stage1 compiler on SPARC: {{{ /home/karel/vcs/ghc-src/ghc-sparc-reg_ncg/inplace/bin/ghc-stage1 -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7507.hs -O -ddump-opt-cmm > T7507.opt-cmm- sparc-reg-ncg }}} Of course non-opt Cmm is got by -ddump-cmm instead of -ddump-opt-cmm. If you need more simplified testcase, then following code is usable too: {{{ module Main where import Data.Int main = print ( ( 2 ^ 6 ) :: Int64 ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 09:50:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 09:50:15 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.4382083880fcb60b2833d08705489591@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------------- Changes (by simonpj): * owner: => thoughtpolice Comment: Just to amplify, the AMP warnings are switched off when `-XNoImplicitPrelude` is on, for reasons described in `Note [No AMP warning with NoImplicitPrelude]`. That means that `Control.Applicative`, and everything that might be compiled before it (ie that does not depend on it) should really be compiled with `-XNoImplicitPrelude`. But that is not the case, and I believe that's what is causing the trouble. Once we've verified that this is indeed the source of the trouble (comment 29) I suppose we can either * Do nothing, on the grounds that the entire AMP-warning stuff is going away in 7.9, once Applicative is a superclass of Monad. * Change the test to be "`-XNoImplicitPrelucde` or part of package `base`". * Ensure that `base` is compiled with `-fno-warn-amp`. The latter is probably the easiest, because it can be done by modifying `base.cabal`. Not a good long term fix, but the whole thing is only relevant to 7.8. I'm transferring ownership to Austin. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 09:51:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 09:51:04 -0000 Subject: [GHC] #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm In-Reply-To: <046.9e3184b9c42741faf5afebe36355ed9b@haskell.org> References: <046.9e3184b9c42741faf5afebe36355ed9b@haskell.org> Message-ID: <061.26d65e6d48a0262ec9f18232f00462c2@haskell.org> #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm -------------------------------------+------------------------------------ Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Are you using -O? Can you give your command line and output of `-ddump- cmm`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 09:54:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 09:54:09 -0000 Subject: [GHC] #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm In-Reply-To: <046.9e3184b9c42741faf5afebe36355ed9b@haskell.org> References: <046.9e3184b9c42741faf5afebe36355ed9b@haskell.org> Message-ID: <061.a25777cb0cbdf31b1e29c06ff3784f63@haskell.org> #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm -------------------------------------+------------------------------------ Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by kgardas): Replying to [comment:1 simonpj]: > Are you using -O? Can you give your command line and output of `-ddump- cmm`? Yes, see the command-line and also see attached files. BTW, I'm able to also reproduce this on PPC 32bit as I wrote. This is by using my simplified example above: {{{ $ grep "I64" T7507d_64-O-ppc.opt-cmm|grep Base I64[BaseReg + 784] = _s317::I64; I64[BaseReg + 784] = _s31d::I64; I64[BaseReg + 784] = 1 :: W64; I64[BaseReg + 784] = I64[BaseReg + 784]; I64[Hp - 4] = I64[BaseReg + 784]; I64[Sp - 8] = I64[BaseReg + 784]; }}} you see the line in the middle of grep... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 09:59:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 09:59:32 -0000 Subject: [GHC] #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm In-Reply-To: <046.9e3184b9c42741faf5afebe36355ed9b@haskell.org> References: <046.9e3184b9c42741faf5afebe36355ed9b@haskell.org> Message-ID: <061.d113ef9f17204bb72b58747192f83b23@haskell.org> #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm -------------------------------------+------------------------------------ Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by kgardas): Also for your reference this is slightly out-dated HEAD (master branch) where the last patch is: {{{ commit 018676c7f883886b388652c913c99a10d2591b0b Author: Herbert Valerio Riedel Date: Sun Feb 23 22:00:57 2014 +0100 Use U+2018 instead of U+201B quote mark in compiler messages This matches GCC's choice of Unicode quotation marks (i.e. U+2018 and U+2019) and therefore looks more familiar on the console. This addresses #2507. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 10:10:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 10:10:13 -0000 Subject: [GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster In-Reply-To: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> References: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> Message-ID: <060.44600618d7f4fa3aa5d6f2f788a3b4aa@haskell.org> #8766: length [Integer] is twice as slow but length [Int] is 10 times faster --------------------------------------------+------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: T8755 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * owner: nomeata => * status: closed => new * resolution: fixed => Comment: Hmm, this is not fully fixed, it seems. Consider {{{ f :: Integer -> Integer f n = n {-# NOINLINE f #-} main :: IO () main = sum (map f [0 .. 10000]) `seq` return () }}} Here, the rule {{{ {-# RULES "enumDeltaToInteger1" [0] forall c n x . enumDeltaToIntegerFB c n x 1 = up_fb c n x 1 #-} }}} does not fire and we end up with {{{ main3 :: Integer -> Integer main3 = enumDeltaToIntegerFB @ (Integer -> Integer) main6 (id @ Integer) main2 main5 main4 main5 :: Integer main5 = __integer 1 }}} and that despite that we have this code in `Phase = 0`: {{{ enumDeltaToIntegerFB @ (Integer -> Integer) (\ (x :: Integer) (ys [OS=OneShot] :: Integer -> Integer) -> let { ds [OS=ProbOneShot] :: Integer ds = f x } in \ (ds2 :: Integer) -> ys (plusInteger ds2 ds)) (id @ Integer) (__integer 0) (__integer 1) (__integer 10000) (__integer 0) }}} The rule engine is still a bit of a mystery to me. Why does the rule not match reliably here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 10:13:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 10:13:58 -0000 Subject: [GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster In-Reply-To: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> References: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> Message-ID: <060.6620f80bef6e09187b82561a7c9ae4bd@haskell.org> #8766: length [Integer] is twice as slow but length [Int] is 10 times faster --------------------------------------------+------------------------------ Reporter: George | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: T8755 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: Darn, ignore me. Used the binary from the wrong working copy. That?s what happens when I start work in `ghc-master/` that I don?t get to push right away, and `ghc/` becomes my working copy that tracks master... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 10:18:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 10:18:32 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.5e5ef0e86a015b0d3b735f5f839bd8e2@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): @simonmar, unreverting `isTrivial` brokes things again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 10:20:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 10:20:55 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.c84e3a17b137c584a2eb59861b7b3557@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by jstolarek): I see something that looks suspicious. In the correct version we have: {{{ c1zB: _r1xg::P64 = R1; if ((Sp + -16) < SpLim) goto c1zC; else goto c1zD; c1zC: R1 = _r1xg::P64; call (stg_gc_enter_1)(R1) args: 8, res: 0, upd: 8; c1zD: (_c1zx::I64) = call "ccall" arg hints: [PtrHint, PtrHint] result hints: [PtrHint] newCAF(BaseReg, _r1xg::P64); if (_c1zx::I64 == 0) goto c1zz; else goto c1zy; c1zz: call (I64[_r1xg::P64])() args: 8, res: 0, upd: 8; c1zy: I64[Sp - 16] = stg_bh_upd_frame_info; I64[Sp - 8] = _c1zx::I64; R2 = c1zA_str; Sp = Sp - 16; call GHC.CString.unpackCString#_info(R2) args: 24, res: 0, upd: 24; }}} In the incorrect one we have: {{{ c1zy: if ((Sp + -16) < SpLim) goto c1zz; else goto c1zA; c1zz: R1 = R1; call (stg_gc_enter_1)(R1) args: 8, res: 0, upd: 8; c1zA: (_c1zu::I64) = call "ccall" arg hints: [PtrHint, PtrHint] result hints: [PtrHint] newCAF(BaseReg, R1); if (_c1zu::I64 == 0) goto c1zw; else goto c1zv; c1zw: call (I64[R1])() args: 8, res: 0, upd: 8; c1zv: I64[Sp - 16] = stg_bh_upd_frame_info; I64[Sp - 8] = _c1zu::I64; R2 = c1zx_str; Sp = Sp - 16; call GHC.CString.unpackCString#_info(R2) args: 24, res: 0, upd: 24; }}} Notice how correct version saves `R1` to local variable. I'm especially worried about this call: {{{ call (I64[_r1xg::P64])() args: 8, res: 0, upd: 8; CORRECT.CMM call (I64[R1])() args: 8, res: 0, upd: 8; WRONG.CMM }}} '''If''' `R1` gets clobbered be earlier ccall to `newCAF(BaseReg, R1)` then this is probably the reason why things go wrong. In that case the right solution would be to tell GHC that the call to `newCAF` defines register `R1` (see `DefinerOfRegs` instance declaration for `GlobalReg`). Then this case should be caught by first guard in `conflicts`. Also, Note [Sinking and calls] seems very relevant here. As a side note: it is really annoying to see these `R1 = R1` assignments. I recall they are eliminated by the code generator but it is frustrating to see them at the Cmm level. I believe the sinking pass should eliminate these assignments but I didn't have enough time to investigate into this further during my internship. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 10:24:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 10:24:56 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.9cae4b0454852a5541432f11c32ef569@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by jstolarek): Replying to [comment:12 awson]: > @simonmar, unreverting `isTrivial` brokes things again. So this works: {{{ isTrivial :: CmmExpr -> Bool isTrivial (CmmReg _) = True isTrivial _ = False }}} but this doesn't: {{{ isTrivial :: CmmExpr -> Bool isTrivial (CmmReg (CmmLocal _)) = True isTrivial _ = False }}} ? I know this is slightly different from your patch (it ignores literals which I believe are irrelevant here). Again, would be nice to see differences in Cmm between the two. simonmar: could you tell us whether the call to `newCAF` clobbers `R1` ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 10:35:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 10:35:24 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.a4176c0cf8f9cdaec53d395d0bae9fe8@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): Replying to [comment:14 jstolarek]: > So this works: > > {{{ > isTrivial :: CmmExpr -> Bool > isTrivial (CmmReg _) = True > isTrivial _ = False > }}} > > but this doesn't: > > {{{ > isTrivial :: CmmExpr -> Bool > isTrivial (CmmReg (CmmLocal _)) = True > isTrivial _ = False > }}} Conversely. The first does not work, the second works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 11:02:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 11:02:05 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.009805425644b0b4169e0879d5c46562@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by jstolarek): > Conversely. The first does not work, the second works. Yes, you're right. It should be other way around. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 11:11:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 11:11:34 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.5e6d0f65addfc578d58572788b9d2f47@haskell.org> #8851: Standalone deriving and GND behave differently -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple deriving/should_compile/T8851 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9d14262299fe721e49eb0efadebca9d095c834b3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9d14262299fe721e49eb0efadebca9d095c834b3" Improve documentation of standalone deriving (c.f. Trac #8851) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 11:11:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 11:11:34 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238865=3A_Cannot_derive_well-kinded_i?= =?utf-8?q?nstance_of_form_=E2=80=98Category?= In-Reply-To: <048.9835e0581238f6f4bbded51439894fae@haskell.org> References: <048.9835e0581238f6f4bbded51439894fae@haskell.org> Message-ID: <063.26dbdc6a27e16aa54d7e55b9b917934f@haskell.org> #8865: Cannot derive well-kinded instance of form ?Category ----------------------------------------------+---------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: MacOS X | Keywords: Type of failure: GHC rejects valid program | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f521a26cb741409011137115d17232df901c3c94/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f521a26cb741409011137115d17232df901c3c94" Unify, rather than match, in GND processing (fixes Trac #8865) Yet another small way in which polymorphic kinds needs a bit of care See Note [Unify kinds in deriving] in TcDeriv }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 11:28:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 11:28:05 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238865=3A_Cannot_derive_well-kinded_i?= =?utf-8?q?nstance_of_form_=E2=80=98Category?= In-Reply-To: <048.9835e0581238f6f4bbded51439894fae@haskell.org> References: <048.9835e0581238f6f4bbded51439894fae@haskell.org> Message-ID: <063.c80d3e4d89eb9a901140a19ac1b9baa4@haskell.org> #8865: Cannot derive well-kinded instance of form ?Category ----------------------------------------------+---------------------------- Reporter: adinapoli | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | 7.8.1-rc2 Operating System: MacOS X | Keywords: Type of failure: GHC rejects valid program | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Fairly easy fix, fortunately. Thank you for reporting. It should be easy to merge, but it's a bit of a corner case, and we are really far into the 7.8 cycle, so it might be better not to Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 11:31:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 11:31:11 -0000 Subject: [GHC] #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm In-Reply-To: <046.9e3184b9c42741faf5afebe36355ed9b@haskell.org> References: <046.9e3184b9c42741faf5afebe36355ed9b@haskell.org> Message-ID: <061.941fb15234372eee1d332ee37a28dc9c@haskell.org> #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm -------------------------------------+------------------------------------ Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * cc: jstolarek, simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 11:56:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 11:56:45 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition In-Reply-To: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> References: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> Message-ID: <062.169f11b20a4c251f9c0b700784a63d8a@haskell.org> #8707: Kind inference fails in data instance definition -------------------------------------+------------------------------------ Reporter: goldfire | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I'm not sure of the problem here. It's true that, even with `-fprint- explicit-kinds` a promoted tuple data constructor is printed without its kind arguments, hence {{{ Data constructor ?SFalse? returns type ?SingDF Bool k '('False, Ctor k)? }}} Is that bad? When we pretty-print Core we print tuple terms without the type args, thus {{{ ('x', True) rather than (,) Char Bool 'x' True }}} Richard, re (2) why do you say that the error message is unhelpful compared to 7.6? Jan, how did you manage to get GHC to produce this? {{{ Data constructor `SFalse' returns type `SingDF Bool k ('(,) Bool (k -> *) 'False (Ctor k))' }}} That does look wrong. Can you explain how to reproduce it? Point (1) is another matter. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 12:01:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 12:01:15 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.53b4e0e1f48b33da011ea1ac8a94fdb3@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------------- Comment (by bernalex): Replying to [comment:29 simonpj]: > Can you just try from scratch with `-fno-warm-amp`? I think that'll cure it. Could you be more specific? What scratch? In base? What command? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 12:02:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 12:02:59 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition In-Reply-To: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> References: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> Message-ID: <062.142a56fe03253e62b0de275522af01c2@haskell.org> #8707: Kind inference fails in data instance definition -------------------------------------+------------------------------------ Reporter: goldfire | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by jstolarek): Replying to [comment:4 simonpj]: > Jan, how did you manage to get GHC to produce this? > {{{ > Data constructor `SFalse' returns type `SingDF > Bool k ('(,) Bool (k -> *) 'False (Ctor k))' > }}} > That does look wrong. Can you explain how to reproduce it? That is part of error message produced by GHC 7.6.3. As for this output: {{{ Data constructor ?SFalse? returns type ?SingDF Bool k '(Bool, k -> *, 'False, Ctor k)? }}} I made a quick hack in `pprTcApp` and replaced `ty_args = drop arity tys` with `ty_args = tys`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 12:04:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 12:04:20 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238865=3A_Cannot_derive_well-kinded_i?= =?utf-8?q?nstance_of_form_=E2=80=98Category?= In-Reply-To: <048.9835e0581238f6f4bbded51439894fae@haskell.org> References: <048.9835e0581238f6f4bbded51439894fae@haskell.org> Message-ID: <063.b7a14559f3de6f56598ce922b3403eec@haskell.org> #8865: Cannot derive well-kinded instance of form ?Category ----------------------------------------------+---------------------------- Reporter: adinapoli | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | 7.8.1-rc2 Operating System: MacOS X | Keywords: Type of failure: GHC rejects valid program | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by adinapoli): Glad I was useful. Happy to do my part on GHC, even if for some minor bug reporting :) Alfredo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 12:21:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 12:21:47 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.54334a77c8c4f83f0967410aeaa4c1fb@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): I think the bad code is much more likely to be in a library somewhere, not in the code that calls `readFile`/`lines`, so we're not going to see anything bad in that file. @jstolarek - R1 is not caller-saves (on either Linux or Win64), so it is safe to leave it live across a foreign call. Also, that code fragment is the standard `newCAF` call which appears everywhere, if this was broken then everything would be broken. I'm surprised that the change to `isTrivial` all by itself causes this failure. That must mean that there was something wrong with the code before the "bad patch", because the change to `isTrivial` should be safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 12:27:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 12:27:17 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition In-Reply-To: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> References: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> Message-ID: <062.96355663c18e6f4d06c3858a7e72b734@haskell.org> #8707: Kind inference fails in data instance definition -------------------------------------+------------------------------------ Reporter: goldfire | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Oh oh, so that message is not something can currently produce. Fine. Then my question remains: what's wrong with the status quo, for question (2)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 12:36:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 12:36:23 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.97d23a1b40a0a96b7f059e042398d510@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): It's looking more likely that there is a bug related to caller-saves registers somewhere else, and the change to `isTrivial` tickles it by making `CmmSink` more eager to inline `GlobalReg`s. This is affecting Win64 because that platform has a different C calling convention, with different caller-saves registers. So either we have a bad optimisation (probably in `CmmSink`), or the specification for what is a caller-saves reg on Win64 is wrong (`includes/stg/MachRegs.h`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 12:42:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 12:42:56 -0000 Subject: [GHC] #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm In-Reply-To: <046.9e3184b9c42741faf5afebe36355ed9b@haskell.org> References: <046.9e3184b9c42741faf5afebe36355ed9b@haskell.org> Message-ID: <061.5f0366f93646ab83d9227df9cd9f0201@haskell.org> #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm -------------------------------------+------------------------------------ Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Yes, this is just a missing optimisation. I didn't implement it because I hadn't seen any code that needed it, until now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 12:46:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 12:46:58 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.e223b7f65815b2ac74e9e643a4594b3a@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): Replying to [comment:17 simonmar]: > I'm surprised that the change to `isTrivial` all by itself causes this failure. That must mean that there was something wrong with the code before the "bad patch", because the change to `isTrivial` should be safe. It probably would worth to add that reverting `isTrivial` only does not help either. I. e. `isTrivial` all by itself broke things as they were before that bad commit, but changing *only* `isTrivial` to it's pre-commit state does not help either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 12:56:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 12:56:03 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.a78381a322c6d573e87644042905dccb@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): JFTR: I?m currently working on a presentation and short paper on this, and did some measurements, and found that while making `foldl` a good consumer has a nice effect on allocations (`-4.1%`, the overall effect on the runtime is negligible). Effect of Call Arity (with the original foldl): {{{ min mean max Allocations -1.3% -0.1% 0.0% Runtime -10.8% -0.9% +2.0% }}} Effect of Call Arity + defining foldl with foldr: {{{ min mean max Allocations -74.5% -4.1% 0.0% Runtime -10.4% -0.9% +1.7% }}} (Wishful thinking: Maybe there are real-world programs that would benefit more noticeably, but they are just not included in nofib) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 13:11:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 13:11:20 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition In-Reply-To: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> References: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> Message-ID: <062.d327559247571a2418e3e9b41f09fd27@haskell.org> #8707: Kind inference fails in data instance definition -------------------------------------+------------------------------------ Reporter: goldfire | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Richard, re (1), here's my analysis * For ordinary GADTs we first figure out the kind of the type constructor, and only then typecheck the constructor types. So this works fine: {{{ data SingDF (a :: (Bool, Bool -> *)) where SFalse :: SingDF '(False, Ctor) }}} We figure out the kind `SingDF :: (Bool, Bool -> *) -> *`, and only then typecheck the type of `SFalse`. So the use of `SingDF` in the type of the data constructor is fine. * But for a data family, the kind of the type constructor is polymorphic, in this case `SingDF :: forall k1,k1. (k1, k2 -> *) -> *`. When we use this kind in type-checking the type of `SFalse` we don't get any info from the `data instance` header. * And indeed if `SingDF` was used in a constructor ''argument'' we would want the polymorphic version: {{{ data instance SingDF (a :: (Bool, Bool) -> *) where SFalse :: SingDF (...blah...) -> SingDF '(False, Ctor) }}} Here the `(...blah...)` need not have kind `(Bool,Bool) -> *`. * So if we are to use the `data instance` header to inform the kind of the quantified type variables in the data constructor(s), we must treat the result type specially (`TcTyClsDecls.tcConRes`). * Currently we simply use `tcHsLiftedType`. I think to do the Right Thing we would need a special version of `TcHsType.tc_lhs_type`, expecially for data constructor result types. And this might be a Good Thing. Although it would mean a little code duplication, it might eliminate much of the delicacy in `Note [Checking GADT return types]` This is a bit of code you know quite well. Happy to discuss. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 13:15:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 13:15:01 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.479326e7b06db6a1b7a739fa739320cd@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonpj): Could this have anything to do with #8870, a much simpler case than Cabal? (As #8870 says, I can't even build a working stage-2 GHC on Windows now.) Both this and #8870 look like release blockers to me. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 13:41:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 13:41:41 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.be265597c2bb7fac11c21680532ec605@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): Replying to [comment:20 simonpj]: > Could this have anything to do with #8870, a much simpler case than Cabal? > > (As #8870 says, I can't even build a working stage-2 GHC on Windows now.) > > Both this and #8870 look like release blockers to me. > > Simon I can't reproduce #8870 using 32-bit GHC on 64-bin Windows. Are you using 32-bit Windows? If no, then your problem can be different from #8870 (but still related to #8834). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 14:00:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 14:00:41 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.034827222d9b95d9ba1a96d1eefc88db@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by thoughtpolice): * version: 7.8.1-rc1 => 7.8.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 14:00:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 14:00:47 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.899cef6684df46ae6cef0502e053beca@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Changes (by thoughtpolice): * version: 7.8.1-rc1 => 7.8.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 14:00:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 14:00:57 -0000 Subject: [GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error In-Reply-To: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> References: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> Message-ID: <066.b12902e5a972601e081183072f644896@haskell.org> #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error -------------------------------------+---------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by thoughtpolice): * version: 7.8.1-rc1 => 7.8.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 14:01:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 14:01:47 -0000 Subject: [GHC] #8736: GHCi doesn't load .dyn_o files appropriately In-Reply-To: <052.b282b771a49ddd09f40719b07cb558fa@haskell.org> References: <052.b282b771a49ddd09f40719b07cb558fa@haskell.org> Message-ID: <067.be284ed555df17b3eeb8f6db2b90bf9f@haskell.org> #8736: GHCi doesn't load .dyn_o files appropriately -------------------------------------+------------------------------------ Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 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 thoughtpolice): * version: 7.8.1-rc1 => 7.8.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 14:02:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 14:02:08 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.540682732ecffb4e50af9a8799cdcdc6@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 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 thoughtpolice): * version: 7.8.1-rc1 => 7.8.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 14:02:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 14:02:13 -0000 Subject: [GHC] #8831: Cannot use Template Haskell splice in ghci In-Reply-To: <047.1688ea3628125d840e5d96b182466527@haskell.org> References: <047.1688ea3628125d840e5d96b182466527@haskell.org> Message-ID: <062.187459e4310f821d5825e46e3cd64af0@haskell.org> #8831: Cannot use Template Haskell splice in ghci -------------------------------------+---------------------------------- Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by thoughtpolice): * version: 7.8.1-rc1 => 7.8.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 14:02:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 14:02:20 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.5d709f1dc25a883a20ba711a7d9be9e5@haskell.org> #8851: Standalone deriving and GND behave differently -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple deriving/should_compile/T8851 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * version: 7.8.1-rc1 => 7.8.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 14:09:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 14:09:38 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238865=3A_Cannot_derive_well-kinded_i?= =?utf-8?q?nstance_of_form_=E2=80=98Category?= In-Reply-To: <048.9835e0581238f6f4bbded51439894fae@haskell.org> References: <048.9835e0581238f6f4bbded51439894fae@haskell.org> Message-ID: <063.f50eb0ef1461532755b4b7a1a5e9eec1@haskell.org> #8865: Cannot derive well-kinded instance of form ?Category ----------------------------------------------+---------------------------- Reporter: adinapoli | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | 7.8.1-rc2 Operating System: MacOS X | Keywords: Type of failure: GHC rejects valid program | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by thoughtpolice): I'm somewhat inclined to think we actually should merge this. At the time the proposal to make `Category` PolyKinded was made, one of the nice parts was that it is essentially an invisible change to already existing code. In some sense I might argue that this is a regression, because while it involves a small 'change' that did not exist prior, it does cause GND over Category to fail in the wild, where it did not before. OTOH, I'm not sure how common the case of using GND to derive Category instances is - this is certainly the first time I've seen it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 14:12:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 14:12:17 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238865=3A_Cannot_derive_well-kinded_i?= =?utf-8?q?nstance_of_form_=E2=80=98Category?= In-Reply-To: <048.9835e0581238f6f4bbded51439894fae@haskell.org> References: <048.9835e0581238f6f4bbded51439894fae@haskell.org> Message-ID: <063.0308bbcbc20d01a0b8686c9fc7e40e79@haskell.org> #8865: Cannot derive well-kinded instance of form ?Category ----------------------------------------------+---------------------------- Reporter: adinapoli | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | 7.8.1-rc2 Operating System: MacOS X | Keywords: Type of failure: GHC rejects valid program | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by thoughtpolice): Oh, and really, Category isn't necessarily the only thing affected - per the test case, I would actually expect *anything* with a polymorphic kind inferred by `PolyKinds` being enabled will no longer be GND-able, which is quite a shame it would seem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 14:16:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 14:16:14 -0000 Subject: [GHC] #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout In-Reply-To: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> References: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> Message-ID: <059.253c602da1ba7df9150d81987099aeee@haskell.org> #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I've added this to `StgCmmMonad`: {{{ {- Note [Virtual and real heap pointers] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The code generator can allocate one or more objects contiguously, performing one heap check to cover allocation of all the objects at once. Let's call this little chunk of heap space an "allocation chunk". The code generator will emit code to * Perform a heap-exhaustion check * Move the heap pointer to the end of the allocation chunk * Allocate multiple objects within the chunk The code generator uses VirtualHpOffsets to address words within a single allocation chunk; these start at one and increase positively. The first word of the chunk has VirtualHpOffset=1, the second has VirtualHpOffset=2, and so on. * The field realHp tracks (the VirtualHpOffset) where the real Hp register is pointing. Typically it'll be pointing to the end of the allocation chunk. * The field virtHp gives the VirtualHpOffset of the highest-allocated word so far. It starts at zero (meaning no word has been allocated), and increases whenever an object is allocated. The difference between realHp and virtHp gives the offset from the real Hp register of a particular word in the allocation chunk. This is what getHpRelOffset does. }}} Does that help? If not, how can I clarify further? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 14:22:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 14:22:45 -0000 Subject: [GHC] #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout In-Reply-To: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> References: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> Message-ID: <059.c334698bf0a08c9a0ac27e91cf051729@haskell.org> #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): That does help. Clarifying the invariants (e.g. when does a value returned by `getHpRelOffset` become invalid) would also help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 14:28:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 14:28:28 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition In-Reply-To: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> References: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> Message-ID: <062.68aa986a169ee645b8772d5bbb119904@haskell.org> #8707: Kind inference fails in data instance definition -------------------------------------+------------------------------------ Reporter: goldfire | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by jstolarek): Thanks for all the detail Simon. I've been looking at this for the last two days trying to make sense of what is going on. I have a few newbie questions: 1. Kind checking type patterns (`TcTyClsDecls.tcFamTyPat` function called from `TcInstDcls.tcDataFamInstDecl`). Does the term "type patterns" refer to type parameters of a data family? 2. From looking at `traceTc` output I see that kind checking type patterns includes type checking (and also inferring?) type of `SFalse` constructor and its components (`False` and `Ctor`). Then GHC typechecks constructor declarations (`TcTyClsDecls.tcConDecls` called from `TcInstDcls.tcDataFamInstDecl`) where it again typechecks `SFalse` and its components. Why is this done twice? I believe I can implement solution to this ticket if someone more experienced helps me to figure out what is the right thing to do here. > Then my question remains: what's wrong with the status quo, for question (2)? I believe that Richard's point was that GHC 7.6.3 displayed kind parameters, which made it easier for the user to deduce what went wrong (ie. seeing incorrect `Bool (k -> *)` kind params instead of correct `Bool (Bool -> *)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 14:34:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 14:34:53 -0000 Subject: [GHC] #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout In-Reply-To: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> References: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> Message-ID: <059.12c4cc0349c801c2a30a3b03f7303091@haskell.org> #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): It's never invalid, so far as I know. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 14:40:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 14:40:02 -0000 Subject: [GHC] #8872: hsc cast size warnings on 32-bit Linux Message-ID: <047.be22991936f471049817609a4b1ea4f2@haskell.org> #8872: hsc cast size warnings on 32-bit Linux ------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When compiling the gtk package with GHC 7.9.20140308 I get a bunch of warnings as outlined below. I'm on 32-bit system. Apparently this is something that should be reported. {{{ In file included from dist/dist-sandbox- c4fc5f8b/build/Graphics/UI/Gtk/General/Structs_hsc_make.c:1:0: Structs.hsc: In function ?main?: /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1020:5: note: in expansion of macro ?hsc_const? /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1020:5: note: in expansion of macro ?hsc_const? /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1025:5: note: in expansion of macro ?hsc_const? /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1025:5: note: in expansion of macro ?hsc_const? /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1029:5: note: in expansion of macro ?hsc_const? /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1029:5: note: in expansion of macro ?hsc_const? /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1033:5: note: in expansion of macro ?hsc_const? /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1033:5: note: in expansion of macro ?hsc_const? /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1037:5: note: in expansion of macro ?hsc_const? /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1037:5: note: in expansion of macro ?hsc_const? /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1042:5: note: in expansion of macro ?hsc_const? /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1042:5: note: in expansion of macro ?hsc_const? /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1046:5: note: in expansion of macro ?hsc_const? /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1046:5: note: in expansion of macro ?hsc_const? /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1051:5: note: in expansion of macro ?hsc_const? /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 14:52:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 14:52:34 -0000 Subject: [GHC] #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout In-Reply-To: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> References: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> Message-ID: <059.3d55e05b2c1887d12acab9a5e2cef2c8@haskell.org> #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Replying to [comment:5 simonpj]: > It's never invalid, so far as I know. I think it's invalid as soon as Hp changes. See this comment: https://github.com/ghc/ghc/blob/master/compiler/codeGen/StgCmmHeap.hs#L80 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 15:07:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 15:07:00 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.0776978751403a269daf385f65cb2d88@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Updated numbers, now running nofib in slow mode. Now the results look slightly better. Guess that is what benchmarking is about: Tweaking the tests until the results are what we want them to be: Effect of Call Arity (with the original foldl): {{{ min mean max Allocations -1.3% -0.0% 0.0% Runtime -4.0% -0.0% +4.9% }}} Effect of Call Arity + defining foldl with foldr: {{{ min mean max Allocations -79.0% -5.2% 0.0% Runtime -47.4% -1.9% +3.0% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 15:08:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 15:08:22 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.d3204e173aabca222c830ea748c05723@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+----------------------------- Reporter: facundoq | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+----------------------------- Changes (by thoughtpolice): * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 15:22:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 15:22:26 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.8ce93b4996831181b45f74441b30118c@haskell.org> #8851: Standalone deriving and GND behave differently -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple deriving/should_compile/T8851 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by goldfire): You have a better perspective on the difficulty of implementation here, so I'm happy enough to agree. It does seem a little silly that we can accept `deriving instance Parsing MyParser` (with no context at all) but not `newtype MyParser ... deriving Parsing`. But, this behavior is fully consistent with the articulation of the two `deriving` features, so there's nothing wrong with it. And, keeping the code simpler when the fix for users is so trivial is a good thing. Thanks for taking another look. We should modify the test case to reflect this change. I can do that later this week when I spend some time working on GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 15:29:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 15:29:24 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.760159e5c771adf6c653f8e2b826df79@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+----------------------------- Reporter: facundoq | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+----------------------------- Comment (by simonpj): Austin says: if ghc-stage2 is seg-faulting, try re-linking it with the debug runtime system, thus {{{ cd ./ghc make re2 GhcDebugged=YES }}} and now try the seg-faulting ghc-stage2 again. Also https://ghc.haskell.org/trac/ghc/wiki/Debugging/CompiledCode -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 15:30:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 15:30:22 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition In-Reply-To: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> References: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> Message-ID: <062.ac4b57f858a0418be23f27401ab79c05@haskell.org> #8707: Kind inference fails in data instance definition -------------------------------------+------------------------------------ Reporter: goldfire | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Replying to [comment:6 simonpj]: > Oh oh, so that message is not something can currently produce. Fine. Then my question remains: what's wrong with the status quo, for question (2)? Nothing, upon further inspection. I believe I wrote that message toward the end of a 6-hour flight and may have been a little addled. I withdraw point (2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 15:39:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 15:39:59 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.a04b4b62738fcf8074187d9b79b582eb@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 15:41:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 15:41:50 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.214a4ced14bcbd86c6cc8616d40fdf0a@haskell.org> #8851: Standalone deriving and GND behave differently -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple deriving/should_compile/T8851 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => merge Comment: Please merge the documentation changes to 7.8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 15:44:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 15:44:47 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.983abc70e5df016d0d1c9b77f56f419d@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 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 simonpj): * cc: dterei (added) Comment: David Terei may have an opinion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 15:52:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 15:52:33 -0000 Subject: [GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error In-Reply-To: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> References: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> Message-ID: <066.d9143b6d2a83ac7de5ec0e276a246bde@haskell.org> #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error -------------------------------------+---------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by thoughtpolice): * priority: normal => highest Comment: Simon says this is a legitimate bug in the floater; so it should definitely be fixed and merged to 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 16:10:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 16:10:32 -0000 Subject: [GHC] #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout In-Reply-To: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> References: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> Message-ID: <059.438cee810d30ccf775f271abb47164ee@haskell.org> #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Ah yes, now I see. You are right: the offset returned is valid only until the real heap pointer is moved. `virtHp` doesn't matter. I'll add that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 16:18:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 16:18:56 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition In-Reply-To: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> References: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> Message-ID: <062.4c58803815da60d51ad99f8bd134fd60@haskell.org> #8707: Kind inference fails in data instance definition -------------------------------------+------------------------------------ Reporter: goldfire | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Jan, this is one of the gnarliest bits of the type checker, and I caution against committing too many days of your life to it. I think that #8832 might be a better investment of your valuable time; as would anything that helps cure the Windows seg-faults that are blocking the 7.8 release (eg #8870, #8834). But yes "type patterns" means the type arguments of the data instance. The two pases are one to do kind checking, and then a second to generate the actual type constructors. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 17:46:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 17:46:40 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition In-Reply-To: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> References: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> Message-ID: <062.b2a0d9473b929649cb76390ca8450a0e@haskell.org> #8707: Kind inference fails in data instance definition -------------------------------------+------------------------------------ Reporter: goldfire | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Jan asked me a few months ago for a "simple" bug to fix in the type- checker, and I recommended this one, thinking it to be much simpler than it is -- that's why I haven't tackled it myself. He and I just spent a some time going through the details, and we hit upon a much simpler solution than what you proposed. Right now, `tcConRes` looks like this: {{{ tcConRes (ResTyGADT res_ty) = do { res_ty' <- tcHsLiftedType res_ty ; return (ResTyGADT res_ty') } }}} I propose changing it to: {{{ tcConRes (ResTyGADT res_ty) = do { res_ty' <- tcHsLiftedType res_ty ; _ <- unifyType type_in_head res_ty' ; return (ResTyGADT res_ty') } }}} where `type_in_head` is the desugared type that appears in the declaration (either normal datatype or data instance) head. Getting that data here will take some plumbing, but it shouldn't be too bad. We also will need to freshen any type variables (with `tcInstTyVars` for the type from the declaration head and `tcInstSkolTyVars` for the return type, I imagine) to get everything to work. This approach seems to solve the case in point, and it would also fix the complications in `Note [Checking GADT return types]`. I do see some potential trouble with getting error messages to be right, but I still think this is a better approach than repeating much of `tc_hs_type`. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 20:28:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 20:28:59 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition In-Reply-To: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> References: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> Message-ID: <062.589ecead17304fdbbf14ce900436266d@haskell.org> #8707: Kind inference fails in data instance definition -------------------------------------+------------------------------------ Reporter: goldfire | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I don't think that'll work for ordinary GADTs. Remember, for them the `TyCon` itself is knot-tied, so attempts to unify with it will yield a black hole. (Ironically it might be ok for data instances.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 10 21:49:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Mar 2014 21:49:37 -0000 Subject: [GHC] #5925: Add inline version of newArray# In-Reply-To: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> References: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> Message-ID: <059.23d2cc38c5e473719737d52663481572@haskell.org> #5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): I've attached my refactored patches, there are two patches that apply on top of the original newArray# patch. The first is a patch I had lying around to change the representation of heap offsets from word to byte offsets, which turned out to be useful here too, so we might as well include it. I haven't tested this other than to eyeball the Cmm, which looks vaguely sensible. Johan, if you could take it from here and run your tests, that would be great. I think I'm still missing a bugfix that you applied in your second patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 00:42:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 00:42:21 -0000 Subject: [GHC] #8873: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory Message-ID: <051.c7c74d65a5ac5256959953ba2081bc0a@haskell.org> #8873: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory -------------------------------------------+------------------------------- Reporter: configurator | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- The paths used in the {{{ghcii.sh}}} scripts to start {{{ghc --interactive}}} are incorrectly built using {{{"$0"/..}}}, which causes the message: {{{ /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: exec: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: cannot execute: No such file or directory }}} I believe using {{{"$(dirname "$0")"}}} would be a portable solution that works under both cygwin and Linux versions of bash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 00:47:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 00:47:24 -0000 Subject: [GHC] #8873: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory In-Reply-To: <051.c7c74d65a5ac5256959953ba2081bc0a@haskell.org> References: <051.c7c74d65a5ac5256959953ba2081bc0a@haskell.org> Message-ID: <066.33de7dc9028e10fabbeebe3b1f9a140a@haskell.org> #8873: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory -------------------------------+------------------------------------------- Reporter: | Owner: configurator | Status: new Type: bug | Milestone: Priority: low | Version: 7.6.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by configurator): Output from looking at ghcii.sh: {{{ configurator at koan:/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin$ cat ghcii-7.6.3.sh #!/bin/sh exec "$0"/../ghc --interactive ${1+"$@"} }}} This version seems to work: {{{ #!/bin/sh exec "$(dirname "$0")"/ghc --interactive ${1+"$@"} }}} However, I can't find ghcii.sh in the source to modify it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 01:19:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 01:19:32 -0000 Subject: [GHC] #8873: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory In-Reply-To: <051.c7c74d65a5ac5256959953ba2081bc0a@haskell.org> References: <051.c7c74d65a5ac5256959953ba2081bc0a@haskell.org> Message-ID: <066.902851c31465686bba405dd11195ff5a@haskell.org> #8873: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory -------------------------------+------------------------------------------- Reporter: | Owner: configurator | Status: new Type: bug | Milestone: Priority: low | Version: 7.6.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by rwbarton): Well I've never heard of `ghcii.sh`; apparently it is a Windows-only thing so no worries about portability. It's produced by `driver/ghci/ghc.mk`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 01:51:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 01:51:09 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition In-Reply-To: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> References: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> Message-ID: <062.9800446841b31f3e754759783bf85bb7@haskell.org> #8707: Kind inference fails in data instance definition -------------------------------------+------------------------------------ Reporter: goldfire | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Quite right. But, your comment about the fact that this works for data instances gives me an idea: what about doing this unification in `kcDataDefn`? Note that the function is used only in the data instance case. (It might be worth renaming to make this now-critical fact more obvious.) There's no knot to worry about there. `kcConDecl` would be rewritten to return the desugared result type so that `kcDataDefn` can access it. Should be rather straightforward. If you agree that this might work, the question now is: is it better to have this (admittedly somewhat delicate) check in addition to the already- delicate handling of GADT return types? Or is it better to have a duplication of all the work in `tc_hs_type`? If we go with duplicating `tc_hs_type`, it's not immediately obvious exactly how the GADT-return- type typechecker would operate, given that the constraints on that type may appear arbitrarily deep in the type, depending on the data instance type patterns. I'm sure there's a way to get it to work, but I have a sneaking suspicion it will look a lot like a call to `unifyType` somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 01:53:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 01:53:44 -0000 Subject: [GHC] #8873: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory In-Reply-To: <051.c7c74d65a5ac5256959953ba2081bc0a@haskell.org> References: <051.c7c74d65a5ac5256959953ba2081bc0a@haskell.org> Message-ID: <066.160c3d6fe99a67661032ee9345f98de5@haskell.org> #8873: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory -------------------------------+------------------------------------------- Reporter: | Owner: configurator | Status: new Type: bug | Milestone: Priority: low | Version: 7.6.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by configurator): {{{perl boot}}} seems to fail on my machine, rendering me unable to compile GHC - I'd look into it if my change touched any of the compiler stuff, but this is just a shell file change. Is there a process for suggesting a patch without being able to compile? My patch is attached; it changes the directory name to use the version I specified earlier, and also changes {{{${1+"$@"}}}} to {{{"$@"}}} which does the exact same thing but cleaner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 07:04:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 07:04:43 -0000 Subject: [GHC] #5925: Add inline version of newArray# In-Reply-To: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> References: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> Message-ID: <059.50ba65f0dcd0148159f99a639adcb28b@haskell.org> #5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Could you please attach the first patch you used as well (i.e. run `git format-patch -n master..` and include all three patches). I no longer have the version of my patch that you based your work on and your patches don't apply cleanly on top of the `0001-codeGen-allocate-small-arrays-of- statically-known-si.patch` patch attached to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 07:48:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 07:48:53 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238865=3A_Cannot_derive_well-kinded_i?= =?utf-8?q?nstance_of_form_=E2=80=98Category?= In-Reply-To: <048.9835e0581238f6f4bbded51439894fae@haskell.org> References: <048.9835e0581238f6f4bbded51439894fae@haskell.org> Message-ID: <063.4edfbec87e0aad94f1c2d609af9c58df@haskell.org> #8865: Cannot derive well-kinded instance of form ?Category ----------------------------------------------+---------------------------- Reporter: adinapoli | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | 7.8.1-rc2 Operating System: MacOS X | Keywords: Type of failure: GHC rejects valid program | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by carter): the Pattern Arrows package used for purescript hits this exact same issue too. https://github.com/paf31/pattern-arrows {{{ [1 of 1] Compiling Control.PatternArrows ( src/Control/PatternArrows.hs, dist/build/Control/PatternArrows.o ) src/Control/PatternArrows.hs:32:92: Cannot derive well-kinded instance of form ?C.Category (Pattern ...)? Class ?C.Category? expects an argument of kind ?k -> k -> *? In the newtype declaration for ?Pattern? }}} can i assume that the fix will be merged into 7.8 branch too? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 07:56:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 07:56:44 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238865=3A_Cannot_derive_well-kinded_i?= =?utf-8?q?nstance_of_form_=E2=80=98Category?= In-Reply-To: <048.9835e0581238f6f4bbded51439894fae@haskell.org> References: <048.9835e0581238f6f4bbded51439894fae@haskell.org> Message-ID: <063.e4578f54d078a01eb6dff1f7498060ad@haskell.org> #8865: Cannot derive well-kinded instance of form ?Category ----------------------------------------------+---------------------------- Reporter: adinapoli | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | 7.8.1-rc2 Operating System: MacOS X | Keywords: Type of failure: GHC rejects valid program | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by simonpj): * status: closed => merge Comment: Yes, I think we should merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 08:47:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 08:47:43 -0000 Subject: [GHC] #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version In-Reply-To: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> References: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> Message-ID: <063.16d9c24927d38464f4e32a7504380d39@haskell.org> #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version -------------------------------------------------+------------------------- Reporter: cetinsert | Owner: Type: bug | dterei Priority: high | Status: new Component: Compiler (LLVM) | Milestone: 7.8.1 Resolution: | Version: Operating System: Windows | 7.6.1-rc1 Type of failure: Incorrect warning at | Keywords: llvm compile-time | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by is7s): Replying to [comment:11 schyler]: > Replying to [comment:10 carter]: > > schyler, could you confirm that editing the relevant fields in your GHC settings file fixes things > Confirming llvm 3.4svn and 2.9 on path work perfectly with the settings file fix. Where is the GHC settings file located on Windows? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 08:58:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 08:58:05 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.6c0a40e9b0be5d781effd5b941b4f214@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------ Reporter: parcs | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 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 simonmar): * cc: hvr (added) Comment: It looks plausible, but before committing someone should check that it doesn't regress any of the issues that the original version was designed to avoid, see #5926. Ideally we should have tests for these. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 09:00:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 09:00:41 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.79d3fb75baed1b170087062c23b0fb27@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: IORef Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #5926 -------------------------------------+------------------------------------- Changes (by hvr): * failure: None/Unknown => Runtime performance bug * related: => #5926 * difficulty: Unknown => Moderate (less than a day) * milestone: => 7.10.1 * keywords: => IORef * type: task => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 09:02:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 09:02:06 -0000 Subject: [GHC] #8868: Old information in Extensions to data types and type synonyms In-Reply-To: <048.c300fb88d6d104dbe2190663e186986f@haskell.org> References: <048.c300fb88d6d104dbe2190663e186986f@haskell.org> Message-ID: <063.18521332bfe6a0c9873cecf17b16143c@haskell.org> #8868: Old information in Extensions to data types and type synonyms --------------------------------------+------------------------------------ Reporter: Kinokkory | Owner: Type: bug | Status: closed Priority: normal | Milestone: ? Component: Documentation | Version: 7.6.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by Kinokkory): * status: new => closed * resolution: => wontfix Comment: OK, the User's Guide of GHC 7.8.1-rc1 looks good, so I'll close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 09:05:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 09:05:25 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.fa2cf351d5bf8866329cf6c3b6722980@haskell.org> #8793: Improve GHC.Event.IntTable performance --------------------------------------------+------------------------------ Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by hvr): * cc: hvr (added) * failure: None/Unknown => Runtime performance bug * milestone: 7.8.1 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 09:14:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 09:14:26 -0000 Subject: [GHC] #8010: Add forkOSUnmasked (patch) In-Reply-To: <048.eb7119d903e5adba0673b07e7cf0b9ea@haskell.org> References: <048.eb7119d903e5adba0673b07e7cf0b9ea@haskell.org> Message-ID: <063.ebc11bb3f5c3862d14c7b82d3e0218ea@haskell.org> #8010: Add forkOSUnmasked (patch) -------------------------------------+------------------------------------ Reporter: joeyadams | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.7 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) Comment: for some reason that proposal went totally ignored (maybe it was just posted with bad timing?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 09:18:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 09:18:23 -0000 Subject: [GHC] #8874: Warning: Couldn't figure out linker information! Message-ID: <046.d67a2973b6290e10568e89b029230c9a@haskell.org> #8874: Warning: Couldn't figure out linker information! -------------------------+------------------------------------------------- Reporter: | Owner: Lemming | Status: new Type: bug | Milestone: Priority: | Version: 7.8.1-rc2 normal | Operating System: Linux Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: x86_64 (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- {{{ $ cabal-1.18.0.2 install --with-ghc=ghc-7.8.0.20140228 utility-ht-0.0.10 ... [ 1 of 24] Compiling Text.Show.HT ( src/Text/Show/HT.hs, dist/build/Text/Show/HT.o ) [ 2 of 24] Compiling Text.Read.HT ( src/Text/Read/HT.hs, dist/build/Text/Read/HT.o ) [ 3 of 24] Compiling Data.Strictness.HT ( src/Data/Strictness/HT.hs, dist/build/Data/Strictness/HT.o ) [ 4 of 24] Compiling Control.Monad.HT ( src/Control/Monad/HT.hs, dist/build/Control/Monad/HT.o ) [ 5 of 24] Compiling Data.Tuple.HT ( src/Data/Tuple/HT.hs, dist/build/Data/Tuple/HT.o ) [ 6 of 24] Compiling Control.Functor.HT ( src/Control/Functor/HT.hs, dist/build/Control/Functor/HT.o ) [ 7 of 24] Compiling Data.Monoid.HT ( src/Data/Monoid/HT.hs, dist/build/Data/Monoid/HT.o ) [ 8 of 24] Compiling Data.Maybe.HT ( src/Data/Maybe/HT.hs, dist/build/Data/Maybe/HT.o ) [ 9 of 24] Compiling Data.Ix.Enum ( src/Data/Ix/Enum.hs, dist/build/Data/Ix/Enum.o ) [10 of 24] Compiling Data.Function.HT.Private ( src/Data/Function/HT/Private.hs, dist/build/Data/Function/HT/Private.o ) [11 of 24] Compiling Data.Function.HT ( src/Data/Function/HT.hs, dist/build/Data/Function/HT.o ) [12 of 24] Compiling Data.List.Key.Private ( src/Data/List/Key/Private.hs, dist/build/Data/List/Key/Private.o ) [13 of 24] Compiling Data.List.Key ( src/Data/List/Key.hs, dist/build/Data/List/Key.o ) [14 of 24] Compiling Data.Ord.HT ( src/Data/Ord/HT.hs, dist/build/Data/Ord/HT.o ) [15 of 24] Compiling Data.Eq.HT ( src/Data/Eq/HT.hs, dist/build/Data/Eq/HT.o ) [16 of 24] Compiling Data.Bool.HT.Private ( src/Data/Bool/HT/Private.hs, dist/build/Data/Bool/HT/Private.o ) [17 of 24] Compiling Data.Bool.HT ( src/Data/Bool/HT.hs, dist/build/Data/Bool/HT.o ) [18 of 24] Compiling Data.List.Match.Private ( src/Data/List/Match/Private.hs, dist/build/Data/List/Match/Private.o ) [19 of 24] Compiling Data.List.HT.Private ( src/Data/List/HT/Private.hs, dist/build/Data/List/HT/Private.o ) [20 of 24] Compiling Data.List.HT ( src/Data/List/HT.hs, dist/build/Data/List/HT.o ) [21 of 24] Compiling Data.Record.HT.Private ( src/Data/Record/HT/Private.hs, dist/build/Data/Record/HT/Private.o ) [22 of 24] Compiling Data.Record.HT ( src/Data/Record/HT.hs, dist/build/Data/Record/HT.o ) [23 of 24] Compiling Data.String.HT ( src/Data/String/HT.hs, dist/build/Data/String/HT.o ) [24 of 24] Compiling Data.List.Match ( src/Data/List/Match.hs, dist/build/Data/List/Match.o ) [ 1 of 24] Compiling Text.Show.HT ( src/Text/Show/HT.hs, dist/build/Text/Show/HT.p_o ) : Warning: Couldn't figure out linker information! Make sure you're using GNU gcc, or clang [ 2 of 24] Compiling Text.Read.HT ( src/Text/Read/HT.hs, dist/build/Text/Read/HT.p_o ) [ 3 of 24] Compiling Data.Strictness.HT ( src/Data/Strictness/HT.hs, dist/build/Data/Strictness/HT.p_o ) [ 4 of 24] Compiling Control.Monad.HT ( src/Control/Monad/HT.hs, dist/build/Control/Monad/HT.p_o ) ... }}} The warning only appears for the first module in profiling mode. What does the warning mean? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 09:25:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 09:25:16 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition In-Reply-To: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> References: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> Message-ID: <062.cd5d7e2e467b2cf0f1f5701fc3e4d06c@haskell.org> #8707: Kind inference fails in data instance definition -------------------------------------+------------------------------------ Reporter: goldfire | Owner: jstolarek Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 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 simonpj): * priority: normal => low * type: bug => feature request Comment: I've thought about this some more. My conclusion: we should do nothing. * Whatever we do will make things more complicated * Arguably what is happening now is right anyway For the second point, consider {{{ data family T a data instance T [a] where MkT :: b -> T b }}} We rightly reject this because `(T b)` is not an instance of `T [a]`. We do not say "oh, that b must be [c]", using information from the header. No, we treat the type signature for `MkT` as a perfectly ordinary type signature, and check that it has the right shape. Similarly when you write {{{ data instance SingDF (a :: (Bool, Bool -> *)) where SFalse :: SingDF '(False, Ctor) }}} the type signature for `SFalse` is perfectly ordinary type signature, and means what it means. We then check that it is an instance of the header, and it isn't. It's less obvious, because the kinds are hidden, but it's the same thing really. Moreover, if/when we have kind equalities, the kind arguments in the result type may be an instance of (not equal to) the kind arguments of the header. I can see a way to hack it up (along the lines I suggested) but it feels like a hack. Perhaps convenient in certain cases, but imagine trying to write the typing rules that says exactly which programs are accepted and which are rejected! I don't think the `kcConDecl` thing will work. Look at `TcHsType.tcTyVar` and the local definition `get_loopy_tc`; plus `Note [Type checking recursive type and class declarations]` in `TcTyClsDecls` which describes how a `TyCon` can have a definition in both the local and global environments. It's not a bug; it's a feature request, and one that I'm dubious about. On reflection I think we probably have better uses for our cycles. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 09:44:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 09:44:17 -0000 Subject: [GHC] #7949: Haskell Platform doesn't build on Fedora 17 In-Reply-To: <045.c23bafc8b668987cc9bcc5a8e47d3508@haskell.org> References: <045.c23bafc8b668987cc9bcc5a8e47d3508@haskell.org> Message-ID: <060.19791af57a71340d1a9b80cf5dcd20f6@haskell.org> #7949: Haskell Platform doesn't build on Fedora 17 -----------------------------+------------------------------------ Reporter: photex | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+------------------------------------ Changes (by lcf): * difficulty: => Unknown Comment: Same problem on Ubuntu 12.04. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 10:32:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 10:32:17 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.58f84a09193e8c6aa3cff6d2215ba18f@haskell.org> #8793: Improve GHC.Event.IntTable performance --------------------------------------------+------------------------------ Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): cdk, thanks for the patch. It would be much easier to review the patch if it didn't also reformat all the code. Please try to respect the original author's style. We don't want "edit wars" where people keep reformatting code back and forth to fit their style. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 10:35:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 10:35:06 -0000 Subject: [GHC] #8874: Warning: Couldn't figure out linker information! In-Reply-To: <046.d67a2973b6290e10568e89b029230c9a@haskell.org> References: <046.d67a2973b6290e10568e89b029230c9a@haskell.org> Message-ID: <061.95285374a7ef8d37646b0024d01b9d05@haskell.org> #8874: Warning: Couldn't figure out linker information! -------------------------------------------------+------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | x86_64 (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by slyfox): I think it's a dupe of #8825. Can you post your output for: {{{ $ locale $ gcc -v 2>&1 | tail -n 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 11:16:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 11:16:02 -0000 Subject: [GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error In-Reply-To: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> References: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> Message-ID: <066.66b3bbc8caab99662b695f0257affa92@haskell.org> #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error -------------------------------------+---------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ef44a429af4a630a153b5774d0e19dbcad8328d5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ef44a429af4a630a153b5774d0e19dbcad8328d5" Make SetLevels do substitution properly (fixes Trac #8714) Nowadays SetLevels floats case expressions as well as let-bindings, and case expressions bind type variables. We need to clone all such floated binders, to avoid accidental name capture. But I'd forgotten to substitute for the cloned type variables, causing #8714. (In the olden days only Ids were cloned, from let-bindings.) This patch fixes the bug and does quite a bit of clean-up refactoring as well, by putting the context level in the LvlEnv. There is no effect on performance, except that nofib 'rewrite' improves allocations by 3%. On investigation I think it was a fluke to do with loop-cutting in big letrec nests. But at least it's a fluke in the right direction. Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -0.4% -3.0% -19.4% -19.4% -26.7% Max -0.0% +0.0% +17.9% +17.9% 0.0% Geometric Mean -0.1% -0.0% -0.7% -0.7% -0.4% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 11:18:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 11:18:12 -0000 Subject: [GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error In-Reply-To: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> References: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> Message-ID: <066.dec71caef7a99f8a7e2a80c1ae21ae06@haskell.org> #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error -------------------------------------------------+------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | x86_64 (amd64) simplCore/should_compile/T8714 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => merge * testcase: => simplCore/should_compile/T8714 Comment: Finally fixed this. Sorry it's been a long time coming ... I kept getting distracted. Thank you for a lovely small test case. Let's merge this to 7.8 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 11:23:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 11:23:11 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT In-Reply-To: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> References: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> Message-ID: <062.c8d1cc761154f4817406cf9c7979c385@haskell.org> #8776: Displaying pattern synonym for a GADT -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Gergo writes (to ghc-devs):The problem is that the two type variables occurring in the provided context both have "t" as their user-visible name; even though the second one is projected as "t1" in the tau type on the right-hand side. The code to generate this output is in `HsBinds.ppr_sig`, using `pprPatSynSig` which just adds the "pattern" keyword and the separating "=>" symbols etc: {{{ ppr_sig (PatSynSig name arg_tys ty prov req) = pprPatSynSig (unLoc name) False args (ppr ty) (pprCtx prov) (pprCtx req) where args = fmap ppr arg_tys pprCtx lctx = case unLoc lctx of [] -> Nothing ctx -> Just (pprHsContextNoArrow ctx) }}} My guess is that the problem is `pprHsContextNoArrow` projects individual constraints one-by-one and so doesn't notice the name clash on 't' between the two constraints in the example; whereas 'ppr ty' walks the whole right-hand tau type and thus has the opportunity to maintain a set of type variable names used. My question is, where is that logic, and how can I use that in this instance? My hope is to be shown a design where I can run 'ppr ty', 'pprCtx prov' and 'pprCtx req' in the same "naming environment" (I hope such a thing exists) so that they use a consistent naming scheme. This looks like a problem that must have popped up at a lot of places in GHC already and must have an idiomatic solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 11:35:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 11:35:47 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT In-Reply-To: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> References: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> Message-ID: <062.faf62f219b9c42bca446d87963f31456@haskell.org> #8776: Displaying pattern synonym for a GADT -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Yes, this does pop up, and there is only half of an idiomatic solution. * When pretty-printing (a type, say), the idiomatic solution is not to "rename type variables on the fly", but rather to "tidy" the type (which gives each variable a distinct print-name), and then pretty-print it (without renaming). Separate the two concerns. Functions like `tidyType` do this. * Alas, for type constructors, `TyCon`, tidying does not work well, because a `TyCon` includes `DataCon`s which include `Type`s, which mention `TyCon`s. And tidying can't tidy a mutually recursive data structure graph, only trees. * One alternative would be to ensure that `TyCons` get type variables with distinct print-names. That's ok for type variables but less easy for kind variables. Processing data type declarations is already so complicated that I don't think it's sensible to add the extra requirement that it generates only "pretty" types and kinds. * One place the non-pretty names can show up is in GHCi. But another is in interface files. Look at `MkIface.tyThingToIfaceDecl` which converts a `TyThing` (i.e. `TyCon`, `Class` etc) to an `IfaceDecl`. '''And it does tidying as part of that conversion.''' Why? Because interface files contains fast-strings, not uniques, so the names must at least be distinct. (You can see this happening for pattern synonyms in `patSynToIfaceDecl`. * SO MY PLAN is that the `:info` stuff in GHCi should work in two stages: * Use `tyThingToIfaceDecl` to convert the `TyThing` to an `IfaceDecl` * Pretty print that. Nothing very hard. It requires quite a bit of re-working in `PprTyThing`, but I think fairly routine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 11:59:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 11:59:36 -0000 Subject: [GHC] #8831: Cannot use Template Haskell splice in ghci In-Reply-To: <047.1688ea3628125d840e5d96b182466527@haskell.org> References: <047.1688ea3628125d840e5d96b182466527@haskell.org> Message-ID: <062.ac9ce58c722c3476db0d6fde8cf43b78@haskell.org> #8831: Cannot use Template Haskell splice in ghci -------------------------------------+---------------------------------- Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by kazu-yamamoto): * cc: kazu@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 12:06:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 12:06:51 -0000 Subject: [GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error In-Reply-To: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> References: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> Message-ID: <066.6f0cf15a43c093497b8f1a4ba50dfc0b@haskell.org> #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error -------------------------------------------------+------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | x86_64 (amd64) simplCore/should_compile/T8714 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nomeata): Your commit does not validate: {{{ compiler/simplCore/SetLevels.lhs:467:31: Not in scope: `expr' Perhaps you meant `exp' (imported from Prelude) }}} https://s3.amazonaws.com/archive.travis-ci.org/jobs/20523523/log.txt -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 12:11:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 12:11:05 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238865=3A_Cannot_derive_well-kinded_i?= =?utf-8?q?nstance_of_form_=E2=80=98Category?= In-Reply-To: <048.9835e0581238f6f4bbded51439894fae@haskell.org> References: <048.9835e0581238f6f4bbded51439894fae@haskell.org> Message-ID: <063.00737b322b734ba6c95aaca0b8d38563@haskell.org> #8865: Cannot derive well-kinded instance of form ?Category ----------------------------------------------+---------------------------- Reporter: adinapoli | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | 7.8.1-rc2 Operating System: MacOS X | Keywords: Type of failure: GHC rejects valid program | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Lemming): Just encountered this problem myself. It can be reproduced with the simple module: {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} import Control.Arrow (Arrow) import Control.Category (Category) newtype Fails a b = Fails (a -> b) deriving (Category, Arrow) newtype Works a b = Works (a -> b) deriving (Arrow) instance Category Works where }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 12:19:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 12:19:05 -0000 Subject: [GHC] #8874: Warning: Couldn't figure out linker information! In-Reply-To: <046.d67a2973b6290e10568e89b029230c9a@haskell.org> References: <046.d67a2973b6290e10568e89b029230c9a@haskell.org> Message-ID: <061.80bcc8d521ca0bbeb4a6cd2a6a2c9816@haskell.org> #8874: Warning: Couldn't figure out linker information! -------------------------------------------------+------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | x86_64 (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Lemming): {{{ $ locale LANG=de_DE.UTF-8 LANGUAGE= LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES="de_DE.UTF-8" LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL= $ gcc -v 2>&1 | tail -n 1 gcc-Version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 12:43:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 12:43:31 -0000 Subject: [GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error In-Reply-To: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> References: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> Message-ID: <066.ebbd64dc77a4e496745db03f776a3bf2@haskell.org> #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error -------------------------------------------------+------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | x86_64 (amd64) simplCore/should_compile/T8714 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): Ha that'll teach me to make a last minute cosmetic change after validating. Patch coming. S -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 12:45:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 12:45:43 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238865=3A_Cannot_derive_well-kinded_i?= =?utf-8?q?nstance_of_form_=E2=80=98Category?= In-Reply-To: <048.9835e0581238f6f4bbded51439894fae@haskell.org> References: <048.9835e0581238f6f4bbded51439894fae@haskell.org> Message-ID: <063.a33c2fb3328edd9c53f4141367a76aa7@haskell.org> #8865: Cannot derive well-kinded instance of form ?Category -------------------------------------------------+------------------------- Reporter: adinapoli | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | 7.8.1-rc2 Operating System: MacOS X | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | x86_64 (amd64) deriving/should_compile/T8865 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * testcase: => deriving/should_compile/T8865 Comment: Yes, works in HEAD, and will do in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 12:58:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 12:58:49 -0000 Subject: [GHC] #5925: Add inline version of newArray# In-Reply-To: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> References: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> Message-ID: <059.df3f0bdf86ab88040ca0536f840f7374@haskell.org> #5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Please review `0004-Fix-incorrect-loop-condition-in-inline-array- allocat.patch`?. I also attached previous patches so it's possible to apply them all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 13:12:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 13:12:11 -0000 Subject: [GHC] #5925: Add inline version of newArray# In-Reply-To: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> References: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> Message-ID: <059.194c8bb34ee44debf8d7331339cf9627@haskell.org> #5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Looks great. Is there a test too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 13:19:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 13:19:05 -0000 Subject: [GHC] #8874: Warning: Couldn't figure out linker information! In-Reply-To: <046.d67a2973b6290e10568e89b029230c9a@haskell.org> References: <046.d67a2973b6290e10568e89b029230c9a@haskell.org> Message-ID: <061.1664118b4cdd153eea1962a5220e4c12@haskell.org> #8874: Warning: Couldn't figure out linker information! -------------------------------------------------+------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | x86_64 (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: 8825 -------------------------------------------------+------------------------- Changes (by slyfox): * related: => 8825 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 14:34:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 14:34:59 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.435003eacfe143ae6d21d719c12e83e4@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+----------------------------- Reporter: facundoq | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+----------------------------- Comment (by darchon): When i run `ghc` from within `gdb` I consistently get it to successfully compile and link the program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 15:19:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 15:19:53 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.f514c71763398022209091aa9442d96b@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): In comment 3 I argue that it's right to infer Safe for B, and hence that B should compile fine with {-# LANGUAGE Safe #-}. That would mean removing the recursive check. Does anyone object? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 15:27:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 15:27:06 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.62059913516bb2061acc006f83bc45b8@haskell.org> #8793: Improve GHC.Event.IntTable performance --------------------------------------------+------------------------------ Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by bos): Hi, cdk, I'll echo Johan's feedback: your patch is not reviewable. I have read it for several minutes, and I cannot tell what or where your real changes are, as opposed to all of the gratuitous reformatting you did. (As Johan mentions, the reformatting is discourteous, as well as obscuring the substance of the change.) If you would like this change to go in, please resubmit it as one or two minimal patches that do not reformat code except as necessary for semantic purposes, and that make it easy for a reviewer to tell what is going on. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 15:38:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 15:38:25 -0000 Subject: [GHC] #8828: allow fully applied type families in instance heads In-Reply-To: <045.6152be3035980bd31e93fc1579e85689@haskell.org> References: <045.6152be3035980bd31e93fc1579e85689@haskell.org> Message-ID: <060.33033e77ae35bdb6d3132d1a949ed3ec@haskell.org> #8828: allow fully applied type families in instance heads -------------------------------------+------------------------------------ Reporter: aavogt | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 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 simonpj): * owner: => goldfire Comment: Seems very reasonable. The rule would be this: you normalise the instance type, and check that there are no remaining type family calls. After all, with `-XFlexibleInstances` you can use type synonyms in instance heads, and this is just an extension of the same idea. c.f. http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#flexible-instance-head Richard will work on this in due course. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 15:50:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 15:50:28 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.cde54045c3f17d8db11b78fcfd5f21ab@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 bgamari): * cc: bgamari@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 16:07:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 16:07:39 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.08918378628bdfcb746e17fa66b82d09@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Under the assumption that library authors will get their role annotations right it is ok to remove that check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 17:49:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 17:49:27 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition In-Reply-To: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> References: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> Message-ID: <062.c76230ca9bb5a8b05e0b2b9311132668@haskell.org> #8707: Kind inference fails in data instance definition -------------------------------------+------------------------------------ Reporter: goldfire | Owner: jstolarek Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Given the (current) separation between types and kinds, I'm not 100% convinced that the `SingDF` case is the same as your `T` case, but I can see how these might become the same in the future. I agree with the reclassification as a feature request, and that there are bigger fish to fry, so I agree to table this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 17:52:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 17:52:01 -0000 Subject: [GHC] #8875: Track Exceptions Message-ID: <044.40ee9daff1e997b21df30175182c507b@haskell.org> #8875: Track Exceptions ----------------------------------------------+---------------------------- Reporter: yokto | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- Figure out for each function which exceptions can be thrown by it. This could probably be done by tracking calls to {{{ throw }}} and {{{ catch }}} and their types. The info would probably need to be stored in the .hi files, and could then be displayed by haddock. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 18:21:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 18:21:45 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.50b12a1ac33ff77eb4864bbe9a089afa@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: IORef Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #5926 -------------------------------------+------------------------------------- Comment (by carter): huh, i'll try to find some cycles to think about the semantics of this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 20:11:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 20:11:56 -0000 Subject: [GHC] #4385: Type-level natural numbers In-Reply-To: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> References: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> Message-ID: <062.1e25a9d7be9158a4f637bc88aba8d691@haskell.org> #4385: Type-level natural numbers --------------------------------------------+------------------------------ Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Lemming): Type-level natural numbers are advertised everywhere for GHC-7.8, but I cannot find documentation in http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 22:14:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 22:14:12 -0000 Subject: [GHC] #4385: Type-level natural numbers In-Reply-To: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> References: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> Message-ID: <062.8823a47cbf50babfbad1531c9e900883@haskell.org> #4385: Type-level natural numbers --------------------------------------------+------------------------------ Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by hvr): Replying to [comment:66 Lemming]: > Type-level natural numbers are advertised everywhere for GHC-7.8, but I cannot find documentation in > http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/ does http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/promotion.html #promoted-literals count? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 22:27:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 22:27:48 -0000 Subject: [GHC] #4385: Type-level natural numbers In-Reply-To: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> References: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> Message-ID: <062.37d6620a26810c4f8840a18026063f4e@haskell.org> #4385: Type-level natural numbers --------------------------------------------+------------------------------ Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Lemming): Replying to [comment:67 hvr]: > Replying to [comment:66 Lemming]: > > Type-level natural numbers are advertised everywhere for GHC-7.8, but I cannot find documentation in > > http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/ > > does http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/promotion.html #promoted-literals count? Indeed, that's a nice start. What about type-level natural number operations and predicates? What about conversion from type-level numbers to data-level numbers? I found: https://ghc.haskell.org/trac/ghc/wiki/TypeNats/Basics https://ghc.haskell.org/trac/ghc/wiki/TypeNats/Operations Do these articles reflect the current state of implementation? I also found the announcement: http://www.well-typed.com/blog/85 where many feature names are linked to the GHC documentation, but "type- level natural numbers" is not. I also like to see the keyword "type-level natural number" somewhere in GHC docs, since this is how this feature is advertised. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 22:35:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 22:35:40 -0000 Subject: [GHC] #8835: 7.6.3 vs 7.8-RC performance regression In-Reply-To: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> References: <044.eb2d55c1dc1bd8255065f2133247ef13@haskell.org> Message-ID: <059.45499dfe44762385aed667e6d7821ae3@haskell.org> #8835: 7.6.3 vs 7.8-RC performance regression --------------------------------------------+------------------------------ Reporter: cbm80 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8814 --------------------------------------------+------------------------------ Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: Fine. I'll close this as a dup of #8814. Sadly, the latter still needs someone to dig into it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 11 22:42:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Mar 2014 22:42:27 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.2d6dc95c2c2779120baaa05bf514a5fa@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8763 --------------------------------------------+------------------------------ Comment (by simonpj): See also #8835, which we believe to be a dup of this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 06:09:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 06:09:38 -0000 Subject: [GHC] #5925: Add inline version of newArray# In-Reply-To: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> References: <044.8ef4af7e87ac82361eb86094a580d22d@haskell.org> Message-ID: <059.d55f7c0f8b80dea4f7e97b22927ad51a@haskell.org> #5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tibbe): * status: patch => closed * resolution: => fixed Comment: Implemented in: [changeset:22f010e08e58ba40b0ab59ec7a7c02cce0938cce], [changeset:a70e7b4762c75812254f7781bcd48139c4ec40dd], [changeset:b684f27ec7b3538ffd9401de70ef5685b8b71978], [changeset:c1d74ab96df7607529596d01223bc8654abf71b9] Test: [changeset:22e4bba2df99a2c9ad2822b3a7a5ac6de0f805e4] Benchmark: [changeset:d793a148917aa62e8860ffd7b66936d41bfa5737] `ByteArray#` is not yet implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 07:07:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 07:07:10 -0000 Subject: [GHC] #8876: Add inline version of newByteArray# Message-ID: <044.dd45b49424b698e257c76edd9a3cc0b3@haskell.org> #8876: Add inline version of newByteArray# ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- This is the equivalent of #5925 for `ByteArray#`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 07:08:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 07:08:04 -0000 Subject: [GHC] #8876: Add inline version of newByteArray# In-Reply-To: <044.dd45b49424b698e257c76edd9a3cc0b3@haskell.org> References: <044.dd45b49424b698e257c76edd9a3cc0b3@haskell.org> Message-ID: <059.b2f7b007e8bfce79103efd17d9e64dd2@haskell.org> #8876: Add inline version of newByteArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 tibbe): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 07:08:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 07:08:19 -0000 Subject: [GHC] #8876: Add inline version of newByteArray# In-Reply-To: <044.dd45b49424b698e257c76edd9a3cc0b3@haskell.org> References: <044.dd45b49424b698e257c76edd9a3cc0b3@haskell.org> Message-ID: <059.fc8566aa29b70164e1f9017684583203@haskell.org> #8876: Add inline version of newByteArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 tibbe): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 07:51:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 07:51:01 -0000 Subject: [GHC] #8876: Add inline version of newByteArray# In-Reply-To: <044.dd45b49424b698e257c76edd9a3cc0b3@haskell.org> References: <044.dd45b49424b698e257c76edd9a3cc0b3@haskell.org> Message-ID: <059.fefe96b1d6351588010f5092147ba349@haskell.org> #8876: Add inline version of newByteArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Validates for me on 64-bit OS X. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 08:55:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 08:55:39 -0000 Subject: [GHC] #8877: "if this code is reached, the program will abort" in sparc Message-ID: <046.60053a1b01344ea9a41702e5732d6278@haskell.org> #8877: "if this code is reached, the program will abort" in sparc ----------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: sparc | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8857 | ----------------------------+------------------------------------- Hi, sparc, when built with dynamic libraries, fails with a segmentation fault: https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=sparc&ver=7.8.20140228-1&stamp=1393975264 Possible cause indicated by {{{ "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Apply.cmm -o rts/dist/build/Apply.o /tmp/ghc14927_0/ghc14927_2.hc: In function 'stg_PAP_entry': /tmp/ghc14927_0/ghc14927_2.hc:101:30: warning: function called through a non-compatible type [enabled by default] /tmp/ghc14927_0/ghc14927_2.hc:101:30: note: if this code is reached, the program will abort }}} It works without shared libraries (see #8857) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 09:19:55 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 09:19:55 -0000 Subject: [GHC] #8878: Export runTcInteractive from TcRnDriver Message-ID: <047.6601d2f94bde1975c44c22d38170011e@haskell.org> #8878: Export runTcInteractive from TcRnDriver -------------------------------------------+------------------------------- Reporter: holzensp | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- For people writing more involved code onto GHC than the normal API (GHC.hs) allows, this is a very useful function. In previous versions of GHC, it has always been unclear to me how I should run the type checker on, for example, a single expression, while keeping the context (i.e. when running the type checker again, the types derived in the former run should still be known in the latter). Simply having runTcInteractive exported does wonders for self-documentation purposes. (patch to follow shortly) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 09:23:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 09:23:37 -0000 Subject: [GHC] #8878: Export runTcInteractive from TcRnDriver In-Reply-To: <047.6601d2f94bde1975c44c22d38170011e@haskell.org> References: <047.6601d2f94bde1975c44c22d38170011e@haskell.org> Message-ID: <062.0964296c3c86de6d84191628ed49e4dd@haskell.org> #8878: Export runTcInteractive from TcRnDriver -------------------------------+------------------------------------------- Reporter: holzensp | Owner: holzensp Type: feature | Status: new request | Milestone: 7.8.1 Priority: lowest | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by holzensp): * owner: => holzensp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 11:16:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 11:16:51 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition In-Reply-To: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> References: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> Message-ID: <062.aa086928fc9579dd87096d130d75d416@haskell.org> #8707: Kind inference fails in data instance definition -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 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 jstolarek): * owner: jstolarek => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 11:41:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 11:41:32 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.e7a9054c8bd5090a1dce564d9b127b11@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by maeder): * difficulty: Unknown => Easy (less than 1 hour) * milestone: => 7.8.1 * os: Unknown/Multiple => Solaris * version: 7.8.1-rc1 => 7.8.1-rc2 * failure: None/Unknown => Building GHC failed Comment: Replying to [comment:2 maeder]: > The $(SHELL) setting from configure is not taken, because mk/config.mk.in contains /bin/sh hard-coded. > A fix might be: > > {{{ > -SHELL = /bin/sh > +SHELL = @SHELL@ > }}} I propose to commit this change in line 655 of mk/config.mk.in as it is still relevant for me and ghc-7.8.1-rc2. Could someone do this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 12:44:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 12:44:06 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.8d4cb40bebee43477da80072464d7813@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by kgardas): I see that /bin/sh is hardcoded, but how exactly fails your Solaris build? I should have noted here at least too so I'm curious how our envs differ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 12:45:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 12:45:22 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT In-Reply-To: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> References: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> Message-ID: <062.0caf60886bb9f86aa6704217ba6c206f@haskell.org> #8776: Displaying pattern synonym for a GADT -------------------------------------+------------------------------------ Reporter: monoidal | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 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 cactus): * owner: => cactus Comment: OK I have pushed a prototype implementation of that to the `T8776` branch. It changes `ppr_ty_thing` to go via the `IfaceDecl`, but only for `PatSynCon`, since `tyThingToIfaceDecl` doesn't work for `RealDataCon`s. If you think that makes sense, I can clean it up somewhat (by removing remnants of the old way to print `PatSynCon` `TyThing`s) and merge it to `master`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 12:51:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 12:51:27 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.58b14983c38624841bf46849ccd403e3@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by maeder): I try to cross-compile for x86_64-pc-solaris2. {{{ inplace/bin/hsc2hs: LD_LIBRARY_PATH=/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/process-1.1.0.2:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/directory-1.2.0.1:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/unix-2.6.0.1:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/time-1.4.0.1:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/old-locale-1.0.0.5:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/filepath-1.3.0.1:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/containers-0.5.0.0:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/bytestring-0.10.0.2:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/deepseq-1.3.0.1:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/array-0.4.0.1:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/base-4.6.0.1:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/integer-gmp-0.5.0.0:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/ghc-prim-0.3.0.0:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3:: ist kein Kennzeichner gmake[1]: *** [compiler/stage1/build/Fingerprint.hs] Fehler 1 }}} The message "ist kein Kennzeichner" is the german version of the above "is not an identifier". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 13:06:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 13:06:35 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.5e8b7a0e0f8ef192531e7d47dcc6b655@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by kgardas): Replying to [comment:6 maeder]: > I try to cross-compile for x86_64-pc-solaris2. > > {{{ > inplace/bin/hsc2hs: LD_LIBRARY_PATH=/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/process-1.1.0.2:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/directory-1.2.0.1:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/unix-2.6.0.1:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/time-1.4.0.1:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/old-locale-1.0.0.5:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/filepath-1.3.0.1:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/containers-0.5.0.0:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/bytestring-0.10.0.2:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/deepseq-1.3.0.1:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/array-0.4.0.1:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/base-4.6.0.1:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/integer-gmp-0.5.0.0:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3/ghc-prim-0.3.0.0:/home/pub-bkb/pc- solaris/ghc/ghc-7.6.3/lib/ghc-7.6.3:: ist kein Kennzeichner > gmake[1]: *** [compiler/stage1/build/Fingerprint.hs] Fehler 1 > }}} > > The message "ist kein Kennzeichner" is the german version of the above "is not an identifier". This is IMHO caused by using export LD_LIBRARY_PATH=.... somewhere in build machinery and not by hard-coding /bin/sh. Anyway, if you use your patch and then look into processed config.mk what value is saved into SHELL variable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 13:15:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 13:15:14 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.ec5d8341ec9dbb3eb55f5571f0b9c468@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by maeder): It is caused by "export LD_LIBRARY_PATH=..." in inplace/bin/hsc2hs that my Bourne shell /bin/sh does not support. With the patch (after ./configure) my config.mk contains {{{ SHELL = /bin/bash }}} And then "#!/bin/bash" is finally used in inplace/bin/hsc2hs (rather than the failing "#!/bin/sh") -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 13:26:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 13:26:47 -0000 Subject: [GHC] #8875: Track Exceptions In-Reply-To: <044.40ee9daff1e997b21df30175182c507b@haskell.org> References: <044.40ee9daff1e997b21df30175182c507b@haskell.org> Message-ID: <059.d7ecdd3cd4a7aa937339f0ae140291ae@haskell.org> #8875: Track Exceptions ----------------------------+---------------------------------------------- Reporter: yokto | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by schyler): I sense confusion about the point of `.hi` files. Without going into too much detail why this ticket doesn't make sense for the current implementation of exceptions, this is a haddock feature request and not one for ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 13:33:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 13:33:52 -0000 Subject: [GHC] #8875: Track Exceptions In-Reply-To: <044.40ee9daff1e997b21df30175182c507b@haskell.org> References: <044.40ee9daff1e997b21df30175182c507b@haskell.org> Message-ID: <059.0556053da96e18bfc441ebeae346eea0@haskell.org> #8875: Track Exceptions ----------------------------+---------------------------------------------- Reporter: yokto | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by yokto): Ok i'm not sure about the .hi file and i don't know a lot of haddock/ghc internals. But this seems pretty impossible to implement without a little help from the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 13:35:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 13:35:58 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.84ee416a59c34ff9766178ab7ccf2768@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by maeder): The man-page of my sh looks like the one at http://www.manpages.info/sunos/jsh.1.html but says "SunOS 5.10 Last change: 2 May 2008" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 13:39:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 13:39:40 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.43eb502772bc1e086b6071980a5581b9@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by kgardas): Hmm, and ls -la /bin/sh tells what? On Solaris 11.1 it's: {{{ $ ls -al /bin/sh lrwxrwxrwx 1 root root 9 Feb 5 14:39 /bin/sh -> i86/ksh93 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 13:42:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 13:42:29 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.997ce199e0e0aaae3ff1eb955f094473@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by maeder): Solaris 10 {{{ -bash-3.2$ ls -la /bin/sh lrwxrwxrwx 1 root root 13 Dez 16 09:32 /bin/sh -> ../../sbin/sh -bash-3.2$ ls -la /sbin/sh -r-xr-xr-x 1 root root 82456 Sep 22 2010 /sbin/sh }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 13:42:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 13:42:42 -0000 Subject: [GHC] #8877: "if this code is reached, the program will abort" in unregisterised build (was: "if this code is reached, the program will abort" in sparc) In-Reply-To: <046.60053a1b01344ea9a41702e5732d6278@haskell.org> References: <046.60053a1b01344ea9a41702e5732d6278@haskell.org> Message-ID: <061.77f21b9089c58afc16cb2e525e7da795@haskell.org> #8877: "if this code is reached, the program will abort" in unregisterised build -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8857 -------------------------------------+------------------------------------ Changes (by trommler): * cc: ptrommler@? (added) * version: 7.6.3 => 7.8.1-rc2 * architecture: sparc => Unknown/Multiple Comment: I see the same on powerpc64 with dynamic libraries enabled: [https://build.opensuse.org/package/live_build_log/home:ptrommler/ghc/openSUSE_Factory_PowerPC_standard/ppc64] Changing architecture accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 13:47:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 13:47:36 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT In-Reply-To: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> References: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> Message-ID: <062.e85b2234543e551123580f1ed2047790@haskell.org> #8776: Displaying pattern synonym for a GADT -------------------------------------+------------------------------------ Reporter: monoidal | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Gergo, Yes that looks right to me, thank you. Do remove the remnants and merge. Maybe add the comments above as a Note to explain the strategy. For `RealDataCon`, you can generate an `IfaceId` decl, because that will print just the way that `pprDataConSig` worked. If you felt brave you could try converting some of the other cases. `AnId` is simple, and `ACoAxiom` is probably simple too. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 13:54:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 13:54:50 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.220c352fd76caa7626a001a1563a6cb1@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` --------------------------------------------+------------------------------ Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonpj): * owner: => simonpj Comment: I have a fix for this, but only on my laptop. And since I can't build on my laptop (we have a seg-fault on Windows that needs someone to pay attention to) it'll have to wait till I'm back in the office. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 14:06:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 14:06:08 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.7eda62e055386fd0adfd4fc4f3805908@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by kgardas): Simple change to SHELL = @SHELL@ in mk/config.mk.in is not working for me with simple ./configure. How exactly do you run configure script? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 14:36:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 14:36:22 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.42db731ace433b8de96ad1c70862345d@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by maeder): {{{ ./configure --target=x86_64-pc-solaris2 --with- gcc=/local/home/maeder/haskell/ghc64bin/gcc --with-ld=/usr/ccs/bin/ld --with-nm=/local/home/maeder/haskell/ghc-bin/nm }}} What do you mean by "is not working"? If @SHELL@ ist replaced by "/bin/sh" then this should work for you, because (any call of) ./configure should recognise the proper shell (that is /bin/sh for you and /bin/bash for me). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 14:42:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 14:42:11 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.6fd0090e88e51e3f33fa09db66f1e3ff@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+----------------------------- Reporter: facundoq | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+----------------------------- Comment (by simonpj): See also #8834 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 15:15:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 15:15:21 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.1c967d1aee60629e08e43cc97f285f0e@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by kgardas): OK, scratch that, issue between my chair and keyboard. Git patch attached! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 15:16:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 15:16:23 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.74a9fe8b3f061e5ec0ecf30fd1ac7d30@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by kgardas): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 19:28:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 19:28:03 -0000 Subject: [GHC] #8833: GHC (compilation mode) crashes In-Reply-To: <044.2af677b3d4a2a13d2e8b023bf15580e4@haskell.org> References: <044.2af677b3d4a2a13d2e8b023bf15580e4@haskell.org> Message-ID: <059.595302140766bea378f421ef8431dc6c@haskell.org> #8833: GHC (compilation mode) crashes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time | Difficulty: Moderate (less crash | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by thoughtpolice): (Apparently I forgot to post my comment on this one. Urgh.) After talking with Simon, we don't think this is a bug. This program probably won't compile on ''any'' GHC version (and Simon verified it on 7.4) as well - this is a variant of a known problem I believe, where you can trick the inliner into looping by encoding recursion into a data type: http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/bugs.html#bugs- ghc It will of course work in GHCi - but that's because it doesn't use the inliner. Unless I'm missing something here, I believe this is a WONTFIX. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 21:20:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 21:20:03 -0000 Subject: [GHC] #8879: System.IO.Error documentation refers to invalid module Control.Exception.Exception Message-ID: <048.8482d21568301182b05f72934f6258eb@haskell.org> #8879: System.IO.Error documentation refers to invalid module Control.Exception.Exception -------------------------------------+------------------------------------- Reporter: shadewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- See: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.6.0.1 /System-IO-Error.html The description for IOError refers to module Control.Exception.Exception: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.6.0.1 /Control-Exception-Exception.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 12 21:46:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Mar 2014 21:46:35 -0000 Subject: [GHC] #8833: GHC (compilation mode) crashes In-Reply-To: <044.2af677b3d4a2a13d2e8b023bf15580e4@haskell.org> References: <044.2af677b3d4a2a13d2e8b023bf15580e4@haskell.org> Message-ID: <059.3a74adb8a72d3c1beb0bb50e14fbb45e@haskell.org> #8833: GHC (compilation mode) crashes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time | Difficulty: Moderate (less crash | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonpj): Indeed, it's a dup of #3872, #5400, #5448, #5722, #7057, #7369. Nevertheless, good to have another example Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 08:47:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 08:47:22 -0000 Subject: [GHC] #7633: Checkable "minimal complete definitions" In-Reply-To: <046.58636b55ed32747ffa4f860e053150cd@haskell.org> References: <046.58636b55ed32747ffa4f860e053150cd@haskell.org> Message-ID: <061.64f9b904eb06abbd983f36021fe29f94@haskell.org> #7633: Checkable "minimal complete definitions" -------------------------------------------------+------------------------- Reporter: shachaf | Owner: Type: feature request | twanvl Priority: normal | Status: Component: Compiler | closed Resolution: fixed | Milestone: 7.8.1 Operating System: Unknown/Multiple | Version: 7.6.1 Type of failure: None/Unknown | Keywords: Test Case: warnings/minimal/WarnMinimal | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: #6028 -------------------------------------------------+------------------------- Comment (by haasn): Would it be possible to attach a BooleanFormula to HsDecls, too? Specifically, to the ClassDecl constructor of a TyClDecl. I could use this in order to figure out and show minimal complete definitions for class declarations in Haddock. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 08:52:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 08:52:41 -0000 Subject: [GHC] #7633: Checkable "minimal complete definitions" In-Reply-To: <046.58636b55ed32747ffa4f860e053150cd@haskell.org> References: <046.58636b55ed32747ffa4f860e053150cd@haskell.org> Message-ID: <061.9cb6177aeb462306f7e1a52d52758e09@haskell.org> #7633: Checkable "minimal complete definitions" -------------------------------------------------+------------------------- Reporter: shachaf | Owner: Type: feature request | twanvl Priority: normal | Status: Component: Compiler | closed Resolution: fixed | Milestone: 7.8.1 Operating System: Unknown/Multiple | Version: 7.6.1 Type of failure: None/Unknown | Keywords: Test Case: warnings/minimal/WarnMinimal | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: #6028 -------------------------------------------------+------------------------- Comment (by simonpj): It's there already. The `tcdSigs` field of a `ClassDecl` can include a `MinimalSig`. What am I missing? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 08:55:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 08:55:10 -0000 Subject: [GHC] #8666: integer-gmp fails to compile on Debian Squeeze In-Reply-To: <048.8db85b43ef2d1468096db30170850312@haskell.org> References: <048.8db85b43ef2d1468096db30170850312@haskell.org> Message-ID: <063.a792909a2be1a0159b120703ed2147c6@haskell.org> #8666: integer-gmp fails to compile on Debian Squeeze ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by tibbe): * cc: tibbe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 09:00:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 09:00:17 -0000 Subject: [GHC] #8880: Configured gcc not used for some build steps Message-ID: <044.63c25d7af11908ebc05cbaf95265feed@haskell.org> #8880: Configured gcc not used for some build steps ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The gcc passed to `./configure --with-gcc` isn't used for all gcc invocations, leadings to warnings (and potentially problems) on OS X where the default gcc is llvm. Here's an example, the call to `gcc -E` doesn't use my configure gcc, `/usr/local/bin/gcc-4.9`: {{{ sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.l_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.debug_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_debug_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_l_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.debug_dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_debug_dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.l_dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_l_dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && true gcc -E -m64 -DPROFILING -DTHREADED_RTS -DDEBUG -Irts/dist/build -m64 -fno-stack-protector -Wall -Wextra -Wstrict-prototypes -Wmissing- prototypes -Wmissing-declarations -Winline -Waggregate-return -Wpointer- arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -fno-strict- aliasing -fno-common -DDTRACE -O2 -fomit-frame-pointer -DRtsWay=\"rts_v\" -Wno-strict-prototypes -MM -x c rts/WSDeque.c -MF rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit no checking for sigaction... In file included from rts/WSDeque.c:44: In file included from rts/RtsUtils.h:12: rts/BeginPrivate.h:9:13: warning: unknown pragma ignored [-Wunknown- pragmas] #pragma GCC visibility push(hidden) ^ In file included from rts/WSDeque.c:44: In file included from rts/RtsUtils.h:48: rts/EndPrivate.h:2:13: warning: unknown pragma ignored [-Wunknown-pragmas] #pragma GCC visibility pop ^ 2 warnings generated. }}} I can't quite tell from which part of the build this is. Looks RTS related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 09:04:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 09:04:44 -0000 Subject: [GHC] #8880: Configured gcc not used for some build steps In-Reply-To: <044.63c25d7af11908ebc05cbaf95265feed@haskell.org> References: <044.63c25d7af11908ebc05cbaf95265feed@haskell.org> Message-ID: <059.e66c5f8c53ef78dfdb388e814eb9aa81@haskell.org> #8880: Configured gcc not used for some build steps -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.9 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tibbe): * status: new => closed * resolution: => duplicate Comment: Duplicate of #8498. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 09:05:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 09:05:41 -0000 Subject: [GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) In-Reply-To: <045.6e47836af0f0e307f79949999a773a19@haskell.org> References: <045.6e47836af0f0e307f79949999a773a19@haskell.org> Message-ID: <060.c016455374addec682a07ad35920958e@haskell.org> #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ---------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by tibbe): * cc: tibbe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 09:24:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 09:24:11 -0000 Subject: [GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) In-Reply-To: <045.6e47836af0f0e307f79949999a773a19@haskell.org> References: <045.6e47836af0f0e307f79949999a773a19@haskell.org> Message-ID: <060.3f388e76b997a8b9757d04b69d9224a7@haskell.org> #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ---------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by tibbe): * cc: simonmar (added) Comment: Using `make -d` it seems like the RTS is indeed to blame: {{{ Must remake target `rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug- thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm'. "rm" -f rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l- debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp Putting child 0x7fc32f874ae0 (rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm) PID 46072 on the chain. Live child 0x7fc32f874ae0 (rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm) PID 46072 Reaping winning child 0x7fc32f874ae0 PID 46072 gcc -E -m64 -DPROFILING -DTHREADED_RTS -DDEBUG -Irts/dist/build -m64 -fno-stack-protector -Wall -Wextra -Wstrict-prototypes -Wmissing- prototypes -Wmissing-declarations -Winline -Waggregate-return -Wpointer- arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -fno-strict- aliasing -fno-common -DDTRACE -O2 -fomit-frame-pointer -DRtsWay=\"rts_v\" -Wno-strict-prototypes -Wno-strict-prototypes -MM -x c rts/Adjustor.c -MF rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit Live child 0x7fc32f874ae0 (rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm) PID 46074 }}} Do we have anyone who understands the build system now when Ian isn't working at GHC HQ anymore? Simon M? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 09:25:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 09:25:35 -0000 Subject: [GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) In-Reply-To: <045.6e47836af0f0e307f79949999a773a19@haskell.org> References: <045.6e47836af0f0e307f79949999a773a19@haskell.org> Message-ID: <060.35026b743a50444e37dd7a5ae208c98e@haskell.org> #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ---------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by hvr): Replying to [ticket:8498 carter]: > notice the hard coded gcc call > > {{{ gcc -E -m64 -undef -traditional -P -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Icompiler/stage1 -x c compiler/prelude/primops.txt.pp | grep -v '^#pragma GCC' > compiler/stage1/build/primops.txt }}} fyi, this may be actually related to #8683 as the rule involved uses `$CPP`: {{{#!make compiler/stage$1/build/Parser.y: compiler/parser/Parser.y.pp $$(CPP) $$(RAWCPP_FLAGS) -P $$(compiler_CPP_OPTS) -x c $$< | grep -v '^#pragma GCC' > $$@ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 09:26:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 09:26:31 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.f46ba57512a8d704689d35d492db4f11@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Changes (by tibbe): * cc: tibbe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 10:12:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 10:12:50 -0000 Subject: [GHC] #7633: Checkable "minimal complete definitions" In-Reply-To: <046.58636b55ed32747ffa4f860e053150cd@haskell.org> References: <046.58636b55ed32747ffa4f860e053150cd@haskell.org> Message-ID: <061.250b3cf1d209f92fc3234fdacbdc7156@haskell.org> #7633: Checkable "minimal complete definitions" -------------------------------------------------+------------------------- Reporter: shachaf | Owner: Type: feature request | twanvl Priority: normal | Status: Component: Compiler | closed Resolution: fixed | Milestone: 7.8.1 Operating System: Unknown/Multiple | Version: 7.6.1 Type of failure: None/Unknown | Keywords: Test Case: warnings/minimal/WarnMinimal | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: #6028 -------------------------------------------------+------------------------- Comment (by haasn): Thanks, can't believe I missed that! I didn't think about looking inside the tcdSigs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 10:15:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 10:15:30 -0000 Subject: [GHC] #8881: No way to unsubscribe a bug Message-ID: <046.3e20bef03cc312ed086d6bf0a5bf092e@haskell.org> #8881: No way to unsubscribe a bug ------------------------------------+------------------------------------- Reporter: nomeata | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The current trac settings are so that when I comment on a bug, I am automatically subscribed to it. This is good, but there should be way to unsubscribe from a bug as well. Also, and I?m not sure if this is the same thing or not, if I put myself in the ?Observer? list (possibly wrong translation), I cannot undo that. Generally, we might give our users more permissions, e.g. to edit ticket descriptions (and not just the summary). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 12:25:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 12:25:03 -0000 Subject: [GHC] #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout In-Reply-To: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> References: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> Message-ID: <059.1bdf2e886cc43142ec07d44dd0811a38@haskell.org> #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"b0416e776d2959ac8b9903eb9301b7b967c53a8e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b0416e776d2959ac8b9903eb9301b7b967c53a8e" Comments on virtHp, realHp (Trac #8864) Documentation in response to Johan's questions Plus, don't export hpRel from StgCmmHeap, StgCmmLayout (it is only used locally in StgCmmLayout) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 12:25:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 12:25:04 -0000 Subject: [GHC] #8878: Export runTcInteractive from TcRnDriver In-Reply-To: <047.6601d2f94bde1975c44c22d38170011e@haskell.org> References: <047.6601d2f94bde1975c44c22d38170011e@haskell.org> Message-ID: <062.1e26d1ecc291503769306a5a0bff5780@haskell.org> #8878: Export runTcInteractive from TcRnDriver -------------------------------+------------------------------------------- Reporter: holzensp | Owner: holzensp Type: feature | Status: new request | Milestone: 7.8.1 Priority: lowest | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"60bbc0af79ddfe977d93e271b57c2bc25d3fcde6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="60bbc0af79ddfe977d93e271b57c2bc25d3fcde6" Export runTcInteractive from TcRnDriver, and from GHC (Trac #8878) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 12:25:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 12:25:04 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.ce495ef5bb41627aa11705b656aed4ec@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` --------------------------------------------+------------------------------ Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"8fd7d581da448d81fc2f9d47366c36c5f57ed564/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8fd7d581da448d81fc2f9d47366c36c5f57ed564" Add BuiltinRules for constant-folding not# and notI# (logical complement) I don't know why these constant-folding rules were implemented for and/or/xor but not for 'not'. Adding them is part of the fix for Trac #8832. (The other part is in Data.Bits.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 12:25:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 12:25:05 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.d68575670fb2cf32d21b9ae0810de4e7@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` --------------------------------------------+------------------------------ Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"ea6dcef1d9800953b1791304d52884359f415ad9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ea6dcef1d9800953b1791304d52884359f415ad9" Test Trac #8832 The test is a bit crude; -ddump-simpl | grep '#'. I'm concerned that the -ddump-simpl output may differ on 32 and 64-bit platforms. So far I've only put in output for 64-bit platforms. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 12:26:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 12:26:44 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.73bec7492551e217a96e1e7419421908@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` --------------------------------------------+------------------------------ Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"f7a7b586bc89ca7fd56792da4172bd93a2acdae9/base"]: {{{ #!CommitTicketReference repository="base" revision="f7a7b586bc89ca7fd56792da4172bd93a2acdae9" Add shiftR and shiftL implementations to instance Bits Integer Apart from simply making sense (avoid the conditional in 'shift'), this makes left and right shifts on Integer more likely to inline (plain 'shift' is just too large); and this in turn is important when fixing the Integer case of #8832 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 12:28:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 12:28:02 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.c1d25d9170a1c25e06e70885bd2b00ce@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` --------------------------------------------+------------------------------ Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): I believe I've fixed this. I'm not sure if it's worth merging into 7.8; the status quo is definitely not a show-stopper. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 12:28:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 12:28:50 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.bd0b1bb92cd0ba6ab8fe04e50b7eb347@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------------------+------------------------- Reporter: hvr | Owner: Type: bug | simonpj Priority: normal | Status: new Component: Compiler | Milestone: 7.8.1 Resolution: | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: Runtime performance bug | Keywords: Test Case: | Architecture: simplCore/should_compile/T8832 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * testcase: => simplCore/should_compile/T8832 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 12:30:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 12:30:19 -0000 Subject: [GHC] #8878: Export runTcInteractive from TcRnDriver In-Reply-To: <047.6601d2f94bde1975c44c22d38170011e@haskell.org> References: <047.6601d2f94bde1975c44c22d38170011e@haskell.org> Message-ID: <062.c1d5b19e03be1768a3abcfbbd8a6f353@haskell.org> #8878: Export runTcInteractive from TcRnDriver -------------------------------+------------------------------------------- Reporter: holzensp | Owner: holzensp Type: feature | Status: new request | Milestone: 7.8.1 Priority: lowest | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by simonpj): OK I've done this, and also exported it from module GHC, which is supposed to be the API that clients use. Is it important to merge this into 7.8? It is very late in the day, but its a very innocuous change. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 12:34:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 12:34:04 -0000 Subject: [GHC] #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout In-Reply-To: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> References: <044.fdf525e430e1a7e0e9b8328fb13bcd31@haskell.org> Message-ID: <059.f34a52cdedb43e45d9c7f7b13831eb9d@haskell.org> #8864: Document heap allocation functions in StgCmmMonad/StgCmmLayout -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 12:40:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 12:40:17 -0000 Subject: [GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) In-Reply-To: <045.6e47836af0f0e307f79949999a773a19@haskell.org> References: <045.6e47836af0f0e307f79949999a773a19@haskell.org> Message-ID: <060.ce25e4c0daa1a83b18e190c44c8dffce@haskell.org> #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ---------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by simonmar): I don't off-hand know why this is happening, but regressions in `--with- gcc` are not uncommon since we don't test it regularly. Looks like there are at least two things wrong: * `$(CPP)` is mapped to `gcc`. It comes directly from configure, so that should be easy enough to find. * The command that is building a file from the RTS is invoking GHC, so I suspect somehow GHC itself has a `gcc` baked into it (or passed in from configure?). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 13:08:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 13:08:07 -0000 Subject: [GHC] #8882: Anatomy Muscles Message-ID: <047.2f89340e60a8bec6199d985a9e83244a@haskell.org> #8882: Anatomy Muscles -----------------------------------------+--------------------------------- Reporter: coustato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Data Parallel Haskell | Version: 7.6.3 Keywords: Nitric Max Muscle | Operating System: Architecture: arm | Unknown/Multiple Difficulty: Difficult (2-5 days) | Type of failure: Runtime Blocked By: | crash Related Tickets: | Test Case: | Blocking: -----------------------------------------+--------------------------------- Morphology Muscles - Muscles Chart - Muscles Accumulation These 5 steps expose the things you dead Staleness Refrain if you essential to larghetto the aging touch, reprocess your upbeat, and attain your ideal body (Morphology Muscles - Muscles Interpret - Muscles Magnitude). Nitric Max Muscle What you impoverishment is a disperse of insensate liquid, a signature of Old Polish, and the artless emancipationist. Quantify good? Let's diving in! Interval 1: Bury Low-Fat Diets Support 2: Spot Running in Circles Support 3: Preclude Blaming Everything On How Old You Are Tread 4: Desist Degenerative Extraction Block 5: Impact Out Fewer (Yes, Less) Support 6: Anatomy Muscles - Muscles Chart - Muscles Accumulation Now You Can Unhurried The Old Affect To A Crawling, Quick Forge The Embody You've Always Welcome, Quality Alter It Sensing As If You're Aging 'Backwards' And Do It All In Fitting 90 Transactions A Period FACT: Our bodies all age, one day at a period. Withal: You can Inactive the old outgrowth physician and totally mold your body to the direction to where you sensing a decade junior than you are manus now in little than 90 days. This does not relate special creams, or whatsoever benevolent of 'miracle' FACT: Most people understand that both men and women Staleness work in order to grow affirm the timepiece. But did you experience that both men and women should essentially utilise out the comparable? Trusty, men leave use statesman metric, but the fright of women "getting bulky" is a MYTH and construe on. We'll substantiate it to you with pictures! FACT: You bang been lied to if you opine you human to rise large weights hours a day to countenance similar a complete stud, or that women status to terminate differently than men. We BOTH beggary LESS Clip in the gym, and we BOTH necessity the same fundamental prescript. Exclusive the status instrument change. FACT: You cannot gain this youth-enhancing System anywhere added. Becky and I hit restore control of it, and it's only initiate reactionary here, on this Anatomy Muscles - Muscles Chart - Muscles Massso ready reading?? I'm not asking you to vindicatory "buy a fact". I'm asking you to scan what Becky and I jazz to say in this laurels. It affects anyone over the age of especially if you are touch an age where you are mentation to yourself, "Vessel, I'm old it's downhill from Morphology Muscles - Muscles Chart - Muscles Collection." http://trynitricmaxmuscle.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 13:13:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 13:13:43 -0000 Subject: [GHC] #8878: Export runTcInteractive from TcRnDriver In-Reply-To: <047.6601d2f94bde1975c44c22d38170011e@haskell.org> References: <047.6601d2f94bde1975c44c22d38170011e@haskell.org> Message-ID: <062.8fe01151bd3930431b1c35b72c1d958f@haskell.org> #8878: Export runTcInteractive from TcRnDriver -------------------------------+------------------------------------------- Reporter: holzensp | Owner: holzensp Type: feature | Status: merge request | Milestone: 7.8.1 Priority: lowest | Version: 7.8.1-rc2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * status: new => merge * version: 7.6.3 => 7.8.1-rc2 Comment: A minor API addition like this isn't really a big deal IMO. It can go in the queue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 13:18:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 13:18:06 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.b2e39e5b5efe772fdde8f1447f558a23@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------------------+------------------------- Reporter: hvr | Owner: Type: bug | simonpj Priority: normal | Status: Component: Compiler | closed Resolution: fixed | Milestone: Operating System: Unknown/Multiple | Version: Type of failure: Runtime performance bug | 7.8.1-rc2 Test Case: | Keywords: simplCore/should_compile/T8832 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * milestone: 7.8.1 => Comment: Thanks Simon. I don't think this is worth merging with the fix Herbert put in the 7.8 branch, so I'm punting it off the 7.8.1 milestone now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 13:22:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 13:22:42 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT In-Reply-To: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> References: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> Message-ID: <062.8868d04faa45bbfcfee093dad9298dfa@haskell.org> #8776: Displaying pattern synonym for a GADT -------------------------------------+------------------------------------ Reporter: monoidal | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.7 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 cactus): * status: new => merge Comment: OK I've done all but `ATyCon`. It's merged into `master` and should be ready to be picked up into `ghc-7.8`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 13:24:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 13:24:03 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.40b85afb47cfa26e9a3794d7b5ad13ab@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by jstolarek): Bug report says: > During debugging I see segfault occurs inside `evacuate` somewhere near `get_itbl` call I guess. Can someone tell me what is `evacuate` and `get_itbl`? Are these functions in the RTS? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 13:25:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 13:25:07 -0000 Subject: [GHC] #8882: internal error (deriving generic / cyclical imports?) Message-ID: <044.1daca3870a219aee32c2f06e9482c6a5@haskell.org> #8882: internal error (deriving generic / cyclical imports?) ----------------------------------+------------------------------- Reporter: mf825 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: panic | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------- Hi everybody, I often get compiler crashes in my larger and less well-maintained projects of this sort: ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: <
> This happened on earlier 7.* ghc versions (debian 64bit), and from the counter-example I have condensed today my vague guess is that it has something to do with cyclical imports and -XDerivingGeneric or some other type system related language extension. I witnessed this in both ghc and ghci, but the counter-example is in ghci. I want to investigate this further later, but in the hope that somebody can immediately see what's wrong, I decided to open this ticket with my preliminary findings. Just unpack and run ./crash.sh. (Possibly you don't need to populate the sandbox and can crash it manually in your environment right away.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 13:26:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 13:26:55 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT In-Reply-To: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> References: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> Message-ID: <062.d931c8093dbce6a064bccc8e86c83204@haskell.org> #8776: Displaying pattern synonym for a GADT -------------------------------------+------------------------------------ Reporter: monoidal | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Did you come across any particular obstacles with `TyCon`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 13:44:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 13:44:12 -0000 Subject: [GHC] #8878: Export runTcInteractive from TcRnDriver In-Reply-To: <047.6601d2f94bde1975c44c22d38170011e@haskell.org> References: <047.6601d2f94bde1975c44c22d38170011e@haskell.org> Message-ID: <062.d63530666930b832af79521037530033@haskell.org> #8878: Export runTcInteractive from TcRnDriver -------------------------------+------------------------------------------- Reporter: holzensp | Owner: holzensp Type: feature | Status: merge request | Milestone: 7.8.1 Priority: lowest | Version: 7.8.1-rc2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by holzensp): I didn't include the export in GHC, because of Simon M's argument on the mailing list [1] that GHC doesn't export TcRn, which is required for runTcInteractive. I'm fine with it either way, though. Methinks it is a rather harmless change, so I see no issue with including it in 7.8 as you have now done. Thanks much ;) [1] http://www.haskell.org/pipermail/ghc-devs/2014-February/004013.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 13:50:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 13:50:01 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature Message-ID: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature ------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- I assume that if a program typechecks, adding any missing top-level signature inferred by GHC should be a meaning-preserving transformation and yield a new program which typechecks. (Please correct me if I'm wrong). But I've found a violation: namely, given enough other extensions (I think TypeFamilies is the relevant one), GHC will infer signatures which would require FlexibleContexts! Arguably, either those signatures should be rejected in the first place with a special error message (since GHC is not supposed to show code the user didn't write in error messages), or TypeFamilies should imply FlexibleContexts (or a restricted form which is sufficient for what TypeFamilies produces - namely, constraints can contain type families in place of raw type variables). Here's an example - without FlexibleContexts it does not typecheck , unless you comment out the signature of fold and unfold. Those signatures where produced by GHCi (with :browse) in the first-place. {{{#!haskell {-# LANGUAGE TypeFamilies, DeriveFunctor, NoMonomorphismRestriction #-} -- , FlexibleContexts data Fix f = In { out :: f (Fix f) } data Expr = Const Int | Add Expr Expr data PFExpr r = ConstF Int | AddF r r deriving Functor type Expr' = Fix PFExpr class Regular0 a where deepFrom0 :: a -> Fix (PF a) deepTo0 :: Fix (PF a) -> a type family PF a :: * -> * type instance PF Expr = PFExpr instance Regular0 Expr where deepFrom0 = In . (\expr -> case expr of Const n -> ConstF n Add a b -> AddF (deepFrom0 a) (deepFrom0 b)) deepTo0 = (\expr' -> case expr' of ConstF n -> Const n AddF a b -> Add (deepTo0 a) (deepTo0 b)) . out class Regular a where from :: a -> PF a a to :: PF a a -> a instance Regular Expr where from expr = case expr of Const n -> ConstF n Add a b -> AddF a b to expr' = case expr' of ConstF n -> Const n AddF a b -> Add a b -- But in fact, the construction is just an instance of fold. fold :: (Functor (PF a), Regular a) => (PF a b -> b) -> a -> b unfold :: (Functor (PF b), Regular b) => (a -> PF b a) -> a -> b fold f = f . fmap (fold f) . from unfold f = to . fmap (unfold f) . f }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 13:59:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 13:59:59 -0000 Subject: [GHC] #8882: internal error (deriving generic / cyclical imports?) In-Reply-To: <044.1daca3870a219aee32c2f06e9482c6a5@haskell.org> References: <044.1daca3870a219aee32c2f06e9482c6a5@haskell.org> Message-ID: <059.25a884f6aedb01c7e637921855fe86e3@haskell.org> #8882: internal error (deriving generic / cyclical imports?) -------------------------------+---------------------------------- Reporter: mf825 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: panic Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by thoughtpolice): This seems to be fixed in 7.8.1. Using 7.8.1-rc2, running `crash.sh` I get: {{{ $ ./crash.sh ... lots of stuff ... Loading package profunctors-4.0.2 ... linking ... done. Loading package reflection-1.4 ... linking ... done. Loading package split-0.2.2 ... linking ... done. Loading package void-0.6.1 ... linking ... done. Loading package lens-4.0.5 ... linking ... done. [1 of 5] Compiling Adhocracy.DataModel.Types ( src/Adhocracy/DataModel/Types.hs, interpreted ) [2 of 5] Compiling Adhocracy.Types ( src/Adhocracy/Types.hs, interpreted ) [3 of 5] Compiling Adhocracy.DataModel.Universes[boot] ( src/Adhocracy/DataModel/Universes.hs-boot, interpreted ) [4 of 5] Compiling Adhocracy.DataModel.Default ( src/Adhocracy/DataModel/Default.hs, interpreted ) [5 of 5] Compiling Adhocracy.DataModel.Universes ( src/Adhocracy/DataModel/Universes.hs, interpreted ) Ok, modules loaded: Adhocracy.DataModel.Default, Adhocracy.DataModel.Types, Adhocracy.DataModel.Universes, Adhocracy.DataModel.Universes, Adhocracy.Types. *Adhocracy.DataModel.Default> *Adhocracy.DataModel.Default Adhocracy.DataModel.Default> Top level: Not in scope: data constructor ?WDF? }}} The last error message looks like a bug in your script since I have no idea where `WDF` is supposed to come from. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 14:07:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 14:07:29 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.1e4af2486fc7cdf24c1e9649b48df91c@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): Yes, they are in RTS. More precise location is rts/sm/Evac.c line 390. Also I think this bug is triggered near foreign `memchr` call in function `elemIndex` from `Data.ByteString` module in `bytestring` package, which is inlined down to `lines` function from `Data.ByteString.Char8`. Also I checked this bug is not triggered if relevant modules from `bytestring` package are compiled with `-O` flag instead of `-O2`, hence this bug could be more ubiquitous if more applications code was compiled with `-O2`, perhaps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 14:14:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 14:14:40 -0000 Subject: [GHC] #8882: internal error (deriving generic / cyclical imports?) In-Reply-To: <044.1daca3870a219aee32c2f06e9482c6a5@haskell.org> References: <044.1daca3870a219aee32c2f06e9482c6a5@haskell.org> Message-ID: <059.803d9ec767b5f36c1b6e921e5c9eaa4f@haskell.org> #8882: internal error (deriving generic / cyclical imports?) -------------------------------+---------------------------------- Reporter: mf825 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: panic Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by simonpj): See also #8374 Try with `-fno-warn-amp`? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 14:15:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 14:15:17 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.1925c29d1c88799bee4fb23ee290e73f@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by jstolarek): > Also I checked this bug is not triggered if relevant modules from `bytestring` package are compiled with `-O` flag instead of `-O2` That's interesting. Looking at `DynFlags.lhs` I see two optimisations that are enabled only with `-O2`: liberate case and SpecConstr. I admit have no idea what they do. Suggestions please? > Also I think this bug is triggered near foreign `memchr` call in function `elemIndex` from `Data.ByteString` module in bytestring package, which is inlined down to lines function from `Data.ByteString.Char8`. It would be great if we had a test case that does not depend on any library code. This way we could eyeball the problem by looking at Cmm. Do you think you would be able to create such a test case. I got my hands on 64-bit Windows, I'm building GHC at the moment so I'll try to look into this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 14:19:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 14:19:37 -0000 Subject: [GHC] #8878: Export runTcInteractive from TcRnDriver In-Reply-To: <047.6601d2f94bde1975c44c22d38170011e@haskell.org> References: <047.6601d2f94bde1975c44c22d38170011e@haskell.org> Message-ID: <062.cc73c74f0e4dcc471dfdf978d0e50840@haskell.org> #8878: Export runTcInteractive from TcRnDriver -------------------------------+------------------------------------------- Reporter: holzensp | Owner: holzensp Type: feature | Status: merge request | Milestone: 7.8.1 Priority: lowest | Version: 7.8.1-rc2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by simonpj): I don't really care either, but my inclination is that if it's something we expect GHC-API clients to call, it should be exported by GHC. You want `runTcInterative`, but presumably to make use of it you also need some other functions in the `TcRn` monad. So probably it alone isn't enough. Identifying a useful set would be a Good Thing. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 14:23:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 14:23:46 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.8a34319f79af7842985e8f16822fd7f3@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by thoughtpolice): It's not true that those are the *only* things enabled by -O2 - you must also search for `optLevel`, which client code can depend on for specific instances if they wish (for example, maybe it's *not* an entire Core->Core pass, but an otherwise small micro-optimization). Actually, now that I'm searching and thinking about it - the only other case where we do this is when we short-cut PAPs - see 4d1ea482885481073d2fee0ea0355848b9d853a1 and `Note [avoid intermediate PAPs]` in `StgCmmLayout`. Simon committed this a while ago. I also have a Win32 build going, so I'll test this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 14:24:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 14:24:19 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.3d047b30f9820ddb7560898a1e62ba9b@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by thoughtpolice): (To be clear: by 'test this' I mean reverting that). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 14:25:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 14:25:14 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.a983294dd65c193ee4b48c91463b9211@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): Replying to [comment:24 jstolarek]: > It would be great if we had a test case that does not depend on any library code. This way we could eyeball the problem by looking at Cmm. Do you think you would be able to create such a test case. I think, this code should be enough: {{{ module BugIso (lines1) where import Prelude hiding (null, take, drop) import Data.ByteString hiding (elemIndex) import Data.ByteString.Internal import Data.Word import Foreign elemIndex1 :: Word8 -> ByteString -> Maybe Int elemIndex1 c (PS x s l) = inlinePerformIO $ withForeignPtr x $ \p -> do let p' = p `plusPtr` s q <- memchr p' c (fromIntegral l) return $! if q == nullPtr then Nothing else Just $! q `minusPtr` p' {-# INLINE elemIndex1 #-} elemIndex :: Char -> ByteString -> Maybe Int elemIndex = elemIndex1 . c2w {-# INLINE elemIndex #-} lines1 :: ByteString -> [ByteString] lines1 ps | null ps = [] | otherwise = case search ps of Nothing -> [ps] Just n -> take n ps : lines1 (drop (n+1) ps) where search = elemIndex '\n' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 14:35:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 14:35:55 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.76152ea5e69d9fa4bdbb72f0777415dd@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature -------------------------------------+------------------------------------ Reporter: Blaisorblade | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): You are technically quite right, and this wouldn't be hard to fix, by looking at the inferred type. Not, perhaps, very high priority, but if someone would like to have a go it would not be hard and I could offer guidance. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 14:40:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 14:40:08 -0000 Subject: [GHC] #8884: Producing Slime For a Halloween Party Message-ID: <047.c40acdae5f2e6b10ded38e3238c0f3de@haskell.org> #8884: Producing Slime For a Halloween Party --------------------------------------------+------------------------------ Reporter: ciagogou | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.6.3 Keywords: Simply Green Coffee Bean | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: --------------------------------------------+------------------------------ Do you need to do a immunology proceed which passions as nicely as enhances the skillfulness of your kid virtually the study? If so, then correct here are both directive immunology tasks for little children that give not exclusive ameliorate their tendency, but also have them entertained and occupied. Generating goo faculty be amusing. It is a artist schoolhouse alchemy move. If you possess several knowledge some adding a lot author personalty to muck, condition it to your kid. Matter has numerous variations. Essentially, white cement and borax are the crucial components for producing gunk. Flubber is a singular of its palatable types. Stone spikes are yet added lanceolate and berth see externalise which entails evaporating a medicine of Epsom flavourer on construction medium. When this is settled, it results in crystals with vibrant glasses. New chemical substances these kinds of as seasoning, sweetening and borax can also be utilised. Simply Green Coffee Bean Baking soda volcano is truly simple to act. It does demand whatever origination grooming equal creating the strobilus of a crevice as the baking soda finding as to afflict from the voice. In consideration the hot tonic fox does not direct, then use all the substances that utilized to represent Mentos and fasting regime tonic to generate a crack expeditious. If you youngsters adore to connection you in the kitchen atlantic, then kind both pareve matter items equal dulcify crystals. This can be second intense and desires to be supervised as it involves burning and cooking. Or else, you can unify ice toiletry components unitedly and educate immature children the conception of freezing and melancholy. Instead, you can apprise kids nigh acidity and basicity by giving them a pH publisher and allowing them see few abode cleansing artifact. Erst again this is a supervised employ as it entails chemical compounds. We've noticed Soul Boozing water Sculpture (WWM) in watery pools for virtually 20 some period. Now we are outset to see it spas & sizzling tubs as nicely. WWM is a "naturally" ocurring flora that can inform up anyplace there is h2o or moisture. Consumers are line and asking about and mentioning a "moist paper equivalent" capital on the ascend area(s) of the spa take, filtrate pleats and remaining places. Occasionally, a thin "pinkish" coloring is seen alongside the spoilage. That is titled "flower slime." The two often go hand-in-hand. Unfortunately, by the dimension you license the WWM or knock goo in the spa alone, it nearly ofttimes signifies that the measure lines, jets, viscus components, and more others. are totally plagued. By the way, WWM & Ping matter is not serious - it fair appears Really inferior. How do you get rid of it? With lots or line! The WWM is a biofilm that builds up overtime in the trade lines & progressively spreads all the way finished the spa. Clients usually maintain that the spa has a "funky" sensation and they can't conserves a uppercase present of sanitizer (gas, bromine, or biguanide). The biofilm construct-up is Quite resilient versus any sort of shocking or higher ranges of halogens (element or element). The land billet is you require to knob it evenhandedly than hold it. http://trysimplygreencoffee.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 14:40:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 14:40:58 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.58052dcbadbac713828a49b2c589389f@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by jstolarek): > It's not true that those are the *only* things enabled by -O2 Just to be clear, I only said they are the only `-O2` things enabled in `DynFlags`. > I think, this code should be enough: Yes, I can confirm that it segfaults. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 14:41:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 14:41:38 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.3d3d69415b6730e1298bd3edef1e2c83@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by thoughtpolice): I can confirm Kyril's example above works properly and produces the segfault as well. Here's my updated version: {{{#!haskell module Main (main) where import Prelude hiding (null, take, drop) import Data.ByteString hiding (elemIndex) import qualified Data.ByteString as B import Data.ByteString.Internal import Data.Word import Foreign elemIndex1 :: Word8 -> ByteString -> Maybe Int elemIndex1 c (PS x s l) = inlinePerformIO $ withForeignPtr x $ \p -> do let p' = p `plusPtr` s q <- memchr p' c (fromIntegral l) return $! if q == nullPtr then Nothing else Just $! q `minusPtr` p' {-# INLINE elemIndex1 #-} elemIndex :: Char -> ByteString -> Maybe Int elemIndex = elemIndex1 . c2w {-# INLINE elemIndex #-} lines1 :: ByteString -> [ByteString] lines1 ps | null ps = [] | otherwise = case search ps of Nothing -> [ps] Just n -> take n ps : lines1 (drop (n+1) ps) where search = elemIndex '\n' main = do f <- B.readFile "00-index.cache" print (Prelude.length $ lines1 f) }}} You can grab the `00-index.cache` file from `/c/Users/$USER/AppData/Roaming/cabal/packages/hackage.haskell.org/00-index.cache` I'm investigating reverting the PAP patch (still building). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 14:41:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 14:41:51 -0000 Subject: [GHC] #8858: Wrong maxStkSize calculation In-Reply-To: <044.8f6377e95db4a409b74bd6c341de1406@haskell.org> References: <044.8f6377e95db4a409b74bd6c341de1406@haskell.org> Message-ID: <059.fb81d494f895e2bb4264cdd85ba11f8a@haskell.org> #8858: Wrong maxStkSize calculation -------------------------------------+------------------------------------ Reporter: awson | Owner: thoughtpolice Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc2 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 simonmar): * owner: simonmar => thoughtpolice * milestone: => 7.8.1 Comment: yep, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 14:48:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 14:48:02 -0000 Subject: [GHC] #8855: LLVM backend needs to use `-globalopt` explicitly In-Reply-To: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> References: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> Message-ID: <061.93237de8ce308bdda9af607035d4e6d2@haskell.org> #8855: LLVM backend needs to use `-globalopt` explicitly -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by scpmw): Yes, that's basically my suggestion. Can't say anything about the dynamic linking blacklist change though, that should probably be a different ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 14:49:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 14:49:44 -0000 Subject: [GHC] #8855: LLVM backend needs to use `-globalopt` explicitly In-Reply-To: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> References: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> Message-ID: <061.d572458fe11d8a5535b2e302b3247c95@haskell.org> #8855: LLVM backend needs to use `-globalopt` explicitly -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 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 thoughtpolice): * version: 7.8.1-rc1 => 7.8.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 14:51:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 14:51:35 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.9446fc277908177fc9c04441bcb2c551@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by jstolarek): I applied awson's patch that reverts some of my changes in `CmmSink` and surprisingly I'm still getting a segfault with code posted in comment [[comment:#27]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 14:53:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 14:53:54 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.c87308cda734421fb57e380fb9f8e7bd@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): Replying to [comment:30 jstolarek]: > I applied awson's patch that reverts some of my changes in `CmmSink` and surprisingly I'm still getting a segfault with code posted in comment [[comment:#27]]. Very strange. I have no segfault here with patched HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 14:59:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 14:59:18 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.b2c23478118b791578aec4188f694cee@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): Could someone post Cmm for the working and non-working versions please? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 15:07:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 15:07:18 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.341c3ae1698578de5eeb4e197ea2f393@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): These are versions, compiled with `-O2 -fmax-simplifier-iterations=10 -fdicts-cheap -fspec-constr-count=6` (`bytestring` package flags) by 7.8rc2 (bad) and patched HEAD (good). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 15:08:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 15:08:34 -0000 Subject: [GHC] #8884: Reifying closed type families is broken Message-ID: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> #8884: Reifying closed type families is broken ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If I say {{{ {-# LANGUAGE TemplateHaskell, TypeFamilies, PolyKinds #-} module Scratch where import Language.Haskell.TH type family Foo a where Foo x = x $( do FamilyI foo [] <- reify ''Foo runIO $ putStrLn $ show foo return [] ) }}} and compile, I see (with uniques suppressed) {{{ ClosedTypeFamilyD Scratch.Foo [KindedTV a (VarT k)] (Just (AppT (AppT ArrowT (VarT k)) (VarT k))) [TySynEqn [VarT k,VarT x] (VarT x)] }}} There are two problems here: 1. The return kind (the third parameter to `ClosedTypeFamilyD`) should be just that -- the return kind. In the output, we see the full kind of the type family. `k -> k`. 2. The equation includes the kind variable `k`, which should be implicit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 15:13:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 15:13:43 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.a35e752c322e7168fdd57d800a4ad780@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by jstolarek): Could you also post cmm dumps for `-O1` and unpatched GHC? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 15:27:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 15:27:02 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.c592347909f5740f3ecc049a43177de4@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature -------------------------------------+------------------------------------ Reporter: Blaisorblade | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 jstolarek): * owner: => jstolarek -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 15:27:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 15:27:33 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.82fd23d750b2c2d7b67fa08e081378f8@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): Here is the broken bit of code, from `lines1_bad`: {{{ c2gC: _s2cV::I64 = R5; _s2cY::I64 = R2 + R4; _c2f5::I64 = R5; (_s2d3::I64) = call "ccall" arg hints: [PtrHint, `signed',] result hints: [PtrHint] memchr(_s2cY::I64, 10, _c2f5::I64); if (_s2d3::I64 == 0) goto c2gK; else goto c2gL; c2gK: call MO_Touch(R3); I64[Hp - 128] = Data.ByteString.Internal.PS_con_info; P64[Hp - 120] = R3; I64[Hp - 112] = R2; I64[Hp - 104] = R4; I64[Hp - 96] = _s2cV::I64; I64[Hp - 88] = :_con_info; P64[Hp - 80] = Hp - 127; P64[Hp - 72] = GHC.Types.[]_closure+1; _c2gw::P64 = Hp - 86; Hp = Hp - 72; R1 = _c2gw::P64; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; }}} Note how R2, R3 and R4 are live across the C call. This is wrong, because on Win64, R3 and R4 are caller-saves and therefore clobbered by the C call. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 15:31:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 15:31:14 -0000 Subject: [GHC] #8885: Add inline versions of clone array primops Message-ID: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> #8885: Add inline versions of clone array primops ------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've changed the clone array primops (i.e. `cloneArray#`, `cloneMutableArray#`, `freezeArray#`, and `thawArray#`) to use the new inline allocation optimization for statically known array sizes. Furthermore, I've moved the implementation for the non-statically known case out-of-line, which should reduce code size. The numbers are very encouraging, with the new implementation being 74% (i.e. almost 4x) faster than the old one. I measured this by looking at the total time reported by `+RTS -s` for the attached `InlineCloneArrayAlloc` benchmark. Here are the stats from the best out of three runs of the old implementation: {{{ 1,600,041,120 bytes allocated in the heap 6,504 bytes copied during GC 35,992 bytes maximum residency (1 sample(s)) 21,352 bytes maximum slop 1588 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 1 colls, 0 par 0.01s 0.01s 0.0082s 0.0082s Gen 1 1 colls, 0 par 0.00s 0.11s 0.1062s 0.1062s INIT time 0.00s ( 0.00s elapsed) MUT time 0.29s ( 0.57s elapsed) GC time 0.01s ( 0.11s elapsed) EXIT time 0.01s ( 0.11s elapsed) Total time 0.31s ( 0.80s elapsed) %GC time 2.7% (14.2% elapsed) Alloc rate 5,497,251,856 bytes per MUT second Productivity 97.3% of total user, 37.4% of total elapsed }}} Here are the same for the new implementation: {{{ 1,600,041,120 bytes allocated in the heap 57,224 bytes copied during GC 35,992 bytes maximum residency (1 sample(s)) 21,352 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 3125 colls, 0 par 0.01s 0.01s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.00s 0.00s 0.0003s 0.0003s INIT time 0.00s ( 0.00s elapsed) MUT time 0.08s ( 0.08s elapsed) GC time 0.01s ( 0.01s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.08s ( 0.09s elapsed) %GC time 6.4% (8.8% elapsed) Alloc rate 21,260,179,643 bytes per MUT second Productivity 93.5% of total user, 88.8% of total elapsed }}} The performance ratio between the new and old implementation gets worse for the old implementation as the iteration count is increased. There's also an interesting difference in the Gen 1 collection times between the two implementations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 15:32:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 15:32:01 -0000 Subject: [GHC] #8885: Add inline versions of clone array primops In-Reply-To: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> References: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> Message-ID: <059.a4dacf75e55e28507834800ec7df5a6f@haskell.org> #8885: Add inline versions of clone array primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 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 tibbe): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 15:47:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 15:47:09 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.b57973838a77279539df894bf63b1466@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by jstolarek): > Note how R2, R3 and R4 are live across the C call. This is wrong, because on Win64, R3 and R4 are caller-saves and therefore clobbered by the C call. Just to clarify: floating of R2 is correct? `MachRegs.h` defines R3 and R4 correctly as caller saves: {{{ #if !defined(mingw32_HOST_OS) #define CALLER_SAVES_R3 #define CALLER_SAVES_R4 #endif }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 15:57:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 15:57:59 -0000 Subject: [GHC] #8886: sync-all: END actions result in confusing error message Message-ID: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> #8886: sync-all: END actions result in confusing error message -------------------------------------+------------------------------------- Reporter: fw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The instructions at [wiki:Newcomers] were slightly outdated, and result in a rather confusing error message: {{{ $ ./sync-all --testsuite get Unrecognised flag: --testsuite at ./sync-all line 872. == Checking for old haddock repo == Checking for old binary repo == Checking for old mtl repo == Checking for old Cabal repo == Checking for old time from tarball ============================ ATTENTION! You have an old time package in your GHC tree! Please remove it (e.g. "rm -r libraries/time"), and then run "./sync-all get" to get the new repository. ============================ == Checking for obsolete Git repo URL $ }}} The patch suppresses the misleading error message. I've already removed the `--testsuite` flag from the wiki page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 15:58:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 15:58:44 -0000 Subject: [GHC] #8887: Double double assignment in optimized Cmm on SPARC Message-ID: <046.7dd6ce694dc9c9f0e18236436c35d4a8@haskell.org> #8887: Double double assignment in optimized Cmm on SPARC ----------------------------+-------------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Solaris Architecture: sparc | Type of failure: Runtime performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+-------------------------------------------- Hello, while reading ffi003 asm/opt-cmm for fixing this on SPARC I've noticed this code, this is optimized Cmm dump: {{{ 112 c1or: 113 _s1nw::F64 = F64[_s1nv::P32 + 3]; 114 _c1oj::I32 = sin; 115 _c1ok::F64 = _s1nw::F64; }}} this assignment to _s1nw::F64 looks useless as we may assign directly to _c1ok::F64, may we not? Both optimized and non-optimized Cmms attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 15:59:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 15:59:00 -0000 Subject: [GHC] #8886: sync-all: END actions result in confusing error message In-Reply-To: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> References: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> Message-ID: <056.7a6efe325696763d2dfd602f215d82e6@haskell.org> #8886: sync-all: END actions result in confusing error message -------------------------------------+------------------------------------- Reporter: fw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by fw): * version: 7.6.3 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 16:01:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 16:01:10 -0000 Subject: [GHC] #8887: Double double assignment in optimized Cmm on SPARC In-Reply-To: <046.7dd6ce694dc9c9f0e18236436c35d4a8@haskell.org> References: <046.7dd6ce694dc9c9f0e18236436c35d4a8@haskell.org> Message-ID: <061.1d057159b11b561d10b8958b6fedfc90@haskell.org> #8887: Double double assignment in optimized Cmm on SPARC --------------------------------------------+--------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: Runtime performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+--------------------------- Changes (by kgardas): * version: 7.6.3 => 7.9 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 16:04:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 16:04:01 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.0ae0872f35d69d990baf4e01f3aad291@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): All looks quite the contrary: {{{ ... #define REG_R2 r14 #define REG_R3 rsi #define REG_R4 rdi ... }}} [http://msdn.microsoft.com/en-us/library/6t169e9c.aspx The registers RBX, RBP, RDI, RSI, RSP, R12, R13, R14, and R15 are considered nonvolatile...] And we have *not defined* here: {{{ #if !defined(mingw32_HOST_OS) #define CALLER_SAVES_R3 #define CALLER_SAVES_R4 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 16:14:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 16:14:12 -0000 Subject: [GHC] #8885: Add inline versions of clone array primops In-Reply-To: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> References: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> Message-ID: <059.abe9bb35f541cfb92a782e081f1b957b@haskell.org> #8885: Add inline versions of clone array primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): I did some investigation to figure out why the old implementation holds on to all memory (assuming that it's not an accounting error). First, here's what the inner loop looks like for the old implementation: {{{ $wa_entry() // [R3, R2] { [(c3i2, $wa_info: const 12884901901; const 0; const 15;)] } {offset c3i2: if (R2 != 0) goto c3i0; else goto c3i1; c3i0: _s3f9::P64 = R3; (_c3hS::I64) = call "ccall" arg hints: [PtrHint,] result hints: [PtrHint] allocate(BaseReg - 24, 20); I64[_c3hS::I64] = I64[PicBaseReg + stg_MUT_ARR_PTRS_FROZEN0_info at GOTPCREL]; I64[_c3hS::I64 + 8] = 16; I64[_c3hS::I64 + 16] = 17; _c3i8::I64 = _c3hS::I64 + 24; call MO_Memcpy(_c3i8::I64, _s3f9::P64 + 24, 128, 8); call MO_Memset(_c3i8::I64 + 128, 1, 1, 8); R3 = _s3f9::P64; R2 = R2 - 1; call $wa_info(R3, R2) args: 8, res: 0, upd: 8; c3i1: R1 = PicBaseReg + (()_closure+1); call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } } }}} The first thing I did was to use the correct info table (`FROZEN`, not `FROZEN0`). That didn't help. The second thing I did was to use `-fno-omit-yields` to try to make sure the GC was run, as there's no heap check in this loop (and I don't know if `allocate` ever invokes the GC). That didn't have any effect. For reference, here's what the code with `-fno-omit-yields` looks like: {{{ $wa_entry() // [R3, R2] { [(c3i7, $wa_info: const 12884901901; const 0; const 15;)] } {offset c3i7: if (I64[BaseReg + 856] == 0) goto c3i8; else goto c3ia; c3i8: // nop // nop R1 = PicBaseReg + $wa_closure; call (I64[BaseReg - 8])(R3, R2, R1) args: 8, res: 0, upd: 8; c3ia: if (R2 != 0) goto c3i5; else goto c3i6; c3i5: _s3f9::P64 = R3; (_c3hX::I64) = call "ccall" arg hints: [PtrHint,] result hints: [PtrHint] allocate(BaseReg - 24, 20); I64[_c3hX::I64] = I64[PicBaseReg + stg_MUT_ARR_PTRS_FROZEN_info at GOTPCREL]; I64[_c3hX::I64 + 8] = 16; I64[_c3hX::I64 + 16] = 17; _c3ie::I64 = _c3hX::I64 + 24; call MO_Memcpy(_c3ie::I64, _s3f9::P64 + 24, 128, 8); call MO_Memset(_c3ie::I64 + 128, 1, 1, 8); R3 = _s3f9::P64; R2 = R2 - 1; call $wa_info(R3, R2) args: 8, res: 0, upd: 8; c3i6: R1 = PicBaseReg + (()_closure+1); call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 16:16:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 16:16:19 -0000 Subject: [GHC] #8886: sync-all: END actions result in confusing error message In-Reply-To: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> References: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> Message-ID: <056.5ea8999c0c1b64c5103ffaff49ed2a04@haskell.org> #8886: sync-all: END actions result in confusing error message -------------------------------------+------------------------------------- Reporter: fw | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by fw): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 17:57:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 17:57:44 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.a08d50593d4f0ef3d068d121a3d96fc9@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): Ah, you're right, my apologies, I misread the conditional in `MachRegs.h`. So the problem is elsewhere... time for gdb? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 18:22:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 18:22:16 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.a3d91ca91015680b2d5531e42ebe952a@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by scpmw): Okay, I have now submitted an (hopefully) improved version: https://github.com/scpmw/ghc/pull/6 The main new idea is that instead of `tickishScoped`+`tickishSoftScope` and `tickishIgnoreCheap` respectively we now have two main tickish properties: - Scoping ([https://github.com/scpmw/ghc/commit/0798888f829fe527b7c03f7d73b1d04746183b64 #diff-90615b0b9a679ebb599d2cb8b2c0dcdeR519 Source]): Determines what transformations are allowed with respect to covered code. The three levels are `NoScope` for don't-care (= HPC ticks), `SoftScope` for no-float-out and `CostCentreScope` for no-float-out plus no-float-in modulo lambdas. - Placement ([https://github.com/scpmw/ghc/commit/0798888f829fe527b7c03f7d73b1d04746183b64 #diff-90615b0b9a679ebb599d2cb8b2c0dcdeR648 Source]): It occurred to me that `mkTick` has a very similar problem with characterising where to create ticks / what to automatically push them through. So I did basically the same thing - the three levels here are `PlaceRuntime` which basically floats through just type applications and casts, `PlaceNonLam` which additionally floats through lambdas, and `PlaceCostCentre` which again implements all the CC-specific rules (such as eliminating ticks on HNFs). Note that the difference between `PlaceRuntime` and `PlaceNonLam` is essentially `tickishCounts`. However, it's actually easier this way, as it allows `mkTick` to do its work without having to care about `tickishCounts` at all ([https://github.com/scpmw/ghc/commit/0798888f829fe527b7c03f7d73b1d04746183b64 #diff-3ff04cec4ec4aff71838022111551fb8R232 Source]). Furthermore I tried to update all documentation and add more comments all around. What is the last verdict on a Wiki page? Sorry if I'm a bit reluctant about this, but I can't think of anything offhand that I would want to put on a Wiki instead of into a code comment. Some more examples, possibly? Btw: A non-paywall link to the paper is http://eprints.whiterose.ac.uk/76448/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 18:22:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 18:22:48 -0000 Subject: [GHC] #8888: Document Coercible in user's guide Message-ID: <047.94c1acfb950684257c799730826cb077@haskell.org> #8888: Document Coercible in user's guide ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As far as I can tell, there is no discussion of `Coercible` in the User's Guide. Although the interface to `coerce` is essentially a vanilla API, the generation of `Coercible` instances is a language feature, and I believe deserves to be included. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 18:55:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 18:55:32 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.8ba34a909a79c6dbe5656476d9f25bb2@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------------- Comment (by goldfire): Having just tripped across this, adding `-fno-warn-amp` to the `GhcLibHcOpts` line in the active section of your `build.mk` works nicely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 19:32:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 19:32:23 -0000 Subject: [GHC] #8888: Document Coercible in user's guide In-Reply-To: <047.94c1acfb950684257c799730826cb077@haskell.org> References: <047.94c1acfb950684257c799730826cb077@haskell.org> Message-ID: <062.a2436c01e885f741520b8753fea3969b@haskell.org> #8888: Document Coercible in user's guide -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I think you are right. Joachim, how do you feel about this? Obviously include a link to the paper -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 19:51:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 19:51:02 -0000 Subject: [GHC] #7633: Checkable "minimal complete definitions" In-Reply-To: <046.58636b55ed32747ffa4f860e053150cd@haskell.org> References: <046.58636b55ed32747ffa4f860e053150cd@haskell.org> Message-ID: <061.405ced5cdeb247eb611bf8609c5da562@haskell.org> #7633: Checkable "minimal complete definitions" -------------------------------------------------+------------------------- Reporter: shachaf | Owner: Type: feature request | twanvl Priority: normal | Status: Component: Compiler | closed Resolution: fixed | Milestone: 7.8.1 Operating System: Unknown/Multiple | Version: 7.6.1 Type of failure: None/Unknown | Keywords: Test Case: warnings/minimal/WarnMinimal | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: #6028 -------------------------------------------------+------------------------- Comment (by Lemming): Interested in an experience report? I added MINIMAL pragmas to numeric- prelude classes. I did several mistakes when transferring human description to MINIMAL pragma, mostly mixing up comma and bar. These mistakes were revealed by instances that gave wrong alarms. However one alarm was serious and spotted a missing method implementation in a cycle of default definitions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 19:53:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 19:53:02 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.0678325eff787f76e44f3b284ad4a82d@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature -------------------------------------+------------------------------------ Reporter: Blaisorblade | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Blaisorblade): Thanks a lot for the prompt answer, and I agree on the priority. I only take the time to report such bugs because GHC is so good ;-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 20:07:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 20:07:18 -0000 Subject: [GHC] #7633: Checkable "minimal complete definitions" In-Reply-To: <046.58636b55ed32747ffa4f860e053150cd@haskell.org> References: <046.58636b55ed32747ffa4f860e053150cd@haskell.org> Message-ID: <061.0867e05cafac3fd90ac3d650fe5dfa6b@haskell.org> #7633: Checkable "minimal complete definitions" -------------------------------------------------+------------------------- Reporter: shachaf | Owner: Type: feature request | twanvl Priority: normal | Status: Component: Compiler | closed Resolution: fixed | Milestone: 7.8.1 Operating System: Unknown/Multiple | Version: 7.6.1 Type of failure: None/Unknown | Keywords: Test Case: warnings/minimal/WarnMinimal | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: #6028 -------------------------------------------------+------------------------- Comment (by Fuuzetsu): We've now pushed rendering of MINIMAL into Haddock. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 20:16:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 20:16:03 -0000 Subject: [GHC] #8885: Add inline versions of clone array primops In-Reply-To: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> References: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> Message-ID: <059.976e59b398086636e5680da81204e051@haskell.org> #8885: Add inline versions of clone array primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Both patches validate (module unrelated failures to type signature printing that's breaking validate in HEAD at the moment.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 20:26:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 20:26:06 -0000 Subject: [GHC] #8889: GHCI reports nasty type signatures Message-ID: <050.8be9da2264f8ee0e1a82a03f55af16c9@haskell.org> #8889: GHCI reports nasty type signatures ----------------------------------+------------------------------ Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.1-rc1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------ Load a file that contains: {{{ {-# LANGUAGE TypeFamilies , ConstraintKinds , MultiParamTypeClasses , UndecidableInstances , FlexibleInstances #-} import GHC.Prim import Prelude hiding (Functor(..)) class Functor f where type C_fmap_a f a :: Constraint type C_fmap_a f a = () type C_fmap_b f b :: Constraint type C_fmap_b f b = () fmap :: (C_fmap_a f a, C_fmap_b f b) => (a -> b) -> f a -> f b fmap1 :: (ValidFunctor f a, ValidFunctor f b) => (a -> b) -> f a -> f b fmap2 :: (ValidFunctor' f a, ValidFunctor' f b) => (a -> b) -> f a -> f b type ValidFunctor f a = ( Functor f , C_fmap_a f a , C_fmap_b f a ) class ValidFunctor f a => ValidFunctor' f a instance ValidFunctor f a => ValidFunctor' f a }}} Then check the following types in ghci {{{ ghci> :t fmap fmap :: (t, t1, Functor f, C_fmap_b f b ~ t1, C_fmap_a f a ~ t) => (a -> b) -> f a -> f b ghci> :t fmap1 fmap1 :: (t, t1, t2, t3, Functor f, C_fmap_b f b ~ t3, C_fmap_b f a ~ t1, C_fmap_a f b ~ t2, C_fmap_a f a ~ t) => (a -> b) -> f a -> f b ghci> :t fmap2 fmap2 :: (t, t1, t2, t3, Functor f, C_fmap_b f b ~ t3, C_fmap_b f a ~ t1, C_fmap_a f b ~ t2, C_fmap_a f a ~ t) => (a -> b) -> f a -> f b }}} These types are much nastier looking than they need to be. There are two problems: 1) Bogus types t,t1,t2,t3 are introduced when they don't need to be. This is confuses the type signatures quite a bit. 2) The type alias ValidFunctor is being desugared in the type signature for fmap1. This makes type aliases for constraints rather pointless. Also, I tried to solve problem two by adding an extra class, and hoping the class would be displayed instead, but this still doesn't work. I assume this is actually intended behavior though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 20:29:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 20:29:25 -0000 Subject: [GHC] #8882: internal error (deriving generic / cyclical imports?) In-Reply-To: <044.1daca3870a219aee32c2f06e9482c6a5@haskell.org> References: <044.1daca3870a219aee32c2f06e9482c6a5@haskell.org> Message-ID: <059.1b66eb18d9a9cabb7351a21cb176b317@haskell.org> #8882: internal error (deriving generic / cyclical imports?) -------------------------------+---------------------------------- Reporter: mf825 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: panic Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by monoidal): I'm almost certain this is #7878. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 21:14:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 21:14:15 -0000 Subject: [GHC] #8718: Add role annotations to base In-Reply-To: <046.5bf32c0ca4f956dafd133cea02061c35@haskell.org> References: <046.5bf32c0ca4f956dafd133cea02061c35@haskell.org> Message-ID: <061.0e42d3cfa86da3e9b9c7e4b6799518e7@haskell.org> #8718: Add role annotations to base -------------------------------+------------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: | Version: 7.6.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 8767 | -------------------------------+------------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"e55acf007f5109b42a2e388eaca63445bbbc7376/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e55acf007f5109b42a2e388eaca63445bbbc7376" Update to containers-0.5.5.0 This adds role annotations to Map and Set and therefore addresses #8718 Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 21:28:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 21:28:40 -0000 Subject: [GHC] #8885: Add inline versions of clone array primops In-Reply-To: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> References: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> Message-ID: <059.12c0091e9b6a5462de7e06d15350c699@haskell.org> #8885: Add inline versions of clone array primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): > 1588 MB total memory in use (0 MB lost due to fragmentation) Hehe, there was a bug in the old implementation, it didn't check for heap overflow so this benchmark never GC'd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 21:30:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 21:30:00 -0000 Subject: [GHC] #8885: Add inline versions of clone array primops In-Reply-To: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> References: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> Message-ID: <059.e2270d9bc47dac594e757480eaf5c0a4@haskell.org> #8885: Add inline versions of clone array primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): So we don't know how much of the speed increase is due to fixing the bug, and how much is due to inlining the array alloc. Still, it's probably better to inline the array alloc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 21:38:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 21:38:19 -0000 Subject: [GHC] #8876: Add inline version of newByteArray# In-Reply-To: <044.dd45b49424b698e257c76edd9a3cc0b3@haskell.org> References: <044.dd45b49424b698e257c76edd9a3cc0b3@haskell.org> Message-ID: <059.92f35ae6daf839fa2fa6edee7bbe2aa2@haskell.org> #8876: Add inline version of newByteArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 simonmar): * owner: simonmar => * status: patch => new Comment: LGTM! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 21:38:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 21:38:38 -0000 Subject: [GHC] #8885: Add inline versions of clone array primops In-Reply-To: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> References: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> Message-ID: <059.6e416073cb4ea338b8d19189a5b8fcda@haskell.org> #8885: Add inline versions of clone array primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Replying to [comment:5 simonmar]: > So we don't know how much of the speed increase is due to fixing the bug, and how much is due to inlining the array alloc. Still, it's probably better to inline the array alloc. Right. Is the bug in the implementation of `allocate` or in the implementation of the primops? If it's in the primops this bug exists in at least `stg_newArrayzh` as well, as I stole the allocation code from there. If you let me know when the bug is fixed, I will rerun the benchmark. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 21:41:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 21:41:03 -0000 Subject: [GHC] #8718: Add role annotations to base In-Reply-To: <046.5bf32c0ca4f956dafd133cea02061c35@haskell.org> References: <046.5bf32c0ca4f956dafd133cea02061c35@haskell.org> Message-ID: <061.dad56537c99812b7d24de1c1c9fa1da9@haskell.org> #8718: Add role annotations to base -------------------------------+------------------------------------------- Reporter: nomeata | Owner: Type: task | Status: closed Priority: high | Milestone: 7.8.1 Component: | Version: 7.6.3 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 8767 | -------------------------------+------------------------------------------- Changes (by goldfire): * cc: hvr (added) * status: new => closed * resolution: => fixed Comment: Yes, this is all in good shape now, assuming the new containers ships with 7.8. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 21:42:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 21:42:41 -0000 Subject: [GHC] #8718: Add role annotations to base In-Reply-To: <046.5bf32c0ca4f956dafd133cea02061c35@haskell.org> References: <046.5bf32c0ca4f956dafd133cea02061c35@haskell.org> Message-ID: <061.ae97c4e6933d6be24fb0499223776abf@haskell.org> #8718: Add role annotations to base -------------------------------+------------------------------------------- Reporter: nomeata | Owner: Type: task | Status: closed Priority: high | Milestone: 7.8.1 Component: | Version: 7.8.1-rc2 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 8767 | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * version: 7.6.3 => 7.8.1-rc2 Comment: Yep, thanks Herbert! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 21:45:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 21:45:22 -0000 Subject: [GHC] #8885: Add inline versions of clone array primops In-Reply-To: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> References: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> Message-ID: <059.02c9b4868d26750c95ae6430273d23d1@haskell.org> #8885: Add inline versions of clone array primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): The bug is in the primop. The out-of-line implementation doesn't have the bug: look for `MAYBE_GC()`, that's the heap-overflow check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 22:00:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 22:00:16 -0000 Subject: [GHC] #8867: newArray# fails to initialize card table correctly In-Reply-To: <044.37e67357715cbf019ab4d4ce4384fe21@haskell.org> References: <044.37e67357715cbf019ab4d4ce4384fe21@haskell.org> Message-ID: <059.2672d82c330673a9fc1d18f42ac6db4d@haskell.org> #8867: newArray# fails to initialize card table correctly -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Johan Tibell ): In [changeset:"46d05ba03d1491cade4a3fe33f0b8c404ad3c760/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="46d05ba03d1491cade4a3fe33f0b8c404ad3c760" Fix two issues in stg_newArrayzh The implementations of newArray# and newArrayArray#, stg_newArrayzh and stg_newArrayArrayzh, had three issues: * The condition for the loop that fills the array with the initial element was incorrect. It would write into the card table as well. The condition for the loop that filled the card table was never executed, as its condition was also wrong. In the end this didn't lead to any disasters as the value of the card table doesn't matter for newly allocated arrays. * The card table was unnecessarily initialized. The card table is only used when the array isn't copied, which new arrays always are. By not writing the card table at all we save some cycles. * The ticky allocation accounting was wrong. The second argument to TICK_ALLOC_PRIM is the size of the closure excluding the header size, but the header size was incorrectly included. Fixes #8867. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 22:01:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 22:01:35 -0000 Subject: [GHC] #8867: newArray# fails to initialize card table correctly In-Reply-To: <044.37e67357715cbf019ab4d4ce4384fe21@haskell.org> References: <044.37e67357715cbf019ab4d4ce4384fe21@haskell.org> Message-ID: <059.f9faaf0420e40c495fd0904bcaa74a55@haskell.org> #8867: newArray# fails to initialize card table correctly -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tibbe): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 22:51:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 22:51:47 -0000 Subject: [GHC] #8885: Add inline versions of clone array primops In-Reply-To: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> References: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> Message-ID: <059.b3a3ea297878aad160c1e41722218ec5@haskell.org> #8885: Add inline versions of clone array primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): There's not much point in comparing the new inline version vs the old, incorrect version. Fixing the old, incorrect version just to get the benchmark numbers doesn't seem worth it, as we'd have to replicate `MAYBE_GC` in `StgCmmPrim`. Instead I compare the new inline version against the new out-of-line version (which calls `allocate`). The inline versions is 69% faster. Here are the `+RTS -s` numbers for the new out-of-line version: {{{ 1,600,041,120 bytes allocated in the heap 57,992 bytes copied during GC 35,992 bytes maximum residency (1 sample(s)) 21,352 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 3173 colls, 0 par 0.01s 0.01s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.00s 0.00s 0.0002s 0.0002s INIT time 0.00s ( 0.00s elapsed) MUT time 0.25s ( 0.25s elapsed) GC time 0.01s ( 0.01s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.26s ( 0.26s elapsed) %GC time 2.1% (2.9% elapsed) Alloc rate 6,417,285,798 bytes per MUT second Productivity 97.9% of total user, 95.6% of total elapsed }}} And for the inline version: {{{ 1,600,041,120 bytes allocated in the heap 57,224 bytes copied during GC 35,992 bytes maximum residency (1 sample(s)) 21,352 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 3125 colls, 0 par 0.00s 0.01s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.00s 0.00s 0.0002s 0.0002s INIT time 0.00s ( 0.00s elapsed) MUT time 0.08s ( 0.08s elapsed) GC time 0.00s ( 0.01s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.08s ( 0.09s elapsed) %GC time 6.1% (8.2% elapsed) Alloc rate 20,999,017,271 bytes per MUT second Productivity 93.9% of total user, 89.2% of total elapsed }}} You can see that the GC issue has been fixed. I've attached updated versions of my patches that address the `MAYBE_GC` issue, which was also present in my new out-of-line implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 22:57:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 22:57:42 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.b4f15546f7fb465f88727c886c33abbf@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"a0bcbb54481297f9ff329766529a8343c4853e3f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a0bcbb54481297f9ff329766529a8343c4853e3f" fix SHELL makefile variable to be set by the configure script (fixes #8783) The patch provided by Christian Maeder Signed-off-by: Karel Gardas Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 22:57:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 22:57:43 -0000 Subject: [GHC] #8857: Sparc needs to be on the NoSharedLibsPlatformList In-Reply-To: <046.258abaf74ed428bef525e7078c75e6a0@haskell.org> References: <046.258abaf74ed428bef525e7078c75e6a0@haskell.org> Message-ID: <061.502e855befc9f7badde800722cde4241@haskell.org> #8857: Sparc needs to be on the NoSharedLibsPlatformList -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: sparc Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"623883f1ed0ee11cc925c4590fb09565403fd231/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="623883f1ed0ee11cc925c4590fb09565403fd231" disable shared libs on sparc (linux/solaris) (fixes #8857) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 22:57:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 22:57:43 -0000 Subject: [GHC] #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory In-Reply-To: <044.398377c33d022955e6b200df91088795@haskell.org> References: <044.398377c33d022955e6b200df91088795@haskell.org> Message-ID: <059.248d481f786105e593eee4f4122c67f5@haskell.org> #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory -----------------------------------+---------------------------------- Reporter: awson | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"b7e5d722c6811f34253d8202540dd9b0ec1b6766/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b7e5d722c6811f34253d8202540dd9b0ec1b6766" Fix incorrect blocksize calculation on Win64 Fixes #8839 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 22:57:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 22:57:44 -0000 Subject: [GHC] #8855: LLVM backend needs to use `-globalopt` explicitly In-Reply-To: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> References: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> Message-ID: <061.fe09afbe39a7eb6708fe3b2cb662d2b3@haskell.org> #8855: LLVM backend needs to use `-globalopt` explicitly -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"b84b5da4430aacd5bf8422b06a861cd0584f99cf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b84b5da4430aacd5bf8422b06a861cd0584f99cf" DriverPipeline: Ensure -globalopt is passed to LLVM opt While -O1 and -O2 both include -globalopt, the order in which the passes are run means that aliases aren't resolved which then causes llc to fall over. See GHC bug #8855. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 22:57:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 22:57:44 -0000 Subject: [GHC] #8858: Wrong maxStkSize calculation In-Reply-To: <044.8f6377e95db4a409b74bd6c341de1406@haskell.org> References: <044.8f6377e95db4a409b74bd6c341de1406@haskell.org> Message-ID: <059.caddea467206405926d502b25e0db203@haskell.org> #8858: Wrong maxStkSize calculation -------------------------------------+------------------------------------ Reporter: awson | Owner: thoughtpolice Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"b99ace39cb2484bfc2d648b55a1a43ed78e4b9a0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b99ace39cb2484bfc2d648b55a1a43ed78e4b9a0" Fix incorrect maxStkSize calculation (#8858) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 22:58:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 22:58:07 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.a581879ff0f8e7e602bddcabb454834a@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 22:58:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 22:58:41 -0000 Subject: [GHC] #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory In-Reply-To: <044.398377c33d022955e6b200df91088795@haskell.org> References: <044.398377c33d022955e6b200df91088795@haskell.org> Message-ID: <059.8f657cd50f2bfb885297db1eccee7782@haskell.org> #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory -----------------------------------+---------------------------------- Reporter: awson | Owner: thoughtpolice Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 22:59:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 22:59:02 -0000 Subject: [GHC] #8857: Sparc needs to be on the NoSharedLibsPlatformList In-Reply-To: <046.258abaf74ed428bef525e7078c75e6a0@haskell.org> References: <046.258abaf74ed428bef525e7078c75e6a0@haskell.org> Message-ID: <061.b14aed70f2e7eb5daeda9d3a9a2cb70b@haskell.org> #8857: Sparc needs to be on the NoSharedLibsPlatformList -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: sparc Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 22:59:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 22:59:12 -0000 Subject: [GHC] #8855: LLVM backend needs to use `-globalopt` explicitly In-Reply-To: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> References: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> Message-ID: <061.8c0982f09f57ef5ce556ef931c25b94f@haskell.org> #8855: LLVM backend needs to use `-globalopt` explicitly -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 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 thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 22:59:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 22:59:19 -0000 Subject: [GHC] #8858: Wrong maxStkSize calculation In-Reply-To: <044.8f6377e95db4a409b74bd6c341de1406@haskell.org> References: <044.8f6377e95db4a409b74bd6c341de1406@haskell.org> Message-ID: <059.fa411343add54b21964ec684c67271ed@haskell.org> #8858: Wrong maxStkSize calculation -------------------------------------+------------------------------------ Reporter: awson | Owner: thoughtpolice Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc2 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 thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 22:59:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 22:59:54 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.929a84b8a1c027275312c67957f60fc3@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8718 Blocking: | Related Tickets: #2110 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"f96dc5470355ce52741c717b6387d7f61b6a8dc1/base"]: {{{ #!CommitTicketReference repository="base" revision="f96dc5470355ce52741c717b6387d7f61b6a8dc1" Add RULE for "map coerce = map" (#8767) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 23:01:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 23:01:18 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.08226a607d2f94cb6c082ee6702ef60f@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: merge Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8718 Blocking: | Related Tickets: #2110 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * cc: hvr (added) * status: new => merge * version: 7.9 => 7.8.1-rc2 * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 23:02:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 23:02:00 -0000 Subject: [GHC] #8876: Add inline version of newByteArray# In-Reply-To: <044.dd45b49424b698e257c76edd9a3cc0b3@haskell.org> References: <044.dd45b49424b698e257c76edd9a3cc0b3@haskell.org> Message-ID: <059.3cd8fcb97cd859d0129cab5db3ad9602@haskell.org> #8876: Add inline version of newByteArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Johan Tibell ): In [changeset:"210ccabc9489bfbf814939e8b45646c8d0c7ce5f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="210ccabc9489bfbf814939e8b45646c8d0c7ce5f" codeGen: allocate small byte arrays of statically known size inline This results in a 57% runtime decrease when allocating an array of 128 bytes on a 64-bit machine. Fixes #8876. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 23:02:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 23:02:24 -0000 Subject: [GHC] #2110: Rules to eliminate casted id's In-Reply-To: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> References: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> Message-ID: <059.d604bacc47d89f75c1f744289f1e9891@haskell.org> #2110: Rules to eliminate casted id's -------------------------------------------------+------------------------- Reporter: igloo | Owner: Type: feature request | Status: Priority: lowest | closed Component: Compiler | Milestone: Resolution: fixed | 7.10.1 Operating System: Unknown/Multiple | Version: 6.8.2 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: tests/simplCore/should_run/T2110 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: #8767 -------------------------------------------------+------------------------- Changes (by thoughtpolice): * testcase: => tests/simplCore/should_run/T2110 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 23:02:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 23:02:30 -0000 Subject: [GHC] #8876: Add inline version of newByteArray# In-Reply-To: <044.dd45b49424b698e257c76edd9a3cc0b3@haskell.org> References: <044.dd45b49424b698e257c76edd9a3cc0b3@haskell.org> Message-ID: <059.f6788efaac204f71c27a1db9e8aba1eb@haskell.org> #8876: Add inline version of newByteArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tibbe): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 23:02:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 23:02:34 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.8fe15f1ee9be8a24eead4156c9ecca3e@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | Status: merge Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple tests/simplCore/should_run/T2110.hs | Difficulty: Blocking: | Unknown | Blocked By: 8718 | Related Tickets: #2110 -------------------------------------------------+------------------------- Changes (by thoughtpolice): * testcase: => tests/simplCore/should_run/T2110.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 23:03:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 23:03:31 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.3bd3b0089155581674363745d8d169de@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | Status: merge Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple tests/simplCore/should_run/T2110.hs | Difficulty: Blocking: | Unknown | Blocked By: 8718 | Related Tickets: #2110 -------------------------------------------------+------------------------- Comment (by thoughtpolice): Please excuse the completely stupid commit message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 23:08:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 23:08:17 -0000 Subject: [GHC] #8890: segfault on Windows 7 i386 Message-ID: <045.ef91946d4291bd999be2fb92692f63b8@haskell.org> #8890: segfault on Windows 7 i386 ----------------------------+--------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------------- This minimal example causes the GHC 7.8.1 i386 RC1 and RC2 binaries to segafult on two different Window 7 machines. It doesn't happen with the x86_64 binaries and it doesn't happen on the one Windows 8.1 machine I tried. {{{ {-# LANGUAGE GADTs #-} module Test1 where data T t where T :: T () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 23:20:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 23:20:19 -0000 Subject: [GHC] #8890: segfault on Windows 7 i386 In-Reply-To: <045.ef91946d4291bd999be2fb92692f63b8@haskell.org> References: <045.ef91946d4291bd999be2fb92692f63b8@haskell.org> Message-ID: <060.f919f253d3c156305563ae0c48601ad3@haskell.org> #8890: segfault on Windows 7 i386 ---------------------------------------+----------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+----------------------------- Comment (by ganesh): I attached a debugger but didn't see anything obviously helpful. Happy to provide dump files or anything else that's useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 13 23:38:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Mar 2014 23:38:55 -0000 Subject: [GHC] #8888: Document Coercible in user's guide In-Reply-To: <047.94c1acfb950684257c799730826cb077@haskell.org> References: <047.94c1acfb950684257c799730826cb077@haskell.org> Message-ID: <062.4563a712f878e866aaf2c5eccefd58c5@haskell.org> #8888: Document Coercible in user's guide -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): I still believe there is little to be gained by spreading documentation across different places. The user guide already references the API documentation, AFAIR, and the API docs should contain everything (in concise form) the user needs to know. A link to the paper should be added to the API docs... Hmm, I thought I added a reference to the docs at http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/special- ids.html. That would be the natural place for a link to the API, woudln?t it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 00:25:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 00:25:19 -0000 Subject: [GHC] #8888: Document Coercible in user's guide In-Reply-To: <047.94c1acfb950684257c799730826cb077@haskell.org> References: <047.94c1acfb950684257c799730826cb077@haskell.org> Message-ID: <062.dc89502a0d40204002884a412eeb802a@haskell.org> #8888: Document Coercible in user's guide -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Well, there really is a new form of constraint, written `(Coercible s t)`. It isn't really a class constraint, although by design it behaves in analogous ways. But you can't declare instances of `Coercible`, and it has special constraint-solving rules all of its own. That sounds like a language extension to me! There is no new syntax, but there ''is'' a new sort of constraint. I think it deserves its own section in Chapter 7. That's where users will lok. As to "spreading the documentation around", where (apart from the paper) are the solving rules for `Coercible` given? Perhaps with the (data type!) `Corecible` in `GHC.Types`? I'd be happier with a reference from there to the user manual, I think. Mind you, I'm puzzled. `Data.Coerce` in package `base` imports `Coercible` from `GHC.Prim` (which has no corresponding Haskell module). But `GHC.Types` in package `ghc-prim` defines `Coercible` (as a data type). So where is it defined? In `GHC.Prim` or `GHC.Types`? The Name defined in `PrelNames` suggests the latter. Also oddly, `PrelNames` defines `gHC_COERCIBLE` which seems to be unused ... delete? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 00:32:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 00:32:51 -0000 Subject: [GHC] #8600: ghc --help is outdated In-Reply-To: <048.bdb06add437102212b23e2d2cf0573f6@haskell.org> References: <048.bdb06add437102212b23e2d2cf0573f6@haskell.org> Message-ID: <063.5aa915a60d548ec6791394744447a756@haskell.org> #8600: ghc --help is outdated -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 foxnorth): * status: new => patch Comment: Simple textual change in driver/ghc-usage.txt per the above description. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 03:07:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 03:07:09 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT In-Reply-To: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> References: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> Message-ID: <062.11af451de5df85aeaad0c638de7e04d3@haskell.org> #8776: Displaying pattern synonym for a GADT -------------------------------------+------------------------------------ Reporter: monoidal | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by cactus): I may have to back out on `AnId` since it always prints explicit foralls, which could confuse newbies. Let's see if it's possible to know from an `IfaceId` if it was originally defined with explicit foralls. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 03:22:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 03:22:38 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.fecb6e066f83da2129cdb765e3c159ad@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | Status: merge Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple tests/simplCore/should_run/T2110.hs | Difficulty: Blocking: | Unknown | Blocked By: 8718 | Related Tickets: #2110 -------------------------------------------------+------------------------- Comment (by goldfire): But, there should be many more similar RULES than just this, no? For example, any lawful `Functor` instance should have a RULE for its `fmap`, as I understand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 03:35:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 03:35:42 -0000 Subject: [GHC] #8826: Allow more coercions in Safe Haskell In-Reply-To: <047.5c2eeb13a41e01da9bb6e46c88e0f15c@haskell.org> References: <047.5c2eeb13a41e01da9bb6e46c88e0f15c@haskell.org> Message-ID: <062.0e6745ea6d73c6a82f219c0f21168a6d@haskell.org> #8826: Allow more coercions in Safe Haskell -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"59722295bb8da8f01d37356fbed6aef7321a8195/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="59722295bb8da8f01d37356fbed6aef7321a8195" Remove "Safe mode" check for Coercible instances We assume that library authors supply correct role annotations for their types, and therefore we do not need to check for the availability of data constructors in Safe mode. See discussion in #8725. This effectively fixes #8827 and #8826. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 03:35:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 03:35:42 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.05694496f547547d9d64897c0858465d@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"59722295bb8da8f01d37356fbed6aef7321a8195/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="59722295bb8da8f01d37356fbed6aef7321a8195" Remove "Safe mode" check for Coercible instances We assume that library authors supply correct role annotations for their types, and therefore we do not need to check for the availability of data constructors in Safe mode. See discussion in #8725. This effectively fixes #8827 and #8826. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 03:35:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 03:35:43 -0000 Subject: [GHC] #8725: make DESTDIR=... install broken In-Reply-To: <046.8a9f647d92bb798f75143ee1d2ebdcd8@haskell.org> References: <046.8a9f647d92bb798f75143ee1d2ebdcd8@haskell.org> Message-ID: <061.e45f78a31a7a628749320ff2fae4a8ff@haskell.org> #8725: make DESTDIR=... install broken ----------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Build System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by Richard Eisenberg ): In [changeset:"59722295bb8da8f01d37356fbed6aef7321a8195/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="59722295bb8da8f01d37356fbed6aef7321a8195" Remove "Safe mode" check for Coercible instances We assume that library authors supply correct role annotations for their types, and therefore we do not need to check for the availability of data constructors in Safe mode. See discussion in #8725. This effectively fixes #8827 and #8826. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 03:35:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 03:35:44 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.43eda8bab9b541cc45e839b9bd29efe3@haskell.org> #8851: Standalone deriving and GND behave differently -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple deriving/should_compile/T8851 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Richard Eisenberg ): In [changeset:"8ee6162e9a3377cd4c79f49b63f92046b0d5c708/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8ee6162e9a3377cd4c79f49b63f92046b0d5c708" Recharacterize test according to discussion in #8851. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 03:35:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 03:35:44 -0000 Subject: [GHC] #8884: Reifying closed type families is broken In-Reply-To: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> References: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> Message-ID: <062.b7652e24d817e4b8ad7fa1b9234d05e3@haskell.org> #8884: Reifying closed type families is broken -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"8c5ea91d68cdc79b413e05f7dacfd052f5de8c64/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8c5ea91d68cdc79b413e05f7dacfd052f5de8c64" Fix #8884. There were two unrelated errors fixed here: 1) Make sure that only the *result kind* is reified when reifying a type family. Previously, the whole kind was reified, which defies the TH spec. 2) Omit kind patterns in equations. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 03:38:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 03:38:08 -0000 Subject: [GHC] #8725: make DESTDIR=... install broken In-Reply-To: <046.8a9f647d92bb798f75143ee1d2ebdcd8@haskell.org> References: <046.8a9f647d92bb798f75143ee1d2ebdcd8@haskell.org> Message-ID: <061.5a28a2437c9462180a0af51fde652f40@haskell.org> #8725: make DESTDIR=... install broken ----------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Build System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by goldfire): Oops -- meant to reference #8745 in the commit above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 03:38:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 03:38:56 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.b0121c42f5ebb3e2e7f8279686de940f@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc1 Type of failure: None/Unknown | Keywords: Safe Test Case: | Architecture: should_fail/TcCoercibleFailSafe | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by goldfire): See also [changeset:"59722295bb8da8f01d37356fbed6aef7321a8195/ghc"] which was meant to reference this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 03:46:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 03:46:27 -0000 Subject: [GHC] #8884: Reifying closed type families is broken In-Reply-To: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> References: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> Message-ID: <062.a66d17a4ed3280a202729615eb724e75@haskell.org> #8884: Reifying closed type families is broken -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 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 goldfire): * status: new => merge Comment: The fix affects ''open'' type families as well as closed. Both families had exactly the same mis-behavior, upon inspection of the code. Given that, it's unclear to me whether this should be merged. The old behavior was clearly wrong -- for example, reifying a type family and then trying to splice it would end in failure. But, the old behavior was also quite reliable, and it's conceivable that users have noticed the poor behavior and have coded against it. (In fact, a co-author of one of my libraries has done just that, which is how I discovered the GHC bug!) So, we must choose between * Retaining the incorrect behavior (which has been around for some time), while not surprising users in the final 7.8 release, or * Having correct behavior. I slightly favor the latter, believing that this error was so egregious that no one (other than me, evidently) is using this feature of GHC. If anyone else were using the feature, we would have seen the bug report! So, I'm setting this ticket to `merge` but am happy to have others disagree about that decision. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 03:47:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 03:47:21 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.44f92d42faf2c3db2d821083cb8a826a@haskell.org> #8851: Standalone deriving and GND behave differently -----------------------------------------------+--------------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: deriving/should_fail/T8851 | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: -----------------------------------------------+--------------------------- Changes (by goldfire): * testcase: deriving/should_compile/T8851 => deriving/should_fail/T8851 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 03:47:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 03:47:37 -0000 Subject: [GHC] #8884: Reifying closed type families is broken In-Reply-To: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> References: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> Message-ID: <062.ea0a66b4dd0da878beff9be4a56c2072@haskell.org> #8884: Reifying closed type families is broken -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T8884 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * testcase: => th/T8884 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 03:48:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 03:48:30 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.eba5198a2963f836362876162e46e6c8@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 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 goldfire): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 03:49:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 03:49:23 -0000 Subject: [GHC] #8826: Allow more coercions in Safe Haskell In-Reply-To: <047.5c2eeb13a41e01da9bb6e46c88e0f15c@haskell.org> References: <047.5c2eeb13a41e01da9bb6e46c88e0f15c@haskell.org> Message-ID: <062.b544ddcdd739add6232c4c74b4552edd@haskell.org> #8826: Allow more coercions in Safe Haskell -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: Ticket #8827 is marked as "merge". I'm just closing this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 04:33:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 04:33:27 -0000 Subject: [GHC] #8884: Reifying closed type families is broken In-Reply-To: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> References: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> Message-ID: <062.baeed5f8406d162049501c32a1dd53c8@haskell.org> #8884: Reifying closed type families is broken -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T8884 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): how would they even use the incorrect behavior constructively? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 05:14:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 05:14:41 -0000 Subject: [GHC] #8891: Data.Time.Clock documentation error (?) Message-ID: <044.1be40f314158351ae50287bb80b4a97b@haskell.org> #8891: Data.Time.Clock documentation error (?) ------------------------------------+------------------------------------- Reporter: b7j0c | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | 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: | ------------------------------------+------------------------------------- http://hackage.haskell.org/package/time-1.4.2/docs/Data-Time-Clock.html includes a "Show" instance for UTCTime...but it doesn't seem to have a Show instance declaration (?) thanks brad -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 07:23:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 07:23:43 -0000 Subject: [GHC] #8892: Ghc panics (variable not found) Message-ID: <045.3e8c8bb464ddd3c1e55d55ced44d87a2@haskell.org> #8892: Ghc panics (variable not found) -----------------------------------+--------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- When attempting to compile a module with ghc-7.8-RC2, using the flags `--ghc-options=-j8 -O2 -Werror`, I encountered this error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.0.20140228 for x86_64-unknown-linux): StgCmmEnv: variable not found foldlM'_loop{v i1iSV} [lid] local binds for: }}} followed by about 1100 bindings (none of are the binding in question). Omitting the `-j` flag makes no difference. Building `-O0` succeeds. I don't have a standalone test case, and it's not clear to me how to make one as I have no idea what's causing this. I'll try to narrow it down, but if anyone could suggest some flags to twiddle or some other factor to adjust I'd appreciate it. I'm suspecting that it's a function referenced from inlining something vector-related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 07:28:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 07:28:37 -0000 Subject: [GHC] #8882: internal error (deriving generic / cyclical imports?) In-Reply-To: <044.1daca3870a219aee32c2f06e9482c6a5@haskell.org> References: <044.1daca3870a219aee32c2f06e9482c6a5@haskell.org> Message-ID: <059.bcd555ac5ae7ec7b792ef69ac28702f2@haskell.org> #8882: internal error (deriving generic / cyclical imports?) -------------------------------+---------------------------------- Reporter: mf825 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: panic Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by mf825): @thoughpolice: you are right, WDF got shrunk away at some point, but the fact that you are getting this far without the bug showing proves that it is gone in 7.8 (assuming this is what you used to run crash.sh). great! @simon: ghc-7.6.3 does not understand -fno-warn-amp, and i could not find it in the manual either. if you still think it is relevant, could you give me another hint? @monoidal: yes, that seems likely. in my case, the -XDerivingGeneric is in module Default, and the hs-boot file belongs to module Universes. but when i disable DerivingGeneric in Default, the problem goes away. i think i'll try to get 7.8 running now. Ii am ok with closing this issue. thanks everybody for the great help! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 07:29:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 07:29:23 -0000 Subject: [GHC] #8882: internal error (deriving generic / cyclical imports?) In-Reply-To: <044.1daca3870a219aee32c2f06e9482c6a5@haskell.org> References: <044.1daca3870a219aee32c2f06e9482c6a5@haskell.org> Message-ID: <059.d4c9fe584ceaa96f9dfa114ae1a74788@haskell.org> #8882: internal error (deriving generic / cyclical imports?) -------------------------------+---------------------------------- Reporter: mf825 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: panic Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 7878, 8374 -------------------------------+---------------------------------- Changes (by mf825): * related: => 7878, 8374 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 08:11:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 08:11:30 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.860122eb46b132165d0092af8d0afeb6@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | Status: merge Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple tests/simplCore/should_run/T2110.hs | Difficulty: Blocking: | Unknown | Blocked By: 8718 | Related Tickets: #2110 -------------------------------------------------+------------------------- Comment (by nomeata): I don?t think there is a point in merging this into 7.8; the support for `coerce` in rules was added to master after the freeze ([b4715d6] up to [cde88e2]). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 08:25:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 08:25:03 -0000 Subject: [GHC] #8888: Document Coercible in user's guide In-Reply-To: <047.94c1acfb950684257c799730826cb077@haskell.org> References: <047.94c1acfb950684257c799730826cb077@haskell.org> Message-ID: <062.d5b2949717f96f47eca241fecf947840@haskell.org> #8888: Document Coercible in user's guide -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Now that we have rc builds with documentation, I can actually point you to the docs (we don?t have that for HEAD): http://www.haskell.org/ghc/docs/7.8.1-rc2/html/libraries/base-4.7.0.0 /Data-Coerce.html > I think it deserves its own section in Chapter 7. That's where users will look. I doubt that ? I find my documentation via hoogle or hayoo, or via the package index. It would also work much better for those who use an IDE like leksah, who have the haddock documentation for each identifier at their finger tip, but possibly not the users guide. Also note that for example the documentation of, for example, `unsafeCoerce` has actually been removed from the users guide ([7ea4966]). Isn?t that also a language extension? But this is bikeshedding and I?m not insisting, so I can move the documentation later today. > But GHC.Types in package ghc-prim defines Coercible (as a data type). So where is it defined? In GHC.Prim or GHC.Types? The definition in `GHC.Types` is just so that the constructor has an info table and so on. I had problems using it from `GHC.Types` (with the overwritten id from `PrelNames`). I was following the example set by `data (~) a b = Eq# ((~#) a b)`, but if that is wrong I?ll happily learn what the right way would have been. > Also oddly, PrelNames defines gHC_COERCIBLE which seems to be unused ... delete? Yes, cruft from earlier iterations. Removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 08:27:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 08:27:00 -0000 Subject: [GHC] #8826: Allow more coercions in Safe Haskell In-Reply-To: <047.5c2eeb13a41e01da9bb6e46c88e0f15c@haskell.org> References: <047.5c2eeb13a41e01da9bb6e46c88e0f15c@haskell.org> Message-ID: <062.f7336fb3cdb96370e05e010896f32396@haskell.org> #8826: Allow more coercions in Safe Haskell -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"db4f5e5245d5b24a8f0a06a85ded89c6124fb4c7/ghc-prim"]: {{{ #!CommitTicketReference repository="ghc-prim" revision="db4f5e5245d5b24a8f0a06a85ded89c6124fb4c7" Update Coercible docs due to Safe Haskell adjustment This should go with [59722295bb8da8f01d37356fbed6aef7321a8195/ghc], see bug #8826. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 08:35:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 08:35:26 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.09548abeed15cb79b02b1c2e21c736d3@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Can we get a merge of this soon? I think it would be desireable if we get useful information about the stable branch again on https://travis- ci.org/nomeata/ghc-complete/builds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 08:38:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 08:38:41 -0000 Subject: [GHC] #8884: Reifying closed type families is broken In-Reply-To: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> References: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> Message-ID: <062.50563ce1315811897b0dccfbd804b511@haskell.org> #8884: Reifying closed type families is broken -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T8884 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I think we should merge. IBM and Microsoft may sometimes have to maintain old, incorrect behaviour for legacy reasons, but GHC doesn't! Thank you for fixing this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 08:51:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 08:51:46 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.36b08f9fd5f2768b576ba6bf0bf39ab4@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): It seems to be on the list of things to merge: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8/RC2. Austin? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 08:53:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 08:53:45 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.a43638f7d2930d76e253ee7c6bf37e58@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by thoughtpolice): Yes, it's on my queue. Sorry, I forgot this was breaking the travis build... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 09:06:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 09:06:01 -0000 Subject: [GHC] #8888: Document Coercible in user's guide In-Reply-To: <047.94c1acfb950684257c799730826cb077@haskell.org> References: <047.94c1acfb950684257c799730826cb077@haskell.org> Message-ID: <062.7e82e852c6e3aeadf9f0736671925964@haskell.org> #8888: Document Coercible in user's guide -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): You've put a lot of work into this, and you may well be right. I'd welcome opinions from others. For now, though, even if the main documentation stays in the library Haddock stuff, could you * add a link to the paper (which gives far more background) to the Haddock docs * add a user-manual sub-section that summarises in one paragraph and points off to the Haddock docs That way people like me who look at the manual will still end up in the right place. I'm still puzzled about two things though. * `Data.Coerce` has {{{ import GHC.Prim (coerce, Coercible) }}} But `GHC.Prim` does not export `Coercible`.... it's defined in `GHC.Types`. So how does this even compile? * In the [http://www.haskell.org/ghc/docs/7.8.1-rc2/html/libraries/base-4.7.0.0 /Data-Coerce.html Haddock link you sent], `Coercible` shows as a class. But it's defined (in `GHC.Types` as a data type. I believe that happens by way of `TysWiredIn.coercibleTyCon` and `coercibleClass`, but it's quite hard to unravel, and definitely deserves a `Note` in `GHC.Types`, and or `TysWiredIn` (details in one place, a pointer in the other. It may well be that the way that `(~)` is handled needs similar documentation. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 09:09:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 09:09:00 -0000 Subject: [GHC] #8882: internal error (deriving generic / cyclical imports?) In-Reply-To: <044.1daca3870a219aee32c2f06e9482c6a5@haskell.org> References: <044.1daca3870a219aee32c2f06e9482c6a5@haskell.org> Message-ID: <059.3da39063991aaa6dbbf290245a7dd1c4@haskell.org> #8882: internal error (deriving generic / cyclical imports?) -------------------------------+---------------------------------- Reporter: mf825 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: panic Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 7878, 8374 -------------------------------+---------------------------------- Comment (by simonpj): I think my guess about #8374 and `-fwarn-amp` was wrong. Monoidal is likely right. In which case we can close as already-fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 09:12:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 09:12:05 -0000 Subject: [GHC] #8892: Ghc panics (variable not found) In-Reply-To: <045.3e8c8bb464ddd3c1e55d55ced44d87a2@haskell.org> References: <045.3e8c8bb464ddd3c1e55d55ced44d87a2@haskell.org> Message-ID: <060.b4c1b2623a8c9adde9bd280f95048055@haskell.org> #8892: Ghc panics (variable not found) ---------------------------------------+----------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by simonpj): John, the first thing is to add `-dcore-lint` and compile everything from scratch. I bet that shows something. I vaguely remember someone reporting a bug to do with `ghc -jN` but it's hard to search for. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 09:21:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 09:21:16 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT In-Reply-To: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> References: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> Message-ID: <062.c51362c44f32b3616f47063d1e17f211@haskell.org> #8776: Displaying pattern synonym for a GADT -------------------------------------+------------------------------------ Reporter: monoidal | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Gergo, it's all fine, but just needs a bit more refactoring: * `PprTyThing.pprTypeForUser` consults a flag `-fprint-explicit-foralls` to see whether to print the foralls. * So we should call `pprTypeForUser` when printing types in `IfaceDecls` (since we are now converting `TyThings` to `IfaceDecls` before printing. * That means moving `pprTypeForUser` to `IfaceSyn`; or perhaps even all the way into `TypeRep` with the other type-printing machinery. * Currently `pprTypeForUser` also tidies the type. That is not necessary (and therefore confusing) when printing `IfaceDecls` since they are already tidy. It is only necessary for the calls in `ghc/InteractiveUI` where we print un-tidy types and kinds. So we could do with a variant (even locally in `InteractiveUI` that tides the type and then calls `pprTypeForUser`, where the latter no longer does tidying). Does that make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 09:35:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 09:35:33 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.e08b400dda747c4406ec484b6ccd93de@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+----------------------------- Reporter: facundoq | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+----------------------------- Comment (by simonpj): See also #8890 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 09:35:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 09:35:36 -0000 Subject: [GHC] #8890: segfault on Windows 7 i386 In-Reply-To: <045.ef91946d4291bd999be2fb92692f63b8@haskell.org> References: <045.ef91946d4291bd999be2fb92692f63b8@haskell.org> Message-ID: <060.de20a5b2ab7cf0b7b0c192bd1285196a@haskell.org> #8890: segfault on Windows 7 i386 ---------------------------------------+----------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+----------------------------- Comment (by simonpj): See also #8870, #8834. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 09:37:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 09:37:51 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.9cfa9f51d6f8d477915fdddbf876b7cd@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | Status: Priority: normal | closed Component: libraries/base | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: tests/simplCore/should_run/T2110.hs | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: 8718 | Related Tickets: #2110 -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Ah, I see. In that case that's fine - it's strictly an optimization, so I'm don't really care about missing this little thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 09:42:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 09:42:09 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.91c1f6dcfc1a38545e52ce1ff8e0dabd@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonpj): So where are we on this? * Simon M says "here is the broken bit of code" (comment 35), and then says "I misread" (comment 38). Does that mean that the broken bit of code isn't broken? * If we use Karel's reversion patch (between comments 2 and 3 above) does that cure all known crashes? I confirm that it ''does'' fix my own "ghc- stage2 segfaults" problem, reported in #8870. But what about the hello- world problem in #8834, and Ganesh's new report in #8890? * If reverting the `CmmSink` change does in fact solve the problem, we should probably go ahead and revert it, and un-block the GHC 7.8 release. * But even if we do that we are still stuck with not knowing WHY it solves the problem. Perhaps the patch was fine, but it exposes a problem somewhere else? And we really want the `CmmSink` improvements. We really need someone to dig into it with GDB. Austin, can you get a Windows box on the network that exhibits the bug, so that Simon M can crank up gdb? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 09:43:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 09:43:56 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.92e7493b8273d00a5b8bea81c87d9fc1@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple tests/simplCore/should_run/T2110.hs | Difficulty: Blocking: | Unknown | Blocked By: 8718 | Related Tickets: #2110 -------------------------------------------------+------------------------- Changes (by thoughtpolice): * cc: ekmett (added) * status: closed => new * resolution: fixed => Comment: (Whoops, accidentally closed.) Richard, Edward probably has something to say about the `fmap` rule, but in general do we want it right now when it can break things? I'm under the impression there's not a sensible and safe one we can write that won't break for non-lawful Functors. (I guess we can tell everyone to always write ones that obey the rules, but I'm not sure how much that might backfire). There was some discussion of related approaches a few months ago around ICFP time (don't have a link on me). Anyway, worth a good discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 10:14:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 10:14:54 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.df80c0a3f9e6da866bf54448a3cc3e8a@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): I'm still missing a solution in ghc-7.8-rc2, but my preferred way is simply using gnm (via a link called nm). The provided patch for !DeriveConstants.hs works but looks a bit scary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 10:16:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 10:16:53 -0000 Subject: [GHC] #8718: Add role annotations to base In-Reply-To: <046.5bf32c0ca4f956dafd133cea02061c35@haskell.org> References: <046.5bf32c0ca4f956dafd133cea02061c35@haskell.org> Message-ID: <061.1582e7ac191d3e9376eb33eb27341f4e@haskell.org> #8718: Add role annotations to base -------------------------------+------------------------------------------- Reporter: nomeata | Owner: Type: task | Status: closed Priority: high | Milestone: 7.8.1 Component: | Version: 7.8.1-rc2 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 8767 | -------------------------------+------------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"df265b95a2f3640425b43b17993b9ec78a287f60/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="df265b95a2f3640425b43b17993b9ec78a287f60" Update to containers-0.5.5.1 This fixes a wrong #if around role annotations (see #8718) Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 10:25:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 10:25:01 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.e61e82d69de652bbfa896ab4c32b9ede@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by kgardas): Christian, I've not pushed this patch to Austin for inclusion in 7.8.1 as I've though it's already too late and the patches now in RCx times should be quite safe or fix real regression. Let's see after 7.8.1 is out of door if Austin thinks this may be merged into HEAD or not. What do you find on this patch scary? It simply uses and parses different output from Solaris nm than it's provided from GNU nm and it also automatically test if its using GNU or Solaris' nm and behaves accordingly. So what's problem with it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 10:29:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 10:29:44 -0000 Subject: [GHC] #8888: Document Coercible in user's guide In-Reply-To: <047.94c1acfb950684257c799730826cb077@haskell.org> References: <047.94c1acfb950684257c799730826cb077@haskell.org> Message-ID: <062.65efe8902e03db4e078482a559da6d56@haskell.org> #8888: Document Coercible in user's guide -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): > I'd welcome opinions from others. Me too. Adding the cross-references you mention makes perfect sense, will do it in a moment. > So how does this even compile? `coercibleTyCon` is added to `ghcPrimExports` in `PrelInfo`. I recall that when I was exporting it from `GHC.Types`, haddock would display it as a regular data type, not as a constraint. I now added this note: {{{ Note [Kind-changing of (~) and Coercible] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (~) and Coercible are tricky to define. To the user, they must appear as constraints, but we cannot define them as such in Haskell. But we also cannot just define them only in GHC.Prim (like (->)), because we need a real module for them, e.g. to compile the constructor's info table. Furthermore the type of MkCoercible cannot be written in Haskell (no syntax for ~#R). So we define them as regular data types in GHC.Types, but do /not/ export them. This ensures we have a home module. We then define them with the types and kinds that we actually want, in TysWiredIn, and export them in GHC.Prim. Haddock still takes the documentation from GHC.Types (and not from the fake module created from primops.txt.pp), so we have the user-facing documentation here. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 10:31:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 10:31:06 -0000 Subject: [GHC] #8893: -XPolyKinds causes "*** Exception: Prelude.(!!): index too large" Message-ID: <044.75b9ae16eaafc02be44ca541a7f043cc@haskell.org> #8893: -XPolyKinds causes "*** Exception: Prelude.(!!): index too large" -----------------------------------+--------------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: PolyKinds | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- The following program will compile fine: {{{ {-# OPTIONS_GHC -Wall #-} {-# Language DeriveFunctor #-} --{-# Language PolyKinds #-} module Bug where data V a = V [a] deriving Functor data C x a = C (V (P x a)) deriving Functor data P x a = P (x a) deriving Functor }}} But when PolyKinds is enabled, GHC crashes with {{{ $ ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:37:ghc: panic! (the 'impossible' happened) (GHC version 7.8.0.20140228 for x86_64-unknown-linux): Prelude.(!!): index too large }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 10:31:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 10:31:28 -0000 Subject: [GHC] #8893: -XPolyKinds causes "*** Exception: Prelude.(!!): index too large" In-Reply-To: <044.75b9ae16eaafc02be44ca541a7f043cc@haskell.org> References: <044.75b9ae16eaafc02be44ca541a7f043cc@haskell.org> Message-ID: <059.a765a6d6fd6d038321e8d6633ea6ebeb@haskell.org> #8893: -XPolyKinds causes "*** Exception: Prelude.(!!): index too large" ---------------------------------------+----------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by ghorn): * cc: gregmainland@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 10:31:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 10:31:49 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.53276ce9e361b82b097346192badfb6e@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple tests/simplCore/should_run/T2110.hs | Difficulty: Blocking: | Unknown | Blocked By: 8718 | Related Tickets: #2110 -------------------------------------------------+------------------------- Comment (by nomeata): I still believe that people should be free to write non-law-abiding instances (or maybe law-abiding up to some interface), and the compiler should not interfere with that. We should simply suggest them to add a `fmap coerce = coerce` rule for their particular fmap if they care. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 10:33:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 10:33:30 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.c7506b7ad99d22eb219cbb037d66fa29@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): It's sort of duplicate (but different) code that is difficult to maintain (for various nm versions). How did the code look like for ghc-7.6.3 that used to work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 10:54:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 10:54:35 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.6249fe2093a1e83d66192e6da7a14d3a@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): Replying to [comment:39 simonpj]: > * If we use Karel's reversion patch I'm Kyrill, not Karel. Extremely sorry for OT. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 11:00:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 11:00:03 -0000 Subject: [GHC] #8888: Document Coercible in user's guide In-Reply-To: <047.94c1acfb950684257c799730826cb077@haskell.org> References: <047.94c1acfb950684257c799730826cb077@haskell.org> Message-ID: <062.be1ab4d93406f94130f3f919c4f2233a@haskell.org> #8888: Document Coercible in user's guide -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): "`coercibleTyCon` is added to `ghcPrimExports` in `PrelInfo`". Wow! That is truly unique! `Coercible` is defined and exported (in the interface file) by `GHC.Types`, '''and''' is exported by `GHC.Prim`. I can imagine all sorts of confusion can arise from that. I'm astonished it works. And, despite its unique weirdness, there is no comment with `ghcPrimExports`. None of this happens for `(~)`. Why it needed for `Coercible`? After all, it's in the `wiredInTyCons` in `TysWiredIn`. Why does it also need to be in `ghcPrimExports` at all? Why not just remove it? (And import it from `GHC.Types` in `Data.Coerce`). There may be some Deep Reason for all this strangeness, but I can't see it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 11:01:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 11:01:52 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.8e09f589b560f2892a44c8038bb90f3f@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): Curiously, I did not find differences related to nm. http://git.haskell.org/ghc.git/history/refs/heads/master:/utils/deriveConstants/DeriveConstants.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 11:30:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 11:30:35 -0000 Subject: [GHC] #8888: Document Coercible in user's guide In-Reply-To: <047.94c1acfb950684257c799730826cb077@haskell.org> References: <047.94c1acfb950684257c799730826cb077@haskell.org> Message-ID: <062.413f8ba839b9c2a25e26bf9b92b3aea0@haskell.org> #8888: Document Coercible in user's guide -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): > And, despite its unique weirdness, there is no comment with ghcPrimExports. Added. > None of this happens for (~). Why it needed for Coercible? Hmm. Good question. I believe that `(~)` needs to not to be importable at all (it is handled by the Parser). Also commented in the Note. > There may be some Deep Reason for all this strangeness, but I can't see it. It is just what happened to work and seems reasonable, starting with the example of `(~)`. Quite likely that a less strange implementation is possible (with little change to make sure haddock and ghci use the updated kind); I do not know my way around all related parts of the compiler yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 11:53:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 11:53:13 -0000 Subject: [GHC] #8888: Document Coercible in user's guide In-Reply-To: <047.94c1acfb950684257c799730826cb077@haskell.org> References: <047.94c1acfb950684257c799730826cb077@haskell.org> Message-ID: <062.ee16870c1519b4a0f1622a125cbe90e3@haskell.org> #8888: Document Coercible in user's guide -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"1e36a386042248523de69ad6b02c43a6631ed5d0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1e36a386042248523de69ad6b02c43a6631ed5d0" Document Coercible in the user guide as a subsection of "Equality constraints", containing references to the module's haddock and to the paper. Fixes #8888 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 11:53:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 11:53:13 -0000 Subject: [GHC] #8888: Document Coercible in user's guide In-Reply-To: <047.94c1acfb950684257c799730826cb077@haskell.org> References: <047.94c1acfb950684257c799730826cb077@haskell.org> Message-ID: <062.0d51d801bdfedcd888355d1f89b51f8a@haskell.org> #8888: Document Coercible in user's guide -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"fc7aaf57a33ab07b70628c75fcf134fdf4e701e5/ghc-prim"]: {{{ #!CommitTicketReference repository="ghc-prim" revision="fc7aaf57a33ab07b70628c75fcf134fdf4e701e5" Refer to the coercible paper in Coercible' docs Implements parts of #8888. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 11:54:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 11:54:00 -0000 Subject: [GHC] #8888: Document Coercible in user's guide In-Reply-To: <047.94c1acfb950684257c799730826cb077@haskell.org> References: <047.94c1acfb950684257c799730826cb077@haskell.org> Message-ID: <062.9f2f5e4e47e74d32c1fc71a58cc6427c@haskell.org> #8888: Document Coercible in user's guide -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 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 nomeata): * status: new => merge Comment: References from user guide to haddock, and from both to the paper added. I guess we want this to be merged into 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 11:56:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 11:56:26 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.76d7a44ce67ddef76cfea1fff876b14e@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): I've inspected "bad" Cmm a bit and found [https://ghc.haskell.org/trac/ghc/attachment/ticket/8834/lines1_bad#L2276 this]: {{{ call (stg_gc_fun)(R1) args: 40, res: 0, upd: 8; c2gF: if (%MO_S_Le_W64(R5, 0)) goto c2gB; else goto c2gC; }}} `R5` is `r8` and is volatile on Win64. I don't see it restored before `%MO_S_Le_W64(R5, 0)` (honestly, I don't know what `%MO_S_Le_W64(R5, 0)` is). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 11:59:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 11:59:26 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.90241fc4906c7df2848e3056ad512345@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): The whole utils/deriveConstants did not exist in ghc-7.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 12:20:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 12:20:21 -0000 Subject: [GHC] #8888: Document Coercible in user's guide In-Reply-To: <047.94c1acfb950684257c799730826cb077@haskell.org> References: <047.94c1acfb950684257c799730826cb077@haskell.org> Message-ID: <062.03b2eaf61987c9eab974c953536ee0c5@haskell.org> #8888: Document Coercible in user's guide -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): The example of `(~)` doesn't have one type constructor claiming to be defined in two different modules! What you are doing here is totally new, and does not follow any previous pattern. To be specific: '''what goes wrong if you simply remove `Coercible` from `ghcPrimExports`'''? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 12:27:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 12:27:01 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.0d1719c816fe116e15d2cc456ef82f68@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by jstolarek): > I don't know what %MO_S_Le_W64(R5, 0) is MO = Machine Operation S = Signed Le = less-equal W64 = 64-bit word It's a !PrimOp (ie. a built-in machine operation) that checks whether R5 is less or equal to 0. > Could it be that ?another patch interacts badly with stg_gc_fun? I believe this patch should be irrelevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 12:28:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 12:28:47 -0000 Subject: [GHC] #8888: Document Coercible in user's guide In-Reply-To: <047.94c1acfb950684257c799730826cb077@haskell.org> References: <047.94c1acfb950684257c799730826cb077@haskell.org> Message-ID: <062.7ecf379c051e4431ea0f06de96445d5c@haskell.org> #8888: Document Coercible in user's guide -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): > To be specific: what goes wrong if you simply remove Coercible from ghcPrimExports? It cannot be imported any more. And if I export it in `GHC.Types` and import it from there, then haddock and ghci (IIRC) display it as regular data type, not as a constraint, which I found very confusing. This might be a considered a bug or a misfeature; should I open a bug for it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 12:32:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 12:32:01 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.24e35d2d96eb2170de4513a207617a5a@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): But, AFAIUI, `R5` shall be restored anyway after calling `stg_gc_fun`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 12:37:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 12:37:52 -0000 Subject: [GHC] #8888: Document Coercible in user's guide In-Reply-To: <047.94c1acfb950684257c799730826cb077@haskell.org> References: <047.94c1acfb950684257c799730826cb077@haskell.org> Message-ID: <062.05b3f9200ecd4b7ebe0e5991b0ea1a5c@haskell.org> #8888: Document Coercible in user's guide -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Replying to [comment:13 nomeata]: > And if I export it in `GHC.Types` and import it from there, then haddock and ghci (IIRC) display it as regular data type, not as a constraint, Are you certain of that? Since it is in `wiredInTyCons` it will never get into `GHC/Types.hi`, nor will it be read from the interface file, so GHCi could never know that in the source file it was declared with `data`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 12:41:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 12:41:16 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.fd25602b666758698d73d85172a61a2b@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): > Simon M says "here is the broken bit of code" (comment 35), and then says "I misread" (comment 38). Does that mean that the broken bit of code isn't broken? Correct, we still don't know what's broken. > If we use Karel's reversion patch (between comments 2 and 3 above) does that cure all known crashes? I confirm that it does fix my own "ghc-stage2 segfaults" problem, reported in #8870. But what about the hello-world problem in #8834, and Ganesh's new report in #8890? > If reverting the CmmSink change does in fact solve the problem, we should probably go ahead and revert it, and un-block the GHC 7.8 release. > But even if we do that we are still stuck with not knowing WHY it solves the problem. Perhaps the patch was fine, but it exposes a problem somewhere else? And we really want the CmmSink improvements. We really need someone to dig into it with GDB. Austin, can you get a Windows box on the network that exhibits the bug, so that Simon M can crank up gdb? I doubt that the patch actually introduced the bug, since @awson said that just the single change to `isTrivial` is enough to trigger the crash. Still, this patch isn't really essential - it made it possible to run `CmmSink` before stack layout, but measurements showed that it didn't buy anything to do that, so we're not currently using that functionality. The other thing in the patch is the `isTrivial` change that makes it more keen to inline `GlobalReg`s and literals; this is a very small win (<1%, IIRC). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 12:42:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 12:42:29 -0000 Subject: [GHC] #8894: Clean up `Coercible` plumbing Message-ID: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> #8894: Clean up `Coercible` plumbing ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently, the way `Coercible` is exported (with an data type in `GHC.Types` and a built-in !TyCon exported in `GHC.Prim`) works, but is confusing and should be cleaned up. Probably by exporting it directly from `GHC.Types`. Care needs to be taken that ghci and haddock display the data from modified built-in !TyCon; when I tried that a while ago it was displayed as a regular data type by one of them. If that is still the case and I didn't just do a mistake back then, this probably needs to be understood and fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 12:43:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 12:43:20 -0000 Subject: [GHC] #8888: Document Coercible in user's guide In-Reply-To: <047.94c1acfb950684257c799730826cb077@haskell.org> References: <047.94c1acfb950684257c799730826cb077@haskell.org> Message-ID: <062.e5894c0edf90ec2089530396f0af8d4d@haskell.org> #8888: Document Coercible in user's guide -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): > Are you certain of that? Since it is in wiredInTyCons it will never get into GHC/Types.hi, nor will it be read from the interface file, so GHCi could never know that in the source file it was declared with data. I am relatively certain, but didn?t try it out right now. I just opened a bug about it: #8894, maybe I?ll work on it when I have some quiet minutes, but not right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 12:43:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 12:43:32 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.d1c23355f2358e000573abe7951f5dba@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by kgardas): Thanks for investigation. In its light, have you changed your attitude to my proposed patch? I'm afraid that if we're going to support several nm output formats, then either the code looks like you criticize or we need to employ some Haskell library for parsing which I'm not sure if it's not over-kill in this simple case. I'm curious how things work on MacOSX or *BSDs. IIRC On Windows we're using GNU tools and no other commercial UNIX besides Solaris looks supported... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 12:48:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 12:48:55 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.b2da19ba30b8ef00acb056c07d431795@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple tests/simplCore/should_run/T2110.hs | Difficulty: Blocking: | Unknown | Blocked By: 8718 | Related Tickets: #2110 -------------------------------------------------+------------------------- Comment (by ekmett): You can defintely have users write the rule for particular functors of course, but that means reasonably polymorphic code that is too complicated to INLINE will get penalized asymptotically, so in the long run I'd really like to find a better solution that might have a chance of firing on my code. ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 13:31:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 13:31:17 -0000 Subject: [GHC] #8884: Reifying closed type families is broken In-Reply-To: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> References: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> Message-ID: <062.0298c3c13703002fd9d42c96343ded55@haskell.org> #8884: Reifying closed type families is broken -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T8884 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Replying to [comment:4 carter]: > how would they even use the incorrect behavior constructively? Note that the incorrect behavior applied to ''open'' type families as well as closed, so this isn't a new bug in 7.8. How could they use it constructively? Reifying a type family gives the list of arguments and the result kind. By counting the number of arguments, a program could remove the same number of arrows from the returned kind to get the actual result kind. It's not too hard, actually. As for the extra kind parameters, I suppose a program could do dependency analysis to discover which variables are kind variables and remove them. In any case, my library (a branch of `singletons`) was able to use the incorrect behavior without too much trouble (once we figured out what was going on), so there's an evidence proof for you. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 13:36:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 13:36:33 -0000 Subject: [GHC] #8115: GHC 64-bit Windows build failures with LLVM In-Reply-To: <046.85b4ba291c9a7177535aee44db08c94a@haskell.org> References: <046.85b4ba291c9a7177535aee44db08c94a@haskell.org> Message-ID: <061.db0696c6e0c8eec6fe8636e5a14cbf10@haskell.org> #8115: GHC 64-bit Windows build failures with LLVM ---------------------------------+------------------------------------ Reporter: schyler | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by hvr): can somebody retry with GHC 7.8.1(RC)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 13:37:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 13:37:39 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT In-Reply-To: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> References: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> Message-ID: <062.2db630e67682cf22c17964150f78a451@haskell.org> #8776: Displaying pattern synonym for a GADT -------------------------------------+------------------------------------ Reporter: monoidal | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by cactus): I've wasted too much time trying to get it to work... While the general idea is sound, there's one tiny problem that unfortunately breaks the whole thing: `IfaceType`'s `ppr_ty` has no way of splitting an `IfaceType` into a theta and a tau, because `isIfacePredTy` is stubbed out: {{{ isIfacePredTy :: IfaceType -> Bool isIfacePredTy _ = False -- FIXME: fix this to print iface pred tys correctly -- isIfacePredTy ty = isConstraintKind (ifaceTypeKind ty) }}} and there's no obvious way to implement `ifaceTypeKind` either... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 13:58:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 13:58:03 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.faeefaa63104653faccc65d5f8f3851b@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): [https://ghc.haskell.org/trac/ghc/attachment/ticket/8834/lines1_good#L2295 Corresponding code] from "good" cmm is: {{{ I64[Sp - 32] = _s2d4::I64; P64[Sp - 24] = _s2d5::P64; I64[Sp - 16] = _s2d6::I64; I64[Sp - 8] = _s2d7::I64; Sp = Sp - 32; call (stg_gc_fun)(R1) args: 40, res: 0, upd: 8; c2gR: if (%MO_S_Le_W64(_s2d7::I64, 0)) goto c2gN; else goto c2gO; }}} Not that it restores `R5` - it use no `R5` at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 14:02:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 14:02:47 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.8f315dad65223097d615e60705c631a7@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple tests/simplCore/should_run/T2110.hs | Difficulty: Blocking: | Unknown | Blocked By: 8718 | Related Tickets: #2110 -------------------------------------------------+------------------------- Comment (by goldfire): Right. I forgot that #2110 isn't getting into 7.8. Then, neither should this.... which is good, because I agree that maybe some more thought is required. I was ''not'' suggesting that there be a blanket `fmap coerce --> coerce` rule, just that we should add the specific rules for all the individual (lawful) `Functor`s that we define. I agree completely that users should be free to write unlawful `Functor`s if they wish to do so. I don't believe there's a link to earlier discussions on `fmap coerce` issue because the discussions happened among actual humans, in an actual room, instead of among computers online. It's an amazing thought. In any case, I remember one conclusion being a suggestion to add a new method to `Functor` being `fmapCoerce :: Coercible a b => f a -> f b`. This would have a default implementation of `fmapCoerce = fmap coerce` (no surprise there) but could be reimplemented where there would be a performance improvement. Returning to Edward's comment, I guess I don't understand the limits of the RULES mechanism to respond all that intelligently. In Core, anything that looks like `fmap coerce` in the source code would look something like `$fmapIdForSomeInstance (\x -> x |> co)`. This should be easy enough to match at the Core level. If it's impossible to write a RULE that desugars to the pattern above, then I think it's a bug (er, feature request) in the RULES mechanism, not a call for a change to the `Functor` definition. Though I'm not dead set against `fmapCoerce` in `Functor`, I believe that if we have to add such a thing, then there is a weakness in our design somewhere. During the conversations at ICFP, I was unaware of #2110 and Joachim's efforts to fix that bug. Now that we have that fixed, I believe `fmapCoerce` should be avoidable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 14:20:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 14:20:39 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.b12665d7162b833c9c3c369a3a5e7168@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): I think, I've a better patch. Always call "nm -P" (for POSIX.2 standard output). The output looks like {{{ derivedConstantMAX_Vanilla_REG C 0000000b 0000000b }}} for gnm or like {{{ derivedConstantMAX_Vanilla_REG D 1 b }}} for Solaris nm. So just take the first and last word (of 4 words) to extract the name and the size. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 14:26:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 14:26:05 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT In-Reply-To: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> References: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> Message-ID: <062.9b357bdfc363a55a80a3c425c62e9406@haskell.org> #8776: Displaying pattern synonym for a GADT -------------------------------------+------------------------------------ Reporter: monoidal | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Dr. ERDI Gergo ): In [changeset:"52003696ff7a2bbf86fbfccfe29b9f146a1ea549/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="52003696ff7a2bbf86fbfccfe29b9f146a1ea549" Reinstate pretty-printing of AnIds via pprId (#8776) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 14:35:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 14:35:04 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT In-Reply-To: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> References: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> Message-ID: <062.3817aa54d419b7a635ecbb4f72d303ca@haskell.org> #8776: Displaying pattern synonym for a GADT -------------------------------------+------------------------------------ Reporter: monoidal | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Dr. ERDI Gergo ): In [changeset:"de32a95ef21970c2db959509861b4f59d1dcbb82/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="de32a95ef21970c2db959509861b4f59d1dcbb82" Add test case for #8776 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 14:51:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 14:51:34 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.d96eba461cfc5732cc40400bf6f32b5a@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple tests/simplCore/should_run/T2110.hs | Difficulty: Blocking: | Unknown | Blocked By: 8718 | Related Tickets: #2110 -------------------------------------------------+------------------------- Comment (by nomeata): > I was not suggesting that there be a blanket fmap coerce --> coerce rule, just that we should add the specific rules for all the individual (lawful) Functors that we define. I agree completely that users should be free to write unlawful Functors if they wish to do so. Ok, good. Then we fully agree :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 15:04:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 15:04:32 -0000 Subject: [GHC] #8893: -XPolyKinds causes "*** Exception: Prelude.(!!): index too large" In-Reply-To: <044.75b9ae16eaafc02be44ca541a7f043cc@haskell.org> References: <044.75b9ae16eaafc02be44ca541a7f043cc@haskell.org> Message-ID: <059.1b68ad683535e41f86667c259b4a4f8e@haskell.org> #8893: -XPolyKinds causes "*** Exception: Prelude.(!!): index too large" ---------------------------------------+----------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by goldfire): Confirmed reproducible in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 15:06:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 15:06:50 -0000 Subject: [GHC] #8893: -XPolyKinds causes "*** Exception: Prelude.(!!): index too large" In-Reply-To: <044.75b9ae16eaafc02be44ca541a7f043cc@haskell.org> References: <044.75b9ae16eaafc02be44ca541a7f043cc@haskell.org> Message-ID: <059.5eb75b5221655856a2a5bb1fd4e65847@haskell.org> #8893: -XPolyKinds causes "*** Exception: Prelude.(!!): index too large" ---------------------------------------+----------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by simonpj): Yes I'm on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 15:14:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 15:14:39 -0000 Subject: [GHC] #8826: Allow more coercions in Safe Haskell In-Reply-To: <047.5c2eeb13a41e01da9bb6e46c88e0f15c@haskell.org> References: <047.5c2eeb13a41e01da9bb6e46c88e0f15c@haskell.org> Message-ID: <062.c26db2758620a4c64b31a0c0f6d4223e@haskell.org> #8826: Allow more coercions in Safe Haskell -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * status: closed => merge * version: 7.9 => 7.8.1-rc2 * milestone: => 7.8.1 Comment: Joachim's commit should get merged, as it goes with the fix to #8827. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 15:24:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 15:24:07 -0000 Subject: [GHC] #8885: Add inline versions of clone array primops In-Reply-To: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> References: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> Message-ID: <059.ee005bd87931b0d09b92f364f626425a@haskell.org> #8885: Add inline versions of clone array primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Marking these "out-of-line but may be inlined" primops as out-of-line in `primops.txt.pp` had the side effect of always adding an extra heap check for them, removing some of the benefits of inlining them in the first place. I've attached a patch that makes the heap check layout code respect the decision to inline these primops. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 15:36:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 15:36:10 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.420cf691bd4009a2bea98b9b31d12364@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple tests/simplCore/should_run/T2110.hs | Difficulty: Blocking: | Unknown | Blocked By: 8718 | Related Tickets: #2110 -------------------------------------------------+------------------------- Comment (by ekmett): The `fmapCoerce` solution turned out not to be powerful enough to handle things like `Compose f g` while `g` remains polymorphic or many monad transformers. We vacillated between a few other solutions that let you add a different member to Functor that could lift coercions by the end of ICFP, but with GHC 7.8 happening "any day now" at the time we agreed to just punt on it until we could give it due deliberation. My main point was that if the code is still polymorphic in the functor and complicated enough not to inline into a place where that rule can fire the rule doesn't help. We encourage people to write very polymorphic code. e.g. It solves many of the bugaboos people trot out about monad transformers and the like if you avoid picking a concrete instance until the last second. I'd be really sad to see that part of our culture die to get a few zero-cost newtype applications. Anyways, not sure what the right solution is yet, but I did want to interject that whatever it is, `fmapCoerce` isn't it. ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 16:01:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 16:01:11 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.fed36e9a791a13af0a89f015eb443e6a@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): Somehow my comment for OS X got lost. The patches are not yet working on OS X. "nm -V" fails on Mac. The third word is the size and leading underscores must be ignored. I'll provide a patch checking for "C" in the second word and extracting the size from the third word. (For GNU nm the third and last words are identical.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 16:15:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 16:15:51 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.daa6ed30d08206c746d8c3a6180da879@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple tests/simplCore/should_run/T2110.hs | Difficulty: Blocking: | Unknown | Blocked By: 8718 | Related Tickets: #2110 -------------------------------------------------+------------------------- Comment (by goldfire): Right -- of course. I guess I always am thinking that we have to know the `Functor` instance even to be thinking about any of this, because the `Functor` instance might not be lawful, in which case this optimization is bogus. But I do see how you might make progress with yet-to-be-imagined solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 16:28:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 16:28:41 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.e9ef74cddc6ec95562a865063ac341a4@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple tests/simplCore/should_run/T2110.hs | Difficulty: Blocking: | Unknown | Blocked By: 8718 | Related Tickets: #2110 -------------------------------------------------+------------------------- Comment (by ekmett): That is why I think any solution that works in a polymorphic setting or one too big to `INLINE` really involves adding something to `Functor` that permits the lifting of coercions for lawful functors. `fmapCoerce` was the first such candidate. It just isn't strong enough. A more viable alternative is to add something like `liftCoercion :: Functor f => Coercion a b -> Maybe (Coercion (f a) (f b))` to `Functor`, analogous to the precedent of how `(<$)` is already added there to permit faster 'scrubbing' of functor contents with increased sharing. This'd permit `liftCoercion Coercion = Just Coercion` to be written (or generated) as a witness for the representational or phantom role of the argument, and it could be used inside an `fmapCoerce` to lift over complex polymorphic functors. There are admittedly a lot of moving parts in such a design, though, and even ''that'' design as I recall isn't sufficient to address more complicated transformers and recursive data types, so there is still work to be done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 16:41:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 16:41:18 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.2118bc708d2753a3dd4ec5d6243e5b62@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): @awson - the call to `stg_gc_fun` doesn't return (there's no "returns to" annotation on it). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 16:48:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 16:48:58 -0000 Subject: [GHC] #8895: GHC Bug trac login verification fails Message-ID: <044.2a053d7f423d334139f7a70ba861b845@haskell.org> #8895: GHC Bug trac login verification fails ------------------------------------+------------------------------------- Reporter: guest | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I tried to register a new login for the username novadenizen (with corresponding gmail account) and I never received a verification email. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 16:54:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 16:54:35 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.5f4d5bc54290d7e9f8970642110cf363@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): Ah, thanks, assembler intuition was wrong for Cmm :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 17:39:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 17:39:31 -0000 Subject: [GHC] #8895: GHC Bug trac login verification fails In-Reply-To: <044.2a053d7f423d334139f7a70ba861b845@haskell.org> References: <044.2a053d7f423d334139f7a70ba861b845@haskell.org> Message-ID: <059.b21f1ae42617a6b7cf97992ca47637d0@haskell.org> #8895: GHC Bug trac login verification fails -------------------------------------+------------------------------------ Reporter: guest | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): I've deleted the account, can you try again? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 17:51:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 17:51:33 -0000 Subject: [GHC] #8896: ghci fails on Arm - "Illegal instruction" Message-ID: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> #8896: ghci fails on Arm - "Illegal instruction" ----------------------------+------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: arm ghci | Operating System: Linux Architecture: arm | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------- With the help of qemu compiled ghc 7.8.1-rc2 for raspberry pi. Ghc is successful, and ghci compiles, but ghci gets an 'Illegal instruction' error. A sample session: ccrma at satellite:~$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228 ccrma at satellite:~$ ghci --version The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228 ccrma at satellite:~$ ghci GHCi, version 7.8.0.20140228: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... Illegal instruction ccrma at satellite:~$ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 17:58:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 17:58:01 -0000 Subject: [GHC] #8895: GHC Bug trac login verification fails In-Reply-To: <044.2a053d7f423d334139f7a70ba861b845@haskell.org> References: <044.2a053d7f423d334139f7a70ba861b845@haskell.org> Message-ID: <059.dbd134a70b290444e38f279af5441d23@haskell.org> #8895: GHC Bug trac login verification fails -------------------------------------+------------------------------------ Reporter: guest | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by guest): I went through the registration form about 5 minutes ago. I haven't received an email yet. I try to login, but it automatically sends me to "logged in as guest". I have deleted all cookies and stored passwords, but the problem persists. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 18:05:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 18:05:48 -0000 Subject: [GHC] #8895: GHC Bug trac login verification fails In-Reply-To: <044.2a053d7f423d334139f7a70ba861b845@haskell.org> References: <044.2a053d7f423d334139f7a70ba861b845@haskell.org> Message-ID: <059.96bb16524ec050209f7d3a43cb4bd4cd@haskell.org> #8895: GHC Bug trac login verification fails -------------------------------------+------------------------------------ Reporter: guest | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by novadenizen): I had been using Firefox. I tried Chrome and I got the verification email. I still can't log in with Firefox. It keeps sending me to guest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 18:08:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 18:08:45 -0000 Subject: [GHC] #8897: Can't change "Full Name" in preferences Message-ID: <050.cac5fdb9d34ae50c72ea407a1870d09e@haskell.org> #8897: Can't change "Full Name" in preferences ------------------------------------+------------------------------------- Reporter: novadenizen | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | 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: | ------------------------------------+------------------------------------- I mistyped my Full Name when I registered my account. I try to change it from preferences and I get an error message "Warning: The email address specified is already in use. Please specify a different one." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 18:57:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 18:57:16 -0000 Subject: [GHC] #8898: Overall improvement for randomIvalInteger Message-ID: <050.d45afe73360610d848e4eba302442e5f@haskell.org> #8898: Overall improvement for randomIvalInteger -------------------------------------+------------------------------------- Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect result Difficulty: Easy (less than 1 | at runtime hour) | Test Case: Blocked By: | Blocking: Related Tickets: 5278 5280 1120 | -------------------------------------+------------------------------------- The current randomIvalInteger implementation uses repeated div operations to approximate the size of the desired random output, then generates that number of random values from the given RandomGen. It does not compensate for the "mod base" uniformity problem. It also assumes that all RandomGen implementations produce the same range of random values as StdGen. My new implementation addresses all these correctness issues, with potentially a slight performance improvement. Instead of performing repeated div base operations to determine the size of the desired range, this uses faster (* base) operations. An equivalent set of intermediate Integers is generated still. To compensate for the "`mod` base" uniformity problem, the desired range size is multiplied by the q factor (1000 in my code). When k is the desired range and b^(n) is the range of numbers generated, and d = b^(n) div k, some elements will have probability d/b^(n) and others will have probability (d+1)/b^(n), resulting in significant nonuniformity when d is very small. When you extend the generated range beyond the minimum by a factor of q, you are guaranteeed that d will be at least q, so the nonuniformity will be much less consequential. This implementation also works with any RandomGen, even ones that produce as little as a single bit of entropy per next call or have a minimum bound other than zero. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 19:04:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 19:04:30 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.8a3f35a814ac8954bcae9ac417b98ba5@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"7602bd4de901e4304a3a45dca08fc630d1bb5bf2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7602bd4de901e4304a3a45dca08fc630d1bb5bf2" Remove code reporting issues with Safe Haskell and coerce. This is a followup to the fix for #8827, and should be merged with that change. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 20:49:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 20:49:26 -0000 Subject: [GHC] #8895: GHC Bug trac login verification fails In-Reply-To: <044.2a053d7f423d334139f7a70ba861b845@haskell.org> References: <044.2a053d7f423d334139f7a70ba861b845@haskell.org> Message-ID: <059.a8f4506a5c5000b015cced2321928353@haskell.org> #8895: GHC Bug trac login verification fails -------------------------------------+------------------------------------ Reporter: guest | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): doesn't the https://ghc.haskell.org/trac/ghc/logout link let your browser forget its HTTP auth credentials? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 21:00:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 21:00:31 -0000 Subject: [GHC] #8898: Overall improvement for randomIvalInteger In-Reply-To: <050.d45afe73360610d848e4eba302442e5f@haskell.org> References: <050.d45afe73360610d848e4eba302442e5f@haskell.org> Message-ID: <065.dd956a2f8aab3ccce290d299f334116f@haskell.org> #8898: Overall improvement for randomIvalInteger -------------------------------------+------------------------------------- Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: #5278 #5280 #1120 -------------------------------------+------------------------------------- Changes (by hvr): * related: 5278 5280 1120 => #5278 #5280 #1120 Old description: > The current randomIvalInteger implementation uses repeated div operations > to approximate the size of the desired random output, then generates that > number of random values from the given RandomGen. It does not compensate > for the "mod base" uniformity problem. It also assumes that all > RandomGen implementations produce the same range of random values as > StdGen. > > My new implementation addresses all these correctness issues, with > potentially a slight performance improvement. > > Instead of performing repeated div base operations to determine the size > of the desired range, this uses faster (* base) operations. An > equivalent set of intermediate Integers is generated still. > > To compensate for the "`mod` base" uniformity problem, the desired range > size is multiplied by the q factor (1000 in my code). When k is the > desired range and b^(n) is the range of numbers generated, and d = b^(n) > div k, some elements will have probability d/b^(n) and others will have > probability (d+1)/b^(n), resulting in significant nonuniformity when d > is very small. When you extend the generated range beyond the minimum by > a factor of q, you are guaranteeed that d will be at least q, so the > nonuniformity will be much less consequential. > > This implementation also works with any RandomGen, even ones that produce > as little as a single bit of entropy per next call or have a minimum > bound other than zero. New description: The current `randomIvalInteger` implementation uses repeated `div` operations to approximate the size of the desired random output, then generates that number of random values from the given `RandomGen`. It does not compensate for the {{{`mod` base}}} uniformity problem. It also assumes that all `RandomGen` implementations produce the same range of random values as `StdGen`. My new implementation addresses all these correctness issues, with potentially a slight performance improvement. Instead of performing repeated div base operations to determine the size of the desired range, this uses faster `(* base)` operations. An equivalent set of intermediate `Integer`s is generated still. To compensate for the {{{`mod` base}}} uniformity problem, the desired range size is multiplied by the ''q'' factor (1000 in my code). When ''k'' is the desired range and ''b^n^'' is the range of numbers generated, and ''d = b^n^ div k'', some elements will have probability ''d/b^n^'' and others will have probability ''(d+1)/b^n^'', resulting in significant non- uniformity when ''d'' is very small. When you extend the generated range beyond the minimum by a factor of ''q'', you are guaranteed that ''d'' will be at least ''q'', so the non-uniformity will be much less consequential. This implementation also works with any `RandomGen`, even ones that produce as little as a single bit of entropy per next call or have a minimum bound other than zero. -- Comment: fixup wiki-markup in description -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 21:57:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 21:57:01 -0000 Subject: [GHC] #8895: GHC Bug trac login verification fails In-Reply-To: <044.2a053d7f423d334139f7a70ba861b845@haskell.org> References: <044.2a053d7f423d334139f7a70ba861b845@haskell.org> Message-ID: <059.c2e2634071ee90b986b69da3f4b7e9ef@haskell.org> #8895: GHC Bug trac login verification fails -------------------------------------+------------------------------------ Reporter: guest | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by novadenizen): The login link did something to let me change my login. The error still exists because I can click on logout and login and I am not prompted for a password. However, my problem is worked around for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 22:58:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 22:58:34 -0000 Subject: [GHC] #8896: ghci fails on Arm - "Illegal instruction" In-Reply-To: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> References: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> Message-ID: <061.7766183d6265c6eed7231bd54cee1aa7@haskell.org> #8896: ghci fails on Arm - "Illegal instruction" -------------------------------+----------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: arm ghci Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+----------------------------- Comment (by Ansible): If its helpful, I have ghc 7.8.1-rc2 compiled and can make it available to anyone who wants to work on this. It took me about 4 days to compile it for the PI, so its a significant undertaking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 14 23:16:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Mar 2014 23:16:26 -0000 Subject: [GHC] #8896: ghci fails on Arm - "Illegal instruction" In-Reply-To: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> References: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> Message-ID: <061.b1591f804ef9a5763bde05e41d3f6e3e@haskell.org> #8896: ghci fails on Arm - "Illegal instruction" -------------------------------+----------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: arm ghci Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+----------------------------- Comment (by nomeata): I?m surprised you get different results than I get compiling on Debian (https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=7.8.20140228-1&stamp=1394495564 and https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armhf&ver=7.8.20140228-1&stamp=1394723755) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 00:35:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 00:35:12 -0000 Subject: [GHC] #8896: ghci fails on Arm - "Illegal instruction" In-Reply-To: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> References: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> Message-ID: <061.e2806aa1704bb0eb6443f12e02e54996@haskell.org> #8896: ghci fails on Arm - "Illegal instruction" -------------------------------+----------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: arm ghci Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+----------------------------- Comment (by Ansible): Is that on the PI? I compiled using qemu instead of a real PI, and I used a 2G ram disk for swap. Without the swap the compile would not complete, nor would "cabal install cabal-install". Here's my build on the PI: https://dl.dropboxusercontent.com/u/80409492/ghc-7.8.1-rc2.zip and here's my .cabal folder. Compiling cabal-install also required the ram disk. https://dl.dropboxusercontent.com/u/80409492/pi_7.8.1-rc2-.cabal.zip And this is the distro I was using: https://ccrma.stanford.edu/~eberdahl/Satellite/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 00:39:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 00:39:36 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT In-Reply-To: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> References: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> Message-ID: <062.4ebf971c2f43f54b49dab32675328191@haskell.org> #8776: Displaying pattern synonym for a GADT -------------------------------------+------------------------------------ Reporter: monoidal | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by cactus): Simon, I've reverted the part of the change that tunneled `AnId`s via the `IfaceDecl` path. We should have a discussion on the eventual Correct(tm) implementation, but for now, this passes all the existing GHCi tests and also fixes the pattern synonym issue at hand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 08:28:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 08:28:28 -0000 Subject: [GHC] #8895: GHC Bug trac login verification fails In-Reply-To: <044.2a053d7f423d334139f7a70ba861b845@haskell.org> References: <044.2a053d7f423d334139f7a70ba861b845@haskell.org> Message-ID: <059.6fe09f5f12da03f549b32839c0eda150@haskell.org> #8895: GHC Bug trac login verification fails -------------------------------------+------------------------------------ Reporter: guest | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * status: new => closed * resolution: => worksforme -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 09:14:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 09:14:03 -0000 Subject: [GHC] #8833: GHC (compilation mode) crashes In-Reply-To: <044.2af677b3d4a2a13d2e8b023bf15580e4@haskell.org> References: <044.2af677b3d4a2a13d2e8b023bf15580e4@haskell.org> Message-ID: <059.6ccf1e4d8065ff3c2ca20d7741f47b79@haskell.org> #8833: GHC (compilation mode) crashes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: ? Component: Compiler | Version: Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time | Difficulty: Moderate (less crash | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #3872, #5400, | #5448, #5722, #7057, #7369 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * version: 7.8.1-rc2 => * resolution: => duplicate * related: => #3872, #5400, #5448, #5722, #7057, #7369 * milestone: 7.8.1 => ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 10:00:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 10:00:56 -0000 Subject: [GHC] #8251: Validate submodule references during pre-receive hook In-Reply-To: <042.3dddefcb4f2f56279562cd3ed6b1a071@haskell.org> References: <042.3dddefcb4f2f56279562cd3ed6b1a071@haskell.org> Message-ID: <057.55c71fee8526ab607f4fcb3b8d265b0b@haskell.org> #8251: Validate submodule references during pre-receive hook -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Resolution: | Keywords: admin git Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Another idea: to avoid updating submodule refs by accident (which has happened a few times already), the respective commit message ought contain the word "submodule" or maybe "update(s) submodule" as a safe-guard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 10:06:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 10:06:12 -0000 Subject: [GHC] #8896: ghci fails on Arm - "Illegal instruction" In-Reply-To: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> References: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> Message-ID: <061.a73918e4c3a988e388d147b566e6854a@haskell.org> #8896: ghci fails on Arm - "Illegal instruction" -------------------------------+----------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: arm ghci Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+----------------------------- Comment (by nomeata): > Is that on the PI? No, on some other arm machine that happens to auto-build the Debian packages. I find the high number of different failure possibilities on arm this late in the release process worrying :-( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 15:57:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 15:57:00 -0000 Subject: [GHC] #8899: StdGen does not generate 0 Message-ID: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> #8899: StdGen does not generate 0 ------------------------------------+------------------------------------- Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- `genRange` for `StdGen` returns `(0,2147483562)`. However, as far as I can tell, `StdGen` doesn't generate 0. This code performs 200 billion iterations of `next` on a `StdGen`. I ran it and it output `Nothing`. The probability that no 0 was generated by chance is approximately ''e^-200/2.147^'' =~ ''10^-40^''. {{{#!haskell import System.Random import Data.Int find0 :: StdGen -> Int64 -> Maybe Int64 find0 g0 n0 = aux g0 n0 where aux _ 0 = Nothing aux g r = let (v,g') = next g in if v == 0 then Just (n0 - r + 1) else aux g' (r-1) main :: IO () main = print $ find0 (mkStdGen 1234) 200000000000 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 16:03:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 16:03:39 -0000 Subject: [GHC] #8899: StdGen does not generate 0 In-Reply-To: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> References: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> Message-ID: <065.f9e3e9fd4567e3d7bbc4800d93f0a67f@haskell.org> #8899: StdGen does not generate 0 -------------------------------------+------------------------------------ Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Out of curiosity: How long did it take you running that code? Also, did you you verify that your approach works by looking for, say, `1`, `42` or `2147483562`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 16:19:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 16:19:41 -0000 Subject: [GHC] #8899: StdGen does not generate 0 In-Reply-To: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> References: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> Message-ID: <065.a5a08662816096ed4ada85ab1947e2a3@haskell.org> #8899: StdGen does not generate 0 -------------------------------------+------------------------------------ Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by novadenizen): It ran overnight and I forgot to use `time`, so I'm not sure. Running with 20 billion iterations took 36 minutes on my linode, though, so I would expect it took about 6 hours. I just now reran this tool looking for `v == 3` and it output `Just 871055575`, which is reasonable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 16:22:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 16:22:57 -0000 Subject: [GHC] #8899: StdGen does not generate 0 In-Reply-To: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> References: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> Message-ID: <065.01f033aff89b4e6bdfe3235a9b1caadf@haskell.org> #8899: StdGen does not generate 0 -------------------------------------+------------------------------------ Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Hmm, I don?t have the rights to put other people on CC on this ticket. Ryan (`random` maintainer), are you reading this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 17:00:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 17:00:45 -0000 Subject: [GHC] #8900: unordered-containers 19% slower in HEAD vs 7.6.3 Message-ID: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> #8900: unordered-containers 19% slower in HEAD vs 7.6.3 ------------------------------+-------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Runtime performance bug (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I ran a simple benchmark that exercises `Data.HashMap.Lazy.insert`. It's 19% slower using HEAD compared to using 7.6.3. The generated Core is the same, but the new codegen generates substantially different Cmm. '''Steps to reproduce''' 1. Download the attached `HashMapInsert.hs` benchmark. 2. Install unordered-containers with both 7.6.3 and HEAD: {{{ $ cabal install -w ghc-7.6.3 unordered-containers-0.2.3.3 $ cabal install -w inplace/bin/ghc-stage2 unordered-containers-0.2.3.3 }}} 3. Compile the benchmark with both compilers: {{{ $ ghc-7.6.3 -O2 HashMapInsert.hs $ mv HashMapInsert HashMapInsertOld $ inplace/bin/ghc-stage2 -O2 HashMapInsert.hs $ mv HashMapInsert HashMapInsertNew }}} '''Results (best of 3 runs)''' 7.6.3 {{{ $ ./HashMapInsertOld +RTS -s 1,191,223,528 bytes allocated in the heap 141,978,520 bytes copied during GC 37,811,840 bytes maximum residency (8 sample(s)) 22,378,432 bytes maximum slop 99 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2277 colls, 0 par 0.06s 0.06s 0.0000s 0.0002s Gen 1 8 colls, 0 par 0.07s 0.10s 0.0127s 0.0479s INIT time 0.00s ( 0.00s elapsed) MUT time 0.24s ( 0.24s elapsed) GC time 0.13s ( 0.17s elapsed) EXIT time 0.00s ( 0.01s elapsed) Total time 0.37s ( 0.41s elapsed) %GC time 34.8% (40.3% elapsed) Alloc rate 4,923,204,681 bytes per MUT second Productivity 65.2% of total user, 59.0% of total elapsed }}} HEAD: {{{ $ ./HashMapInsertNew +RTS -s 1,191,223,128 bytes allocated in the heap 231,158,688 bytes copied during GC 55,533,064 bytes maximum residency (13 sample(s)) 22,378,488 bytes maximum slop 144 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2268 colls, 0 par 0.06s 0.07s 0.0000s 0.0003s Gen 1 13 colls, 0 par 0.12s 0.16s 0.0127s 0.0468s INIT time 0.00s ( 0.00s elapsed) MUT time 0.25s ( 0.25s elapsed) GC time 0.18s ( 0.23s elapsed) EXIT time 0.00s ( 0.01s elapsed) Total time 0.43s ( 0.49s elapsed) %GC time 41.6% (47.5% elapsed) Alloc rate 4,738,791,249 bytes per MUT second Productivity 58.3% of total user, 51.9% of total elapsed }}} (Note that this is without the patches in #8885, so they're not the cause.) An interesting difference is that we spend more time in GC in HEAD. I don't know if that's related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 17:02:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 17:02:00 -0000 Subject: [GHC] #8900: unordered-containers 16% slower in HEAD vs 7.6.3 (was: unordered-containers 19% slower in HEAD vs 7.6.3) In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.f416632d77fe0ceda04a56b6cd414adc@haskell.org> #8900: unordered-containers 16% slower in HEAD vs 7.6.3 --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Description changed by tibbe: Old description: > I ran a simple benchmark that exercises `Data.HashMap.Lazy.insert`. It's > 19% slower using HEAD compared to using 7.6.3. The generated Core is the > same, but the new codegen generates substantially different Cmm. > > '''Steps to reproduce''' > > 1. Download the attached `HashMapInsert.hs` benchmark. > 2. Install unordered-containers with both 7.6.3 and HEAD: > > {{{ > $ cabal install -w ghc-7.6.3 unordered-containers-0.2.3.3 > $ cabal install -w inplace/bin/ghc-stage2 unordered-containers-0.2.3.3 > }}} > > 3. Compile the benchmark with both compilers: > > {{{ > $ ghc-7.6.3 -O2 HashMapInsert.hs > $ mv HashMapInsert HashMapInsertOld > $ inplace/bin/ghc-stage2 -O2 HashMapInsert.hs > $ mv HashMapInsert HashMapInsertNew > }}} > > '''Results (best of 3 runs)''' > > 7.6.3 > > {{{ > $ ./HashMapInsertOld +RTS -s > 1,191,223,528 bytes allocated in the heap > 141,978,520 bytes copied during GC > 37,811,840 bytes maximum residency (8 sample(s)) > 22,378,432 bytes maximum slop > 99 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 2277 colls, 0 par 0.06s 0.06s 0.0000s > 0.0002s > Gen 1 8 colls, 0 par 0.07s 0.10s 0.0127s > 0.0479s > > INIT time 0.00s ( 0.00s elapsed) > MUT time 0.24s ( 0.24s elapsed) > GC time 0.13s ( 0.17s elapsed) > EXIT time 0.00s ( 0.01s elapsed) > Total time 0.37s ( 0.41s elapsed) > > %GC time 34.8% (40.3% elapsed) > > Alloc rate 4,923,204,681 bytes per MUT second > > Productivity 65.2% of total user, 59.0% of total elapsed > }}} > > HEAD: > > {{{ > $ ./HashMapInsertNew +RTS -s > 1,191,223,128 bytes allocated in the heap > 231,158,688 bytes copied during GC > 55,533,064 bytes maximum residency (13 sample(s)) > 22,378,488 bytes maximum slop > 144 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 2268 colls, 0 par 0.06s 0.07s 0.0000s > 0.0003s > Gen 1 13 colls, 0 par 0.12s 0.16s 0.0127s > 0.0468s > > INIT time 0.00s ( 0.00s elapsed) > MUT time 0.25s ( 0.25s elapsed) > GC time 0.18s ( 0.23s elapsed) > EXIT time 0.00s ( 0.01s elapsed) > Total time 0.43s ( 0.49s elapsed) > > %GC time 41.6% (47.5% elapsed) > > Alloc rate 4,738,791,249 bytes per MUT second > > Productivity 58.3% of total user, 51.9% of total elapsed > }}} > > (Note that this is without the patches in #8885, so they're not the > cause.) > > An interesting difference is that we spend more time in GC in HEAD. I > don't know if that's related. New description: I ran a simple benchmark that exercises `Data.HashMap.Lazy.insert`. It's 16% slower using HEAD compared to using 7.6.3. The generated Core is the same, but the new codegen generates substantially different Cmm. '''Steps to reproduce''' 1. Download the attached `HashMapInsert.hs` benchmark. 2. Install unordered-containers with both 7.6.3 and HEAD: {{{ $ cabal install -w ghc-7.6.3 unordered-containers-0.2.3.3 $ cabal install -w inplace/bin/ghc-stage2 unordered-containers-0.2.3.3 }}} 3. Compile the benchmark with both compilers: {{{ $ ghc-7.6.3 -O2 HashMapInsert.hs $ mv HashMapInsert HashMapInsertOld $ inplace/bin/ghc-stage2 -O2 HashMapInsert.hs $ mv HashMapInsert HashMapInsertNew }}} '''Results (best of 3 runs)''' 7.6.3 {{{ $ ./HashMapInsertOld +RTS -s 1,191,223,528 bytes allocated in the heap 141,978,520 bytes copied during GC 37,811,840 bytes maximum residency (8 sample(s)) 22,378,432 bytes maximum slop 99 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2277 colls, 0 par 0.06s 0.06s 0.0000s 0.0002s Gen 1 8 colls, 0 par 0.07s 0.10s 0.0127s 0.0479s INIT time 0.00s ( 0.00s elapsed) MUT time 0.24s ( 0.24s elapsed) GC time 0.13s ( 0.17s elapsed) EXIT time 0.00s ( 0.01s elapsed) Total time 0.37s ( 0.41s elapsed) %GC time 34.8% (40.3% elapsed) Alloc rate 4,923,204,681 bytes per MUT second Productivity 65.2% of total user, 59.0% of total elapsed }}} HEAD: {{{ $ ./HashMapInsertNew +RTS -s 1,191,223,128 bytes allocated in the heap 231,158,688 bytes copied during GC 55,533,064 bytes maximum residency (13 sample(s)) 22,378,488 bytes maximum slop 144 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2268 colls, 0 par 0.06s 0.07s 0.0000s 0.0003s Gen 1 13 colls, 0 par 0.12s 0.16s 0.0127s 0.0468s INIT time 0.00s ( 0.00s elapsed) MUT time 0.25s ( 0.25s elapsed) GC time 0.18s ( 0.23s elapsed) EXIT time 0.00s ( 0.01s elapsed) Total time 0.43s ( 0.49s elapsed) %GC time 41.6% (47.5% elapsed) Alloc rate 4,738,791,249 bytes per MUT second Productivity 58.3% of total user, 51.9% of total elapsed }}} (Note that this is without the patches in #8885, so they're not the cause.) An interesting difference is that we spend more time in GC in HEAD. I don't know if that's related. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 17:04:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 17:04:54 -0000 Subject: [GHC] #8900: unordered-containers 16% slower in HEAD vs 7.6.3 In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.31e787e943ee749de4a6be7a288179a4@haskell.org> #8900: unordered-containers 16% slower in HEAD vs 7.6.3 --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by tibbe): * version: 7.6.3 => 7.9 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 17:12:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 17:12:51 -0000 Subject: [GHC] #8900: unordered-containers 16% slower in HEAD vs 7.6.3 In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.3bf8c44a0b286bda758ebc929858cfda@haskell.org> #8900: unordered-containers 16% slower in HEAD vs 7.6.3 --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): I also see some changes in the Core. I've attached both the Core and optimized Cmm output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 17:18:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 17:18:21 -0000 Subject: [GHC] #8900: unordered-containers 16% slower in HEAD vs 7.6.3 In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.37b8200676f90ce8733a9622335ee761@haskell.org> #8900: unordered-containers 16% slower in HEAD vs 7.6.3 --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Description changed by tibbe: Old description: > I ran a simple benchmark that exercises `Data.HashMap.Lazy.insert`. It's > 16% slower using HEAD compared to using 7.6.3. The generated Core is the > same, but the new codegen generates substantially different Cmm. > > '''Steps to reproduce''' > > 1. Download the attached `HashMapInsert.hs` benchmark. > 2. Install unordered-containers with both 7.6.3 and HEAD: > > {{{ > $ cabal install -w ghc-7.6.3 unordered-containers-0.2.3.3 > $ cabal install -w inplace/bin/ghc-stage2 unordered-containers-0.2.3.3 > }}} > > 3. Compile the benchmark with both compilers: > > {{{ > $ ghc-7.6.3 -O2 HashMapInsert.hs > $ mv HashMapInsert HashMapInsertOld > $ inplace/bin/ghc-stage2 -O2 HashMapInsert.hs > $ mv HashMapInsert HashMapInsertNew > }}} > > '''Results (best of 3 runs)''' > > 7.6.3 > > {{{ > $ ./HashMapInsertOld +RTS -s > 1,191,223,528 bytes allocated in the heap > 141,978,520 bytes copied during GC > 37,811,840 bytes maximum residency (8 sample(s)) > 22,378,432 bytes maximum slop > 99 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 2277 colls, 0 par 0.06s 0.06s 0.0000s > 0.0002s > Gen 1 8 colls, 0 par 0.07s 0.10s 0.0127s > 0.0479s > > INIT time 0.00s ( 0.00s elapsed) > MUT time 0.24s ( 0.24s elapsed) > GC time 0.13s ( 0.17s elapsed) > EXIT time 0.00s ( 0.01s elapsed) > Total time 0.37s ( 0.41s elapsed) > > %GC time 34.8% (40.3% elapsed) > > Alloc rate 4,923,204,681 bytes per MUT second > > Productivity 65.2% of total user, 59.0% of total elapsed > }}} > > HEAD: > > {{{ > $ ./HashMapInsertNew +RTS -s > 1,191,223,128 bytes allocated in the heap > 231,158,688 bytes copied during GC > 55,533,064 bytes maximum residency (13 sample(s)) > 22,378,488 bytes maximum slop > 144 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 2268 colls, 0 par 0.06s 0.07s 0.0000s > 0.0003s > Gen 1 13 colls, 0 par 0.12s 0.16s 0.0127s > 0.0468s > > INIT time 0.00s ( 0.00s elapsed) > MUT time 0.25s ( 0.25s elapsed) > GC time 0.18s ( 0.23s elapsed) > EXIT time 0.00s ( 0.01s elapsed) > Total time 0.43s ( 0.49s elapsed) > > %GC time 41.6% (47.5% elapsed) > > Alloc rate 4,738,791,249 bytes per MUT second > > Productivity 58.3% of total user, 51.9% of total elapsed > }}} > > (Note that this is without the patches in #8885, so they're not the > cause.) > > An interesting difference is that we spend more time in GC in HEAD. I > don't know if that's related. New description: I ran a simple benchmark that exercises [https://github.com/tibbe /unordered-containers/blob/master/Data/HashMap/Base.hs#L303 Data.HashMap.Lazy.insert]. It's 16% slower using HEAD compared to using 7.6.3. The generated Core is the same, but the new codegen generates substantially different Cmm. '''Steps to reproduce''' 1. Download the attached `HashMapInsert.hs` benchmark. 2. Install unordered-containers with both 7.6.3 and HEAD: {{{ $ cabal install -w ghc-7.6.3 unordered-containers-0.2.3.3 $ cabal install -w inplace/bin/ghc-stage2 unordered-containers-0.2.3.3 }}} 3. Compile the benchmark with both compilers: {{{ $ ghc-7.6.3 -O2 HashMapInsert.hs $ mv HashMapInsert HashMapInsertOld $ inplace/bin/ghc-stage2 -O2 HashMapInsert.hs $ mv HashMapInsert HashMapInsertNew }}} '''Results (best of 3 runs)''' 7.6.3 {{{ $ ./HashMapInsertOld +RTS -s 1,191,223,528 bytes allocated in the heap 141,978,520 bytes copied during GC 37,811,840 bytes maximum residency (8 sample(s)) 22,378,432 bytes maximum slop 99 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2277 colls, 0 par 0.06s 0.06s 0.0000s 0.0002s Gen 1 8 colls, 0 par 0.07s 0.10s 0.0127s 0.0479s INIT time 0.00s ( 0.00s elapsed) MUT time 0.24s ( 0.24s elapsed) GC time 0.13s ( 0.17s elapsed) EXIT time 0.00s ( 0.01s elapsed) Total time 0.37s ( 0.41s elapsed) %GC time 34.8% (40.3% elapsed) Alloc rate 4,923,204,681 bytes per MUT second Productivity 65.2% of total user, 59.0% of total elapsed }}} HEAD: {{{ $ ./HashMapInsertNew +RTS -s 1,191,223,128 bytes allocated in the heap 231,158,688 bytes copied during GC 55,533,064 bytes maximum residency (13 sample(s)) 22,378,488 bytes maximum slop 144 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2268 colls, 0 par 0.06s 0.07s 0.0000s 0.0003s Gen 1 13 colls, 0 par 0.12s 0.16s 0.0127s 0.0468s INIT time 0.00s ( 0.00s elapsed) MUT time 0.25s ( 0.25s elapsed) GC time 0.18s ( 0.23s elapsed) EXIT time 0.00s ( 0.01s elapsed) Total time 0.43s ( 0.49s elapsed) %GC time 41.6% (47.5% elapsed) Alloc rate 4,738,791,249 bytes per MUT second Productivity 58.3% of total user, 51.9% of total elapsed }}} (Note that this is without the patches in #8885, so they're not the cause.) An interesting difference is that we spend more time in GC in HEAD. I don't know if that's related. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 17:19:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 17:19:07 -0000 Subject: [GHC] #8900: unordered-containers 16% slower in HEAD vs 7.6.3 In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.7d6d0a3958687d78100a6480724c0fea@haskell.org> #8900: unordered-containers 16% slower in HEAD vs 7.6.3 --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Description changed by tibbe: Old description: > I ran a simple benchmark that exercises [https://github.com/tibbe > /unordered-containers/blob/master/Data/HashMap/Base.hs#L303 > Data.HashMap.Lazy.insert]. It's 16% slower using HEAD compared to using > 7.6.3. The generated Core is the same, but the new codegen generates > substantially different Cmm. > > '''Steps to reproduce''' > > 1. Download the attached `HashMapInsert.hs` benchmark. > 2. Install unordered-containers with both 7.6.3 and HEAD: > > {{{ > $ cabal install -w ghc-7.6.3 unordered-containers-0.2.3.3 > $ cabal install -w inplace/bin/ghc-stage2 unordered-containers-0.2.3.3 > }}} > > 3. Compile the benchmark with both compilers: > > {{{ > $ ghc-7.6.3 -O2 HashMapInsert.hs > $ mv HashMapInsert HashMapInsertOld > $ inplace/bin/ghc-stage2 -O2 HashMapInsert.hs > $ mv HashMapInsert HashMapInsertNew > }}} > > '''Results (best of 3 runs)''' > > 7.6.3 > > {{{ > $ ./HashMapInsertOld +RTS -s > 1,191,223,528 bytes allocated in the heap > 141,978,520 bytes copied during GC > 37,811,840 bytes maximum residency (8 sample(s)) > 22,378,432 bytes maximum slop > 99 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 2277 colls, 0 par 0.06s 0.06s 0.0000s > 0.0002s > Gen 1 8 colls, 0 par 0.07s 0.10s 0.0127s > 0.0479s > > INIT time 0.00s ( 0.00s elapsed) > MUT time 0.24s ( 0.24s elapsed) > GC time 0.13s ( 0.17s elapsed) > EXIT time 0.00s ( 0.01s elapsed) > Total time 0.37s ( 0.41s elapsed) > > %GC time 34.8% (40.3% elapsed) > > Alloc rate 4,923,204,681 bytes per MUT second > > Productivity 65.2% of total user, 59.0% of total elapsed > }}} > > HEAD: > > {{{ > $ ./HashMapInsertNew +RTS -s > 1,191,223,128 bytes allocated in the heap > 231,158,688 bytes copied during GC > 55,533,064 bytes maximum residency (13 sample(s)) > 22,378,488 bytes maximum slop > 144 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 2268 colls, 0 par 0.06s 0.07s 0.0000s > 0.0003s > Gen 1 13 colls, 0 par 0.12s 0.16s 0.0127s > 0.0468s > > INIT time 0.00s ( 0.00s elapsed) > MUT time 0.25s ( 0.25s elapsed) > GC time 0.18s ( 0.23s elapsed) > EXIT time 0.00s ( 0.01s elapsed) > Total time 0.43s ( 0.49s elapsed) > > %GC time 41.6% (47.5% elapsed) > > Alloc rate 4,738,791,249 bytes per MUT second > > Productivity 58.3% of total user, 51.9% of total elapsed > }}} > > (Note that this is without the patches in #8885, so they're not the > cause.) > > An interesting difference is that we spend more time in GC in HEAD. I > don't know if that's related. New description: I ran a simple benchmark that exercises [https://github.com/tibbe /unordered-containers/blob/master/Data/HashMap/Base.hs#L303 Data.HashMap.Lazy.insert]. It's 16% slower using HEAD compared to using 7.6.3. The generated Core is a bit different and the generated Cmm is quite a bit different. '''Steps to reproduce''' 1. Download the attached `HashMapInsert.hs` benchmark. 2. Install unordered-containers with both 7.6.3 and HEAD: {{{ $ cabal install -w ghc-7.6.3 unordered-containers-0.2.3.3 $ cabal install -w inplace/bin/ghc-stage2 unordered-containers-0.2.3.3 }}} 3. Compile the benchmark with both compilers: {{{ $ ghc-7.6.3 -O2 HashMapInsert.hs $ mv HashMapInsert HashMapInsertOld $ inplace/bin/ghc-stage2 -O2 HashMapInsert.hs $ mv HashMapInsert HashMapInsertNew }}} '''Results (best of 3 runs)''' 7.6.3 {{{ $ ./HashMapInsertOld +RTS -s 1,191,223,528 bytes allocated in the heap 141,978,520 bytes copied during GC 37,811,840 bytes maximum residency (8 sample(s)) 22,378,432 bytes maximum slop 99 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2277 colls, 0 par 0.06s 0.06s 0.0000s 0.0002s Gen 1 8 colls, 0 par 0.07s 0.10s 0.0127s 0.0479s INIT time 0.00s ( 0.00s elapsed) MUT time 0.24s ( 0.24s elapsed) GC time 0.13s ( 0.17s elapsed) EXIT time 0.00s ( 0.01s elapsed) Total time 0.37s ( 0.41s elapsed) %GC time 34.8% (40.3% elapsed) Alloc rate 4,923,204,681 bytes per MUT second Productivity 65.2% of total user, 59.0% of total elapsed }}} HEAD: {{{ $ ./HashMapInsertNew +RTS -s 1,191,223,128 bytes allocated in the heap 231,158,688 bytes copied during GC 55,533,064 bytes maximum residency (13 sample(s)) 22,378,488 bytes maximum slop 144 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2268 colls, 0 par 0.06s 0.07s 0.0000s 0.0003s Gen 1 13 colls, 0 par 0.12s 0.16s 0.0127s 0.0468s INIT time 0.00s ( 0.00s elapsed) MUT time 0.25s ( 0.25s elapsed) GC time 0.18s ( 0.23s elapsed) EXIT time 0.00s ( 0.01s elapsed) Total time 0.43s ( 0.49s elapsed) %GC time 41.6% (47.5% elapsed) Alloc rate 4,738,791,249 bytes per MUT second Productivity 58.3% of total user, 51.9% of total elapsed }}} (Note that this is without the patches in #8885, so they're not the cause.) An interesting difference is that we spend more time in GC in HEAD. I don't know if that's related. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 21:05:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 21:05:22 -0000 Subject: [GHC] #8900: unordered-containers 16% slower in HEAD vs 7.6.3 In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.f39e58751ea4664f30c726be50d5c6ad@haskell.org> #8900: unordered-containers 16% slower in HEAD vs 7.6.3 --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): So we have {{{ MUT time 0.24s ( 0.24s elapsed) GC time 0.13s ( 0.17s elapsed) vs MUT time 0.25s ( 0.25s elapsed) GC time 0.18s ( 0.23s elapsed) }}} ie. almost all the difference is in GC. And: {{{ 141,978,520 bytes copied during GC 99 MB total memory in use (0 MB lost due to fragmentation) vs 231,158,688 bytes copied during GC 144 MB total memory in use (0 MB lost due to fragmentation) }}} And {{{ Gen 1 8 colls, 0 par 0.07s 0.10s 0.0127s 0.0479s vs Gen 1 13 colls, 0 par 0.12s 0.16s 0.0127s 0.0468s }}} My guess, based on seeing things like this before, is that the benchmark is very sensitive to when exactly major GC strikes - perhaps it has a spike in memory usage at some point. You ought to be able to test this hypothesis by tweaking the GC options. Try with a very large heap size (-A2G). There's a very small change in the MUT time, which is probably accounted for by extra cache misses caused by the extra GC activity. So I suspect this is nothing to worry about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 21:07:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 21:07:09 -0000 Subject: [GHC] #8900: unordered-containers 16% slower in HEAD vs 7.6.3 In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.f7bcf359640304176e3996e4b7699f3b@haskell.org> #8900: unordered-containers 16% slower in HEAD vs 7.6.3 --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): I've found a likely culprit in the generated Core. Compare the case for `Full` in `$wpoly_go` for [https://ghc.haskell.org/trac/ghc/attachment/ticket/8900/HashMapInsert-7.6.3 .dump-simpl#L569 7.6.3]: {{{ 569 case indexArray# rb_a1cI i#_s1oq of _ { (# ipv2_a1cS #) -> 570 case $wpoly_go ww_s2HT ww1_s2HX w_s2HZ (+# ww2_s2I2 4) ipv2_a1cS 571 of st'_a1cV { __DEFAULT -> }}} vs the case for `Full` in `$wpoly_go` for [https://ghc.haskell.org/trac/ghc/attachment/ticket/8900/HashMapInsert- HEAD.dump-simpl#L554 HEAD]: {{{ 554 case indexArray# dt_a2Ly i#_a2LH 555 of _ [Occ=Dead] { (# ipv2_a2LM #) -> 556 case ipv2_a2LM of st_a2LO { __DEFAULT -> 557 case $wpoly_go ww_s4A3 ww1_s4A7 w_s4zY (+# ww2_s4Ab 4) st_a2LO 558 of st'_a2LP { __DEFAULT -> }}} Both cases correspond to this snippet in `Data.HashMap.Base`: {{{ #!haskell go h k x s t@(Full ary) = let !st = A.index ary i !st' = go h k x (s+bitsPerSubkey) st }}} Here's the definition for `A.index`: {{{ #!haskell index :: Array a -> Int -> a index ary _i@(I# i#) = case indexArray# (unArray ary) i# of (# b #) -> b }}} There's an extra `case` in the HEAD version, which translates into an extra tag bits check in the Cmm. This happens in a couple of places in the core. This `case` is unnecessary since `$wpoly_go` scrutinizes `st_a2LO` immediately. This looks like a regression in strictness analysis. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 21:14:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 21:14:05 -0000 Subject: [GHC] #8900: unordered-containers 16% slower in HEAD vs 7.6.3 In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.fd270d594a4469905db5fbab02719ccc@haskell.org> #8900: unordered-containers 16% slower in HEAD vs 7.6.3 --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): While the extra `case` is definitely a regression, it doesn't seem to be the cause of the time difference. Changing `A.index` to: {{{ #!haskell index :: Array a -> Int -> (# a #) index ary _i@(I# i#) = indexArray# (unArray ary) i# }}} and the snippet from `Data.HashMap.Base` to: {{{ #!haskell go h k x s t@(Full ary) = let !(# st #) = A.index ary i !st' = go h k x (s+bitsPerSubkey) st }}} makes the difference in the Core go away, but the time difference remains. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 21:19:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 21:19:30 -0000 Subject: [GHC] #8900: unordered-containers 16% slower in HEAD vs 7.6.3 In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.26b84ae7c3ac3e9847451b524d83c02c@haskell.org> #8900: unordered-containers 16% slower in HEAD vs 7.6.3 --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): Here are the numbers with `-A2G`: 7.6.3: {{{ $ ./HashMapInsert +RTS -s -A2G 1,191,223,528 bytes allocated in the heap 3,400 bytes copied during GC 36,080 bytes maximum residency (1 sample(s)) 13,072 bytes maximum slop 2081 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.00s 0.00s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.01s 0.01s 0.0064s 0.0064s INIT time 0.01s ( 0.02s elapsed) MUT time 0.58s ( 0.93s elapsed) GC time 0.01s ( 0.01s elapsed) EXIT time 0.01s ( 0.01s elapsed) Total time 0.60s ( 0.96s elapsed) %GC time 1.0% (0.7% elapsed) Alloc rate 2,063,221,325 bytes per MUT second Productivity 97.6% of total user, 61.0% of total elapsed }}} HEAD: {{{ $ ./HashMapInsert +RTS -s -A2G 1,191,223,096 bytes allocated in the heap 3,312 bytes copied during GC 35,992 bytes maximum residency (1 sample(s)) 13,160 bytes maximum slop 2081 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.00s 0.00s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.01s 0.02s 0.0158s 0.0158s INIT time 0.01s ( 0.02s elapsed) MUT time 0.60s ( 0.93s elapsed) GC time 0.01s ( 0.02s elapsed) EXIT time 0.01s ( 0.02s elapsed) Total time 0.62s ( 0.99s elapsed) %GC time 1.0% (1.6% elapsed) Alloc rate 1,998,679,702 bytes per MUT second Productivity 97.7% of total user, 61.3% of total elapsed }}} I'll accept Simon M's explanation of the difference. I'll leave the ticket open for the strictness analysis issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 21:20:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 21:20:49 -0000 Subject: [GHC] #8900: Strictness analysis regression (was: unordered-containers 16% slower in HEAD vs 7.6.3) In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.bdfd257dee3ecac82b05f7b62be3dae2@haskell.org> #8900: Strictness analysis regression --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Description changed by tibbe: Old description: > I ran a simple benchmark that exercises [https://github.com/tibbe > /unordered-containers/blob/master/Data/HashMap/Base.hs#L303 > Data.HashMap.Lazy.insert]. It's 16% slower using HEAD compared to using > 7.6.3. The generated Core is a bit different and the generated Cmm is > quite a bit different. > > '''Steps to reproduce''' > > 1. Download the attached `HashMapInsert.hs` benchmark. > 2. Install unordered-containers with both 7.6.3 and HEAD: > > {{{ > $ cabal install -w ghc-7.6.3 unordered-containers-0.2.3.3 > $ cabal install -w inplace/bin/ghc-stage2 unordered-containers-0.2.3.3 > }}} > > 3. Compile the benchmark with both compilers: > > {{{ > $ ghc-7.6.3 -O2 HashMapInsert.hs > $ mv HashMapInsert HashMapInsertOld > $ inplace/bin/ghc-stage2 -O2 HashMapInsert.hs > $ mv HashMapInsert HashMapInsertNew > }}} > > '''Results (best of 3 runs)''' > > 7.6.3 > > {{{ > $ ./HashMapInsertOld +RTS -s > 1,191,223,528 bytes allocated in the heap > 141,978,520 bytes copied during GC > 37,811,840 bytes maximum residency (8 sample(s)) > 22,378,432 bytes maximum slop > 99 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 2277 colls, 0 par 0.06s 0.06s 0.0000s > 0.0002s > Gen 1 8 colls, 0 par 0.07s 0.10s 0.0127s > 0.0479s > > INIT time 0.00s ( 0.00s elapsed) > MUT time 0.24s ( 0.24s elapsed) > GC time 0.13s ( 0.17s elapsed) > EXIT time 0.00s ( 0.01s elapsed) > Total time 0.37s ( 0.41s elapsed) > > %GC time 34.8% (40.3% elapsed) > > Alloc rate 4,923,204,681 bytes per MUT second > > Productivity 65.2% of total user, 59.0% of total elapsed > }}} > > HEAD: > > {{{ > $ ./HashMapInsertNew +RTS -s > 1,191,223,128 bytes allocated in the heap > 231,158,688 bytes copied during GC > 55,533,064 bytes maximum residency (13 sample(s)) > 22,378,488 bytes maximum slop > 144 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 2268 colls, 0 par 0.06s 0.07s 0.0000s > 0.0003s > Gen 1 13 colls, 0 par 0.12s 0.16s 0.0127s > 0.0468s > > INIT time 0.00s ( 0.00s elapsed) > MUT time 0.25s ( 0.25s elapsed) > GC time 0.18s ( 0.23s elapsed) > EXIT time 0.00s ( 0.01s elapsed) > Total time 0.43s ( 0.49s elapsed) > > %GC time 41.6% (47.5% elapsed) > > Alloc rate 4,738,791,249 bytes per MUT second > > Productivity 58.3% of total user, 51.9% of total elapsed > }}} > > (Note that this is without the patches in #8885, so they're not the > cause.) > > An interesting difference is that we spend more time in GC in HEAD. I > don't know if that's related. New description: Edit: There were two issues discussed here. One is solved. I left the ticket open for the strictness analysis regression part. I ran a simple benchmark that exercises [https://github.com/tibbe /unordered-containers/blob/master/Data/HashMap/Base.hs#L303 Data.HashMap.Lazy.insert]. It's 16% slower using HEAD compared to using 7.6.3. The generated Core is a bit different and the generated Cmm is quite a bit different. '''Steps to reproduce''' 1. Download the attached `HashMapInsert.hs` benchmark. 2. Install unordered-containers with both 7.6.3 and HEAD: {{{ $ cabal install -w ghc-7.6.3 unordered-containers-0.2.3.3 $ cabal install -w inplace/bin/ghc-stage2 unordered-containers-0.2.3.3 }}} 3. Compile the benchmark with both compilers: {{{ $ ghc-7.6.3 -O2 HashMapInsert.hs $ mv HashMapInsert HashMapInsertOld $ inplace/bin/ghc-stage2 -O2 HashMapInsert.hs $ mv HashMapInsert HashMapInsertNew }}} '''Results (best of 3 runs)''' 7.6.3 {{{ $ ./HashMapInsertOld +RTS -s 1,191,223,528 bytes allocated in the heap 141,978,520 bytes copied during GC 37,811,840 bytes maximum residency (8 sample(s)) 22,378,432 bytes maximum slop 99 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2277 colls, 0 par 0.06s 0.06s 0.0000s 0.0002s Gen 1 8 colls, 0 par 0.07s 0.10s 0.0127s 0.0479s INIT time 0.00s ( 0.00s elapsed) MUT time 0.24s ( 0.24s elapsed) GC time 0.13s ( 0.17s elapsed) EXIT time 0.00s ( 0.01s elapsed) Total time 0.37s ( 0.41s elapsed) %GC time 34.8% (40.3% elapsed) Alloc rate 4,923,204,681 bytes per MUT second Productivity 65.2% of total user, 59.0% of total elapsed }}} HEAD: {{{ $ ./HashMapInsertNew +RTS -s 1,191,223,128 bytes allocated in the heap 231,158,688 bytes copied during GC 55,533,064 bytes maximum residency (13 sample(s)) 22,378,488 bytes maximum slop 144 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2268 colls, 0 par 0.06s 0.07s 0.0000s 0.0003s Gen 1 13 colls, 0 par 0.12s 0.16s 0.0127s 0.0468s INIT time 0.00s ( 0.00s elapsed) MUT time 0.25s ( 0.25s elapsed) GC time 0.18s ( 0.23s elapsed) EXIT time 0.00s ( 0.01s elapsed) Total time 0.43s ( 0.49s elapsed) %GC time 41.6% (47.5% elapsed) Alloc rate 4,738,791,249 bytes per MUT second Productivity 58.3% of total user, 51.9% of total elapsed }}} (Note that this is without the patches in #8885, so they're not the cause.) An interesting difference is that we spend more time in GC in HEAD. I don't know if that's related. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 21:49:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 21:49:18 -0000 Subject: [GHC] #8885: Add inline versions of clone array primops In-Reply-To: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> References: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> Message-ID: <059.65298e88147795e20dbcc830e621f58b@haskell.org> #8885: Add inline versions of clone array primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): My intuition to use a pointer based copy loop instead of an index based loop seems to have been wrong. Changing the loop from: {{{ dst_p = dst + SIZEOF_StgMutArrPtrs; src_p = src + SIZEOF_StgMutArrPtrs + WDS(offset); while: if (n != 0) { n = n - 1; W_[dst_p] = W_[src_p]; dst_p = dst_p + WDS(1); src_p = src_p + WDS(1); goto while; } }}} to {{{ dst_p = dst + SIZEOF_StgMutArrPtrs; src_p = src + SIZEOF_StgMutArrPtrs + WDS(offset); i = 0; while: if (i < n) { W_[dst_p + i] = W_[src_p + i]; i = i + 1; goto while; } }}} improves performance on my benchmark (clone array of 17 elements) by 14%. Attached patch with this improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 21:59:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 21:59:38 -0000 Subject: [GHC] #8900: Strictness analysis regression In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.820721b7449955e00d5344c823aae812@haskell.org> #8900: Strictness analysis regression --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by tibbe): * version: 7.9 => 7.8.1-rc2 Comment: Strictness analysis regression is also in the latest 7.8 snapshot I had lying around, ghc-7.8.0.20140228, so it's likely in 7.8 RC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 22:02:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 22:02:38 -0000 Subject: [GHC] #8900: Strictness analysis regression In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.25086e7df8bfaf5cf12e339753627f7a@haskell.org> #8900: Strictness analysis regression --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Description changed by tibbe: Old description: > Edit: There were two issues discussed here. One is solved. I left the > ticket open for the strictness analysis regression part. > > I ran a simple benchmark that exercises [https://github.com/tibbe > /unordered-containers/blob/master/Data/HashMap/Base.hs#L303 > Data.HashMap.Lazy.insert]. It's 16% slower using HEAD compared to using > 7.6.3. The generated Core is a bit different and the generated Cmm is > quite a bit different. > > '''Steps to reproduce''' > > 1. Download the attached `HashMapInsert.hs` benchmark. > 2. Install unordered-containers with both 7.6.3 and HEAD: > > {{{ > $ cabal install -w ghc-7.6.3 unordered-containers-0.2.3.3 > $ cabal install -w inplace/bin/ghc-stage2 unordered-containers-0.2.3.3 > }}} > > 3. Compile the benchmark with both compilers: > > {{{ > $ ghc-7.6.3 -O2 HashMapInsert.hs > $ mv HashMapInsert HashMapInsertOld > $ inplace/bin/ghc-stage2 -O2 HashMapInsert.hs > $ mv HashMapInsert HashMapInsertNew > }}} > > '''Results (best of 3 runs)''' > > 7.6.3 > > {{{ > $ ./HashMapInsertOld +RTS -s > 1,191,223,528 bytes allocated in the heap > 141,978,520 bytes copied during GC > 37,811,840 bytes maximum residency (8 sample(s)) > 22,378,432 bytes maximum slop > 99 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 2277 colls, 0 par 0.06s 0.06s 0.0000s > 0.0002s > Gen 1 8 colls, 0 par 0.07s 0.10s 0.0127s > 0.0479s > > INIT time 0.00s ( 0.00s elapsed) > MUT time 0.24s ( 0.24s elapsed) > GC time 0.13s ( 0.17s elapsed) > EXIT time 0.00s ( 0.01s elapsed) > Total time 0.37s ( 0.41s elapsed) > > %GC time 34.8% (40.3% elapsed) > > Alloc rate 4,923,204,681 bytes per MUT second > > Productivity 65.2% of total user, 59.0% of total elapsed > }}} > > HEAD: > > {{{ > $ ./HashMapInsertNew +RTS -s > 1,191,223,128 bytes allocated in the heap > 231,158,688 bytes copied during GC > 55,533,064 bytes maximum residency (13 sample(s)) > 22,378,488 bytes maximum slop > 144 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 2268 colls, 0 par 0.06s 0.07s 0.0000s > 0.0003s > Gen 1 13 colls, 0 par 0.12s 0.16s 0.0127s > 0.0468s > > INIT time 0.00s ( 0.00s elapsed) > MUT time 0.25s ( 0.25s elapsed) > GC time 0.18s ( 0.23s elapsed) > EXIT time 0.00s ( 0.01s elapsed) > Total time 0.43s ( 0.49s elapsed) > > %GC time 41.6% (47.5% elapsed) > > Alloc rate 4,738,791,249 bytes per MUT second > > Productivity 58.3% of total user, 51.9% of total elapsed > }}} > > (Note that this is without the patches in #8885, so they're not the > cause.) > > An interesting difference is that we spend more time in GC in HEAD. I > don't know if that's related. New description: Edit: There were two issues discussed here. One is solved. I left the ticket open for the strictness analysis regression part. Analysis of strictness regression starts in comment 7 below. I ran a simple benchmark that exercises [https://github.com/tibbe /unordered-containers/blob/master/Data/HashMap/Base.hs#L303 Data.HashMap.Lazy.insert]. It's 16% slower using HEAD compared to using 7.6.3. The generated Core is a bit different and the generated Cmm is quite a bit different. '''Steps to reproduce''' 1. Download the attached `HashMapInsert.hs` benchmark. 2. Install unordered-containers with both 7.6.3 and HEAD: {{{ $ cabal install -w ghc-7.6.3 unordered-containers-0.2.3.3 $ cabal install -w inplace/bin/ghc-stage2 unordered-containers-0.2.3.3 }}} 3. Compile the benchmark with both compilers: {{{ $ ghc-7.6.3 -O2 HashMapInsert.hs $ mv HashMapInsert HashMapInsertOld $ inplace/bin/ghc-stage2 -O2 HashMapInsert.hs $ mv HashMapInsert HashMapInsertNew }}} '''Results (best of 3 runs)''' 7.6.3 {{{ $ ./HashMapInsertOld +RTS -s 1,191,223,528 bytes allocated in the heap 141,978,520 bytes copied during GC 37,811,840 bytes maximum residency (8 sample(s)) 22,378,432 bytes maximum slop 99 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2277 colls, 0 par 0.06s 0.06s 0.0000s 0.0002s Gen 1 8 colls, 0 par 0.07s 0.10s 0.0127s 0.0479s INIT time 0.00s ( 0.00s elapsed) MUT time 0.24s ( 0.24s elapsed) GC time 0.13s ( 0.17s elapsed) EXIT time 0.00s ( 0.01s elapsed) Total time 0.37s ( 0.41s elapsed) %GC time 34.8% (40.3% elapsed) Alloc rate 4,923,204,681 bytes per MUT second Productivity 65.2% of total user, 59.0% of total elapsed }}} HEAD: {{{ $ ./HashMapInsertNew +RTS -s 1,191,223,128 bytes allocated in the heap 231,158,688 bytes copied during GC 55,533,064 bytes maximum residency (13 sample(s)) 22,378,488 bytes maximum slop 144 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2268 colls, 0 par 0.06s 0.07s 0.0000s 0.0003s Gen 1 13 colls, 0 par 0.12s 0.16s 0.0127s 0.0468s INIT time 0.00s ( 0.00s elapsed) MUT time 0.25s ( 0.25s elapsed) GC time 0.18s ( 0.23s elapsed) EXIT time 0.00s ( 0.01s elapsed) Total time 0.43s ( 0.49s elapsed) %GC time 41.6% (47.5% elapsed) Alloc rate 4,738,791,249 bytes per MUT second Productivity 58.3% of total user, 51.9% of total elapsed }}} (Note that this is without the patches in #8885, so they're not the cause.) An interesting difference is that we spend more time in GC in HEAD. I don't know if that's related. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 15 23:29:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Mar 2014 23:29:31 -0000 Subject: [GHC] #8901: (very) bad inline heuristics Message-ID: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> #8901: (very) bad inline heuristics ------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I observe a bad case for inlining blowup for the time library. Observed for 7.7, just checked in 7.9. The problem is so bad that the PowerPC32 assembler cannot resolve cross- routine references. (I have no error message at hand, but could try to get one.) Instead here are the stats for x86, with inlining and certain inlining suppressed. The architecture seems irrelevant. {{{ $ file ./libraries/time/dist-install/build/Data/Time/Format.o ./libraries/time/dist-install/build/Data/Time/Format.o: Mach-O object i386 $ ls -l ./libraries/time/dist-install/build/Data/Time/Format.* -rw-r--r-- 1 ggreif staff 61875 Mar 15 16:48 ./libraries/time/dist- install/build/Data/Time/Format.dyn_hi -rw-r--r-- 1 ggreif staff 450864 Mar 15 16:48 ./libraries/time/dist- install/build/Data/Time/Format.dyn_o -rw-r--r-- 1 ggreif staff 61863 Mar 15 16:48 ./libraries/time/dist- install/build/Data/Time/Format.hi -rw-r--r-- 1 ggreif staff 332216 Mar 15 16:48 ./libraries/time/dist- install/build/Data/Time/Format.o }}} With following patch applied: I get: {{{ $ ls -l ./libraries/time/dist-install/build/Data/Time/Format.* -rw-r--r-- 1 ggreif staff 10554 Mar 16 00:08 ./libraries/time/dist- install/build/Data/Time/Format.dyn_hi -rw-r--r-- 1 ggreif staff 106832 Mar 16 00:08 ./libraries/time/dist- install/build/Data/Time/Format.dyn_o -rw-r--r-- 1 ggreif staff 10542 Mar 16 00:08 ./libraries/time/dist- install/build/Data/Time/Format.hi -rw-r--r-- 1 ggreif staff 78864 Mar 16 00:08 ./libraries/time/dist- install/build/Data/Time/Format.o }}} The factor is 4.2 for Format.o, Format.dyn_o and 5.8 for the .hi files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 01:27:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 01:27:38 -0000 Subject: [GHC] #8901: (very) bad inline heuristics In-Reply-To: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> References: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> Message-ID: <063.d4fef470f914b756a877f0295a9f5db2@haskell.org> #8901: (very) bad inline heuristics -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Ashley Yakeley): It's not clear to me whether this should be considered a bug in the time library or a bug in GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 11:16:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 11:16:22 -0000 Subject: [GHC] #8251: Validate submodule references during pre-receive hook In-Reply-To: <042.3dddefcb4f2f56279562cd3ed6b1a071@haskell.org> References: <042.3dddefcb4f2f56279562cd3ed6b1a071@haskell.org> Message-ID: <057.e3c494d951b5e10e9864d16c8e3a5b96@haskell.org> #8251: Validate submodule references during pre-receive hook -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Resolution: | Keywords: admin git Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): I've implemented a server-side hook and enabled it for `git-sandbox.git` and `ghc.git` The hacked-up implementation can be found in this [https://gist.github.com/hvr/9580927 gist] Some details: - only commits becoming reachable via non-`wip/`-branches ("persistent branches") are validated - if a non-merge commit results in a modified gitlink-type, or a merge commit results in a gitlink-type entry which is different from all its ancestors, then - the git commit message body must contain the string `submodule` - each touched gitlink is - looked up in the `.gitmodules` file and resolved to the respective git repo hosted `git.haskell.org`, - the referenced submodule commit must be reachable from a "persistent branch" (i.e. a non-`wip/`-branch) This scheme relies on "persistent branches" not being allowed to be deleted or non-fast-fwd updated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 11:58:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 11:58:25 -0000 Subject: [GHC] #8713: Avoid libraries if unneeded (librt, libdl, libpthread) In-Reply-To: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> References: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> Message-ID: <060.54a78390726c2e1c8c27d0e6ac48a1b7@haskell.org> #8713: Avoid libraries if unneeded (librt, libdl, libpthread) ----------------------------+---------------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: GHCi | Difficulty: Moderate (less than a day) crash | Blocked By: Test Case: | Related Tickets: Blocking: | ----------------------------+---------------------------------------------- Changes (by trommler): * cc: ptrommler@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 15:49:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 15:49:18 -0000 Subject: [GHC] #8900: Strictness analysis regression In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.5082659a510ba7fbc70dc4e197270d50@haskell.org> #8900: Strictness analysis regression --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): If that small difference in the MUT time is reliable, there might be a regression in the code generator we need to look into. Were those numbers with or without the extra case expression? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 16:13:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 16:13:39 -0000 Subject: [GHC] #8894: Clean up `Coercible` plumbing In-Reply-To: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> References: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> Message-ID: <061.58bff202f3431362840e701a2fbd3934@haskell.org> #8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"014223745186fc0ca6afb9938227df9ce7d28b38/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="014223745186fc0ca6afb9938227df9ce7d28b38" Test case: :info Coercible in GHCi This prepares against future breakage, especially if #8894 is tackled. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 16:57:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 16:57:31 -0000 Subject: [GHC] #8900: Strictness analysis regression In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.555c69c5445abec10b444b77f2af8ac4@haskell.org> #8900: Strictness analysis regression --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): Without the extra case expression, there's still a small difference. Using the best of 5 runs, here are the numbers: HEAD (46d05ba03d1491cade4a3fe33f0b8c404ad3c760): {{{ $ ./HashMapInsert +RTS -s -A2G 1,191,223,096 bytes allocated in the heap 3,312 bytes copied during GC 35,992 bytes maximum residency (1 sample(s)) 13,160 bytes maximum slop 2081 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.00s 0.00s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.01s 0.01s 0.0060s 0.0060s INIT time 0.01s ( 0.02s elapsed) MUT time 0.60s ( 0.89s elapsed) GC time 0.01s ( 0.01s elapsed) EXIT time 0.01s ( 0.01s elapsed) Total time 0.62s ( 0.92s elapsed) %GC time 0.9% (0.6% elapsed) Alloc rate 1,991,359,179 bytes per MUT second Productivity 97.8% of total user, 66.0% of total elapsed }}} 7.6.3: {{{ $ ./HashMapInsert +RTS -s -A2G 1,191,223,528 bytes allocated in the heap 3,400 bytes copied during GC 36,080 bytes maximum residency (1 sample(s)) 13,072 bytes maximum slop 2081 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.00s 0.00s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.01s 0.01s 0.0057s 0.0057s INIT time 0.01s ( 0.02s elapsed) MUT time 0.59s ( 0.86s elapsed) GC time 0.01s ( 0.01s elapsed) EXIT time 0.01s ( 0.01s elapsed) Total time 0.61s ( 0.90s elapsed) %GC time 0.9% (0.6% elapsed) Alloc rate 2,033,686,150 bytes per MUT second Productivity 97.8% of total user, 66.4% of total elapsed }}} I've attached the Cmm for both HEAD and 7.6.3. They're not trivial to compare as in HEAD everything is in one function, `$wpoly_go_entry`, while in 7.6.3 it's split over two, `$wpoly_go_info` and `s2ZS_ret`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 16:58:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 16:58:59 -0000 Subject: [GHC] #5063: unix package has untracked dependency on libbsd In-Reply-To: <045.cf55a0b13cf66f80e2fa9d353d2762fd@haskell.org> References: <045.cf55a0b13cf66f80e2fa9d353d2762fd@haskell.org> Message-ID: <060.314d5d8fcb6c2eb7e89e9f5be96de263@haskell.org> #5063: unix package has untracked dependency on libbsd ----------------------------+---------------------------------------------- Reporter: duncan | Owner: trommler Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: | Version: 7.0.3 libraries/unix | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less than a day) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by trommler): * owner: => trommler * difficulty: => Moderate (less than a day) * milestone: 7.6.2 => 7.10.1 * failure: None/Unknown => Other Comment: I think {{{libutil.h}}} and the dependency on {{{libutil.so}}} can be avoided using {{{posix_openpt}}} instead of {{{openpty}}}. The former is specified in POSIX.1-2001 and is available on FreeBSD, Linux, OSX and Solaris 10 according to Stevens and Rago, Advanced Programming in the UNIX Environment. I will work on a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 17:09:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 17:09:08 -0000 Subject: [GHC] #8902: Test for RTLD_NEXT, RTLD_DEFAULT broken on Linux Message-ID: <047.6577d3b0e4350e5dc6e80e1809edc6cb@haskell.org> #8902: Test for RTLD_NEXT, RTLD_DEFAULT broken on Linux ------------------------------------+--------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: low | Milestone: Component: libraries/unix | Version: 7.8.1-rc2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Building 7.8.1RC2 on openSUSE, I see this: {{{ [ 2270s] checking return type of unsetenv... int [ 2270s] checking for RTLD_NEXT from dlfcn.h... no [ 2270s] checking for RTLD_DEFAULT from dlfcn.h... no [ 2270s] checking for RTLD_LOCAL from dlfcn.h... yes }}} The manual says that both RTLD_NEXT and RTLD_DEFAULT exist. Setting priority to low as I don't see any failures because of that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 17:15:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 17:15:33 -0000 Subject: [GHC] #8024: Dynamic linking not working on PowerPC Linux. In-Reply-To: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> References: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> Message-ID: <059.3b0edec77a22363a03848ddf8ba56387@haskell.org> #8024: Dynamic linking not working on PowerPC Linux. ----------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Changes (by trommler): * cc: ptrommler@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 17:21:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 17:21:03 -0000 Subject: [GHC] #8901: (very) bad inline heuristics In-Reply-To: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> References: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> Message-ID: <063.aca166ca9e73f85fe992d298dee4021e@haskell.org> #8901: (very) bad inline heuristics -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by trommler): Replying to [ticket:8901 heisenbug]: > The problem is so bad that the PowerPC32 assembler cannot resolve cross- routine references. > (I have no error message at hand, but could try to get one.) FWIW The powerpc issue in the time library (#7830) was fixed by @erikd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 17:22:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 17:22:44 -0000 Subject: [GHC] #8903: Add dead store elimination Message-ID: <044.457360c65e33571e0a4f71ea81733822@haskell.org> #8903: Add dead store elimination ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We could use some dead store elimination in the code generator. Here's some Cmm that has redundant stores to the same locations: {{{ // thawArray#: I64[Hp - 168] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info at GOTPCREL]; I64[Hp - 160] = 16; I64[Hp - 152] = 17; _c2nT::I64 = Hp - 168; call MO_Memcpy(_c2nT::I64 + 24, _s2cx::P64 + 24, 128, 8); // writeArray#: P64[(_c2nT::I64 + 24) + (_s2cy::I64 << 3)] = _s2cE::P64; I64[_c2nT::I64] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info at GOTPCREL]; I8[(_c2nT::I64 + 24) + ((I64[_c2nT::I64 + 8] << 3) + (_s2cy::I64 >> 7))] = 1 :: W8; // unsafeFreeze# I64[_c2nT::I64] = I64[PicBaseReg + stg_MUT_ARR_PTRS_FROZEN0_info at GOTPCREL]; }}} There are three stores to the same location (`I64[_c2nT::I64]`). (There's also one much less obvious double store to another location, which will probably be much harder to address: the store to `P64[(_c2nT::I64 + 24) + (_s2cy::I64 << 3)]` overwrites a word previous written by the `MO_Memcpy`. Getting to that one will be hard as the memcoy callish !MachOp only gets expanded in the backend.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 17:33:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 17:33:05 -0000 Subject: [GHC] #8894: Clean up `Coercible` plumbing In-Reply-To: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> References: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> Message-ID: <061.ed620a15fe0478675937987263f13d06@haskell.org> #8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Just gave it a shot, and indeed, the generated `libraries/ghc-prim/dist- install/doc/html/ghc-prim/GHC-Types.html#t:Coercible` shows `data Coercible a b` instead of `class Coercible a b`. GHCi gives the correct information upon `:browse GHC.Types`. Interestingly, `libraries/base/dist-install/doc/html/base/Data- Coerce.html` is correct. Since that is the official location for `Coercible`, I?ll actually push the change; this way someone who knows haddock can have a look (the changes affects three repositories, so having it as a branch is somewhat overkill). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 17:54:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 17:54:14 -0000 Subject: [GHC] #8894: Clean up `Coercible` plumbing In-Reply-To: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> References: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> Message-ID: <061.d8d4b787f517d1893185d5072036e53e@haskell.org> #8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"aea32bc5ca0511b79136b9a7294022ef708d8d3c/ghc-prim"]: {{{ #!CommitTicketReference repository="ghc-prim" revision="aea32bc5ca0511b79136b9a7294022ef708d8d3c" Export Coercible in GHC.Types (#8894) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 17:54:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 17:54:31 -0000 Subject: [GHC] #8894: Clean up `Coercible` plumbing In-Reply-To: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> References: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> Message-ID: <061.603fe8034e939c98c3b3b433e797e0dc@haskell.org> #8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"d59170b6deaee480640889e8a7eef5a863242562/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d59170b6deaee480640889e8a7eef5a863242562" Coercible is now exported from GHC.Types (#8894) so do not export it in GHC.Prim, and also have the pseudo-code for GHC.Prim import GHC.Types, so that haddock is happy. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 17:57:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 17:57:14 -0000 Subject: [GHC] #8904: haddock displays GHC.Types.Coercible as a datatype Message-ID: <046.9569975d8a2129291c9ce95dd884053d@haskell.org> #8904: haddock displays GHC.Types.Coercible as a datatype ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHC API | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- ...and not as a class. Appeared after #8894 was fixed. It is correct in Data.Coerce and GHC.Exts, so this is a minor issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 17:58:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 17:58:32 -0000 Subject: [GHC] #8894: Clean up `Coercible` plumbing In-Reply-To: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> References: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> Message-ID: <061.ce9006087ed13b932ae16b13c1545618@haskell.org> #8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8904 -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed * related: => #8904 Comment: Ok, pushed. The haddock/GHC API issue is at #8904. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 18:27:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 18:27:18 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF Message-ID: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF ------------------------------+-------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- The code generator unnecessarily spills and reloads function arguments if the scrutinee turns out to be already evaluated (i.e. has non-zero tag bits). Here's the beginning of a function body, taken from the `insert` function at https://github.com/tibbe/unordered- containers/blob/master/Data/HashMap/Base.hs#L303: {{{ c2wQ: // stack check if ((Sp + -72) < SpLim) goto c2wR; else goto c2wS; c2wR: // stack check failure R1 = PicBaseReg + $wpoly_go_closure; I64[Sp - 40] = R2; I64[Sp - 32] = R3; P64[Sp - 24] = R4; I64[Sp - 16] = R5; P64[Sp - 8] = R6; Sp = Sp - 40; call (I64[BaseReg - 8])(R1) args: 48, res: 0, upd: 8; c2wS: // stack check success I64[Sp - 40] = PicBaseReg + block_c2my_info; // return addr for eval R1 = R6; // t I64[Sp - 32] = R2; // spill: s I64[Sp - 24] = R3; // spill: x P64[Sp - 16] = R4; // spill: k I64[Sp - 8] = R5; // spill: h Sp = Sp - 40; if (R1 & 7 != 0) goto c2my; else goto c2mz; // eval check of t c2mz: // eval check failed call (I64[R1])(R1) returns to c2my, args: 8, res: 8, upd: 8; // eval c2my: // eval check succeeded _s2b1::I64 = I64[Sp + 8]; // reload: h _s2b2::I64 = I64[Sp + 16]; // reload: k _s2b3::P64 = P64[Sp + 24]; // reload: x _s2b4::I64 = I64[Sp + 32]; // reload: s switch [0 .. 4] (R1 & 7 - 1) { case 0 : goto c2wK; case 1 : goto c2wL; case 2 : goto c2wM; case 3 : goto c2wN; case 4 : goto c2wO; } }}} It seems to me that all the spills/reloads could be pushed into the `c2mz` block. The `c2my` block, in its current form, is reused for a heap check failure case, so the heap check most likely will have to do its own spilling/reloading. However, since the scrutinee not having tags bit or the eval checking failing is not the common case, they should be out of the common path. If it matters the data type is spine strict so GHC should have enough information to know that the common case (e.g. self-recursive calls) already have an evaluated argument (although there might be an indirection in some cases). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 18:32:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 18:32:38 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF In-Reply-To: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> References: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> Message-ID: <059.d382e82c260ca0247341af37fc2b892d@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): If code duplication is a concern, perhaps the spill and load code could be give their own basic blocks that could be jumped to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 18:43:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 18:43:17 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF In-Reply-To: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> References: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> Message-ID: <059.09430c005bfecd4b7b799392a52c6677@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): The register allocator doesn't tidy this up either: {{{ #!asm _c2wS: leaq block_c2my_info(%rip),%rax movq %rax,-40(%rbp) movq %r9,%rbx movq %r14,-32(%rbp) movq %rsi,-24(%rbp) movq %rdi,-16(%rbp) movq %r8,-8(%rbp) addq $-40,%rbp testq $7,%rbx jne _c2my }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 18:55:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 18:55:51 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF In-Reply-To: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> References: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> Message-ID: <059.468e3bcc4b88e1eb4dc904e0eb1df73f@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by carter): @tibbe, is this possibly related to https://ghc.haskell.org/trac/ghc/ticket/8048 ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 19:33:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 19:33:32 -0000 Subject: [GHC] #8048: Register spilling produces ineffecient/highly contending code In-Reply-To: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> References: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> Message-ID: <061.e1e0af1457425b66101fa3665f7236b9@haskell.org> #8048: Register spilling produces ineffecient/highly contending code -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler (NCG) | Version: 7.6.3 Resolution: | Keywords: register Operating System: Unknown/Multiple | allocator spill Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) * component: Compiler => Compiler (NCG) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 19:36:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 19:36:16 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF In-Reply-To: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> References: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> Message-ID: <059.55e1404f92fc44e65f89ceba5be492ae@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): Yeah, it is somewhat by design (to get smaller code), but you're quite right that we should have faster code for the common case. I'll look into it and see if we can improve things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 19:48:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 19:48:02 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF In-Reply-To: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> References: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> Message-ID: <059.073b24d2f829192c68fad6f6602cf7f3@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): If the stack change code can be moved out of the way, couldn't the switch statements also include checking the tags bit for 0? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 20:03:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 20:03:30 -0000 Subject: [GHC] #8904: haddock displays GHC.Types.Coercible as a datatype In-Reply-To: <046.9569975d8a2129291c9ce95dd884053d@haskell.org> References: <046.9569975d8a2129291c9ce95dd884053d@haskell.org> Message-ID: <061.d6acc42f1ba80a37d058c1b6b3947fd1@haskell.org> #8904: haddock displays GHC.Types.Coercible as a datatype -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHC API | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Fuuzetsu): Any chance for a smaller test case than something in base? base is kind of a pain to work against. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 20:07:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 20:07:25 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF In-Reply-To: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> References: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> Message-ID: <059.0f58c5a62632fb3c12347c5e94464360@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): To provide some motivation, I've included the full Cmm of the '''common''' path below. Every line that starts with `>` is what I would considered unnecessary spills/loads for this path: {{{ c2wQ: // stack check if ((Sp + -72) < SpLim) goto c2wR; else goto c2wS; c2wS: // stack check success > I64[Sp - 40] = PicBaseReg + block_c2my_info; // return addr for eval R1 = R6; // t > I64[Sp - 32] = R2; // spill: s > I64[Sp - 24] = R3; // spill: x > P64[Sp - 16] = R4; // spill: k > I64[Sp - 8] = R5; // spill: h Sp = Sp - 40; if (R1 & 7 != 0) goto c2my; else goto c2mz; // eval check of t c2my: // eval check succeded > _s2b1::I64 = I64[Sp + 8]; // reload: h > _s2b2::I64 = I64[Sp + 16]; // reload: k > _s2b3::P64 = P64[Sp + 24]; // reload: x > _s2b4::I64 = I64[Sp + 32]; // reload: s switch [0 .. 4] (R1 & 7 - 1) { case 0 : goto c2wK; case 1 : goto c2wL; case 2 : goto c2wM; case 3 : goto c2wN; case 4 : goto c2wO; } c2wN: // Full _s2cx::P64 = P64[R1 + 4]; // ary _s2cy::I64 = (_s2b1::I64 >> _s2b4::I64) & 15; // i _s2cC::P64 = P64[(_s2cx::P64 + 24) + (_s2cy::I64 << 3)]; // st I64[Sp] = PicBaseReg + block_c2nJ_info; // return addr R6 = _s2cC::P64; // arg: st R5 = _s2b4::I64 + 4; // arg: s + bitsPerSubkey R4 = _s2b3::P64; // arg: x R3 = _s2b2::I64; // arg: k R2 = _s2b1::I64; // arg: h P64[Sp + 8] = _s2cC::P64; // spill: st I64[Sp + 16] = _s2cy::I64; // spill: i P64[Sp + 24] = _s2cx::P64; // spill: ary P64[Sp + 32] = R1; // spill: t (only used in uncommon branch) call $wpoly_go_info(R6, R5, R4, R3, R2) returns to c2nJ, args: 8, res: 8, upd: 8; c2nJ: > _s2b6::P64 = P64[Sp + 32]; // reload: t (only used in uncommon branch) _s2cx::P64 = P64[Sp + 24]; // reload: ary _s2cy::I64 = I64[Sp + 16]; // reload: i _s2cE::P64 = R1; _s2cF::I64 = R1 == P64[Sp + 8]; if (_s2cF::I64 != 1) goto c2nR; else goto c2AE; c2nR: // heap check Hp = Hp + 176; if (Hp > I64[BaseReg + 856]) goto c2AB; else goto c2AA; c2AA: // heap check success I64[Hp - 168] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info at GOTPCREL]; I64[Hp - 160] = 16; I64[Hp - 152] = 17; _c2nT::I64 = Hp - 168; call MO_Memcpy(_c2nT::I64 + 24, _s2cx::P64 + 24, 128, 8); P64[(_c2nT::I64 + 24) + (_s2cy::I64 << 3)] = _s2cE::P64; I64[_c2nT::I64] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info at GOTPCREL]; I8[(_c2nT::I64 + 24) + ((I64[_c2nT::I64 + 8] << 3) + (_s2cy::I64 >> 7))] = 1 :: W8; I64[_c2nT::I64] = I64[PicBaseReg + stg_MUT_ARR_PTRS_FROZEN0_info at GOTPCREL]; I64[Hp - 8] = PicBaseReg + Full_con_info; I64[Hp] = _c2nT::I64; R1 = Hp - 4; Sp = Sp + 40; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; // return }}} The main body of this function, except for the recursive call, is in the last block, `c2AA`. Quite of bit of time is spent on "administrative" things. Also note that there are a bunch of static arguments passed around (`x`, `k`, and `h`). I will try to see what the Cmm looks like if I manually perform a static argument transform on this code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 20:13:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 20:13:26 -0000 Subject: [GHC] #8904: haddock displays GHC.Types.Coercible as a datatype In-Reply-To: <046.9569975d8a2129291c9ce95dd884053d@haskell.org> References: <046.9569975d8a2129291c9ce95dd884053d@haskell.org> Message-ID: <061.32e11a71764cfcbdd8b59ee98511c89f@haskell.org> #8904: haddock displays GHC.Types.Coercible as a datatype -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHC API | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): It?s in `ghc-prim`, not in base, if that helps :-) Otherwise, no: You need something that exports a datatype that GHC internally turns into a constraint, nothing you can have separate of GHC and ghc-prim, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 22:55:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 22:55:18 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF In-Reply-To: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> References: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> Message-ID: <059.ebf6e9167df938460e31e49e1f2ca2f5@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): I attached a patch you can try. It definitely increases code size, but I'd be interested how much benefit it gives in your benchmarks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 16 23:15:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Mar 2014 23:15:05 -0000 Subject: [GHC] #8906: rewrite arrow form in type signature sometimes leads to exception, sometimes not Message-ID: <047.ca98061e7ebf3fd8265b91d2e59a1afa@haskell.org> #8906: rewrite arrow form in type signature sometimes leads to exception, sometimes not ----------------------------------+--------------------------------- Reporter: thaumkid | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- Seems like the arrow form in signatures should either be restricted further or made more flexible. {{{ > let a = id :: ((->) a) a > a 2 *** Exception: expectJust cpeBody:collect_args > :t a a :: (->) a a }}} {{{ > let a = id :: (->) a a > a 2 2 > :t a a :: a -> a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 02:02:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 02:02:37 -0000 Subject: [GHC] #8906: rewrite arrow form in type signature sometimes leads to exception, sometimes not In-Reply-To: <047.ca98061e7ebf3fd8265b91d2e59a1afa@haskell.org> References: <047.ca98061e7ebf3fd8265b91d2e59a1afa@haskell.org> Message-ID: <062.935981904e29f37fd66020987c604149@haskell.org> #8906: rewrite arrow form in type signature sometimes leads to exception, sometimes not ---------------------------------+---------------------------------- Reporter: thaumkid | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: GHCi | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Thanks for the report; it's a duplicate of #7903/#8492. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 05:50:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 05:50:01 -0000 Subject: [GHC] #8892: Ghc panics (variable not found) In-Reply-To: <045.3e8c8bb464ddd3c1e55d55ced44d87a2@haskell.org> References: <045.3e8c8bb464ddd3c1e55d55ced44d87a2@haskell.org> Message-ID: <060.9aaad1f75aa34505d3faa14b8d8d2e3c@haskell.org> #8892: Ghc panics (variable not found) ---------------------------------------+----------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by jwlato): Thanks Simon, with `-dcore-lint` I see *many* warnings like `INLINE binder is (non-rule) loop breaker:`, but they seem so common (and some are clearly unrelated) that I don't think it's relevant. In the module that errors, I see only this: {{{ *** Core Lint errors : in result of Simplifier *** : Warning: [in body of letrec with binders a125_ajLr3 :: GHC.Prim.State# (Control.Monad.Primitive.PrimState (GHC.ST.ST s2_ajLm9)) -> (# GHC.Prim.State# (Control.Monad.Primitive.PrimState (GHC.ST.ST s2_ajLm9)), () #)] foldlM'_loop_ajLpg :: Data.Vector.Fusion.Stream.Monadic.SPEC -> GHC.Types.Int -> GHC.Types.Int -> GHC.ST.ST s2_ajLm9 GHC.Types.Int [LclId, Arity=4, Str=DmdType] is out of scope : Warning: [in body of letrec with binders a125_ajLr3 :: GHC.Prim.State# (Control.Monad.Primitive.PrimState (GHC.ST.ST s2_ajLm9)) -> (# GHC.Prim.State# (Control.Monad.Primitive.PrimState (GHC.ST.ST s2_ajLm9)), () #)] foldlM'_loop_ajLpg :: Data.Vector.Fusion.Stream.Monadic.SPEC -> GHC.Types.Int -> GHC.Types.Int -> GHC.ST.ST s2_ajLm9 GHC.Types.Int [LclId, Arity=4, Str=DmdType] is out of scope }}} followed by the simplifier output. And indeed, there is a `case foldlM'_loop_ajLpg something of`, but no binding for `foldlM'_loop_ajLpg6`. At least I've found the offending function now, so I may be able to isolate a test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 08:10:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 08:10:56 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.d86bb8ffdeae20db03b9e828a8d75162@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by jstolarek): * owner: => jstolarek Comment: Looking into this at the moment. I have a few interesting findings, will post later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 08:29:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 08:29:43 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF In-Reply-To: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> References: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> Message-ID: <059.c61c09a2e34b1ea02a1a7f3c0a903aa0@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): I'm puzzled by why the spill code is before the eval check rather than after. Before spilling etc I'd expect to see: {{{ ... if goto Leval else goto Ldone Leval: call (I64[R1])(R1) returns to Ldone Ldone: // Now it's evaluated }}} Then the stack-layout stuff should insert spills and reloads ''around the call'', but not interfering with the fast path. So how come the spills affect the fast path at all? Is there some special code-size-saving magic in the code generator? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 08:34:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 08:34:56 -0000 Subject: [GHC] #8892: Ghc panics (variable not found) In-Reply-To: <045.3e8c8bb464ddd3c1e55d55ced44d87a2@haskell.org> References: <045.3e8c8bb464ddd3c1e55d55ced44d87a2@haskell.org> Message-ID: <060.9ff8c11a6d0a8e6c4e0132f6c7fef1c1@haskell.org> #8892: Ghc panics (variable not found) ---------------------------------------+----------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by simonpj): Yes, I'm sorry about the loop-breaker warnings -- you can safely ignore those. GHC should never produce an out-of-scope variable, so this is clearly a bug. Maybe you can try this: * Revert to -O not -O2 * Remove individual optimsations, eg `-fno-full-laziness`, `-fno-spec- constr` etc * Remove code from the module being compiled so that it is as small as possible. * And then compile with `-dverbose-core2core -ddump-occur-anal -ddump- inlinings -ddump-rule-rewrites` (as well as `-dcore-lint` and save the output somewhere I can see it. Best of all would be to get a test case I can reproduce here. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 08:46:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 08:46:14 -0000 Subject: [GHC] #8894: Clean up `Coercible` plumbing In-Reply-To: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> References: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> Message-ID: <061.3d54d38b4632a04305d75ad038244152@haskell.org> #8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8904 -------------------------------------+------------------------------------ Comment (by simonpj): Thanks for doing this. I think it's clearly better. Actually I think we can go two steps better still. * Suppose the declaration of `Coercible` in `GHC.Types` is actually {{{ class Coercible a b }}} Then, when compiling `GHC.Types`, the code we produce for the declaration will still include code for the data constructor of the dictionary (with no value fields), although with a different name, built with `mkClassDataConOcc`. But that is fine, provided we adjust the `coercibleDataConName` in `TysWiredIn` to match; and that would probably be a good piece of consistency anyway. * Once that is done, we can declare `coerce` in `GHC.Types` rather than `GHC.Prim`: {{{ coerce :: Coercible a b => a -> b coerce = error "You should not be calling me" }}} * And it might be possible to move both these definitions to `Data.Coerce` which would be better still. Haddock will display the right result for every module, and the documentation will all be in one place in `Data.Coerce`. All this should work because `Coercible` and `coerce` are "wired-in" things, and so they are never written to an interface file. Importing modules just use GHC's built-in knowledge of them. It's fine provided the code generated by compiling the definitions matches the wired-in knowledge. Does that make sense? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 08:51:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 08:51:01 -0000 Subject: [GHC] #8894: Clean up `Coercible` plumbing In-Reply-To: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> References: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> Message-ID: <061.bf07f76292c29d7ab2ee35b49f50e258@haskell.org> #8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8904 -------------------------------------+------------------------------------ Changes (by nomeata): * status: closed => new * resolution: fixed => Comment: > All this should work because Coercible and coerce are "wired-in" things, and so they are never written to an interface file Woudn?t they get written to `GHC.Types` hi interface? Also, would the info table for `MkCoerce` (or however it would be called then) without fields match ours? This requires knowledge of the RTS that I don?t have, so I felt safer with this approach, but if you think it might work, it?s worth a try. (I?d be tempted to put them in a module `GHC.Coerce` in `ghc-prim` and have `Data.Coerce` in `base` re-export it, to slowly work towards having no magic in base, but that is a minor point.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 08:51:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 08:51:09 -0000 Subject: [GHC] #8894: Clean up `Coercible` plumbing In-Reply-To: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> References: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> Message-ID: <061.f4cd3404af30bbafdc902c2ab0177245@haskell.org> #8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8904 -------------------------------------+------------------------------------ Changes (by nomeata): * owner: => nomeata -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 08:51:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 08:51:13 -0000 Subject: [GHC] #8889: GHCI reports nasty type signatures In-Reply-To: <050.8be9da2264f8ee0e1a82a03f55af16c9@haskell.org> References: <050.8be9da2264f8ee0e1a82a03f55af16c9@haskell.org> Message-ID: <065.5faa6ecaae86fb6387cb64103a4c5ba6@haskell.org> #8889: GHCI reports nasty type signatures --------------------------------+---------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------+---------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7a7af1ffc48f605cf365faf8fcef31ef4f13822b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7a7af1ffc48f605cf365faf8fcef31ef4f13822b" Unflatten the constraints of an inferred types (Trac #8889) There was even a comment to warn about this possiblity, and it finally showed up in practice! This patch fixes it quite nicely, with commens to explain. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 08:51:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 08:51:14 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.7408c92a32b1416280b9ecd4d9aa3811@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a79613a75c7da0d3d225850382f0f578a07113b5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a79613a75c7da0d3d225850382f0f578a07113b5" Revert ad15c2, which causes Windows seg-faults (Trac #8834) We don't yet understand WHY commit ad15c2, which is to do with CmmSink, causes seg-faults on Windows, but it certainly seems to. So reverting it is a stop-gap, but we need to un-block the 7.8 release. Many thanks to awson for identifying the offending commit. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 08:53:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 08:53:30 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.f48d304c7b0ab811ffd2b611b258fae8@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by jstolarek): Simon, could we get a day or two more for this one? I'm at the very moment writing a summary of what I've learned so far and I believe it will get us very close to fixing this bug properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 08:57:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 08:57:33 -0000 Subject: [GHC] #8894: Clean up `Coercible` plumbing In-Reply-To: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> References: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> Message-ID: <061.c3e419f936cf06da835fdf0722b463f6@haskell.org> #8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8904 -------------------------------------+------------------------------------ Comment (by simonpj): No, wired-in things are never written to any interface file. GHC already knows all about them, so there's not point in serialising them. Yes, the data constructor would match. (Of course that requires a `Note`.) By declaring a data type and using it as a class we are already being naughty in a different way, so it's really no worse. I have not thought about "no magic in base", although I have not objection. If that's the route you go, be sure to document it as the reason (in `GHC.Coerce`) so that we know in five years time. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 08:59:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 08:59:20 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.8d6322986a8fb85e4f097b775b4778d1@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonpj): I don't think Austin is planning to make the final release in the next day or two, so yes, please go ahead. My reversion was just to un-glue the Windows builds which otherwise are totally stuck. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 09:02:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 09:02:12 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.de944d5ec2a3beab7685e6e44cac0331@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by jstolarek): Replying to [comment:50 jstolarek]: > Simon, could we get a day or two more for this one? I'm at the very moment writing a summary of what I've learned so far and I believe it will get us very close to fixing this bug properly. According to my experiments you can fix Windows build easily by changing definition of `isTrivial` in !CmmSink to: {{{ isTrivial :: CmmExpr -> Bool isTrivial (CmmReg (CmmLocal _)) = True isTrivial (CmmLit _) = True isTrivial _ = False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 09:04:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 09:04:40 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.19cce5042970b66fd119ff9bd0f2a173@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonpj): Fine. But reversion works fine too, right? I'm not suggesting abandoning the `CmmSink` improvements, once you figure out what is going on. If meanwhile you want to re-apply, and make the smaller change you propose, that's fine with me Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 09:20:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 09:20:17 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.5f2c6052f322b07879ff8ccea281e59b@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): Replying to [comment:52 jstolarek]: > According to my experiments you can fix Windows build easily by changing definition of `isTrivial` in !CmmSink to: > > {{{ > isTrivial :: CmmExpr -> Bool > isTrivial (CmmReg (CmmLocal _)) = True > isTrivial (CmmLit _) = True > isTrivial _ = False > }}} Hmm, on my experiments changing `isTrivial` to {{{ isTrivial :: CmmExpr -> Bool isTrivial (CmmReg (CmmLocal _)) = True -- isTrivial (CmmLit _) = True isTrivial _ = False }}} alone was not enough to fix things - see my comment 19. So doing `CmmLit` branch `True` makes this work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 09:37:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 09:37:00 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.c62c77046df6ce57cf3b621745e2342f@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by jstolarek): Here's a quick summary of what I've learned: * As we noticed earlier the bug does not happen when only `-O1` is used. Enabling `-O1 -fspec-constr` triggers the bug, but with `-O1 -fspec-constr -fno-cmm-sink` everything works perfectly fine. * I believe that Simon Marlow correctly identified offending piece of Cmm code, although my knowledge of calling conventions doesn't allow me to say why that piece of code is incorrect. Here's how that piece of code looks only with `-O1`: {{{ c2h9: _s2cz::I64 = _s2ct::I64 + _s2cv::I64; (_s2cE::I64) = call "ccall" arg hints: [PtrHint, `signed',] result hints: [PtrHint] memchr(_s2cz::I64, 10, _s2cw::I64); if (_s2cE::I64 == 0) goto c2h4; else goto c2h5; c2h4: Hp = Hp - 32; _s2cH::P64 = Data.Maybe.Nothing_closure+1; goto s2cF; c2h5: I64[Hp - 24] = GHC.Types.I#_con_info; I64[Hp - 16] = _s2cE::I64 - _s2cz::I64; I64[Hp - 8] = Data.Maybe.Just_con_info; P64[Hp] = Hp - 23; _s2cH::P64 = Hp - 6; goto s2cF; s2cF: call MO_Touch(_s2cu::P64); I64[Sp - 40] = c2f7; R1 = _s2cH::P64; I64[Sp - 32] = _s2ct::I64; P64[Sp - 24] = _s2cu::P64; I64[Sp - 16] = _s2cv::I64; I64[Sp - 8] = _s2cw::I64; Sp = Sp - 40; if (R1 & 7 != 0) goto c2f7; else goto c2f8; }}} It looks that sinking is not performed here for some reason that I was unable to figure out. Enabling `-O1 -fspec-constr` changes the above code to: {{{ c2hi: _s2dr::I64 = R5; _s2du::I64 = R2 + R4; _c2fB::I64 = R5; (_s2dz::I64) = call "ccall" arg hints: [PtrHint, `signed',] result hints: [PtrHint] memchr(_s2du::I64, 10, _c2fB::I64); if (_s2dz::I64 == 0) goto c2hd; else goto c2he; c2hd: call MO_Touch(R3); I64[Hp - 128] = Data.ByteString.Internal.PS_con_info; P64[Hp - 120] = R3; I64[Hp - 112] = R2; I64[Hp - 104] = R4; I64[Hp - 96] = _s2dr::I64; I64[Hp - 88] = :_con_info; P64[Hp - 80] = Hp - 127; P64[Hp - 72] = GHC.Types.[]_closure+1; _c2h8::P64 = Hp - 86; Hp = Hp - 72; R1 = _c2h8::P64; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; }}} Enabling `-fspec-constr` sinks R2, R3 and R4 past the call to `memchr` (which BTW. is consistent with awson's earlier observation that segfault is happening somewhere around the call to `memchr`). * Changing definition of `isTrivial` from: {{{ isTrivial :: CmmExpr -> Bool isTrivial (CmmReg _) = True isTrivial (CmmLit _) = True isTrivial _ = False }}} to {{{ isTrivial :: CmmExpr -> Bool isTrivial (CmmReg (CmmLocal _)) = True isTrivial (CmmLit _) = True isTrivial _ = False }}} makes the bug disappear. I believe this is not a proper fix, because it only hides the bug - global registers should be safe to inline! The above Cmm code changes to (`-O1 -fspec-constr` enabled): {{{ 2hi: _s2du::I64 = _s2do::I64 + _s2dq::I64; (_s2dz::I64) = call "ccall" arg hints: [PtrHint, `signed',] result hints: [PtrHint] memchr(_s2du::I64, 10, _s2dr::I64); if (_s2dz::I64 == 0) goto c2hd; else goto c2he; 2hd: call MO_Touch(_s2dp::P64); I64[Hp - 128] = Data.ByteString.Internal.PS_con_info; P64[Hp - 120] = _s2dp::P64; I64[Hp - 112] = _s2do::I64; I64[Hp - 104] = _s2dq::I64; I64[Hp - 96] = _s2dr::I64; I64[Hp - 88] = :_con_info; P64[Hp - 80] = Hp - 127; P64[Hp - 72] = GHC.Types.[]_closure+1; _c2h8::P64 = Hp - 86; Hp = Hp - 72; R1 = _c2h8::P64; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; }}} * Since it looks like the problem is caused by sinking registers past the unsafe foreign call to `memchr` I changed the definition of `foreignTargetRegs` in the instance definition of `DefinerOfRegs` in `CmmNode` (lines 345-346) from: {{{ foreignTargetRegs (ForeignTarget _ (ForeignConvention _ _ _ CmmNeverReturns)) = [] foreignTargetRegs _ = activeCallerSavesRegs }}} to: {{{ foreignTargetRegs (ForeignTarget _ (ForeignConvention _ _ _ CmmNeverReturns)) = [] foreignTargetRegs _ = activeRegs }}} This says that any global register can be clobbered by unsafe foreign call, in practice preventing any global register sinking past such calls. After this change the Cmm dump looks like this (again, `-O1 -fspec-constr` enabled): {{{ c2hi: _s2dr::I64 = R5; _s2dq::I64 = R4; _s2dp::P64 = R3; _s2do::I64 = R2; _s2du::I64 = R2 + R4; _c2fB::I64 = R5; (_s2dz::I64) = call "ccall" arg hints: [PtrHint, `signed',] result hints: [PtrHint] memchr(_s2du::I64, 10, _c2fB::I64); if (_s2dz::I64 == 0) goto c2hd; else goto c2he; c2hd: call MO_Touch(_s2dp::P64); I64[Hp - 128] = Data.ByteString.Internal.PS_con_info; P64[Hp - 120] = _s2dp::P64; I64[Hp - 112] = _s2do::I64; I64[Hp - 104] = _s2dq::I64; I64[Hp - 96] = _s2dr::I64; I64[Hp - 88] = :_con_info; P64[Hp - 80] = Hp - 127; P64[Hp - 72] = GHC.Types.[]_closure+1; _c2h8::P64 = Hp - 86; Hp = Hp - 72; R1 = _c2h8::P64; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; }}} Based on above facts I believe that the problem lies in incorrect definition of caller saves registers. On the other hand I believe we are defining R2, R3 and R4 as callee-saves according to the specification. So there is still possibility that the bug lies somewhere else. At this point I am stuck. I will attach Cmm dumps in a moment so others can verify my findings. All dumps are for the `BugIso` module - they don't include boilerplate from `Main`. Replying to [comment:54 awson]: > Hmm, on my experiments changing `isTrivial` to > {{{ > isTrivial :: CmmExpr -> Bool > isTrivial (CmmReg (CmmLocal _)) = True > -- isTrivial (CmmLit _) = True > isTrivial _ = False > }}} > alone was not enough to fix things - see my comment 19. So doing `CmmLit` branch `True` makes this work? On my experiments the change of `isTrivial` that you just posted is enough to prevent the segmentation fault. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 09:49:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 09:49:00 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.9dea5a8b909d78c3bb9c46a86d184936@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature -------------------------------------+------------------------------------ Reporter: Blaisorblade | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by jstolarek: Old description: > I assume that if a program typechecks, adding any missing top-level > signature inferred by GHC should be a meaning-preserving transformation > and yield a new program which typechecks. (Please correct me if I'm > wrong). But I've found a violation: namely, given enough other extensions > (I think TypeFamilies is the relevant one), GHC will infer signatures > which would require FlexibleContexts! Arguably, either those signatures > should be rejected in the first place with a special error message (since > GHC is not supposed to show code the user didn't write in error > messages), or TypeFamilies should imply FlexibleContexts (or a restricted > form which is sufficient for what TypeFamilies produces - namely, > constraints can contain type families in place of raw type variables). > > Here's an example - without FlexibleContexts it does not typecheck , > unless you comment out the signature of fold and unfold. Those signatures > where produced by GHCi (with :browse) in the first-place. > > {{{#!haskell > {-# LANGUAGE TypeFamilies, DeriveFunctor, NoMonomorphismRestriction #-} > -- , FlexibleContexts > data Fix f = In { out :: f (Fix f) } > > data Expr = Const Int | Add Expr Expr > > data PFExpr r = ConstF Int | AddF r r deriving Functor > type Expr' = Fix PFExpr > > class Regular0 a where > deepFrom0 :: a -> Fix (PF a) > deepTo0 :: Fix (PF a) -> a > type family PF a :: * -> * > > type instance PF Expr = PFExpr > > instance Regular0 Expr where > deepFrom0 = In . (\expr -> > case expr of > Const n -> ConstF n > Add a b -> AddF (deepFrom0 a) (deepFrom0 b)) > deepTo0 = > (\expr' -> > case expr' of > ConstF n -> Const n > AddF a b -> Add (deepTo0 a) (deepTo0 b)) . out > > class Regular a where > from :: a -> PF a a > to :: PF a a -> a > > instance Regular Expr where > from expr = > case expr of > Const n -> ConstF n > Add a b -> AddF a b > to expr' = > case expr' of > ConstF n -> Const n > AddF a b -> Add a b > > -- But in fact, the construction is just an instance of fold. > fold :: (Functor (PF a), Regular a) => (PF a b -> b) -> a -> b > unfold :: (Functor (PF b), Regular b) => (a -> PF b a) -> a -> b > fold f = f . fmap (fold f) . from > unfold f = to . fmap (unfold f) . f > }}} New description: I assume that if a program typechecks, adding any missing top-level signature inferred by GHC should be a meaning-preserving transformation and yield a new program which typechecks. (Please correct me if I'm wrong). But I've found a violation: namely, given enough other extensions (I think !TypeFamilies is the relevant one), GHC will infer signatures which would require !FlexibleContexts! Arguably, either those signatures should be rejected in the first place with a special error message (since GHC is not supposed to show code the user didn't write in error messages), or !TypeFamilies should imply !FlexibleContexts (or a restricted form which is sufficient for what !TypeFamilies produces - namely, constraints can contain type families in place of raw type variables). Here's an example - without !FlexibleContexts it does not typecheck , unless you comment out the signature of fold and unfold. Those signatures where produced by GHCi (with :browse) in the first-place. {{{#!haskell {-# LANGUAGE TypeFamilies, DeriveFunctor, NoMonomorphismRestriction #-} -- , FlexibleContexts data Fix f = In { out :: f (Fix f) } data Expr = Const Int | Add Expr Expr data PFExpr r = ConstF Int | AddF r r deriving Functor type Expr' = Fix PFExpr class Regular0 a where deepFrom0 :: a -> Fix (PF a) deepTo0 :: Fix (PF a) -> a type family PF a :: * -> * type instance PF Expr = PFExpr instance Regular0 Expr where deepFrom0 = In . (\expr -> case expr of Const n -> ConstF n Add a b -> AddF (deepFrom0 a) (deepFrom0 b)) deepTo0 = (\expr' -> case expr' of ConstF n -> Const n AddF a b -> Add (deepTo0 a) (deepTo0 b)) . out class Regular a where from :: a -> PF a a to :: PF a a -> a instance Regular Expr where from expr = case expr of Const n -> ConstF n Add a b -> AddF a b to expr' = case expr' of ConstF n -> Const n AddF a b -> Add a b -- But in fact, the construction is just an instance of fold. fold :: (Functor (PF a), Regular a) => (PF a b -> b) -> a -> b unfold :: (Functor (PF b), Regular b) => (a -> PF b a) -> a -> b fold f = f . fmap (fold f) . from unfold f = to . fmap (unfold f) . f }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 10:15:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 10:15:02 -0000 Subject: [GHC] #8048: Register spilling produces ineffecient/highly contending code In-Reply-To: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> References: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> Message-ID: <061.fff2fd4384c7b25f7ed0a330794cbace@haskell.org> #8048: Register spilling produces ineffecient/highly contending code -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.6.3 Resolution: | Keywords: register Operating System: Unknown/Multiple | allocator spill Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by schyler): * component: Compiler (NCG) => Compiler Comment: Actually simon, I was able to reproduce this with LLVM also and carter can confirm. Interestingly, when we fiddled with some flags like -march=native and such, llvm seemed to bandaid it somehow by using mmx where the rotation happened properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 10:37:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 10:37:33 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.01c83793bfde2c4c83d42ef58b8d5e15@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonpj): Interesting; good progress. * Can you (by experiment) find which of registers is causing the problem. You fixed it by making them ''all'' caller saves, but that might be more than what's needed. * You say "It looks that sinking is not performed here for some reason that I was unable to figure out". I suspect it'd really be worth figuring this out. Maybe it's important! * You hypothesise that the C procedure `memchr` is destroying a callee- saves register. Might it be possible to test this hypothesis directly? For example, make the Haskell code call `my_memchr` instead, and handwrite `my_memchr` in assembly code, so that it saves all the registers (in a static location), calls the real `memchr`, and then checks whether the registers have changed. That would absolutely confirm that a claimed callee-saves register is being destroyed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 10:52:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 10:52:25 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.ba96cb1646872454a6bcfd6e85692333@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature -------------------------------------+------------------------------------ Reporter: Blaisorblade | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by jstolarek): Replying to [comment:1 simonpj]: > if someone would like to have a go it would not be hard and I could offer guidance. I'd like to tackle this one. Guidance will be really appreciated. I reduced the test case to this snippet of code: {{{ {-# LANGUAGE TypeFamilies, DeriveFunctor, NoMonomorphismRestriction #-} -- , FlexibleContexts module T8883 where type family PF a :: * -> * class Regular a where from :: a -> PF a a -- But in fact, the construction is just an instance of fold. --fold :: (Functor (PF a), Regular a) => (PF a b -> b) -> a -> b fold f = f . fmap (fold f) . from }}} So how should GHC behave for this code? Reject it because !FlexibleContexts extension is not enabled? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 11:16:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 11:16:02 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.8b564bb02942a8dce1420f62a7b95059@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): Is there maybe a problem under windows with "nm -P"? I cannot test it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 13:03:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 13:03:24 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.45ef76e717db3fbdce2f41a3fa2bffca@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by kgardas): On Windows IIRC mingw tools are used which means IMHO GNU nm but I'm not able to test that neither... Are you able to change your patch to git patch? If not, I may try to find the time to do that... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 13:38:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 13:38:34 -0000 Subject: [GHC] #8894: Clean up `Coercible` plumbing In-Reply-To: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> References: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> Message-ID: <061.2dd55a81794839c24173dd5c4e02c3d0@haskell.org> #8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8904 -------------------------------------+------------------------------------ Comment (by simonpj): I'm getting this: {{{ typecheck/should_fail TcCoercibleFail [stderr mismatch] (normal) typecheck/should_fail TcCoercibleFail2 [stderr mismatch] (normal) typecheck/should_fail TcCoercibleFail3 [stderr mismatch] (normal) }}} The error is {{{ +TcCoercibleFail.hs:3:26: + Module ?GHC.Prim? does not export ?Coercible? }}} And indeed `GHC.Prim` doesn't export `Coercible` any more. Did you validate? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 13:43:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 13:43:40 -0000 Subject: [GHC] #8894: Clean up `Coercible` plumbing In-Reply-To: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> References: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> Message-ID: <061.c82a7d86bb36bb96094ce268348d2894@haskell.org> #8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8904 -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"7511d5bf708f38bbdf5733f42dc8a025c76cc684/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7511d5bf708f38bbdf5733f42dc8a025c76cc684" Fix validation issue due to Coercible move (#8894) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 13:43:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 13:43:54 -0000 Subject: [GHC] #8894: Clean up `Coercible` plumbing In-Reply-To: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> References: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> Message-ID: <061.8fe784b2f08345078345fc7e36ea910d@haskell.org> #8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8904 -------------------------------------+------------------------------------ Comment (by nomeata): No, I was a bad boy and lazy and thought I thought of everyting. Fixing the test cases to use the proper import point `Data.Coerce`. I would have noticed myself quicker if CI was useful at the moment, but there are other failures there waiting to be fixed for a few days now :-( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 13:51:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 13:51:12 -0000 Subject: [GHC] #8889: GHCI reports nasty type signatures In-Reply-To: <050.8be9da2264f8ee0e1a82a03f55af16c9@haskell.org> References: <050.8be9da2264f8ee0e1a82a03f55af16c9@haskell.org> Message-ID: <065.602c8c220a1d771d7054056568429893@haskell.org> #8889: GHCI reports nasty type signatures --------------------------------+---------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------+---------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0e2155ddb10f4ccf53e50064756cbc3ce7dd8832/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0e2155ddb10f4ccf53e50064756cbc3ce7dd8832" Test Trac #8889 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 13:52:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 13:52:23 -0000 Subject: [GHC] #8889: GHCI reports nasty type signatures In-Reply-To: <050.8be9da2264f8ee0e1a82a03f55af16c9@haskell.org> References: <050.8be9da2264f8ee0e1a82a03f55af16c9@haskell.org> Message-ID: <065.fe0a7c99d789bf713291d80a1818e7cd@haskell.org> #8889: GHCI reports nasty type signatures -------------------------------------------------+------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: GHCi | Version: Resolution: | 7.8.1-rc1 Operating System: Linux | Keywords: Type of failure: Other | Architecture: Test Case: | x86_64 (amd64) indexed_types/should_compile/T8889 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => merge * testcase: => indexed_types/should_compile/T8889 Comment: Excellent point, thank you. Fixed, with a regression test. Could be merged if there is time, but not a big deal. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 14:16:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 14:16:47 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.c3387be668ba62547409e2bb78f0a020@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): Please make a git patch and maybe extend the comment for the three formats: {{{ "_derivedConstantMAX_Vanilla_REG C b 0" Mac OS X "derivedConstantMAX_Vanilla_REG C 0000000b 0000000b" GNU "derivedConstantMAX_Vanilla_REG D 1 b" Solaris }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 14:25:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 14:25:54 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF In-Reply-To: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> References: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> Message-ID: <059.41985f68a91ad35ea89538848b2915ec@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): Simon - this is one of the things I changed when I worked on the new code generator. We could certainly investigate alternatives, the patch I attached earlier changes it but increases code size, I haven't done a full nofib run though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 14:30:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 14:30:33 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF In-Reply-To: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> References: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> Message-ID: <059.67d14a0024ef47a83cdb76ca658bd295@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): Oh, I just remembered one thing: when we are splitting proc points, then the "faster" sequence is actually worse because it generates two separate proc points, one for the call-return and one for the joint point. If we always do the copyout, then the call-return can be the join point too, which means we only need one proc point. However, we now don't generate proc points (when using the NCG), so we can probably use the faster sequence with only a small increase in code size. Someone needs to measure. And figure out whether we still want to do this when using LLVM or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 14:47:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 14:47:27 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.855827286d82c58718c79eb5e2a14c2a@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by jstolarek): Replying to [comment:56 simonpj]: > * Can you (by experiment) find which of registers is causing the problem? You fixed it by making them ''all'' caller saves, but that might be more than what's needed. > > * You hypothesise that the C procedure `memchr` is destroying a callee- saves register. Might it be possible to test this hypothesis directly? I looked at the implementation of `memchr` in `glibc` and it looks that on 64 bits it is touching `%rsi` and `%rdi` registers (our R3 and R4, respectively). I changed this definition in [[GhcFile(includes/stg/MachRegs.h)]]: {{{ #if !defined(mingw32_HOST_OS) #define CALLER_SAVES_R3 #define CALLER_SAVES_R4 #endif }}} to: {{{ #define CALLER_SAVES_R3 #define CALLER_SAVES_R4 }}} (ie. I removed the conditional) and the segfault has disappeared. Looking at the Cmm confirms that R3 are R4 are now not sunk past the call to `memchr`: {{{ c2hy: _s2dH::I64 = R5; _s2dG::I64 = R4; _s2dF::P64 = R3; _s2dK::I64 = R2 + R4; _c2fR::I64 = R5; (_s2dP::I64) = call "ccall" arg hints: [PtrHint, `signed',] result hints: [PtrHint] memchr(_s2dK::I64, 10, _c2fR::I64); if (_s2dP::I64 == 0) goto c2ht; else goto c2hu; c2ht: call MO_Touch(_s2dF::P64); I64[Hp - 128] = Data.ByteString.Internal.PS_con_info; P64[Hp - 120] = _s2dF::P64; I64[Hp - 112] = R2; I64[Hp - 104] = _s2dG::I64; I64[Hp - 96] = _s2dH::I64; I64[Hp - 88] = :_con_info; P64[Hp - 80] = Hp - 127; P64[Hp - 72] = GHC.Types.[]_closure+1; _c2ho::P64 = Hp - 86; Hp = Hp - 72; R1 = _c2ho::P64; }}} But one thing is not right here: {{{ #if !defined(mingw32_HOST_OS) #define CALLER_SAVES_R3 #define CALLER_SAVES_R4 #endif }}} Under 64 bit Windows `mingw32_HOST_OS` should not be declared and therefore R3 and R4 should be defined as caller saves! As a quick sanity check I wrote this small C program and compiled it with the in-tree mingw gcc: {{{ #include #if !defined(mingw32_HOST_OS) int x = 1; #else int x = 2; #endif int main() { printf("%d",x); } }}} This program prints `1` as expected. Does anyone have any idea what might be going on here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:01:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:01:08 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.48694d9743ed055ed88bff81d6f68ee6@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | 7.10.1 Resolution: | Version: 7.9 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple tests/simplCore/should_run/T2110.hs | Difficulty: Blocking: | Unknown | Blocked By: 8718 | Related Tickets: #2110 -------------------------------------------------+------------------------- Changes (by thoughtpolice): * version: 7.8.1-rc2 => 7.9 * milestone: 7.8.1 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:01:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:01:13 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.9b0155dade2f9d26169e84f81b185c26@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): I believe `mingw32_HOST_OS` is defined on 64-bit Windows. The full platform name is `x86_64-unknown-mingw32`, i.e. `mingw32` is the OS. You can test this with `ghc --info` on your 64-bit Windows GHC. If `memchr` is clobbering allegedly callee-saves registers, then either `memchr` is wrong, or our idea of what is callee-saves is wrong. Which is it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:18:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:18:53 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.04e45259deb1960254455c2d4b3fcf40@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): `glibc` is completely irrelevant here. `memchr` comes from system dll `msvcrt.dll` and I doubt it is wrong. So, perhaps, our idea of what is callee-saves is wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:20:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:20:08 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF In-Reply-To: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> References: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> Message-ID: <059.23727fb29695b229c87b8f2c5c304e12@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): @simonmar, I will try to benchmark your patch against my code tonight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:20:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:20:54 -0000 Subject: [GHC] #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" In-Reply-To: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> References: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> Message-ID: <063.554c867eb4019e624950fd06ef7003b6@haskell.org> #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" ----------------------------------+---------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonpj): Austin says he can't reproduce this on the latest MacOS, 10.9. Can anyone else? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:21:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:21:45 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.d7eeb3a921dacb97603f4a2c0cb08ce0@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by jstolarek): Replying to [comment:58 simonmar]: > I believe `mingw32_HOST_OS` is defined on 64-bit Windows. Doesn't the output from my small C program suggest otherwise? Am I missing something here? > You can test this with `ghc --info` on your 64-bit Windows GHC. {{{ (...) ,("target os","OSMinGW32") ,("target arch","ArchX86_64") (...) ,("Build platform","x86_64-unknown-mingw32") ,("Host platform","x86_64-unknown-mingw32") ,("Target platform","x86_64-unknown-mingw32") (...) }}} > glibc is completely irrelevant here. memchr comes from system dll msvcrt.dll and I doubt it is wrong. Hmm... I doubt we can take a look at source of that dll ;-) awson, could you verify that change in `MachRegs.h` fixes the bug? You might need to recompile GHC from scratch, at least I had to do so because the changes weren't picked up after partial recompilation. Note: don't test that with latest HEAD as it contains Simon's temporary fix based on your earlier patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:25:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:25:00 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF In-Reply-To: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> References: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> Message-ID: <059.a2da702466a160a7451c025042fb53a3@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): Replying to [comment:7 simonmar]: > I attached a patch you can try. It definitely increases code size, but I'd be interested how much benefit it gives in your benchmarks. I will try to benchmark the patch on my code tonight. Will you do a nofib run? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:33:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:33:38 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.4e9cc395f45a9b790797469992e0e6ee@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by refold): Replying to [comment:60 jstolarek]: > > glibc is completely irrelevant here. memchr comes from system dll msvcrt.dll and I doubt it is wrong. > > Hmm... I doubt we can take a look at source of that dll ;-) I believe that Microsoft ships the CRT source with Visual Studio. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:36:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:36:29 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.b79b2b952cf6087fadc1cc4f9fed590d@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonpj): Austin will try: * Re-applying the `CmmSink` patch * Adding R3 and R4 to the caller-saves register for 64-bit That would be a better fix, because if they really are caller-saves then reverting `CmmSink` won't necessarily cure everything. Still needs more investigation for the ultimate cause. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:42:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:42:25 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.f636c7d9c76693fa5c42b28868309127@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:42:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:42:47 -0000 Subject: [GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error In-Reply-To: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> References: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> Message-ID: <066.2899cdcb9e5b3c7151bcf7f859fad166@haskell.org> #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error -------------------------------------------------+------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: Priority: highest | closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: simplCore/should_compile/T8714 | x86_64 (amd64) Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:43:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:43:05 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.7bd77040dab0866e74d280717fe218de@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:43:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:43:45 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.34910cfb74f52bd419ca69b12600ecdb@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by jstolarek): Replying to [comment:61 refold]: > Replying to [comment:60 jstolarek]: > > > glibc is completely irrelevant here. memchr comes from system dll msvcrt.dll and I doubt it is wrong. > > > > Hmm... I doubt we can take a look at source of that dll ;-) > > I believe that Microsoft ships the CRT source with Visual Studio. Great. Does anyone have access to Visual Studio and could check the implementation of `memchr`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:44:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:44:28 -0000 Subject: [GHC] #8826: Allow more coercions in Safe Haskell In-Reply-To: <047.5c2eeb13a41e01da9bb6e46c88e0f15c@haskell.org> References: <047.5c2eeb13a41e01da9bb6e46c88e0f15c@haskell.org> Message-ID: <062.19c37e1f45df8609d332921f0dc49063@haskell.org> #8826: Allow more coercions in Safe Haskell -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:44:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:44:39 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.2883c912b33ed1563e0329e7fede7a94@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:46:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:46:27 -0000 Subject: [GHC] #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory In-Reply-To: <044.398377c33d022955e6b200df91088795@haskell.org> References: <044.398377c33d022955e6b200df91088795@haskell.org> Message-ID: <059.2de6d40bb950f5260cfd591566583810@haskell.org> #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory -----------------------------------+---------------------------------- Reporter: awson | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:47:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:47:12 -0000 Subject: [GHC] #8888: Document Coercible in user's guide In-Reply-To: <047.94c1acfb950684257c799730826cb077@haskell.org> References: <047.94c1acfb950684257c799730826cb077@haskell.org> Message-ID: <062.db5c5191822d82df6238b5e1e2524344@haskell.org> #8888: Document Coercible in user's guide -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:47:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:47:47 -0000 Subject: [GHC] #8884: Reifying closed type families is broken In-Reply-To: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> References: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> Message-ID: <062.5b3e7fe61e5215c93c235d74d4211ef6@haskell.org> #8884: Reifying closed type families is broken -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T8884 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:48:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:48:06 -0000 Subject: [GHC] #8878: Export runTcInteractive from TcRnDriver In-Reply-To: <047.6601d2f94bde1975c44c22d38170011e@haskell.org> References: <047.6601d2f94bde1975c44c22d38170011e@haskell.org> Message-ID: <062.e52a43e995d5c7bccdbc0fbf5af4619b@haskell.org> #8878: Export runTcInteractive from TcRnDriver -------------------------------+------------------------------------------- Reporter: holzensp | Owner: holzensp Type: feature | Status: closed request | Milestone: 7.8.1 Priority: lowest | Version: 7.8.1-rc2 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:48:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:48:20 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238865=3A_Cannot_derive_well-kinded_i?= =?utf-8?q?nstance_of_form_=E2=80=98Category?= In-Reply-To: <048.9835e0581238f6f4bbded51439894fae@haskell.org> References: <048.9835e0581238f6f4bbded51439894fae@haskell.org> Message-ID: <063.985dde63004dd0dc6edf7db34c383ad7@haskell.org> #8865: Cannot derive well-kinded instance of form ?Category -------------------------------------------------+------------------------- Reporter: adinapoli | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: MacOS X | 7.8.1-rc2 Type of failure: GHC rejects valid program | Keywords: Test Case: | Architecture: deriving/should_compile/T8865 | x86_64 (amd64) Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:48:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:48:37 -0000 Subject: [GHC] #8858: Wrong maxStkSize calculation In-Reply-To: <044.8f6377e95db4a409b74bd6c341de1406@haskell.org> References: <044.8f6377e95db4a409b74bd6c341de1406@haskell.org> Message-ID: <059.c3969353e6faf5bca2cf5cc73268d423@haskell.org> #8858: Wrong maxStkSize calculation -------------------------------------+------------------------------------ Reporter: awson | Owner: thoughtpolice Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:48:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:48:56 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.f1ebef3c59737e44de31a42af0dcd23f@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): I've rebased it against 7.8 tip, will see if i can push things along this afternooon https://github.com/cartazio/ghc/compare/ghc:ghc-7.8...cpp_settings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:49:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:49:01 -0000 Subject: [GHC] #8857: Sparc needs to be on the NoSharedLibsPlatformList In-Reply-To: <046.258abaf74ed428bef525e7078c75e6a0@haskell.org> References: <046.258abaf74ed428bef525e7078c75e6a0@haskell.org> Message-ID: <061.99919c6e6f8c0a59ea64450f634712d8@haskell.org> #8857: Sparc needs to be on the NoSharedLibsPlatformList -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: sparc Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:49:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:49:36 -0000 Subject: [GHC] #8855: LLVM backend needs to use `-globalopt` explicitly In-Reply-To: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> References: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> Message-ID: <061.38772ef650d6d896487d4d95c78d566f@haskell.org> #8855: LLVM backend needs to use `-globalopt` explicitly -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:49:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:49:54 -0000 Subject: [GHC] #8851: Standalone deriving and GND behave differently In-Reply-To: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> References: <046.aed001392e1ac6ca93f537a359b2e3e9@haskell.org> Message-ID: <061.e8a2c6b371520bfd64d186d0342b1d33@haskell.org> #8851: Standalone deriving and GND behave differently -----------------------------------------------+--------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: Resolution: fixed | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: deriving/should_fail/T8851 | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: -----------------------------------------------+--------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 15:50:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 15:50:06 -0000 Subject: [GHC] #8841: PatternSynonyms error gives wrong source locations In-Reply-To: <051.266a2b6688dc36204387024e5fd153b2@haskell.org> References: <051.266a2b6688dc36204387024e5fd153b2@haskell.org> Message-ID: <066.8e2573e85670a75d7a9315994d9fc94d@haskell.org> #8841: PatternSynonyms error gives wrong source locations -------------------------------------------------+------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: Priority: low | closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Linux | 7.8.1-rc2 Type of failure: Incorrect warning at | Keywords: compile-time | PatternSynonyms Test Case: patsyn/unidir | Architecture: x86 Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 16:03:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 16:03:41 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.7c35da8054a35932d80a3365944d86dc@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): `memchr` implemented in C and I think MS' own C compiler is right. At least `memchr` extracted from static counterpart of `msvcrt` is good: {{{ test %r8,%r8 je 11 cmp %dl,(%rcx) je 11 inc %rcx dec %r8 jne 5 neg %r8 sbb %rax,%rax and %rcx,%rax retq }}} And it touches `R5` (`r8`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 16:24:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 16:24:34 -0000 Subject: [GHC] #8898: Overall improvement for randomIvalInteger In-Reply-To: <050.d45afe73360610d848e4eba302442e5f@haskell.org> References: <050.d45afe73360610d848e4eba302442e5f@haskell.org> Message-ID: <065.32233b26ffa2cfe1f5e35cfe698fe29f@haskell.org> #8898: Overall improvement for randomIvalInteger -------------------------------------+------------------------------------- Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: #5278 #5280 #1120 -------------------------------------+------------------------------------- Changes (by simonpj): * cc: core-libraries-committee@? (added) Comment: Sounds splendid. Adopting this or otherwise is the responsibility of the Core Libraries committee (core-libraries-committee at haskell.org). I've added them to the cc. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 16:33:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 16:33:03 -0000 Subject: [GHC] #8898: Overall improvement for randomIvalInteger In-Reply-To: <050.d45afe73360610d848e4eba302442e5f@haskell.org> References: <050.d45afe73360610d848e4eba302442e5f@haskell.org> Message-ID: <065.8de27334309c40926b3b0dce14de8c12@haskell.org> #8898: Overall improvement for randomIvalInteger -------------------------------------+------------------------------------- Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: #5278 #5280 #1120 -------------------------------------+------------------------------------- Changes (by simonpj): * cc: rrnewton@? (added) Comment: ... or maybe it's Ryan Newton? Adding him too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 16:35:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 16:35:04 -0000 Subject: [GHC] #8901: (very) bad inline heuristics In-Reply-To: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> References: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> Message-ID: <063.9d7ea0d90fe694d85e5e7e742e8a6c45@haskell.org> #8901: (very) bad inline heuristics -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Can you explain what the bug in GHC is? And (as Ashley asks) why you believe it's a bug in GHC and not the library? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 17:11:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 17:11:26 -0000 Subject: [GHC] #8901: (very) bad inline heuristics In-Reply-To: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> References: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> Message-ID: <063.b1c8851d0fa66f5d02cabfd5af29d58b@haskell.org> #8901: (very) bad inline heuristics -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by heisenbug): Replying to [comment:3 simonpj]: > Can you explain what the bug in GHC is? And (as Ashley asks) why you believe it's a bug in GHC and not the library? It is hard to pinpoint. There has been some rope-pulling between me and Ashley (on the dev list/in private) as he has not been keen of accepting my patch (so far) asking whether it could be a GHC bug. I tend to agree, as a quality inliner should not attempt to inline (e.g.) `formatTime` which has 8 alternatives and is called from 10+ sites. It would be interesting to see whether any bloat-controlling measures failed detecting this case, esp. as `Format.hs` appears to be a relatively benign source file. Some lessons might be learnt from this. OTOH, a library author should keep in eye how popular compilers digest the lib. I am ending up stuck between a rock and a hard place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 17:30:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 17:30:40 -0000 Subject: [GHC] #8901: (very) bad inline heuristics In-Reply-To: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> References: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> Message-ID: <063.294f2d0d6874f41aaf63ab3cfb1cfd51@haskell.org> #8901: (very) bad inline heuristics -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Ashley Yakeley): > The problem is so bad that the PowerPC32 assembler cannot resolve cross- routine references. > (I have no error message at hand, but could try to get one.) This might be helpful. If GHC cannot compile a correct program with a correct time library to PowerPC32, that would surely be a bug in GHC, would it not? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 18:19:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 18:19:07 -0000 Subject: [GHC] #8884: Reifying closed type families is broken In-Reply-To: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> References: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> Message-ID: <062.cde623dc11b357df5d05156dac9beff6@haskell.org> #8884: Reifying closed type families is broken -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T8884 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Test case fails on ghc-7.8: {{{ Actual stderr output differs from expected: --- ./th/T8884.stderr 2014-03-17 16:06:49.515482947 +0000 +++ ./th/T8884.comp.stderr 2014-03-17 16:44:36.121051051 +0000 @@ -1,3 +0,0 @@ -type family T8884.Foo (a_0 :: k_1) :: k_1 where T8884.Foo x_2 = x_2 -type family T8884.Baz (a_0 :: k_1) :: * -type instance T8884.Baz x_0 = x_0 *** unexpected failure for T8884(normal) }}} https://s3.amazonaws.com/archive.travis-ci.org/jobs/20947547/log.txt Maybe some test files missing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 18:20:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 18:20:12 -0000 Subject: [GHC] #8884: Reifying closed type families is broken In-Reply-To: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> References: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> Message-ID: <062.6c98b58d0250c8994f7402f65c6eca72@haskell.org> #8884: Reifying closed type families is broken -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T8884 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): Blagh, totally my fault. On it... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 19:17:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 19:17:41 -0000 Subject: [GHC] #8164: GHC HEAD panics in testsuite on OS X 10.8 with cc=Clang (using newest xcode 5 dev tools) In-Reply-To: <045.7c855f88b94dadeca87747ebd1da5fca@haskell.org> References: <045.7c855f88b94dadeca87747ebd1da5fca@haskell.org> Message-ID: <060.6cd7b6f3c07f57f9bb71b4b4a092e393@haskell.org> #8164: GHC HEAD panics in testsuite on OS X 10.8 with cc=Clang (using newest xcode 5 dev tools) ---------------------------------+---------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Changes (by carter): * status: new => closed * resolution: => fixed Comment: I think this is fixed, closing :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 19:22:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 19:22:30 -0000 Subject: [GHC] #7874: segfault 11 on mac os x when building compiler for ghc 7.7.20130430 In-Reply-To: <045.8383390e2deb2835bd21f457ac5e629a@haskell.org> References: <045.8383390e2deb2835bd21f457ac5e629a@haskell.org> Message-ID: <060.6864620061aac95e7fd5533dbe43a685@haskell.org> #7874: segfault 11 on mac os x when building compiler for ghc 7.7.20130430 ----------------------------------------+---------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by carter): * status: new => closed * resolution: => fixed Comment: I believe this is resolved. closing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 19:26:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 19:26:09 -0000 Subject: [GHC] #8855: LLVM backend needs to use `-globalopt` explicitly In-Reply-To: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> References: <046.a9e296cb1e64a5ea4749e79dc6555502@haskell.org> Message-ID: <061.a473fd9d116dedb25614e55edb8e5842@haskell.org> #8855: LLVM backend needs to use `-globalopt` explicitly -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bgamari): Could you possibly merge `config.mk.in: ARM now supports dynamic linking with the LLVM backend` (https://github.com/ghc/ghc/commit/d574fcbba09fd6c9d10a79e19daf5f15bb0a6cde) to `ghc-7.8` as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 20:24:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 20:24:51 -0000 Subject: [GHC] #8907: Un-zonked kind variable passes through type checker Message-ID: <047.8d583b99a10a02d33fcf9e56e368fd06@haskell.org> #8907: Un-zonked kind variable passes through type checker -------------------------------------------+------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1-rc2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- I have this module: {{{ {-# LANGUAGE PolyKinds #-} module Bug where data Poly a }}} Now, I say this: {{{ > ghc Bug.hs -fforce-recomp -dppr-debug -fprint-explicit-foralls -ddump-tc }}} The following is produced: {{{ [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) TYPE SIGNATURES TYPE CONSTRUCTORS main:Bug.Poly{tc rn2} :: k{tv ao6} [sk] -> ghc-prim:GHC.Prim.*{(w) tc 34d} data Poly{tc} (k::ghc-prim:GHC.Prim.BOX{(w) tc 347}) (a::k) No C type associated Roles: [nominal, phantom] RecFlag NonRecursive, Not promotable = FamilyInstance: none COERCION AXIOMS Dependent modules: [] Dependent packages: [base, ghc-prim, integer-gmp] ==================== Typechecker ==================== }}} My concern is the `[sk]` that appears after the kind variable `k_ao6`. It would appear that a ''skolem'' type variable passes out of the type- checker and is used as the binder for polymorphic kind of `Poly`. Should this get zonked somewhere? My guess is that there is no way to get this apparent misbehavior to trigger some real failure, given that the variable will be substituted away before much else happens. Yet, when I saw a skolem appear in a similar position after modifying the type-checker, I was sure I had done something wrong somewhere. So, is this intended or accidental behavior? If accidental, should we be scared? If we needn't be scared, I'm happy to close this as wontfix, but a Note would probably be helpful somewhere. Apologies if that Note is already written and I missed it! The same behavior is present in 7.8.1 RC 2 and in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 20:48:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 20:48:18 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.ba66c5d51523e532cf26df742bed1106@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): ok, also fixed it up so it properly has all the commit data -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 21:01:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 21:01:12 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.06086006954e6888e0bbfd7dc0dedab7@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by tibbe): Nice. Could the patches be rebased for ease of reviewing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 21:16:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 21:16:21 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF In-Reply-To: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> References: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> Message-ID: <059.ac544bbed9b0030659e3c535f13796c6@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): Here are the nofib results on my machine {{{ $ nofib-analyse/nofib-analyse spill.log no-spill.log | head -n 150 NoFib Results -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- anna +2.2% 0.0% 0.07 0.08 0.0% ansi 0.0% 0.0% 0.00 0.00 0.0% atom 0.0% 0.0% +7.9% +6.1% 0.0% awards 0.0% 0.0% 0.00 0.00 0.0% banner 0.0% 0.0% 0.00 0.00 0.0% bernouilli 0.0% 0.0% 0.11 0.12 0.0% binary-trees 0.0% 0.0% -14.8% -15.1% 0.0% boyer 0.0% 0.0% 0.02 0.03 0.0% boyer2 +0.2% 0.0% 0.00 0.00 0.0% bspt +1.7% 0.0% 0.00 0.01 0.0% cacheprof +0.5% -0.0% +11.8% +12.7% +5.5% calendar +0.1% 0.0% 0.00 0.00 0.0% cichelli +0.1% 0.0% 0.05 0.05 0.0% circsim +0.2% 0.0% +15.0% +15.8% 0.0% clausify 0.0% 0.0% 0.02 0.03 0.0% comp_lab_zift +0.2% 0.0% 0.12 0.13 0.0% compress +0.1% 0.0% 0.11 0.12 0.0% compress2 +0.6% 0.0% 0.10 0.12 0.0% constraints +0.1% 0.0% +9.4% +9.4% 0.0% cryptarithm1 0.0% 0.0% +19.2% +18.4% 0.0% cryptarithm2 +0.1% 0.0% 0.00 0.01 0.0% cse 0.0% 0.0% 0.00 0.00 0.0% eliza 0.0% 0.0% 0.00 0.00 0.0% event +0.1% 0.0% 0.09 0.10 0.0% exp3_8 0.0% 0.0% 0.15 0.16 0.0% expert +0.2% 0.0% 0.00 0.00 0.0% fannkuch-redux +0.1% 0.0% -7.6% -7.3% 0.0% fasta 0.0% 0.0% -4.5% -4.2% 0.0% fem +1.0% 0.0% 0.01 0.02 0.0% fft +0.1% 0.0% 0.02 0.03 0.0% fft2 +0.1% 0.0% 0.03 0.03 0.0% fibheaps +0.2% 0.0% 0.02 0.02 0.0% fish +0.1% 0.0% 0.01 0.01 0.0% fluid +2.5% 0.0% 0.00 0.01 0.0% fulsom +0.8% 0.0% 0.16 0.18 0.0% gamteb +0.3% 0.0% 0.02 0.03 0.0% gcd 0.0% 0.0% 0.02 0.02 0.0% gen_regexps 0.0% 0.0% 0.00 0.00 0.0% genfft 0.0% 0.0% 0.02 0.02 0.0% gg +0.5% 0.0% 0.00 0.01 0.0% grep +0.3% 0.0% 0.00 0.00 0.0% hidden +0.5% 0.0% +1.0% -0.0% 0.0% hpg +0.3% 0.0% 0.04 0.11 0.0% ida +0.2% 0.0% 0.06 0.06 0.0% infer +0.2% 0.0% 0.03 0.04 0.0% integer 0.0% 0.0% +5.6% +5.7% 0.0% integrate 0.0% 0.0% 0.06 0.09 0.0% k-nucleotide +0.2% 0.0% -4.6% -4.8% 0.0% kahan 0.0% 0.0% 0.17 0.18 0.0% knights +0.3% 0.0% 0.00 0.00 0.0% lcss 0.0% -0.0% +2.9% +2.6% 0.0% life 0.0% 0.0% 0.17 0.17 0.0% lift +0.3% 0.0% 0.00 0.00 0.0% listcompr 0.0% 0.0% 0.04 0.05 0.0% listcopy 0.0% 0.0% 0.05 0.06 0.0% maillist 0.0% +0.0% 0.03 0.17 +2.2% mandel 0.0% 0.0% 0.03 0.04 0.0% mandel2 +0.1% 0.0% 0.00 0.00 0.0% minimax +0.1% 0.0% 0.00 0.00 0.0% mkhprog +0.1% 0.0% 0.00 0.00 0.0% multiplier +0.1% 0.0% 0.07 0.08 0.0% n-body 0.0% 0.0% -6.3% -6.2% 0.0% nucleic2 +1.8% 0.0% 0.04 0.05 0.0% para +0.5% 0.0% 0.20 0.22 0.0% paraffins +0.1% 0.0% 0.07 0.09 0.0% parser +1.0% 0.0% 0.02 0.02 0.0% parstof +0.4% 0.0% 0.00 0.01 0.0% pic +0.5% 0.0% 0.00 0.01 0.0% pidigits 0.0% 0.0% -6.3% -5.5% 0.0% power +0.1% 0.0% +7.7% +7.4% +1.8% pretty 0.0% 0.0% 0.00 0.00 0.0% primes 0.0% 0.0% 0.04 0.04 0.0% primetest 0.0% 0.0% 0.06 0.07 0.0% prolog +0.2% 0.0% 0.00 0.00 0.0% puzzle +0.3% 0.0% 0.09 0.13 0.0% queens 0.0% 0.0% 0.01 0.01 0.0% reptile +0.5% 0.0% 0.00 0.01 0.0% reverse-complem +0.1% 0.0% 0.05 0.08 0.0% rewrite +0.2% 0.0% 0.01 0.01 0.0% rfib 0.0% 0.0% 0.01 0.01 0.0% rsa 0.0% 0.0% 0.01 0.01 0.0% scc 0.0% 0.0% 0.00 0.00 0.0% sched +0.1% 0.0% 0.01 0.01 0.0% scs +1.8% 0.0% -10.4% -13.1% 0.0% simple +2.9% 0.0% 0.15 0.17 0.0% solid +0.1% 0.0% 0.09 0.11 0.0% sorting +0.1% 0.0% 0.00 0.00 0.0% spectral-norm 0.0% 0.0% +3.5% +3.1% 0.0% sphere +0.6% 0.0% 0.02 0.03 0.0% symalg +0.2% 0.0% 0.00 0.00 0.0% tak 0.0% 0.0% 0.01 0.01 0.0% transform +0.4% 0.0% 0.22 +12.6% 0.0% treejoin +0.1% 0.0% 0.09 0.11 0.0% typecheck +0.1% 0.0% 0.14 0.15 0.0% veritas +1.9% 0.0% 0.00 0.01 0.0% wang +0.1% 0.0% 0.07 0.09 0.0% wave4main +0.1% 0.0% 0.14 0.16 0.0% wheel-sieve1 +0.1% 0.0% +3.8% +4.5% 0.0% wheel-sieve2 0.0% 0.0% 0.12 0.14 0.0% x2n1 0.0% 0.0% 0.00 0.00 0.0% -------------------------------------------------------------------------------- Min 0.0% -0.0% -14.8% -15.1% 0.0% Max +2.9% +0.0% +19.2% +18.4% +5.5% Geometric Mean +0.3% -0.0% +1.5% +1.8% +0.1% }}} A more detailed analysis of the results would be interesting. For example, I note that programs that are already heavily tuned (from the shootout suite) get faster, while some more "traditional" benchmarks get slower. However, given that it's a slight regressions on average on nofib, I think this isn't something we should go ahead with without further investigation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 23:32:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 23:32:34 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.08c85e381b0b06eadbb29cb39083daa5@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by igloo): http://msdn.microsoft.com/en-us/library/6t169e9c.aspx says {{{ The registers RAX, RCX, RDX, R8, R9, R10, R11 are considered volatile and must be considered destroyed on function calls (unless otherwise safety- provable by analysis such as whole program optimization). The registers RBX, RBP, RDI, RSI, RSP, R12, R13, R14, and R15 are considered nonvolatile and must be saved and restored by a function that uses them. }}} so the saving info looks right to me. It wouldn't be too surprising if saving and restoring registers more worked around a register corruption bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 00:04:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 00:04:28 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.e08838dc2ac14f8d32605a28a6bb952e@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): i'm doing a quick make test cycle to check that this all works out -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 00:10:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 00:10:54 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.d4f45211e4bb133c076786b345182115@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): theres also a bunch of places where GCC is hard coded in the build system still -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 23:54:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 23:54:12 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.3b2649f0d1d90bb06b05a2475a1cb8f4@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): just rebased it (I think i did the rebase correctly, but I have no clueeee) theres two parts to this patch 1) making ghc have its CPP settable / configable in the settings file. This seems work 2) allowing ghc to be built with different CC and CPP. this doesn't quite work, but it does allow use to set it explicitly, and initializes the right fields in settings, but theres CPP stuff lying all around the build system that i'm still unfamiliar with and haven't been address here. this also add --with-cpp and --with-cpp-flags flags to configure currently for building things, -with-cpp and with-gcc need to point to the same program or various bugs in the build system start creeping up! It also seems to have surfaced at least one new race condition in the build system. I will try to dig into that more later. What i also need to finally test properly is if the resulting ghc can handle its settings file being pointed to cpphs Also i thought i had added logic to handle cpphs as a cpp option, but it looks like i lost track of that commit -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 00:18:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 00:18:56 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.6b269981bfb0c6928a546bbefbe46612@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): tl;dr the current state is such that if you do mix and match any combo of clang / gcc (and anything not them ) for with-gcc and with-cpp, you'll hit build failures because of how the libraries make files are setup. Also it currently doesn't have the right logic for CPPHS as an alternative to gcc/clang in the build side. BUT you can put that info in yourself in the settings file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 17 23:56:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Mar 2014 23:56:33 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.0a9a9149b0699422ef543852817a41b6@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): basically: this has surfaced some design issues in the build system, but thats orthogonal to the work to enable a bindist to be bundled with cpphs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 01:20:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 01:20:11 -0000 Subject: [GHC] #8738: msys2 fails cabal01 test In-Reply-To: <045.e5b4b4cce287d04bf2354c1ec173d94b@haskell.org> References: <045.e5b4b4cce287d04bf2354c1ec173d94b@haskell.org> Message-ID: <060.400f3eb1ab27bd7848e1de632096bf84@haskell.org> #8738: msys2 fails cabal01 test ------------------------------------------------+-------------------------- Reporter: ezyang | Owner: refold Type: bug | Status: patch Priority: low | Milestone: Component: Test Suite | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: cabal01 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by refold): * version: 7.8.1-rc1 => 7.9 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 02:18:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 02:18:39 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.c78f343559abde6d895702f72a02fbc9@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): ok, 7.8 Tip builds fine, but the rebased patches on top, https://github.com/cartazio/ghc/compare/ghc:ghc-7.8...cpp_settings somehow totally break building libraries. And i'm quite stumped about how they could be causing that. (partly because i'm not familiar with that part of the build system in details) I'm not going to have time to revisit this for another week or likely two (perhaps three depending on things i cant predict). If someone wants to figure out whats going on or write a better patch in the mean time, please do! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 04:01:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 04:01:35 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.cbe03ecde0e3d2b81d7a2efc01fc4067@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------------ Changes (by awson): * priority: high => highest * status: closed => new * resolution: fixed => * architecture: x86 => Unknown/Multiple Comment: That fix above was insufficient. It resolved linking of decorated function, but any attempt of some foreign code to call it lead to segfault because such foreign code want to call it *indirectly*, while we give it a direct address. This patch fixes things finally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 04:02:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 04:02:11 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.c154e5f0e655fe4f1cd4fd203ad2bafb@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------------ Changes (by awson): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 05:30:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 05:30:17 -0000 Subject: [GHC] #8891: Data.Time.Clock documentation error (?) In-Reply-To: <044.1be40f314158351ae50287bb80b4a97b@haskell.org> References: <044.1be40f314158351ae50287bb80b4a97b@haskell.org> Message-ID: <059.f62fb89d87161b31b995ec2f0510cd9a@haskell.org> #8891: Data.Time.Clock documentation error (?) -------------------------------------+------------------------------------ Reporter: b7j0c | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Documentation | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by b7j0c): * status: new => closed * resolution: => invalid Comment: http://stackoverflow.com/questions/3223576/cannot-derive-a-show-instance- for-data-containing-utctime -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 06:59:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 06:59:52 -0000 Subject: [GHC] #8892: Ghc panics (variable not found) In-Reply-To: <045.3e8c8bb464ddd3c1e55d55ced44d87a2@haskell.org> References: <045.3e8c8bb464ddd3c1e55d55ced44d87a2@haskell.org> Message-ID: <060.241589eb874df4fffd7655671338cfe7@haskell.org> #8892: Ghc panics (variable not found) ---------------------------------------+----------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by jwlato): I've made a test case that I hope is small enough you can work with. This has dependencies on the `vector` and `vector-space` packages. There are two files, `Piecewise.hs` and `Broken.hs`. To trigger the bug, you need to first compile `Piecewise.hs` and install it to ghc's package database, then attempt to compile `Broken.hs` via `ghc -O Broken.hs`. Trying to compile `Broken.hs` when ghc can find `Piecewise.hs` works properly for me. I've put a repo on github with a minimal cabal file also, https://github.com/JohnLato/ghc-8892 I can trigger the bug with any optimization level except `-O0`. `Piecewise.hs` defines `instance (AdditiveGroup (poly a), Ord a) => AdditiveGroup (Piecewise poly a)`, with `{-# SPECIALISE instance AdditiveGroup (Piecewise Scale Double) #-}`. That SPECIALIZE instance pragma, and the `INLINE negateV` pragma, both seem required to trigger this. I haven't attempted to simplify the definition of `^+^` at all, I'll continue with that tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 09:39:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 09:39:00 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.61d2468be525520f882000132bedf4aa@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------------ Comment (by awson): This patch is not a replacement for old patch. It should be applied to the current HEAD and 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 10:09:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 10:09:43 -0000 Subject: [GHC] #8369: Small improvements to ./sync-all In-Reply-To: <042.c6240151f5790c94f3ab310253d6a72c@haskell.org> References: <042.c6240151f5790c94f3ab310253d6a72c@haskell.org> Message-ID: <057.61fad8997826b09a5a1b4bc345fcfc4f@haskell.org> #8369: Small improvements to ./sync-all -------------------------------------+------------------------------------ Reporter: nwf | Owner: hvr Type: bug | Status: new Priority: lowest | Milestone: Component: Trac & Git | Version: 7.7 Resolution: | Keywords: sync-all Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * keywords: => sync-all * owner: => hvr * component: Compiler => Trac & Git -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 10:27:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 10:27:29 -0000 Subject: [GHC] #8251: Validate submodule references during pre-receive hook In-Reply-To: <042.3dddefcb4f2f56279562cd3ed6b1a071@haskell.org> References: <042.3dddefcb4f2f56279562cd3ed6b1a071@haskell.org> Message-ID: <057.4fe1329bbe1db7f0c37cabb284279a6e@haskell.org> #8251: Validate submodule references during pre-receive hook -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Resolution: | Keywords: admin git Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Here's a sample session demonstrating the new server-side validation checks, when trying to update the `Win32` package to version 2.3.0.2 (from previously 2.3.0.1); After having synced up `libraries/Win32` to point version 2.3.0.2 of `Win32` we have the following change to commit to `ghc.git` (`git add libaries/Win32`): {{{#!diff diff --git a/libraries/Win32 b/libraries/Win32 index 1e909ad..c51e81a 160000 --- a/libraries/Win32 +++ b/libraries/Win32 @@ -1 +1 @@ -Subproject commit 1e909adb06b766e107148b8b37a4a9f9e50baf74 +Subproject commit c51e81a43cd5e9540453bd5ca6da8992245a4774 }}} 1. Pushing a commit touching a submodule ref w/o including the "`submodule`" safe-word: {{{ $ git commit -s -m "Update Win32-2.3.0.2" $ git push ... remote: performing tab-check... remote: performing submodule-ref update validations... remote: Submodule update(s) detected in ff458fc260fd05ebcb7db3294cbb1ec623e6525e: remote: *FAIL* commit message does not contain magic 'submodule' word remote: hooklet hooks/update.secondary.d/check-submodule-refs failed remote: hooks/update.secondary died remote: error: hook declined to update refs/heads/master To ssh://git at git.haskell.org/ghc.git ! [remote rejected] master -> master (hook declined) error: failed to push some refs to 'ssh://git at git.haskell.org/ghc.git' }}} 2. Rewrite the commit message to include the magic word, and try pusing again: {{{ $ git commit --amend -s -m "Update submodule to Win32-2.3.0.2" $ git push ... remote: performing tab-check... remote: performing submodule-ref update validations... remote: Submodule update(s) detected in a24ef02140dabb42dfbd2b649434017af6bb6fca: remote: libraries/Win32 => c51e81a43cd5e9540453bd5ca6da8992245a4774 remote: *FAIL* commit not found in submodule repo ('../packages/Win32.git') remote: or not reachable from persistent branches remote: hooklet hooks/update.secondary.d/check-submodule-refs failed remote: hooks/update.secondary died remote: error: hook declined to update refs/heads/master To ssh://git at git.haskell.org/ghc.git ! [remote rejected] master -> master (hook declined) error: failed to push some refs to 'ssh://git at git.haskell.org/ghc.git' }}} 3. Making sure the `Win32` sub-repo actually contains the new commit `ghc.git` is going to refer to, and try pushing again: {{{ $ (cd libraries/Win32 ; git push origin HEAD:ghc-head) ... To ssh://git at git.haskell.org/packages/Win32.git 1e909ad..c51e81a ghc-head -> ghc-head $ git push ... remote: performing tab-check... remote: performing submodule-ref update validations... remote: Submodule update(s) detected in 696bfc4ba5fce6b75cc91bcb67c5d0a3c9f29bd2: remote: libraries/Win32 => c51e81a43cd5e9540453bd5ca6da8992245a4774 remote: OK remote: mirroring ssh://git at git.haskell.org/ghc to ssh://git at github.com/ghc/ghc ... remote: To ssh://git at github.com/ghc/ghc remote: 3099e40..696bfc4 master -> master remote: running notifier To ssh://git at git.haskell.org/ghc.git 3099e40..696bfc4 master -> master }}} The last `git push` finally succeeded! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 11:00:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 11:00:30 -0000 Subject: [GHC] #8892: Ghc panics (variable not found) In-Reply-To: <045.3e8c8bb464ddd3c1e55d55ced44d87a2@haskell.org> References: <045.3e8c8bb464ddd3c1e55d55ced44d87a2@haskell.org> Message-ID: <060.565caffe952bb845f61a43e99ebe6291@haskell.org> #8892: Ghc panics (variable not found) ---------------------------------------+----------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by simonpj): Excellent! I can reproduce it. Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 12:33:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 12:33:36 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.767579c4a5309ef907af9df6cf529e9f@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature -------------------------------------+------------------------------------ Reporter: Blaisorblade | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I suppose that it should reject it because `FlexibleContexts` is not enabled, with an error message that suggests it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 12:45:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 12:45:01 -0000 Subject: [GHC] #8251: Validate submodule references during pre-receive hook In-Reply-To: <042.3dddefcb4f2f56279562cd3ed6b1a071@haskell.org> References: <042.3dddefcb4f2f56279562cd3ed6b1a071@haskell.org> Message-ID: <057.c59a3b80f908974bc881ee653316fab4@haskell.org> #8251: Validate submodule references during pre-receive hook -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Resolution: | Keywords: admin git Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8545 #8544 -------------------------------------+------------------------------------ Changes (by hvr): * related: => #8545 #8544 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 15:04:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 15:04:44 -0000 Subject: [GHC] #8890: segfault on Windows 7 i386 In-Reply-To: <045.ef91946d4291bd999be2fb92692f63b8@haskell.org> References: <045.ef91946d4291bd999be2fb92692f63b8@haskell.org> Message-ID: <060.09d705428bc1d49c521346a8e97732b6@haskell.org> #8890: segfault on Windows 7 i386 ---------------------------------------+----------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+----------------------------- Changes (by augustss): * cc: lennart@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 15:06:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 15:06:43 -0000 Subject: [GHC] #8890: segfault on Windows 7 i386 In-Reply-To: <045.ef91946d4291bd999be2fb92692f63b8@haskell.org> References: <045.ef91946d4291bd999be2fb92692f63b8@haskell.org> Message-ID: <060.8bd818be12947dafcc0a04e5539881f3@haskell.org> #8890: segfault on Windows 7 i386 ---------------------------------------+----------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+----------------------------- Comment (by augustss): Out of curiosity, how did RC1 and RC2 get "released"? Even minimal testing (i.e., compiling anything on i386 Windows-7) would have revealed this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 16:37:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 16:37:52 -0000 Subject: [GHC] #5467: Template Haskell: support for Haddock comments In-Reply-To: <046.e4a8d15ae2317226a67b074817a4dd39@haskell.org> References: <046.e4a8d15ae2317226a67b074817a4dd39@haskell.org> Message-ID: <061.179a68691006062ef845cd925155b4da@haskell.org> #5467: Template Haskell: support for Haddock comments -------------------------------------+------------------------------------ Reporter: reinerp | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Template Haskell | Version: 7.2.1 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 Rothiph): * cc: mikesteele81@? (added) * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 17:17:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 17:17:14 -0000 Subject: [GHC] #8892: Ghc panics (variable not found) In-Reply-To: <045.3e8c8bb464ddd3c1e55d55ced44d87a2@haskell.org> References: <045.3e8c8bb464ddd3c1e55d55ced44d87a2@haskell.org> Message-ID: <060.5296eebcde1cf526ff800e77160f54fb@haskell.org> #8892: Ghc panics (variable not found) ---------------------------------------+----------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"87bbc69c40d36046492d754c8d7ff02c3be6ce43/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="87bbc69c40d36046492d754c8d7ff02c3be6ce43" Make sure we occurrence-analyse unfoldings (fixes Trac #8892) For DFunUnfoldings we were failing to occurrence-analyse the unfolding, and that meant that a loop breaker wasn't marked as such, which in turn meant it was inlined away when it still had occurrence sites. See Note [Occurrrence analysis of unfoldings] in CoreUnfold. This is a pretty long-standing bug, happily nailed by John Lato. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 17:18:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 17:18:31 -0000 Subject: [GHC] #8892: Ghc panics (variable not found) In-Reply-To: <045.3e8c8bb464ddd3c1e55d55ced44d87a2@haskell.org> References: <045.3e8c8bb464ddd3c1e55d55ced44d87a2@haskell.org> Message-ID: <060.2dd0dbe0a03ae9cd29587e6b01e89a6c@haskell.org> #8892: Ghc panics (variable not found) ---------------------------------------+----------------------------------- Reporter: jwlato | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by simonpj): * status: new => merge Comment: Got it. Your test case was terrific, thank you. It's a very long-standing bug, just hard to provoke. I don't know how to make a test case for it, so I'll just close. However, Austin, please merge this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 18:57:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 18:57:08 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.91faebf43497e8e572cc496c0472baae@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): Huh, reverting HVR's patch that touches compiler/main/DynFlags.hs and compiler/main/DriverPipeline.hs allows build to run fine when CPP==CC (ie both GCC or Both clang) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 18:58:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 18:58:58 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.eb739e55d53ec530e0f70734af2a6aa5@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): i'm now (post build) edit of the settings file to do ("Haskell CPP command","cpphs"), ("Haskell CPP flags","--cpp"), and running make test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 19:54:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 19:54:44 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.371e97e81f26856801cb015112959208@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): {{{ OVERALL SUMMARY for test run started at Tue Mar 18 14:58:23 2014 EDT 0:54:39 spent to go through 3903 total tests, which gave rise to 15250 test cases, of which 11683 were skipped 42 had missing libraries 3444 expected passes 62 expected failures 3 caused framework failures 1 unexpected passes 15 unexpected failures Unexpected passes: codeGen/should_run cgrun071 (normal) Unexpected failures: driver/objc objc-hi [exit code non-0] (normal) driver/objc objcpp-hi [exit code non-0] (normal) perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T3294 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/compiler T5030 [stat not good enough] (normal) perf/compiler T5321FD [stat not good enough] (normal) perf/compiler T5321Fun [stat not good enough] (normal) perf/compiler T5631 [stat not good enough] (normal) perf/compiler T5642 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/compiler T783 [stat not good enough] (normal) perf/compiler parsing001 [stat not good enough] (normal) }}} is the result of make test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 18 23:54:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Mar 2014 23:54:36 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.b5eed51824a8b652408ac7b28531344b@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): so current status of my branch: * the build system currently needs some love to handle none gcc/clang CPP, (and fails in way i'm not very good at understanding when i try using cpphs). It seems --with-gcc=gcc-4.8 --with-hs-cpp=clang works, i'm in the midst of testing that and the opposite presently * subject being build with one of those two, we can then patch the settings file to point to cpphs and the resulting configered GHC passes the test suite I factor the latter as its own patch? That seems valuable for us now, the former isnt quite as key, though we shoudl figure it out.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 00:52:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 00:52:07 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.0a2fa627d23163a73491d966d9d46c0d@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Changes (by dterei): * cc: mazieres-i58umkudjfnfpfdx6jbbn3ymzi@? (added) * status: closed => new * resolution: fixed => * related: => 8226, 8745 Comment: Reopening ticket for now. David Mazieres and I don't think that this is the right solution. It means that a developer now needs to understand beyond Haskell2010 and some subtle details just to get correctly working module export control. Including email DM sent describing our position: {{{ At any rate, David and I just discussed the new Coerce typeclass. Based on David's understanding of its behavior, it sounds pretty dangerous for Safe Haskell. At a minimum, the programmer is going to need to understand a lot more than Haskell 2010 to write secure code. Based on my possibly limited understanding of the new feature--automatically generating instances of the Coerce type seems very un-Haskell-like. By analogy, we could automatically generate instance of Read and Show (or add equivalent DebugRead/DebugShow classes) wherever possible, but this would similarly break abstraction by providing effective access to non-exported constructors. I understand why there is a need for something better than GeneralizedNewtypeDeriving. However, implementing Coerce as a typeclass has the very serious disadvantage that there is no Haskell mechanism for controlling instance exports. And if we are going to add a new mechanism (roles) to control such exports, exporting an instance that is never requested and that undermines modularity and abstraction is an unfortunate default. It may be too late for this, but a cleaner solution more in keeping with other extensions would be to have a -XDeriveCoerce extension that allows Coerce to be explicitly derived when safe. This could be combined with leaving the previous behavior of GeneralizedNewtypeDeriving and just deprecating the language feature. Though controlling instance exports does not have a precedent, another option might be to special-case the Coerce class and only export instances of Coerce when all constructors of a type are also exported. This would prevent anyone from using Coerce to do things they couldn't already do manually. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 03:11:55 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 03:11:55 -0000 Subject: [GHC] #8908: ghc: panic! (the 'impossible' happened) Message-ID: <046.2338b068890d8b60251ae00cbf222e71@haskell.org> #8908: ghc: panic! (the 'impossible' happened) ------------------------------------+--------------------------------- Reporter: sledged | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for x86_64-unknown-linux): compiler/rename/RnSource.lhs:429:14-81: Irrefutable pattern failed for pattern Data.Maybe.Just (inst_tyvars, _, SrcLoc.L _ cls, _) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 03:24:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 03:24:22 -0000 Subject: [GHC] #8908: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.2338b068890d8b60251ae00cbf222e71@haskell.org> References: <046.2338b068890d8b60251ae00cbf222e71@haskell.org> Message-ID: <061.2ee44fcf92c532b3828d710452025366@haskell.org> #8908: ghc: panic! (the 'impossible' happened) ---------------------------------+------------------------------------ Reporter: sledged | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: Thanks for the report. This is fixed already in GHC 7.6.3, though: {{{ rwbarton at morphism:/tmp$ ghc-7.6.3 STLCPar.lhs [1 of 1] Compiling Main ( STLCPar.lhs, STLCPar.o ) STLCPar.lhs:319:10: Malformed instance: (NFData => v, NFData => f) -> Multiterm v f }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 03:55:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 03:55:47 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.b53ff4020e559aa8d181cf7261426321@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Changes (by carter): * status: new => patch Comment: Ok, it all works! some notes a) you still have to build using clang / gcc as the choice in cpp for GHC building, but the hooks are there to set it otherwise with --with-hs-cpp and --with-hs-cpp-flags, but various hard codings in the build system prevent ghc builds from succeeding. Its just those issue are more discoverable :-) b) ghc will correctly use the new fields in the settings file, as if invoked with -pgmP and -optP being passed in. I managed to build all of lens's deps successfully using CPPHS! I did hit a bug in CPPHS wrt building Lens 4.0.7, but again thats an issue with using CPPHS, not with the patch c) Theres still lots of hardcoded GCC / CPP things in the build system d) this gives the core of whats needed to provide a bindist that doesn't use clang/gcc for CPP, though because of other issues that need to be address (and should become a new ticket perhaps), you can't as yet build GHC with a CPP thats not clang or gcc is there any documentation i should add? (either to the places patched or the documentation somewhere in the manual / wiki) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 05:07:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 05:07:52 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.8c80cbb14dba6dffe9b6d5260ca41eeb@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): https://github.com/ekmett/lens/issues/415#issuecomment-38016493 eric figured out the cpphs issue -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 05:31:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 05:31:35 -0000 Subject: [GHC] #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults Message-ID: <050.3909a9b5b308161cfebc22d2e86541c4@haskell.org> #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults -------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------+------------------------------------- I built ghc-7.8.1 RC2 on ppc Fedora 21 Development with ghc-7.6.3. When I try to run dynamically linked "helloworld", it segfaults. I don't have direct access yet to a ppc box to investigate further. I guess something about the use of shared libraries on ppc is not working properly. {{{ $ cat > hello.hs main = putStrLn "hi" $ ghc -dynamic hello.hs $ ./hello Segmentation fault (core dumped) ./hello }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 07:17:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 07:17:56 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.c488128727e4a215e6d45393a9cc6562@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------------ Comment (by awson): I've slightly improved the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 08:51:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 08:51:26 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.6e8adf12fe3ad5c5130e47fffc8d9c34@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by nomeata): Just as a data point: > Though controlling instance exports does not have a precedent, another > option might be to special-case the Coerce class and only export > instances of Coerce when all constructors of a type are also exported. > This would prevent anyone from using Coerce to do things they couldn't > already do manually. This is what we had originally; the check was removed in 59722295bb8da8f01d37356fbed6aef7321a8195/ghc. It wouldn?t be hard to re- introduce it; but it will mean that a lot of uses of `coerce` or GND in Safe Haskell will fail, including `coerce :: Set Age -> Set Int`. Maybe requiring a `deriving (Coercible)`, or `-XDeriveCoerce`, or a standalone deriving declaration to get the coerce-under-type constructor behaviour isn?t such a bad idea after all, even outside the context of Safe Haskell? It would turn the current blacklisting (?add role annotatoin if it is not safe?) into whitelisting (?tell us that Coercing is safe, and how?). For additional convenience we could retain the previous behaviour of ?instance available if all constructors are in scope?, so that the author of simple cases like `[]`, `Either`, `Maybe` do not have to do something; only those who hide their constructors have to act to allow their users to coerce under their type constructor. TL;DR: Coercing under a type constructor is allowed if (a) all involved constructors are in scope (?could write it by hand test?) ''or'' (b) someone who had access to the constructors (most likely the author) explicitly declared the instance, using some form of `deriving`. No special behaviour needed for Safe Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 12:06:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 12:06:13 -0000 Subject: [GHC] #8910: cross compiling for x86_64 solaris2 Message-ID: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> #8910: cross compiling for x86_64 solaris2 ----------------------------------+---------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Solaris Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- using a "gcc -m64" and a working ghc-7.8.0.20140228-i386-unknown-solaris2 I was able to create a 64Bit ghc-stage2 compiler that can compile a simple hello world program but may create binaries from larger sources that seg- fault. In particular "ghc-stage2 --interactive" seg-faults: {{{ [Thread debugging using libthread_db enabled] [New Thread 1 (LWP 1)] [New LWP 2 ] [New LWP 3 ] [New LWP 4 ] GHCi, version 7.8.0.20140228: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-simple ... linking ... done. Loading package base ... linking ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x00000000041ea4c0 in ?? () (gdb) bt #0 0x00000000041ea4c0 in ?? () #1 0x000000000369cf92 in resolveObjs () #2 0x000000000206de99 in cplU_info () #3 0x000000000000000c in ?? () #4 0x0000000003d0fe09 in base_GHCziEventziManager_zdLr88clvl8_closure () #5 0x0000000000000000 in ?? () }}} The content of my mk/build.mk is just {{{ INTEGER_LIBRARY = integer-simple }}} Creating a binary-dist also worked, but unpacking and "gmake install" failed at first because old-time, haskell98 and haskell2010 libraries were missing due to "!CrossCompiling" in ghc.mk and the second time with: {{{ Reading package info from "rts/dist/package.conf.install" ... done. "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register libraries/ghc-prim dist-install "/local/home/maeder/haskell/ghc-7.8-x64-static/lib/ghc-7.8.0.20140228/bin/ghc" "/local/home/maeder/haskell/ghc-7.8-x64-static/lib/ghc-7.8.0.20140228/bin /ghc-pkg" "/local/home/maeder/haskell/ghc-7.8-x64-static/lib/ghc-7.8.0.20140228" '' '/local/home/maeder/haskell/ghc-7.8-x64-static' '/local/home/maeder/haskell/ghc-7.8-x64-static/lib/ghc-7.8.0.20140228' '/local/home/maeder/haskell/ghc-7.8-x64-static/share/doc/ghc/html/libraries' NO ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi magic number mismatch: old/corrupt interface file? (wanted 129742, got 33214052) gmake[1]: *** [install_packages] Fehler 1 }}} What am I doing wrong for cross compiling? There is also #8378 using a different build host. #8713 also seem to use x86_64 solaris2 libs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 12:25:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 12:25:43 -0000 Subject: [GHC] #8910: cross compiling for x86_64 solaris2 In-Reply-To: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> References: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> Message-ID: <060.7e58a8abeeb2e587e612ff1ff9efdda5@haskell.org> #8910: cross compiling for x86_64 solaris2 ----------------------------------+---------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by maeder): The "magic number mismatch" is gone when I use my 64bit-gcc --with-gcc= during configure. Is there a better way to pass the "-m64" flag to gcc? (Currently, I'm using a separate shell script.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 12:46:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 12:46:35 -0000 Subject: [GHC] #8911: Panic on incorrect record declaration Message-ID: <044.73ad3b8f74d60739c460a6cf2ee84e3e@haskell.org> #8911: Panic on incorrect record declaration -----------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: record | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- {{{ $ echo 'data X = X { x :: { x :: Int } }' >test.hs; ghc test.hs [1 of 1] Compiling Main ( test.hs, test.o ) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): tc_hs_type: record Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 15:03:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 15:03:26 -0000 Subject: [GHC] #8912: Documentation stale: implicit-parameter constraints seem to be allowed in instance declarations now. Message-ID: <051.9deb02feaf66c13b5aa3da47e90da868@haskell.org> #8912: Documentation stale: implicit-parameter constraints seem to be allowed in instance declarations now. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Keywords: implicit- | Operating System: Unknown/Multiple parameter instance-constraints | Type of failure: Documentation Architecture: Unknown/Multiple | bug Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/other-type- extensions.html#implicit-parameters says: You can't have an implicit parameter in the context of a class or instance declaration. For example, both these declarations are illegal: {{{ class (?x::Int) => C a where ... instance (?x::a) => Foo [a] where ... }}} However, ghc 7.6.3 seems to accept this now: {{{ {-# LANGUAGE ImplicitParams #-} class C a where toInt :: a -> Int instance (?imp :: Int) => C [a] where toInt _ = ?imp test :: Int test = let ?imp = 5 in toInt "Hello, world" }}} test evaluates to 5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 15:11:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 15:11:36 -0000 Subject: [GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) In-Reply-To: <045.6e47836af0f0e307f79949999a773a19@haskell.org> References: <045.6e47836af0f0e307f79949999a773a19@haskell.org> Message-ID: <060.fc853f141efe96bec2bd32b1ed7aa3e9@haskell.org> #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ---------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by simonmar): I think I know why this is (came across it while looking at something else). We ask the bootstrapping GHC for the name of the C compiler it uses, and this becomes `$(CC_STAGE0)`. This is then used for compiling anything in stage 0, that is, things that we need during the build. I'm not sure why it would be used when compiling the RTS though, that seems wrong. Probably what we want to do is make `--with-gcc` set `$(CC_STAGE0)`, overriding the value provided by the stage 0 GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 15:13:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 15:13:46 -0000 Subject: [GHC] #8910: cross compiling for x86_64 solaris2 In-Reply-To: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> References: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> Message-ID: <060.fad3d985f642f3959df264bc1d6259fc@haskell.org> #8910: cross compiling for x86_64 solaris2 ----------------------------------+---------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by maeder): I could install my (half-working) ghc-stage2 compiler and tried to bootstrap ghc-7.8.0.20140228. However, the program {{{ inplace/bin/genprimopcode --data-decl < compiler/stage1/build/primops.txt }}} seg-faults: {{{ [Thread debugging using libthread_db enabled] [New Thread 1 (LWP 1)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x000000000049fb4f in Syntax_getzuattribzuname_info () (gdb) bt #0 0x000000000049fb4f in Syntax_getzuattribzuname_info () #1 0x0000000000000000 in ?? () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 15:29:20 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 15:29:20 -0000 Subject: [GHC] #8913: either bug or confusing error message mixing PolyKinds and TypeFamilies Message-ID: <044.30ecf3720077f5e887124dbcf31b88c9@haskell.org> #8913: either bug or confusing error message mixing PolyKinds and TypeFamilies -------------------------------------------+------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1-rc2 Keywords: PolyKinds, TypeFamilies | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- I found this when using GHC.Generics, but it has to do with TypeFamilies so here is a stand-alone example: {{{ {-# OPTIONS_GHC -Wall #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE PolyKinds #-} module Test where class GCat f where gcat :: f p -> Int cat :: (GCat (MyRep a), MyGeneric a) => a -> Int cat x = gcat (from x) class MyGeneric a where type MyRep a :: * -> * from :: a -> (MyRep a) p }}} This code gives the error message {{{ src/Dyno/Test.hs:12:9: Could not deduce (GCat (MyRep a)) arising from a use of ?gcat? from the context (GCat (MyRep a), MyGeneric a) bound by the type signature for cat :: (GCat (MyRep a), MyGeneric a) => a -> Int at src/Dyno/Test.hs:11:8-48 In the expression: gcat (from x) In an equation for ?cat?: cat x = gcat (from x) Failed, modules loaded: none. }}} If this is not a bug then error message is pretty confusing because it's saying "Can't deduce (C a) from (C a)", where the message I'm used to is "Can't derive (C a) from (C a0)" or something that indicates the mismatch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 16:29:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 16:29:33 -0000 Subject: [GHC] #8914: Remove unnecessary constraints from MonadComprehensions and ParallelListComp Message-ID: <051.acde5e53d639cac227862a3e93262533@haskell.org> #8914: Remove unnecessary constraints from MonadComprehensions and ParallelListComp -------------------------------------------+------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Difficult (2-5 days) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Many parts of MonadComprehensions don't actually require monads instance, the following could do with a `Functor` constraint {{{ fmapM :: Monad m => (a -> b) -> m a -> m b fmapM f xs = [ f x | x <- xs ] }}} and I don't see any reason why the class `MonadZip` (from [http://hackage.haskell.org/package/base-4.4.0.0/docs/Control-Monad- Zip.html Control.Monad.Zip]) requires a `Monad` constraint rather a `Functor` constraint: {{{ class Functor f => FunctorZip f where fzip :: f a -> f b -> f (a,b) fzip = fzipWith (,) fzipWith :: (a -> b -> c) -> f a -> f b -> f c fzipWith f fa fb = fmap (uncurry f) (fzip fa fb) funzip :: f (a,b) -> (f a, f b) funzip fab = (fmap fst fab, fmap snd fab) }}} with the laws {{{ fmap (f *** g) (fzip fa fb) = fzip (fmap f fa) (fmap g fb) fmap (const ()) fa = fmap (const ()) fb ==> funzip (fzip fa fb) = (fa, fb) }}} Same with `Applicative` (see ApplicativeDo): {{{ liftA2 :: Applicative f => (a -> b -> c) -> f a -> f b -> f c liftA2 f a1 a2 = [ f x1 x2 | x1 <- a1, x2 <- a2 ] }}} The reason I bring this up is because I'm writing a DSL that uses length- indexed vectors whose `Functor` and `FunctorZip` instances are trivial but whose `Monad` instance is [http://stackoverflow.com/questions/5802628 /monad-instance-of-a-number-parameterised-vector complicated] and not need. This proposal shares a similar rationale as ApplicativeDo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 16:30:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 16:30:30 -0000 Subject: [GHC] #8913: either bug or confusing error message mixing PolyKinds and TypeFamilies In-Reply-To: <044.30ecf3720077f5e887124dbcf31b88c9@haskell.org> References: <044.30ecf3720077f5e887124dbcf31b88c9@haskell.org> Message-ID: <059.122b52c0be526964d408c44d6a87ee8e@haskell.org> #8913: either bug or confusing error message mixing PolyKinds and TypeFamilies -------------------------------------+------------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: PolyKinds, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by kosmikus): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 18:05:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 18:05:45 -0000 Subject: [GHC] #8911: Panic on incorrect record declaration In-Reply-To: <044.73ad3b8f74d60739c460a6cf2ee84e3e@haskell.org> References: <044.73ad3b8f74d60739c460a6cf2ee84e3e@haskell.org> Message-ID: <059.bf9eb92e8b014e829ebb1731db03ecb4@haskell.org> #8911: Panic on incorrect record declaration ---------------------------------------+----------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: record Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Thanks for the report; it's already fixed in 7.8 (#7943). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 18:15:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 18:15:06 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.21a5ed17e4cb0d3fa0eb4e027bd749fe@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------------ Changes (by thoughtpolice): * version: 6.8.2 => 7.8.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 19:02:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 19:02:36 -0000 Subject: [GHC] #8913: either bug or confusing error message mixing PolyKinds and TypeFamilies In-Reply-To: <044.30ecf3720077f5e887124dbcf31b88c9@haskell.org> References: <044.30ecf3720077f5e887124dbcf31b88c9@haskell.org> Message-ID: <059.4f1ef7f3ce232393565c68f17579247c@haskell.org> #8913: either bug or confusing error message mixing PolyKinds and TypeFamilies -------------------------------------+------------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: PolyKinds, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by goldfire): With `-fprint-explicit-kinds` we see that this really looks like a proper inference bug: {{{ Could not deduce (GCat * (MyRep a)) arising from a use of ?gcat? from the context (GCat * (MyRep a), MyGeneric a) bound by the type signature for cat :: (GCat * (MyRep a), MyGeneric a) => a -> Int at Scratch.hs:12:8-48 In the expression: gcat (from x) In an equation for ?cat?: cat x = gcat (from x) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 22:12:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 22:12:40 -0000 Subject: [GHC] #8915: Instance context not respected in pattern match Message-ID: <048.f432c616aaf5a00378ec20dcd3e2bde2@haskell.org> #8915: Instance context not respected in pattern match ------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- (I'll only excerpt here, see attached testcase for full program) I have an instance {{{ class Foo (f :: Maybe Symbol) instance KnownSymbol a => Foo (Just a) }}} and a constructor constrained `Baz` with it: {{{ data Bar (f :: Maybe Symbol) where Baz :: Foo (Just a) => Bar (Just a) }}} But the `KnownSymbol` constraint is not liberated when pattern matching on `Baz`: {{{ test :: Bar (Just a) -> Bar (Just b) -> Bool test a at Baz b at Baz = case prox a `sameSymbol` prox b of Just Refl -> True _ -> False where prox :: Bar (Just a) -> Proxy a prox Baz = Proxy }}} I get this error: {{{ instance-test.hs:14:32: Could not deduce (KnownSymbol a2) arising from a use of ?sameSymbol? from the context ('Just a ~ 'Just a1, Foo ('Just a1)) bound by a pattern with constructor Baz :: forall (a :: Symbol). Foo ('Just a) => Bar ('Just a), in an equation for ?test? at instance-test.hs:14:8-10 or from ('Just b ~ 'Just a2, Foo ('Just a2)) bound by a pattern with constructor Baz :: forall (a :: Symbol). Foo ('Just a) => Bar ('Just a), in an equation for ?test? at instance-test.hs:14:14-16 }}} By my reasoning `Foo ('Just a2)` should imply `KnownSymbol a2`, why is GHC missing it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 23:16:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 23:16:51 -0000 Subject: [GHC] #8884: Reifying closed type families is broken In-Reply-To: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> References: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> Message-ID: <062.5aa76debdf2a6dcdac84ede208da25e1@haskell.org> #8884: Reifying closed type families is broken -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T8884 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): thoughtpolice: Did you get to fix it? It seems the only failing test case missing after Gergo fixed up the failures he caused. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 19 23:57:55 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Mar 2014 23:57:55 -0000 Subject: [GHC] #8915: Instance context not respected in pattern match In-Reply-To: <048.f432c616aaf5a00378ec20dcd3e2bde2@haskell.org> References: <048.f432c616aaf5a00378ec20dcd3e2bde2@haskell.org> Message-ID: <063.f84cd845bc57b5a44dd1e3c38d253d91@haskell.org> #8915: Instance context not respected in pattern match -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: This is not how instances work, I'm afraid. You've stated that `KnownSymbol a` implies `Foo (Just a)`, but not the other way around. So, pattern matching will bring `Foo (Just a)` into the context, but that says nothing about `KnownSymbol a`. I don't have a good reference of where to point you to explaining this in detail -- sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 20 07:53:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Mar 2014 07:53:19 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.e872beda2987600ad96592721441c1e0@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by tibbe): simonmar, how would one cast the argument in the `emitPopCntCall`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 20 07:53:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Mar 2014 07:53:57 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.fea2837d7bcb099153cd1131849b332f@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by tibbe): Replying to [comment:42 simonmar]: > Well, one bug is that in `emitPopCntCall` we don't cast the argument to the correct width. The `-dcmm-lint` should catch it, because the argument width isn't the same as the primop is expecting, but the Cmm linter doesn't check the arguments of prim calls (that's another bug). How would one cast the argument in the `emitPopCntCall`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 20 08:27:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Mar 2014 08:27:26 -0000 Subject: [GHC] #8914: Remove unnecessary constraints from MonadComprehensions and ParallelListComp In-Reply-To: <051.acde5e53d639cac227862a3e93262533@haskell.org> References: <051.acde5e53d639cac227862a3e93262533@haskell.org> Message-ID: <066.0847fdfb31bae9b6a34612322d5c7fd2@haskell.org> #8914: Remove unnecessary constraints from MonadComprehensions and ParallelListComp -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: None/Unknown | days) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonpj): As you point out, it's quite similar to the !ApplicativeDo idea. But the latter has something approaching a specification, that says what type any given program has. Would you (or someone) like to come up with a specification for your proposed feature? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 20 08:59:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Mar 2014 08:59:34 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.7f8e886e9828ef348b35c421fc5949dd@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by simonpj): `Coercible` is not a regular type class, and its "instances" are not subject to the usual rules of "always-exported". So you can 100% ignore the rules for normal instances. The question is "under what circumstances are the instances of `Coercible` visible?". Or, to make it sound less type-class-ish, you could ask "what rules are used to solve `Coercible` constraints?". Section 3 of the [http://research.microsoft.com/~simonpj/papers/ext-f paper] discusses this in some detail -- I hope everyone in this conversation has read it carefully. Specifically: * The "newtype-unwrapping" instance is available only if the newtype data constructor is visible. This is uncontroversial, just what Safe Haskell wants, and is clearly not what a "normal instance" is like. * The "lifting" instances are controlled by roles. And here there is room for debate about the proper defaults for those roles. For example, we could say that with Safe Haskell the default roles (ie if you don't give an explicit signature) of any data type declared in that module are nominal rather than representational. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 20 12:29:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Mar 2014 12:29:44 -0000 Subject: [GHC] #8693: dyn way broken on powerpc In-Reply-To: <047.84ea3c5f16dbc4a0922607cee32ae1b1@haskell.org> References: <047.84ea3c5f16dbc4a0922607cee32ae1b1@haskell.org> Message-ID: <062.e8f14e327152ab785d27571fbc4ceffd@haskell.org> #8693: dyn way broken on powerpc ----------------------------------------+--------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Changes (by trommler): * status: new => closed * resolution: => duplicate Comment: Duplicate of #7830 and fixed there. Closing the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 20 13:49:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Mar 2014 13:49:27 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.80f0577f74a1e59aefc86cf20ad4626d@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): With a `MO_UU_Conv` `MachOp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 20 14:15:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Mar 2014 14:15:19 -0000 Subject: [GHC] #8048: Register spilling produces ineffecient/highly contending code In-Reply-To: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> References: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> Message-ID: <061.20f90f94c076bd0dcdc9ed264851745e@haskell.org> #8048: Register spilling produces ineffecient/highly contending code -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.6.3 (CodeGen) | Keywords: register Resolution: | allocator spill Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by simonmar): * component: Compiler => Compiler (CodeGen) Comment: Alright then, if we're being nitpicky about the Component field :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 20 15:27:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Mar 2014 15:27:20 -0000 Subject: [GHC] #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults In-Reply-To: <050.3909a9b5b308161cfebc22d2e86541c4@haskell.org> References: <050.3909a9b5b308161cfebc22d2e86541c4@haskell.org> Message-ID: <065.804c2c1f0aa7624fb058f43f6cff124b@haskell.org> #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults -------------------------------------+----------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Changes (by trommler): * cc: ptrommler@? (added) Comment: Here is a stack trace: {{{ [ 34s] Program received signal SIGSEGV, Segmentation fault. [ 34s] 0x0f77e05c in stg_enter_info () [ 34s] from /usr/lib/ghc-7.8.0.20140228/rts-1.0/libHSrts- ghc7.8.0.20140228.so [ 34s] (gdb) #0 0x0f77e05c in stg_enter_info () [ 34s] from /usr/lib/ghc-7.8.0.20140228/rts-1.0/libHSrts- ghc7.8.0.20140228.so [ 34s] #1 0x0f759510 in scheduleWaitThread () [ 34s] from /usr/lib/ghc-7.8.0.20140228/rts-1.0/libHSrts- ghc7.8.0.20140228.so [ 34s] #2 0x0f7625b4 in rts_evalLazyIO () [ 34s] from /usr/lib/ghc-7.8.0.20140228/rts-1.0/libHSrts- ghc7.8.0.20140228.so [ 34s] #3 0x0f764324 in hs_main () [ 34s] from /usr/lib/ghc-7.8.0.20140228/rts-1.0/libHSrts- ghc7.8.0.20140228.so [ 34s] #4 0x100014dc in main () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 20 15:50:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Mar 2014 15:50:53 -0000 Subject: [GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) In-Reply-To: <045.6e47836af0f0e307f79949999a773a19@haskell.org> References: <045.6e47836af0f0e307f79949999a773a19@haskell.org> Message-ID: <060.125b4d0a9048b432741219529527f859@haskell.org> #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ---------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by simonmar): `$CPP` is set by configure's `AC_PROG_CPP`, so it is completely separate from `--with-gcc`. To set this, you need to set `CPP` when invoking `configure`, like this: {{{ $ CPP="/path/to/gcc -E" ./configure --with-gcc=/path/to/gcc }}} I have a patch for the `CC_STAGE0` thing on the way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 20 16:24:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Mar 2014 16:24:00 -0000 Subject: [GHC] #8914: Remove unnecessary constraints from MonadComprehensions and ParallelListComp In-Reply-To: <051.acde5e53d639cac227862a3e93262533@haskell.org> References: <051.acde5e53d639cac227862a3e93262533@haskell.org> Message-ID: <066.d5289abd3f54898a17e05200bb1edbfb@haskell.org> #8914: Remove unnecessary constraints from MonadComprehensions and ParallelListComp -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: None/Unknown | days) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Iceland_jack): I wrote a quick entry GeneralizedMonadComprehensions but I haven't added the specification, I may do so at a later date. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 20 17:34:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Mar 2014 17:34:01 -0000 Subject: [GHC] #8913: either bug or confusing error message mixing PolyKinds and TypeFamilies In-Reply-To: <044.30ecf3720077f5e887124dbcf31b88c9@haskell.org> References: <044.30ecf3720077f5e887124dbcf31b88c9@haskell.org> Message-ID: <059.39b5560c643dc2a3c2e83be952b9609e@haskell.org> #8913: either bug or confusing error message mixing PolyKinds and TypeFamilies -------------------------------------+------------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: PolyKinds, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by ghorn): A workaround for this is to put the "GCat" class in its own module (without PolyKinds), and make orphan instances of it where needed (with PolyKinds). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 10:14:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 10:14:11 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.b83e7cf4b352901ced441f6cc64aea6f@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by nomeata): > For example, we could say that with Safe Haskell the default roles (ie if you don't give an explicit signature) of any data type declared in that module are nominal rather than representational. What would that mean for inferring a module as Safe? Is `A` in the example Safe or nor? Would a module only be safe if it annotates everything as ?nominal?? It seems to me that any special handling of Safe Haskell module is doomed to fail, because we want to be able to infer modules as Safe, i.e. we?ll have code where we do ''not'' know whether they are intended to be used as Safe modules or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 12:48:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 12:48:29 -0000 Subject: [GHC] #8884: Reifying closed type families is broken In-Reply-To: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> References: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> Message-ID: <062.fd540f92923f4e4e80a658aad8e12afb@haskell.org> #8884: Reifying closed type families is broken -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T8884 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"df409de9550dc8a07e010964a54112266d809341/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="df409de9550dc8a07e010964a54112266d809341" Flush after TH in #8884 test case (I recall that this was needed in some cases in the past, and might fix the validate error on travis.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 13:17:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 13:17:02 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.f68d7a598bc5220bb0a9bc774a0024dd@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by simonpj): I think it would be helpful first for David & David to say exactly what they don't like about this: {{{ {-# LANGUAGE Safe #-} module Lib( T, ... ) where data T a = Leaf a | Node (Tree a) (Tree a) {-# LANGUAGE Safe #-} module Client( main ) import Lib newtype Age = MkAge Int foo :: T Age foo = .... bar :: T Int bar = coerce foo }}} To me this seems fine. If (inside `Lib`) the functions over T make use of type-class constraints over T's parameter, then we can declare a nominal role: {{{ {-# LANGUAGE Safe #-} module Lib( T, ... ) where data T a = Leaf a | Node (Tree a) (Tree a) -- Balanced, based on Ord a role T nominal }}} I can see the following possible choices: * (A) Status quo. Data types without role signatures get representational roles by default. The above is accepted as-is * (B) Data types without role signatures get representational roles by default, except with `{-# LANGUAGE SAFE #-}` which changes the default to nominal. So `Lib` will compile without complaint, but `Client` will fail. Presumably, `Lib` without a `Safe` pragma would be inferred as `Unsafe`, since `T` would have representational role. * (C) Data types without role signatures always get nominal roles by default. That would mean that many many data types in libraries would have to have a role signature added, if you want to lift coercions over them. David, David, can you say what you want and why? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 14:59:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 14:59:03 -0000 Subject: [GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) In-Reply-To: <045.6e47836af0f0e307f79949999a773a19@haskell.org> References: <045.6e47836af0f0e307f79949999a773a19@haskell.org> Message-ID: <060.476e13f42af8e5952a798f1d158d8f68@haskell.org> #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ---------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by igloo): Why do we need to use the `--with-gcc` value for `$(CC_STAGE0)`? The idea is that you need to have a working bootstrapping compiler, and the inferred `$(CC_STAGE0)` is part of that. There's no particular reason that the `--with-gcc` value should work, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 15:08:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 15:08:12 -0000 Subject: [GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) In-Reply-To: <045.6e47836af0f0e307f79949999a773a19@haskell.org> References: <045.6e47836af0f0e307f79949999a773a19@haskell.org> Message-ID: <060.02ec7f6086520f95eb5830e7c1b4feaa@haskell.org> #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ---------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by simonmar): We might not be able to use the gcc from the stage 0 compiler (I can go into details about the particular setup that leads to this problem, but it's long and boring). The point is, if you want to override `$(CC_STAGE0)`, there's currently no good way to do it. I think having `--with-gcc` set `$(CC_STAGE0)` is fairly sensible provided we're not cross-compiling. I'm open to other suggestions though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 15:50:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 15:50:20 -0000 Subject: [GHC] #8901: (very) bad inline heuristics In-Reply-To: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> References: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> Message-ID: <063.a1dda7fabf43483383826c38cbee8dcc@haskell.org> #8901: (very) bad inline heuristics -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Not necessarily. It's not hard to give GHC a heart attack by inlining too aggressively. If you can exhibit a case where you think GHC is inlining where it shouldn't I'll gladly look at it. For example you mention `formatTime`; can you give a test case? Eg a test file with 10+ calls, that all inline when they shouldn't? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 16:26:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 16:26:21 -0000 Subject: [GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) In-Reply-To: <045.6e47836af0f0e307f79949999a773a19@haskell.org> References: <045.6e47836af0f0e307f79949999a773a19@haskell.org> Message-ID: <060.b382fd1c3c036a8e76bd48854d2bcf02@haskell.org> #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ---------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by carter): so do we perhaps want to have "overrides" like '--with-FOO-StageN' flags? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 17:08:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 17:08:14 -0000 Subject: [GHC] #8900: Strictness analysis regression In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.ee9216b142c8698b1282313079086eb4@haskell.org> #8900: Strictness analysis regression --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Johan, the "extra case" comes from commit 28d9a03253e8fd613667526a170b684f2017d299, whose comment says {{{ Make CaseElim a bit less aggressive See Note [Case elimination: lifted case]: We used to do case elimination if (c) the scrutinee is a variable and 'x' is used strictly But that changes case x of { _ -> error "bad" } --> error "bad" which is very puzzling if 'x' is later bound to (error "good"). Where the order of evaluation is specified (via seq or case) we should respect it. }}} And indeed that's a good point. `Note [Case binder next]` in `Simplify.lhs` is relevant here. You point out that `$wpoly_go` is strict in its last arg, so it really is "next". I wonder how picky we want to be. Consider {{{ case x of y -> g (error "uk") y }}} and suppose that g is strict in both arguments. Would it be ok to drop the case? Then we might get `error "uk"` (if `g` evaluated its first arg first) rather than any error arising from `x`? Probably yes, I guess. Indeed maybe the change is just wrong, or at least over-conservative. According to our paper "A semantics of imprecise exceptions" it is ok. I don't think anyone actually reported a bug. So maybe we should revert to the ghc 7.6 behaviour? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 17:55:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 17:55:28 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.a53ea5b9d947a74981c599d1886de53c@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by dterei): So I need to educate myself better still but based on my current understanding (from the wiki page on roles) and the example Simon, what David and I don't like about this is that you can no longer look at just an export list for your module to verify what a consumer of your module is capable of doing. I.e., the Safe Haskell specific issue with GND that we cared about when we disabled GND was #5498. My understanding is that the new roles and coercion infrastructure that forms the base of 7.8's GND deals with all the type safety issues where you could easily segfault a program or inspect a bool as an int. However, by default it doesn't deal with the module boundary issue. In fact, it makes it worse as now phantom roles allow coercion between them. For example, Ptr requires explicit use of roles to ensure safety. This isn't very satisfactory to DM and I. Now a developer needs to understand GHC specific Haskell and a some subtle details to correctly implement abstractions. We'd prefer if export lists were self-contained and authoritative, not export lists + roles. Speaking just for myself, I think (C) would be ideal. It coincides most closely with my (and what I believe most programmers) intuitive expectations of data types and abstraction is and gives the strongest safety by default. (B) has the downside of making a lot of code by default not safe and we were very much hoping solving GND would expand the default world that is safe, not reduce it. (A) as explained above isn't great in our opinion. P.S., I'm traveling right now so may be some delays in replying but I'll try to be prompt. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 19:02:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 19:02:34 -0000 Subject: [GHC] #8916: "error: thread-local storage not supported for this target" when building cross-compiling GHC on OSX Message-ID: <047.e5ea9e7d9a3c420fa31087f485544b00@haskell.org> #8916: "error: thread-local storage not supported for this target" when building cross-compiling GHC on OSX ----------------------------------+---------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- Target is `x86_64-pc-linux`. I'm using the toolchain from http://crossgcc .rts-software.org/doku.php, and configured `--with-target=x86_64-pc- linux`. {{{ ===--- building phase 0 /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print- directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print- directory -f ghc.mk phase=1 phase_1_builds utils/unlit/ghc.mk:18: utils/unlit/dist/build/.depend.c_asm: No such file or directory utils/hp2ps/ghc.mk:24: utils/hp2ps/dist/build/.depend.c_asm: No such file or directory includes/ghc.mk:146: includes/dist-derivedconstants/build/.depend.c_asm: No such file or directory includes/ghc.mk:184: includes/dist-ghcconstants/build/.depend.c_asm: No such file or directory utils/genapply/ghc.mk:26: utils/genapply/dist/build/.depend.haskell: No such file or directory utils/genapply/ghc.mk:26: utils/genapply/dist/build/.depend.c_asm: No such file or directory libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.haskell: No such file or directory libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.c_asm: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist- boot/build/.depend-v.haskell: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist- boot/build/.depend-v.c_asm: No such file or directory libraries/binary/ghc.mk:3: libraries/binary/dist- boot/build/.depend-v.haskell: No such file or directory libraries/binary/ghc.mk:3: libraries/binary/dist- boot/build/.depend-v.c_asm: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist- boot/build/.depend-v.haskell: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist- boot/build/.depend-v.c_asm: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist- boot/build/.depend-v.haskell: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/build/.depend-v.c_asm: No such file or directory compiler/ghc.mk:450: compiler/stage1/build/.depend-v.haskell: No such file or directory HC [stage 0] includes/dist-ghcconstants/build/mkDerivedConstants.o In file included from rts/Capability.h:25, from includes/mkDerivedConstants.c:27:0: rts/Task.h:238:0: error: thread-local storage not supported for this target make[1]: *** [includes/dist-ghcconstants/build/mkDerivedConstants.o] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 20:04:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 20:04:14 -0000 Subject: [GHC] #8900: Strictness analysis regression In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.b7797248dda1ffa6d08a85c1cd00cf06@haskell.org> #8900: Strictness analysis regression --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): I don't know what the right approach is. If we decide to keep the new behavior I'll have to be more careful about any extra evaluation, as I can't trust GHC to remove it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 21:22:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 21:22:01 -0000 Subject: [GHC] #8900: Strictness analysis regression In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.0e91db4fc97a968f281d00550f3870a6@haskell.org> #8900: Strictness analysis regression --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): I'm in favour of being gung-ho about evaluation order, especially when there's an optimisation to be had. If the user wants to control evaluation order, then `pseq` is the right way to do it, not `seq`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 22:17:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 22:17:01 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.1c2b0980bc29f7219d757f7bd6bccfd0@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by simonpj): I don't have a strong opinion; (C) is fine with me if library authors are happy. Maybe they will be; after all, they didn't have lifted coercions before, and (by default) they still won't. Note that (C) is not related to the visiblity or otherwise of a recursive set of data constructors; it's simply a question of what the default roles for an un-annotated data type are. Does anyone else care? It's a tremendous pity that all this is happening just as 7.8 is on the verge of release (indeed, I thought it had already happened). I am reluctant to delay it while we debate this issue further. (I am not optimistic about a rapid consensus.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 22:35:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 22:35:57 -0000 Subject: [GHC] #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) In-Reply-To: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> References: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> Message-ID: <068.d8a9006c1b5f0e66fe552d12547c7425@haskell.org> #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ---------------------------------------+---------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by volodya): It is still producing the same error. I'm trying to compile the package with the flag as follows: {{{ cabal build --gcc-options=-nostdinc }}} and as follows: {{{ runhaskell Setup.hs build --gcc-options=-nostdinc }}} What have I missed? Debian testing ghc 7.8.20140228-1 gcc 4.8.2-2 biinutils 2.24-4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 23:09:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 23:09:59 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.c2f36da09d21175ae8d6b3aa0b94f5a4@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by carter): in what cases would (C) break pre 7.8 code? I think we should at least get Edwardk's take on this, at the very least.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 23:36:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 23:36:27 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.e0e4c32dc4f372373314e2aaab6d140a@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by ekmett): Both the (A) and (C) solutions have bad cases. It comes down to picking a poison. In (C), picking `nominal` as the default role means the `GeneralizedNewtypeDeriving` basically goes away with GHC 7.8. You will be unable to use GND for anything unless every author above you in the chain puts role annotations in. Moreover, we'll be stuck writing them forever for every data type. It still closes the GND loopholes, but it does so by nuking the site from orbit. For (A), picking `representational` as the default role means that authors have to deal with unexpected encapsulation leaks. This required a half dozen annotations over `base`, and a couple in `containers`, maybe a dozen in `lens` and affects a relative minority of modules. Both scenarios are bad. Argument in favor of (A) is that many authors have already refactored to write their instances this way over the course of the last 2 release candidates, because we've been hammering home that they'll have to deal with it and that in the long term it is less work for everyone going forward, but it does mean that the folks who do care about `SafeHaskell` need to be conscious of the new language feature. I rather don't like the fact that (A) puts a new burden on people silently, but I ''really'' don't like that (C) requires literally everyone to annotate everything forever. We'd never stop paying that tax, and everyone who thought they were ready for 7.8 is back to the drawing board, and needs to start preparing for the release anew. Turning this around to try to find something productive here, I have two thoughts: 1.) One option might be to add a warning to any data type that doesn't export its constructors that has representational role. That isn't perfect. Some folks expose constructors in `other-modules` that they don't leak to to the end user in `exposed-modules`, but it'd be a start and covers for example, the cases in `containers`. 2.) Is there actually a `SafeHaskell` problem here at all? `coerce` itself isn't currently exposed in a `Safe` module, so it can't be used for a `SafeHaskell` exploit directly without trust. I am currently unaware of any path by which we can abuse GND alone to obtain a coercion. If (2) holds, then while it is annoying to library authors that there is a new avenue to deal with that can violate their encapsulation, it does come into user-land from the same `GHC.Prim` module that you get `unsafeCoerce#` from, which can do everything `coerce` can do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 23:46:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 23:46:20 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.6103913b50f3b0a93801bd0d0b9ac612@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by ekmett): One option here is to just retain the status quo that `GeneralizedNewtypeDeriving` isn't available in `Safe` Haskell. Then you'd retain the invariant that GND absolutely can't be used to violate library invariants, and since `coerce` isn't available in `Safe` mode without explicit trust, the interaction of these two features goes away completely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 23:55:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 23:55:09 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.9b9a4c8f87d8dc66ddd24d5b300cb350@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by dterei): What of this: * nominal by default when constructors aren't all exported * representational by default when all constructors are exported I understand the concern with (C) and the burden, I'm just not sure how high it is with some heuristics applied as suggested above. I like this approach (although I may be missing some corner cases) as it matches what I feel is a good high level starting point that GND and surrounding infrastructure (coercion) shouldn't allow you to write code that you couldn't write by hand unless explicitly opted-in by the library author. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 21 23:59:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Mar 2014 23:59:30 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.e08fdccc9a25bca2d6b882ee79c9173f@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by goldfire): I tend to agree with Edward's comments above, except on one perhaps- critical point: since RC 2, there is now a new module `Data.Coerce` in base that ''does'' export `coerce` Safe-ly. So, Edward's point (2) is incorrect. See #8745. Separately, there has been a fair amount of debate between choices (A) and (C). I have advocated for (A), based on decreasing the pain for library authors. Perhaps in a clean-slate implementation of a language with `coerce`, I would favor (C), but that is not the case we have in front of us. (Yes, under (C), we would require more annotations, but we already require a host of instance declarations for many types, and this would just be yet another thing that Haskellers would know to do.) The recursive-constructor-check that is described in the beginning of this ticket has lost its luster for me. If Safe inference worked, it would solve most of the problems brought up with the interaction between Safe and `coerce`. But, it also makes the `coerce` feature / GND very bowdlerized under Safe Haskell, and many desired uses of GND would no longer be possible. And, it's ugly from a user standpoint, requiring lots of importing of names unmentioned in code. I see a two feasible ways forward, given the lateness of hour: 1) Keep the status quo. 2) Remove GND and `coerce` from the Safe subset for 7.8. We could look into ways of bringing them into Safe Haskell for 7.10. In particular, I don't think that Simon's option (C) is viable, unless we want a Release Candidate 3, which I don't. Separately from the choice between (1) and (2), I definitely favor issuing warnings around missing role annotations, but it's unclear to me where the warnings should go. Edward's idea for warning when abstractly exporting a type with representational roles and no role annotation is a good start, and is perhaps the answer. David's suggestion above (controlling roles in export lists) seems to present strange action-at-a-distance, in that if I don't export constructors from their defining module, the behavior is different from when I don't export the constructors from a different module. I worry that, while perhaps catching common cases, it would be very unexpected behavior in the details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 00:01:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 00:01:47 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.702d5bd557bbcf16acf9d093f04389c7@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by thoughtpolice): Just as a note, I was talking with Edward about this for just a moment, and I'm inclined to agree with him and Richard that we should bar GND and `Data.Coerce` from `-XSafe` for 7.8 as this discussion goes on. It's a bit 11th hour, but the changes are easy and safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 00:10:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 00:10:12 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.feef7171e7caf5f874427ada097724af@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by thoughtpolice): BTW, I ran `nofib` earlier and the results seem pretty conclusive on amd64: this change has minimal - if any - impact. Here's the overview: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min +0.0% -0.2% -6.5% -4.1% +0.0% Max +0.0% +0.0% +5.4% +5.4% +3.0% Geometric Mean -0.0% -0.0% -0.1% +0.1% +0.0% }}} I imagine the differences here are mostly noise due to my machine - the affected programs don't even use dynamic when compiled with nofib. Compile times remain effectively unchanged: {{{ -1 s.d. ----- -2.7% +1 s.d. ----- +3.4% Average ----- +0.3% }}} I saw this consistently on both my Linux/amd64 machines and OSX/amd64 machines. I'll get i386 benchmarks soon, as this is where we will likely see any possible difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 00:26:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 00:26:50 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.c433506681335e9c55a957f58a680b5c@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): based on the discussion on the lens thread, i have changed the CPPHS case in the configure.ac for --with-hs-cpp set the Haskell CPP flags to "--cpp --traditional" mind you, until those other hard coded cases in the build system are addressed (simon m said he'll be helping resolve some of them), doesn't change rest of patch :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 00:28:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 00:28:16 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.5a4177114a3d2eaa224b2033ed73542a@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by ekmett): Ah. I had missed the addition of `Data.Coerce`. I think the least pain would be temporarily marking that module Unsafe, and reverting to the pre 7.8 rule of no GND under `Safe` and then all we'll have "done no harm" as all code that worked before will continue to work and no new security problems will have been introduced. I'd also be okay with looking into the 'if you don't export all your constructors you get a nominal role' rule for 7.10, but I am somewhat leery of introducing it in 7.8 after folks have already braced for a rather different impact. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 01:10:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 01:10:27 -0000 Subject: [GHC] #8831: Cannot use Template Haskell splice in ghci In-Reply-To: <047.1688ea3628125d840e5d96b182466527@haskell.org> References: <047.1688ea3628125d840e5d96b182466527@haskell.org> Message-ID: <062.e3223126574cdc2767fce3f00a5dc53d@haskell.org> #8831: Cannot use Template Haskell splice in ghci -------------------------------------+---------------------------------- Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"f9b6a2bb6574904ab11476d79896491b111ad7cc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f9b6a2bb6574904ab11476d79896491b111ad7cc" testsuite: add test for #8831 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 01:10:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 01:10:28 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.94975821e3dd41e9db85c3bb62889f2d@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"7a1c85113dd082153cc07f4792216beaf34daeeb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7a1c85113dd082153cc07f4792216beaf34daeeb" linker: Fix indirect calls for x86_64 windows (#2283) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 01:10:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 01:10:28 -0000 Subject: [GHC] #8600: ghc --help is outdated In-Reply-To: <048.bdb06add437102212b23e2d2cf0573f6@haskell.org> References: <048.bdb06add437102212b23e2d2cf0573f6@haskell.org> Message-ID: <063.0a3fd97812e1dfa7c235c2b0d5c5512f@haskell.org> #8600: ghc --help is outdated -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"99ef27913dbe55fa57891bbf97d131e0933733e3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="99ef27913dbe55fa57891bbf97d131e0933733e3" Update ghc --help references to --make and a.out (fixes #8600) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 03:48:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 03:48:24 -0000 Subject: [GHC] #8917: :kind! does not work under type constructors Message-ID: <047.7c2cbf8df2580654e4b144c0c3c47c5e@haskell.org> #8917: :kind! does not work under type constructors ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Say I have the following: {{{ {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies #-} module Scratch where data Nat = Zero | Succ Nat type family a + b where Zero + a = a (Succ n) + m = Succ (n + m) }}} I load this into ghci. See what happens next: {{{ GHCi, version 7.8.0.20140228: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Scratch ( Scratch.hs, interpreted ) Ok, modules loaded: Scratch. *Scratch> :kind! Zero + Succ Zero Zero + Succ Zero :: Nat = 'Succ 'Zero *Scratch> :kind! Succ (Zero + Zero) Succ (Zero + Zero) :: Nat = 'Succ ('Zero + 'Zero) }}} Note the last line. It doesn't reduce under the `Succ`! I will fix shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 04:31:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 04:31:50 -0000 Subject: [GHC] #8918: Network package doesn't load under GHC 7.8 RC on windows (?) Message-ID: <047.1e9ba761fa9dc023d8755ecfd2935d3e@haskell.org> #8918: Network package doesn't load under GHC 7.8 RC on windows (?) -------------------------------------+--------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1-rc1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- (Please note that I am not certain that this issue is related to the 7.8 release candidate specifically, it may be some peculiarity of my system. But the same thing does work for me under 7.6.3 on the same machine. I don't understand exactly what the message is complaining about, so I don't feel confident in making a diagnosis. I don't know if the problem is me, the library, or ghc.) Under the GHC 7.8 rc1 build for Windows that I installed, I can't load the network package. In the course of upgrading one of my projects, I cabal install'd the network-conduit package, and network is one of the dependencies. The install worked fine, with the usual sprinkling of deprecation warnings and "rule might not fire because..." warnings, nothing that seemed unusual or alarming. I can't however actually load the package. {{{ GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help 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.4.0 ... linking ... done. Loading package Win32-2.3.0.1 ... 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.1 ... linking ... done. Loading package directory-1.2.0.2 ... linking ... done. Loading package base-unicode-symbols-0.2.2.4 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package transformers-base-0.4.1 ... linking ... done. Loading package monad-control-0.3.2.3 ... linking ... done. Loading package lifted-base-0.2.2.1 ... linking ... done. Loading package mmorph-1.0.2 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package resourcet-0.4.10 ... linking ... done. Loading package text-1.1.0.1 ... linking ... done. Loading package text-stream-decode-0.1.0.4 ... linking ... done. Loading package hashable-1.2.1.0 ... linking ... done. Loading package nats-0.1.2 ... linking ... done. Loading package unordered-containers-0.2.3.3 ... linking ... done. Loading package semigroups-0.12.2 ... linking ... done. Loading package void-0.6.1 ... linking ... done. Loading package conduit-1.0.15.1 ... linking ... done. Loading package parsec-3.1.5 ... linking ... done. Loading package network-2.4.2.2 ... linking ... ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of __imp_inet_ntoa ghc.exe: C:\Users\Doug\Documents\GitHub\bird-brain\.cabal-sandbox\x86_64 -windows-ghc-7.8.20140130\network-2.4.2.2\libHSnetwork-2.4.2.2.a: unknown symbol `WspiapiGetNameInfo' ghc.exe: unable to load package `network-2.4.2.2' }}} (The good bit was way at the end of a line, so repeated where you can see it...) {{{ network-2.4.2.2\libHSnetwork-2.4.2.2.a: unknown symbol `WspiapiGetNameInfo' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 10:17:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 10:17:22 -0000 Subject: [GHC] #8885: Add inline versions of clone array primops In-Reply-To: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> References: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> Message-ID: <059.e2c99f6a16f79c0478d407fe18ac027d@haskell.org> #8885: Add inline versions of clone array primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): I've rebased the first three patches, validated them, and submitted them as: In [changeset:1eece45692fb5d1a5f4ec60c1537f8068237e9c1/ghc]: {{{ commit 1eece45692fb5d1a5f4ec60c1537f8068237e9c1 Author: Johan Tibell Date: Thu Mar 13 09:35:21 2014 +0100 codeGen: inline allocation optimization for clone array primops The inline allocation version is 69% faster than the out-of-line version, when cloning an array of 16 unit elements on a 64-bit machine. Comparing the new and the old primop implementations isn't straightforward. The old version had a missing heap check that I discovered during the development of the new version. Comparing the old and the new version would requiring fixing the old version, which in turn means reimplementing the equivalent of MAYBE_CG in StgCmmPrim. The inline allocation threshold is configurable via -fmax-inline-alloc-size which gives the maximum array size, in bytes, to allocate inline. The size does not include the closure header size. Allowing the same primop to be either inline or out-of-line has some implication for how we lay out heap checks. We always place a heap check around out-of-line primops, as they may allocate outside of our knowledge. However, for the inline primops we only allow allocation via the standard means (i.e. virtHp). Since the clone primops might be either inline or out-of-line the heap check layout code now consults shouldInlinePrimOp to know whether a primop will be inlined. }}} This commit does not include `0004-codeGen-cloneArray-use-index-based-for- loop-instead-.patch`, which was incorrect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 10:17:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 10:17:42 -0000 Subject: [GHC] #8885: Add inline versions of clone array primops In-Reply-To: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> References: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> Message-ID: <059.0230b44d07ba70d8655c9a66c939b138@haskell.org> #8885: Add inline versions of clone array primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tibbe): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 10:49:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 10:49:34 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.90f83fd46680aa591af85b43f1b1a9c0@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by nomeata): May I throw the suggestion in comment:14 again into the ring? Most data types are exported with their constructors, so we want their users to `coerce` and GND as they wish; with that suggestion, no additional annotations are needed, and `coerce` can be replaced by hand-written code. Abstract type constructors would, under this proposal, not be coercible by default, but this can easily be enabled using `deriving` (even `instance deriving` anywhere where the corresponding manual code can be written). This is a variant of David?s suggestion (controlling roles in export lists) in that we correlate coercibility with constructor scope, but does not have the awkwardness of making the defining module?s export list special. In fact, it would quite precisely follow the guidance of ?coerce (and GND) work exactly when you could write manual code for it?. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 10:53:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 10:53:25 -0000 Subject: [GHC] #8831: Cannot use Template Haskell splice in ghci In-Reply-To: <047.1688ea3628125d840e5d96b182466527@haskell.org> References: <047.1688ea3628125d840e5d96b182466527@haskell.org> Message-ID: <062.9f1e656e28c638da4db6713fb15b433a@haskell.org> #8831: Cannot use Template Haskell splice in ghci -------------------------------------+---------------------------------- Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by Joachim Breitner ): In [changeset:"4bc3c8265f988f4456664f502164f52466aab67d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4bc3c8265f988f4456664f502164f52466aab67d" Mark test for #8831 as known-broken to keep validate working. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 11:41:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 11:41:53 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? Message-ID: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> #8919: Why is xhtml library installed but not exported to users? ------------------------------------+------------------------------------- Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC 7.8.1-rc2 installs the xhtml library, but doesn't export it, i.e. it's completely invisible to users. Is there a particular reason why this setup is necessary? If GHC needs that library internally anywhere, would it be possible to link it statically and *not* install it? Or, if that's not possible, if the library needs to be installed, please make it visible to users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 11:47:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 11:47:11 -0000 Subject: [GHC] #8884: Reifying closed type families is broken In-Reply-To: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> References: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> Message-ID: <062.248a08b74d193b4344debc4e6a66c8a5@haskell.org> #8884: Reifying closed type families is broken -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T8884 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: closed => merge Comment: The test case fix should also be merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 12:25:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 12:25:55 -0000 Subject: [GHC] #8920: Alternative GADT syntax Message-ID: <044.aac5121bf5758b0193e2f09652955ddf@haskell.org> #8920: Alternative GADT syntax ----------------------------------------------+---------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Parser) | Version: Keywords: gadts | 7.8.1-rc2 Architecture: Unknown/Multiple | Operating System: Difficulty: Moderate (less than a day) | Unknown/Multiple Blocked By: | Type of failure: Other Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- An alternative syntax for GADTs Instead of {{{ data Term x where K :: Term (a -> b -> a) S :: Term ((a -> b -> c) -> (a -> b) -> a -> c) Const :: a -> Term a (:@) :: Term (a -> b) -> (Term a) -> Term b }}} You can write {{{ data Term x = K :: Term (a -> b -> a) | S :: Term ((a -> b -> c) -> (a -> b) -> a -> c) | Const a :: Term a | (:@) (Term (a -> b)) (Term a) :: Term b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 14:31:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 14:31:42 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.ede6993ed45ce56b19e8f299567097c0@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by tibbe): Replying to [comment:42 simonmar]: > Well, one bug is that in `emitPopCntCall` we don't cast the argument to the correct width. I don't think it should. The `MO_PopCnt` `MachOp` that's emitted by `emitPopCntCall` also takes the width as an argument. The reason we pass the width all the way down to the native and LLVM code generators is to avoid doing any narrowing, as we can emit a `popcnt` instruction that looks at just part of the word (e.g. `popcnt %ax,%ax`). If we end up not using the the dedicated instruction, and we're using GCC 4.2 which doesn't do the narrowing correctly, then we'd have to do the narrowing ourselves before calling the C fallback. I think we have two choices in working around the buggy behavior of GCC 4.2: 1. Change the function prototype as rwbarton suggested. 2. Do some narrowing in the native code generator before emitting the call to the C function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 14:52:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 14:52:02 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.86b3943d16e02309e2b6219bbbb92d09@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by tibbe): I've attached the assembly output for `popcnt.c` (in ghc-prim) and a small C test program, `test.c`, for GCC 4.2 and GCC 4.9, respectively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 15:20:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 15:20:06 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.c0624cc50bcd6812291fd94a33c3e4b9@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by tibbe): Now I'm confused. Both GCC 4.2 (apple-gcc42 from Homebrew) and GCC 4.9 create the correctly zero extended code for `hs_popcnt8`: GCC 4.2 {{{ #!asm _hs_popcnt8: LFB112: pushq %rbp LCFI0: movq %rsp, %rbp LCFI1: movzbl %dil, %edi leaq _popcount_tab(%rip), %rax movzbl (%rdi,%rax), %eax leave ret }}} GCC 4.9: {{{ #!asm _hs_popcnt8: LFB110: leaq _popcount_tab(%rip), %rax movzbl %dil, %edi movzbl (%rax,%rdi), %eax ret }}} Exact GCC versions: {{{ $ gcc-4.2 --version i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) ... $ gcc-4.9 --version gcc-4.9 (GCC) 4.9.0 20140223 (experimental) ... }}} Perhaps this bug was fixed in some release of GCC 4.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 15:57:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 15:57:31 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.770a0bde5fbfb8e52906911a84b637bf@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by tibbe): I think I've figured it out. I've installed the CLI tools that came with XCode 4.6. Here's the gcc that's included: {{{ $ gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) }}} So this is a LLVM-based GCC (i.e. clang). This GCC indeed produces incorrect code for `popcnt.c`: {{{ #!asm _hs_popcnt8: Leh_func_begin1: pushq %rbp Ltmp0: movq %rsp, %rbp Ltmp1: leaq _popcount_tab(%rip), %rax movzbl (%rdi,%rax), %eax popq %rbp ret }}} Note how the argument is not zero extended when it's used to compute and address in `_popcount_tab`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 16:18:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 16:18:31 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.9e190688bfa61fe0208c49917cad233d@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by dterei): So given the late hour, perhaps (sadly) as others have suggested, we keep the status quo for 7.8 and leave GND and Coercion unsafe. Be nicer if we could have solved for 7.8 but that's on me for not be reachable easily or following the mailing list. Going forward, my suggestion or a similar proposal such as nomeata's in comment:27 sound the nicest to me. We could potentially argue for this with data as well by seeing how prevalent coercion and GND is on abstract types that don't have explicit roles. If everyone can quickly reach consensus though on the above proposal then I'm very happy with that as well :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 16:25:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 16:25:23 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.dd42c787769d7b993a8ad8ad45302df3@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by carter): gcc-llvm I think is the apple version of dragonegg, which uses the proper GCC frontend, but does the code gen with llvm -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 16:30:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 16:30:18 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.efc80f4df3d1c2efb0e1f310f62ff33e@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by tibbe): I chatted a bit with rwbarton about the semantics of these primops. My intention is that all the primops work on all input sizes (much like the underlying assembly instruction) and the difference is just the number of bit we count. The code implements this behavior correctly, if it weren't for LLVM misbehaving. The reason I implemented the primops this way is that I wanted to avoid the narrowing. This means that even if we had a `Word8#` type, the primops would still operate on a `Word#`. Does that make sense? If so the right fix is to work around the LLVM bug in `popcnt.c`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 16:38:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 16:38:42 -0000 Subject: [GHC] #8741: `System.Directory.getPermissions` fails on read-only filesystem In-Reply-To: <042.41e003931db44554a93be772501d4d70@haskell.org> References: <042.41e003931db44554a93be772501d4d70@haskell.org> Message-ID: <057.2bcdf7d6c2e7c1c771b0c8a5c5614497@haskell.org> #8741: `System.Directory.getPermissions` fails on read-only filesystem -------------------------------------+------------------------------------- Reporter: hvr | Owner: AlainODea Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: libraries/unix | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"444750d2e5c6b843b937cbe876ce248e76a2a245/unix"]: {{{ #!CommitTicketReference repository="unix" revision="444750d2e5c6b843b937cbe876ce248e76a2a245" Handle EROFS/ETXTBSY as permission denied in `fileAccess` (re #8741) This extends `System.Posix.Files.`access` to map EROFS & ETXTBSY to mean permission denied just like EACCESS. Based on a patch by Alain O'Dea and comments by Duncan Coutts Authored-by: Alain O'Dea Signed-off-by: Herbert Valerio Riedel (cherry picked from commit ecc92abad017cf12d8eb83509d4d57ae14ad47f9) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 16:46:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 16:46:05 -0000 Subject: [GHC] #8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64) In-Reply-To: <047.86e8206e31b6dc590c59487f4d1109a7@haskell.org> References: <047.86e8206e31b6dc590c59487f4d1109a7@haskell.org> Message-ID: <062.c5f3ce45fba0b027852cfb114a24007c@haskell.org> #8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64) -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 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 carter): * cc: carter.schonwald@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 16:49:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 16:49:14 -0000 Subject: [GHC] #8898: Overall improvement for randomIvalInteger In-Reply-To: <050.d45afe73360610d848e4eba302442e5f@haskell.org> References: <050.d45afe73360610d848e4eba302442e5f@haskell.org> Message-ID: <065.ff9cf731948bd7f3d60fbf2d3f74fb3b@haskell.org> #8898: Overall improvement for randomIvalInteger -------------------------------------+------------------------------------- Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: #5278 #5280 #1120 -------------------------------------+------------------------------------- Comment (by hvr): Please re-file this at `random`'s GitHub issue tracker over at https://github.com/haskell/random/issues -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 17:05:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 17:05:08 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.97be27f7c8fc853486bb9c5f3e68e309@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by goldfire): I'll admit to liking the general flavor of comment:27, but the details elude me somewhat. What, precisely, would go after the word `deriving`? What's the interaction between derived instances and role annotations? Could a derived instance be more restrictive than the assigned roles? (It certainly couldn't be ''less'' restrictive!) How would a user specify that? On a separate note, and with no intention to start a flame war, this process would have been easier if we had had a more accurate timeline on the 7.8 release. When some of this debate started in October, we debated under the "late hour" premise, as well. The RCs hadn't gone out, obviously, but any less-than-almost-fully-baked idea was discarded as "too much work too late". If we had known that we had a few months to work out a proposal and implement it, it's possible that we'd be in a better place today. Of course, schedules slip, but communicating a best guess (even as that guess changes) would have been helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 17:15:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 17:15:14 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.e7a26f1c4184abb4e7e28a2f62d51a96@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by nomeata): > I'll admit to liking the general flavor of comment:27, but the details elude me somewhat. What, precisely, would go after the word deriving? Well, either `data MyList a = [a] deriving Coercible`, which will give you the same instance as described in the paper, but independent of the scope of the constructor. Or `deriving instance Coercible a b => Coercible (Map k a) (Map k b)`, which allows you to control the coercing This is even strictly more powerful that our current system: It would allow the author of `Map` to export the instance above, while still using `coerce` in his code (with constructors in scope and no abstraction to follow) to coerce the key, if he wishes to do so. > What's the interaction between derived instances and role annotations? Could a derived instance be more restrictive than the assigned roles? (It certainly couldn't be less restrictive!) How would a user specify that? As you say: The derived instance have to adhere the roles, but may be more restrictive (if created using a standalone deriving instance). The non- standalone-deriving instance would be the one that we have currently. OTOH, this gets hairy once we mix tycons with exported constructors and tycons without, but with exported Coercible instances, in a new data declaration and try to find out when we can coerce under ''that''... and that issue is well handled by roles and role inference. *shrug* -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 17:35:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 17:35:11 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.c1ec52201ffd218bb49de73d83258dc8@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by Johan Tibell ): In [changeset:"ad9bf96815cb5a9bb4acc51c99eff20be3e50da3/ghc-prim"]: {{{ #!CommitTicketReference repository="ghc-prim" revision="ad9bf96815cb5a9bb4acc51c99eff20be3e50da3" Make argument types in popcnt.c match declared primop types On 64-bit Mac OS, gcc 4.2 (which comes with Xcode 4.6) generates code that assumes that an argument that is smaller than the register it is passed in has been sign- or zero-extended. But ghc thinks the types of the PopCnt*Op primops are Word# -> Word#, so it passes the entire argument word to the hs_popcnt* function as though it was declared to have an argument of type StgWord. Segfaults ensue. The easiest fix is to sidestep all this zero-extension business by declaring the hs_popcnt* functions to take a whole StgWord (when their argument would fit in a register), thereby matching the list of primops. Fixes #7684. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 17:37:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 17:37:48 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.187dd2c0c219c7b88a21156052f1eaf3@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by tibbe): I've applied rwbarton's patch, which means that we implement the semantics I described above, just like I originally intended (and just like the -msse4.2 version behaves). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 17:38:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 17:38:00 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.42a74f2450f66f92c2da417f3dee744d@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by tibbe): * status: infoneeded => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 18:02:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 18:02:24 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.cd4dc51822446daaccb440136180188d@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by rwbarton): Any particular reason not to merge to 7.8? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 18:04:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 18:04:27 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.81b580d5c77314f9e3d87d6dd769782b@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by ekmett): {{{ deriving Coercible a b => Coercible (Map k a) (Map k b) }}} is somewhat in line with what I've been playing around with to try to work out how we can lift coercions over complex data types. e.g. {{{ class Representational (t :: k1 -> k2) where rep :: Coercion a b -> Coercion (t a) (t b) default rep :: Phantom t => Coercion a b -> Coercion (t a) (t b) rep _ = phantom class Representational t => Phantom t where phantom :: Coercion (t a) (t b) default phantom :: Coercible (t a) (t b) => Coercion (t a) (t b) phantom = Coercion }}} Then easy cases we can already handle work: {{{ instance Representational Proxy instance Phantom Proxy instance Representational Tagged instance Phantom Tagged instance Representational (Tagged a) where rep Coercion = Coercion instance Representational Const where rep Coercion = Coercion instance Representational (Const a) instance Phantom (Const a) instance Representational Coercion where rep = unsafeCoerce instance Representational (Coercion a) where rep Coercion = Coercion instance Representational (->) where rep Coercion = Coercion instance Representational ((->) a) where rep Coercion = Coercion }}} But with a few helpers {{{ coerce1 :: Coercible a b => Coercion a c -> Coercion b c coerce1 = coerce coerce2 :: Coercible b c => Coercion a b -> Coercion a c coerce2 = coerce -- from Control.Lens as a placeholder new :: (Rewrapping s t, Coercible (Unwrapped s) s, Coercible (Unwrapped t) t) => Coercion (Unwrapped s) (Unwrapped t) -> Coercion s t new = coerce1 . coerce2 -- I don't see how to implement this one directly eta :: forall (f :: x -> y) (g :: x -> y) (a :: x). Coercion f g -> Coercion (f a) (g a) eta = unsafeCoerce }}} we can write several hard cases that are currently beyond our reach: {{{ instance (Representational f, Representational g) => Representational (Compose f g) where rep = new.rep.rep instance Representational m => Representational (StateT s m) where rep = new.rep.rep.eta.rep instance Representational m => Representational (ReaderT e m) where rep = new.rep.rep instance Representational m => Representational (WriterT w m) where rep = new.rep.eta.rep }}} Then instead of lifting `Coercible a b` into `Coercible (f a) (f b)` based on the role of f's next argument, it'd lift using the `Representational` instance. I'd been mostly exploring this as a straw man, but if we're throwing 'big changes' into the discussion, I felt it worth mentioning as a direction. Mind you the code I have above is implementable and implemented with the existing `Coercible` machinery. It isn't perfect though, e.g. I don't know a better way to implement {{{ instance Representational f => Representational (Compose f) where rep = unsafeCoerce }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 18:39:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 18:39:31 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.4ca5fd10231e3150eb206813cf36c659@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by hvr): * status: closed => merge Comment: I'll mark this for merge (if not 7.8.1 then it might make it into 7.8.2) and let Austin decide -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 19:40:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 19:40:57 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.0cb21b4452afb3864c620f22145ed798@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by thoughtpolice): * owner: jstolarek => * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 19:41:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 19:41:09 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.6411ffc7fbb48868b9511be9b5ad628f@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by thoughtpolice): * owner: => jstolarek -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 19:41:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 19:41:26 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.1b2145efde3fedc3f2f65df2288161a9@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged in HEAD and 7.8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 19:43:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 19:43:14 -0000 Subject: [GHC] #8738: msys2 fails cabal01 test In-Reply-To: <045.e5b4b4cce287d04bf2354c1ec173d94b@haskell.org> References: <045.e5b4b4cce287d04bf2354c1ec173d94b@haskell.org> Message-ID: <060.eca2089401185e17a147aa6b8553804e@haskell.org> #8738: msys2 fails cabal01 test ------------------------------------------------+-------------------------- Reporter: ezyang | Owner: refold Type: bug | Status: patch Priority: low | Milestone: Component: Test Suite | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: cabal01 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Austin Seipp ): In [changeset:"be2e0e88d7ddd33eef8277c8d67f0b0f3e2874be/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="be2e0e88d7ddd33eef8277c8d67f0b0f3e2874be" Make cabal01 pass with Cabal 1.18 (#8738). Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 19:43:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 19:43:56 -0000 Subject: [GHC] #8738: msys2 fails cabal01 test In-Reply-To: <045.e5b4b4cce287d04bf2354c1ec173d94b@haskell.org> References: <045.e5b4b4cce287d04bf2354c1ec173d94b@haskell.org> Message-ID: <060.6ac480b781e43673e31770570a4e490f@haskell.org> #8738: msys2 fails cabal01 test ------------------------------------------------+-------------------------- Reporter: ezyang | Owner: refold Type: bug | Status: closed Priority: low | Milestone: Component: Test Suite | Version: 7.9 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: cabal01 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 19:44:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 19:44:18 -0000 Subject: [GHC] #8884: Reifying closed type families is broken In-Reply-To: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> References: <047.359a44e5e87bf466a243e69d2f023f11@haskell.org> Message-ID: <062.8ac801a0a4bfad348755d10d86c6b7f6@haskell.org> #8884: Reifying closed type families is broken -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T8884 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed Comment: Fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 19:45:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 19:45:55 -0000 Subject: [GHC] #8600: ghc --help is outdated In-Reply-To: <048.bdb06add437102212b23e2d2cf0573f6@haskell.org> References: <048.bdb06add437102212b23e2d2cf0573f6@haskell.org> Message-ID: <063.9d4b5b3bfee69d3c18d611ce18be16ce@haskell.org> #8600: ghc --help is outdated -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 19:49:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 19:49:24 -0000 Subject: [GHC] #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" In-Reply-To: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> References: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> Message-ID: <063.9713113acb82e08cb29e6bbbf7cc7440@haskell.org> #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" ----------------------------------+---------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.2 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by thoughtpolice): * milestone: 7.8.1 => 7.8.2 Comment: I've been testing a Cabal built with RC2 on OS X for quite a long time now and cannot reproduce this on Lion or Mavericks, so I'm punting this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 20:16:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 20:16:50 -0000 Subject: [GHC] #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(dyn) test Message-ID: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(dyn) test -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Solaris Architecture: x86_64 (amd64) | Type of failure: Compile-time Difficulty: Easy (less than 1 | crash hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- On SmartOS ghc-stage2 crashes with an error when trying to run the topHandler02(dyn) test: ld: fatal: library -lrt: not found Tracing this with the following DTrace script to stop ghc-stage2 at the point of launching ld: '''~/exit_on_ld.d''': {{{ #!/usr/sbin/dtrace -s #pragma D option destructive syscall::exec*:entry /copyinstr(arg0) == "/usr/bin/ld"/ { trace(pid); stop(); system("pargs %d", pid); exit(0); } }}} This let me observe the command-line arguments to ld: In ssh session A I started DTrace: {{{ chmod +x ~/exit_on_ld.d ~/exit_on_ld.d }}} In a ssh session B I started the topHandler02(dyn) test manually with no output redirection: {{{ cd ~/ghc/libraries/base/tests && '/root/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history -o topHandler02 topHandler02.hs -O -prof -static -auto-all -threaded }}} In ssh session A I observed the ld call (ghc-stage2 is now frozen by stop): {{{ CPU ID FUNCTION:NAME 3 5167 exece:entry 9186691866: /opt/local/gcc47/libexec/gcc/x86_64-sun-solaris2.11/4.7.3/collect2 -R/opt/local argv[0]: /opt/local/gcc47/libexec/gcc/x86_64-sun- solaris2.11/4.7.3/collect2 argv[1]: -R/opt/local/lib/ argv[2]: -Y argv[3]: P,/lib/amd64:/usr/lib/amd64:/opt/local/lib/ argv[4]: -Qy argv[5]: -o argv[6]: topHandler02.o argv[7]: -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3 argv[8]: -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../../../x86_64-sun-solaris2.11/lib/amd64 argv[9]: -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../../amd64 argv[10]: -L/lib/amd64 argv[11]: -L/usr/lib/amd64 argv[12]: -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../../../x86_64-sun-solaris2.11/lib argv[13]: -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/../../.. argv[14]: -R/opt/local/gcc47/x86_64-sun-solaris2.11/lib/amd64 argv[15]: -R/opt/local/gcc47/lib/amd64 argv[16]: -lrt argv[17]: -r argv[18]: /tmp/ghc91814_0/ghc91814_6.o argv[19]: /tmp/ghc91814_0/ghc91814_5.o }}} I was then able to run them in isolation with GHC's temp files present on disk: {{{ # /opt/local/gcc47/libexec/gcc/x86_64-sun-solaris2.11/4.7.3/collect2 -R/opt/local/lib/ -Y P,/lib/amd64:/usr/lib/amd64:/opt/local/lib/ -Qy -o topHandler02.o -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3 -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/../../../../x86_64 -sun-solaris2.11/lib/amd64 -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../../amd64 -L/lib/amd64 -L/usr/lib/amd64 -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/../../../../x86_64 -sun-solaris2.11/lib -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../.. -R/opt/local/gcc47/x86_64-sun- solaris2.11/lib/amd64 -R/opt/local/gcc47/lib/amd64 -lrt -r /tmp/ghc91814_0/ghc91814_6.o /tmp/ghc91814_0/ghc91814_5.o ld: fatal: library -lrt: not found ld: fatal: file processing errors. No output written to topHandler02.o collect2: error: ld returned 1 exit status }}} If I omit '''-lrt''' from the arguments it succeeds (on Illumos-based systems, including SmartOS, librt is a passthrough to libc): {{{ # /opt/local/gcc47/libexec/gcc/x86_64-sun-solaris2.11/4.7.3/collect2 -R/opt/local/lib/ -Y P,/lib/amd64:/usr/lib/amd64:/opt/local/lib/ -Qy -o topHandler02.o -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3 -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/../../../../x86_64 -sun-solaris2.11/lib/amd64 -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../../amd64 -L/lib/amd64 -L/usr/lib/amd64 -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/../../../../x86_64 -sun-solaris2.11/lib -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../.. -R/opt/local/gcc47/x86_64-sun- solaris2.11/lib/amd64 -R/opt/local/gcc47/lib/amd64 -r /tmp/ghc91814_0/ghc91814_6.o /tmp/ghc91814_0/ghc91814_5.o # echo $? 0 }}} No errors are emitted and the exit code is 0 (good). I would like to conditionally omit '''-lrt''' from the ld arguments. Where do I need to look for where ghc-stage2 populates the arguments to ld? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 21:38:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 21:38:07 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.5316ad48e75d33771ffb97fd7d731349@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by kgardas): Austin, could you be so kind and merge the "change deriveConstants to use nm in a POSIX way" patch to HEAD? This basically allows us to use Solaris' own nm and not need to rely on GNU nm on this OS. Also it preserves compatibility with GNU nm of course! Thanks! Karel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 22:39:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 22:39:43 -0000 Subject: [GHC] #8917: :kind! does not work under type constructors In-Reply-To: <047.7c2cbf8df2580654e4b144c0c3c47c5e@haskell.org> References: <047.7c2cbf8df2580654e4b144c0c3c47c5e@haskell.org> Message-ID: <062.22f092f5560b78dc5a787a309b80dad5@haskell.org> #8917: :kind! does not work under type constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"47796026ca35a2438f7a7dc337add2ec3b14f06c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="47796026ca35a2438f7a7dc337add2ec3b14f06c" Add test case for #8917 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 22:39:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 22:39:44 -0000 Subject: [GHC] #8917: :kind! does not work under type constructors In-Reply-To: <047.7c2cbf8df2580654e4b144c0c3c47c5e@haskell.org> References: <047.7c2cbf8df2580654e4b144c0c3c47c5e@haskell.org> Message-ID: <062.61f56041f77473ac33652f49ed3d7e21@haskell.org> #8917: :kind! does not work under type constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"c99941cfeee033fca2df45e9523b65c83be20d31/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c99941cfeee033fca2df45e9523b65c83be20d31" Fix #8917. FamInstEnv.normaliseTcApp should normalise arguments even when the top-level tycon isn't a type family. This was a regression from 7.6 -- not sure when it happened, but it was probably my fault. Fixed now, in any case. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 22:44:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 22:44:33 -0000 Subject: [GHC] #8920: Alternative GADT syntax In-Reply-To: <044.aac5121bf5758b0193e2f09652955ddf@haskell.org> References: <044.aac5121bf5758b0193e2f09652955ddf@haskell.org> Message-ID: <059.dde9df028e8678d0524ef45e5a853819@haskell.org> #8920: Alternative GADT syntax -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 (Parser) | Keywords: gadts Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > An alternative syntax for GADTs > > Instead of > {{{ > data Term x where > K :: Term (a -> b -> a) > S :: Term ((a -> b -> c) -> (a -> b) -> a -> c) > Const :: a -> Term a > (:@) :: Term (a -> b) -> (Term a) -> Term b > }}} > > You can write > {{{ > data Term x = K :: Term (a -> b -> a) | S :: Term ((a -> b -> c) -> (a > -> b) -> a -> c) | Const a :: Term a | (:@) (Term (a -> b)) (Term a) :: > Term b > }}} New description: An alternative syntax for GADTs Instead of {{{ data Term x where K :: Term (a -> b -> a) S :: Term ((a -> b -> c) -> (a -> b) -> a -> c) Const :: a -> Term a (:@) :: Term (a -> b) -> (Term a) -> Term b }}} You can write {{{ data Term x = K :: Term (a -> b -> a) | S :: Term ((a -> b -> c) -> (a -> b) -> a -> c) | Const a :: Term a | (:@) (Term (a -> b)) (Term a) :: Term b }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 22 23:17:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Mar 2014 23:17:08 -0000 Subject: [GHC] #8917: :kind! does not work under type constructors In-Reply-To: <047.7c2cbf8df2580654e4b144c0c3c47c5e@haskell.org> References: <047.7c2cbf8df2580654e4b144c0c3c47c5e@haskell.org> Message-ID: <062.8e534f4016d89c97bb9d49089db8cf44@haskell.org> #8917: :kind! does not work under type constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 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 thoughtpolice): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 00:24:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 00:24:30 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.e939f84a73f5acb09b5ea38e770aa5e2@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): somehow i'm tripping a "make has restarted 3 times" bug when I run validate, heres the tail of the transcript nb: i did configure with --with-gcc=gcc-4.8 and --with-hs-cpp=gcc-4.8 heres a link to the tail of the console output http://lpaste.net/101605 the relevant last few lines being {{{ Writing new package config file... done. "inplace/bin/ghc-cabal" configure ghc stage1 "" --with- ghc="/usr/local/bin/ghc" --with-ghc-pkg="/usr/local/bin/ghc-pkg" --flags=stage1 --constraint "ghc == 7.8.0.20140322" --package- db=/Users/carter/Desktop/repoScratcher/ghc/libraries/bootstrapping.conf --disable-library-for-ghci --disable-library-vanilla --disable-library- profiling --disable-shared --with- hscolour="/Users/carter/.cabal/bin/HsColour" --configure- option=CFLAGS="-Wall -m64 -fno-stack-protector -Werror=unused-but-set- variable -Wno-error=inline" --configure-option=LDFLAGS=" -m64 " --configure-option=CPPFLAGS=" -m64 " --constraint "Cabal == 1.18.1.3" --constraint "hpc == 0.6.0.1" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.10.0.0" --constraint "transformers == 0.3.0.0" --constraint "terminfo == 0.4.0.0" --with-gcc="gcc-4.8" --configure-option =--with-cc="gcc-4.8" --with-ar="/usr/bin/ar" --with-ranlib="ranlib" --with-alex="/Users/carter/.cabal/bin/alex" --with- happy="/Users/carter/.cabal/bin/happy" Configuring ghc-bin-7.8.0.20140322... Warning: 'data-dir: ..' is a relative path outside of the source tree. This will not work when generating a tarball with 'sdist'. ghc.mk:100: *** Make has restarted itself 2 times; is there a makefile bug? See http://ghc.haskell.org/trac/ghc/wiki/Building/Troubleshooting#Makehasrestarteditself3timesisthereamakefilebug for details. Stop. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 00:36:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 00:36:02 -0000 Subject: [GHC] #8917: :kind! does not work under type constructors In-Reply-To: <047.7c2cbf8df2580654e4b144c0c3c47c5e@haskell.org> References: <047.7c2cbf8df2580654e4b144c0c3c47c5e@haskell.org> Message-ID: <062.f05ec7c359e9b897e5fc18c2e41335d3@haskell.org> #8917: :kind! does not work under type constructors ---------------------------------------+----------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: ghci/scripts/T8917 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by goldfire): * testcase: => ghci/scripts/T8917 Comment: Yes, please merge. I conjecture that there are other ways to exhibit the bug fixed in this ticket without using ghci. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 00:39:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 00:39:58 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.96d91d5e87b550898dbb49a53413bb1d@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by Austin Seipp ): In [changeset:"045b28033a33a48d31951240a8cb35f2b78345dc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="045b28033a33a48d31951240a8cb35f2b78345dc" change deriveConstants to use nm in a POSIX way (fixes #8781) The patch provided by Christian Maeder Signed-off-by: Karel Gardas Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 00:40:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 00:40:53 -0000 Subject: [GHC] #8886: sync-all: END actions result in confusing error message In-Reply-To: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> References: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> Message-ID: <056.4d38b046537bb8439203b8cac873c91c@haskell.org> #8886: sync-all: END actions result in confusing error message -------------------------------------+------------------------------------- Reporter: fw | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 00:41:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 00:41:03 -0000 Subject: [GHC] #8765: Add --with-ar and --with-ranlib configure params. In-Reply-To: <046.3ba6d156e363476a08501abfd52128f1@haskell.org> References: <046.3ba6d156e363476a08501abfd52128f1@haskell.org> Message-ID: <061.4a29354f33359eb10f91883e07f47455@haskell.org> #8765: Add --with-ar and --with-ranlib configure params. -------------------------------------+------------------------------------ Reporter: kgardas | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 00:41:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 00:41:21 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.a248da1acdfb2e1ddba7419193683d2f@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 04:27:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 04:27:36 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.24e62743c1fcb7a7ecff8bbe76d76597@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): I just got `validate --fast --no-dph`working, with configure as above -with-gcc=gcc-4.8 and --with-hs-cpp=gcc-4.8 {{{ Unexpected results from: TEST="cgrun071 objc-hi objcpp-hi haddock.base T3064" OVERALL SUMMARY for test run started at Sat Mar 22 23:57:35 2014 EDT 0:27:29 spent to go through 3903 total tests, which gave rise to 15250 test cases, of which 11683 were skipped 28 had missing libraries 3472 expected passes 62 expected failures 0 caused framework failures 1 unexpected passes 4 unexpected failures Unexpected passes: codeGen/should_run cgrun071 (normal) Unexpected failures: driver/objc objc-hi [exit code non-0] (normal) driver/objc objcpp-hi [exit code non-0] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) == Start post-testsuite package check Timestamp 2014-03-23 03:22:17 UTC for /Users/carter/Desktop/repoScratcher/ghc/inplace/lib/package.conf.d/package.cache Timestamp 2014-03-23 03:22:17 UTC for /Users/carter/Desktop/repoScratcher/ghc/inplace/lib/package.conf.d (same as cache) using cache: /Users/carter/Desktop/repoScratcher/ghc/inplace/lib/package.conf.d/package.cache == End post-testsuite package check ------------------------------------------------------------------- Oops! Looks like you have some unexpected test results or framework failures. Please fix them before pushing/sending patches. ------------------------------------------------------------------- }}} i'll try to do a validate run with clang, the gcc-4.8 will barf on objective C. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 05:27:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 05:27:45 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.e6e27146009f218beea84e19ebe912c0@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): I just did a `./configure --with-gcc=clang ; ./validate --no-dph` and i got the following error at the end {{{ = End post-install package check ===--- building phase 0 /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print- directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print- directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print- directory -f ghc.mk phase=final validate_build_xhtml cd libraries/xhtml && "/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/bin/ghc" --make Setup [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... cd libraries/xhtml && ./Setup configure --with- ghc="/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/bin/ghc" --with- haddock="/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/bin/haddock" --enable-shared --disable-library-vanilla --disable- library-prof --global --builddir=dist-bindist --prefix="/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir" Configuring xhtml-3000.2.1... cd libraries/xhtml && ./Setup build --builddir=dist-bindist Building xhtml-3000.2.1... Preprocessing library xhtml-3000.2.1... ghc: could not execute: make[1]: *** [validate_build_xhtml] Error 1 make: *** [validate_build_xhtml] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 07:19:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 07:19:05 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.f43320ff0a3b85d4ee6160321b163052@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): So I think this fix is ok - it avoids the question of whether the ABI requires the caller to sign/zero-extend or not. My suggestion to cast the argument was based on the type of `hs_popcnt8` taking an `HsInt8`, but I see that wasn't what you intended. FWIW I think gcc probably should be zero-extending in the caller, not the callee, for an 8-bit argument (i.e. gcc 4.2 is correct, 4.9 is wrong). This is what we assume in GHC. I couldn't see anything about this in the ABI spec, but there's a gcc bug open: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 07:31:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 07:31:19 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.2aea99ceab0502b552cdda856bc5baf8@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by tibbe): Replying to [comment:57 simonmar]: > FWIW I think gcc probably should be zero-extending in the caller, not the callee, for an 8-bit argument (i.e. gcc 4.2 is correct, 4.9 is wrong). This is what we assume in GHC. I couldn't see anything about this in the ABI spec, but there's a gcc bug open: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942 According to [http://gcc.gnu.org/ml/gcc/2013-01/msg00447.html the discussion with an editor of the System V x86_64 ABI] rwbarton linked to above, it's incorrect for the callee to assume that the register has been zero extended. Accessing bits outside the specified argument size is intentionally undefined behavior (which means that the callee has to zero extend). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 07:34:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 07:34:44 -0000 Subject: [GHC] #8885: Add inline versions of clone array primops In-Reply-To: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> References: <044.b04f93f80730af1e7cd7e9c8ee0fadc3@haskell.org> Message-ID: <059.761eee59ee086532bbaf0c0dd9563af9@haskell.org> #8885: Add inline versions of clone array primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Sorry I didn't get around to reviewing this. I just skimmed the commit and it all looks very reasonable though. Nice work :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 07:42:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 07:42:09 -0000 Subject: [GHC] #8922: GHC unnecessarily sign/zero-extends C call arguments Message-ID: <047.455a422a37c45c247e79c55d0194cab9@haskell.org> #8922: GHC unnecessarily sign/zero-extends C call arguments ----------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (NCG) | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7684 | ----------------------------------+------------------------------------- Ticket created following discussion in [https://ghc.haskell.org/trac/ghc/ticket/7684#comment:58] It seems the zero/sign-extension that we're doing in the NCG for arguments less than a word in size is unnecessary, since the ABI doesn't specify any extension. There's some clarification of the spec in this thread: [http://gcc.gnu.org/ml/gcc/2013-01/msg00448.html] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 07:43:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 07:43:34 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.c53468568d11b08056d9449b641a401d@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): Ok, that means we can remove the extension behaviour from GHC then. I've created a ticket: #8922. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 07:46:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 07:46:57 -0000 Subject: [GHC] #8922: GHC unnecessarily sign/zero-extends C call arguments In-Reply-To: <047.455a422a37c45c247e79c55d0194cab9@haskell.org> References: <047.455a422a37c45c247e79c55d0194cab9@haskell.org> Message-ID: <062.80f7eb8e394e45218423ec30413c5270@haskell.org> #8922: GHC unnecessarily sign/zero-extends C call arguments -------------------------------------+---------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (NCG) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7684 -------------------------------------+---------------------------------- Comment (by tibbe): Note this exchange in the linked email thread above. I'm not sure if Richard (the editor) is saying that zero extending in the caller is an optimization: >>> How? You aren't allowed to access the bits outside the specified argument >>> type (which must match on caller and callee side), so you can't observe >>> them, so it's not required to specify their content. >> >> OK, thanks. It's clear now. >> >> The problem is that LLVM assumes that values are extended at a call. GCC >> does that, but libffi doesn't. So, calls via libffi to LLVM don't work >> correctly. > > It's an optimization to do so to avoid partial register stalls. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 07:55:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 07:55:05 -0000 Subject: [GHC] #8922: GHC unnecessarily sign/zero-extends C call arguments In-Reply-To: <047.455a422a37c45c247e79c55d0194cab9@haskell.org> References: <047.455a422a37c45c247e79c55d0194cab9@haskell.org> Message-ID: <062.36bafe6a8535f1dab6ab476e349f988e@haskell.org> #8922: GHC unnecessarily sign/zero-extends C call arguments -------------------------------------+---------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (NCG) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7684 -------------------------------------+---------------------------------- Comment (by simonmar): My reading of it was that extending in the caller is not strictly necessary but is done as an optimisation to avoid partial register stalls. Maybe that means we ought to be doing it too - that's not clear to me. I'm sure it's not *always* an optimisation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 08:13:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 08:13:22 -0000 Subject: [GHC] #8351: Arrays are always allocated out-of-line In-Reply-To: <044.2c5aaa81ba255a3d6b78466b46ee259f@haskell.org> References: <044.2c5aaa81ba255a3d6b78466b46ee259f@haskell.org> Message-ID: <059.ae929805a1a4ecf75a40c513f9e796b8@haskell.org> #8351: Arrays are always allocated out-of-line -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 5925 -------------------------------------+------------------------------------ Changes (by tibbe): * status: new => closed * resolution: => fixed Comment: Fixed in #5925. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 08:27:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 08:27:07 -0000 Subject: [GHC] #8923: Add SmallArray# type Message-ID: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> #8923: Add SmallArray# type ------------------------------------+------------------------------------- Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Add a `SmallArray#` (and `SmallMutableArray#`) type that doesn't have a card table. This would * save some memory (two words per array), * make updates cheaper (no writing to the card table), and * make GC faster (no traversing the card table). The use case is the unordered-containers package, which uses small arrays to implement a hash array mapped trie. A starting point would be [changeset:0417404f5d1230c9d291ea9f73e2831121c8ec99/ghc], which added the card table to the current array type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 08:37:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 08:37:52 -0000 Subject: [GHC] #8923: Add SmallArray# type In-Reply-To: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> References: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> Message-ID: <059.00efbefe3cee9a5a0c344381e3ff75e4@haskell.org> #8923: Add SmallArray# type -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 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: simonmar (added) * milestone: => 7.10.1 Comment: Some older discussion about this topic: {{{ 17:41 < JaffaCake> I like the idea of a separate small array type 17:41 < hvr> JaffaCake: does that single card-table "bit" make sense for <128 elements btw? 17:42 < JaffaCake> no, because we already have a flag for the whole array that tells us whether anything was modified 17:42 < hvr> or rather: having a kind of threshold (say ~16 elements or so) below which the card-table is 0-sized 17:42 < JaffaCake> so it's no use at all 17:43 < hvr> so we could optimize the <128 element case, by omitting the card-table? 17:43 < hvr> and thus getting a 2+N footprint for <128 elements? 17:43 < JaffaCake> you'd need a different type though 17:44 < JaffaCake> otherwise the write barrier would need a conditional on the size, which is bad 17:44 < hvr> and if the 0th card-table bit would be implicit always? 17:45 < hvr> i.e. derived from the remaining the bits + the whole-array flag you mentioned? 17:45 < JaffaCake> how would you derive it from the remaining bits? 17:46 < hvr> isn't the "whole array flag" == 'and' over all card-table bits? 17:46 < tibbe> Having it conditional would mean that writes would introduce a branch, not good. 17:47 < hvr> nevermind, that wouldn't allow to deduce it in all cases 17:47 < JaffaCake> hvr: right :) 17:48 < JaffaCake> tibbe: yes, we really want to avoid branches in the write barrier 17:48 * hvr needs to read up about write-barriers in that GC-handbook I just bought... 17:48 < JaffaCake> it doesn't have to be a "small array" type as such, you could just reintroduce the old card-table-less arrays 17:49 < JaffaCake> it wouldn't be much code 17:49 < tibbe> JaffaCake: realistically, how much work would it be to add a new closure type for small arrays. I know we have talked about it 10^10 times but perhaps I'll actually do something about it. 17:50 < JaffaCake> you could do it in an afternoon, I would think, it's mostly mechanical 17:51 < JaffaCake> start from 0417404f5d1230c9d291ea9f73e2831121c8ec99 17:51 < JaffaCake> and just add back the old arrays 17:51 < JaffaCake> with a new primitive type, and primops etc. 17:52 < JaffaCake> I suggest not actually having a size requirement, you can call them small arrays if you want but they would work for all sizes 17:52 * JaffaCake must disappear 17:52 < hvr> JaffaCake: so they'd just be a different cost-model for the user to choose from... 17:53 < tibbe> JaffaCake: ok 17:53 < tibbe> JaffaCake: I guess one size field is required for the GC? 17:53 < JaffaCake> hvr: precisely 17:53 < JaffaCake> tibbe: yes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 09:02:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 09:02:57 -0000 Subject: [GHC] #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" In-Reply-To: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> References: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> Message-ID: <063.db83ee93d163801e49f442faa61f9968@haskell.org> #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" ----------------------------------+---------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.2 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by adinapoli): Replying to [comment:4 thoughtpolice]: > I've been testing a Cabal built with RC2 on OS X for quite a long time now and cannot reproduce this on Lion or Mavericks, so I'm punting this bug. Fair enough, I'll keep you guys posted on whether or not it will show up more aggressively on my machine and if I can come up with a reproducible scenario :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 09:49:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 09:49:30 -0000 Subject: [GHC] #8545: Reorganize Git repositories In-Reply-To: <042.ff58f710763777250f3a6776932361cb@haskell.org> References: <042.ff58f710763777250f3a6776932361cb@haskell.org> Message-ID: <057.4aa9dbf1660e5752033d42615da00d7b@haskell.org> #8545: Reorganize Git repositories -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Trac & Git | Version: Resolution: | Keywords: git Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8251 -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"34b072177b687c8fcc24f87293beae0752e82d32/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="34b072177b687c8fcc24f87293beae0752e82d32" Convert haddock into a proper submodule (re #8545) This should help contribute content to https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 10:45:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 10:45:33 -0000 Subject: [GHC] #8924: Text.ParserCombinators.ReadP needs some kind of "commit" or "cut" to force a single parse.. Message-ID: <050.1906743244648eb3189d64db5510846c@haskell.org> #8924: Text.ParserCombinators.ReadP needs some kind of "commit" or "cut" to force a single parse.. ------------------------------------+------------------------------------- Reporter: PaulJohnson | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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 ReadP monad maintains all possible parses of its input, rather than being left-biased as most parsers are. However this is not always quite the Right Thing. I maintain the Data.Decimal library. The Read instance for Data.Decimal up to 0.3.1 had the following behaviour: reads "34.567e8 foo" :: [(Decimal, String)] = [(34.0,".567e8 foo"),(34.567,"e8 foo"),(3.4567e9," foo")] Clearly only the last parse in the list is the Right Thing, and any parser which returns "34.0" when given "34.567" is doing it wrong. The problem came from the implementation of "optional". In numbers only the integer part is mandatory, with the fractional and exponent parts being optional. So I wrote my parser with the fractional part parsed like this: fractPart <- optional "" $ do _ <- char '.' munch1 isDigit The problem is that "optional" uses the symmetric choice operator (+++). I wrote this to work around the problem: myOpt d p = p <++ return d This uses the left-biased choice, so as soon as the parser sees the "." it commits to the fractional part. However this still isn't the Right Thing. reads "34." :: [(Double, String)] = [(34.0, ".")] but the parser above will fail to read it. Furthermore there are a number of combinators built on "+++" in ReadP, and it seems wrong to have left- biased variants of all of them. So what seems to be needed is some kind of "cut" operator, analogous to the Prolog "!" cut, which says that if you have got this far then you should commit to this parse and forget all the others. But it would have to be delimited because I only want that cut to apply to my Decimal type: if someone calls my Decimal parser then I don't want their parser to commit to an entire parse just because I have. So I think the feature I'm looking for is a delimited back-track akin to "prompt" in delimited continuations. But my monad-fu isn't good enough to design it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 11:15:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 11:15:23 -0000 Subject: [GHC] #8923: Add SmallArray# type In-Reply-To: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> References: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> Message-ID: <059.db45e5675aae2abe66ec17e89c5b552c@haskell.org> #8923: Add SmallArray# type -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): I've written a patch (untested, but compiles) that adds a `StgSmallMutArrPtrs` type to the RTS. I would like a preliminary, high- level review of these changes to know if there are any major parts I'm missing. If this patch looks mostly OK I will go ahead and implement the compiler changes (i.e. type system and code generator changes) and write some tests. I'm was thinking of splitting the change into perhaps 3 commits for ease of reviewing: the RTS changes (roughly this patch), the compiler front-end changes (`Type` things), and finally the primops changes to code generator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 12:40:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 12:40:01 -0000 Subject: [GHC] #1721: Make GHCi print the entire result of an interactive 'bind' statement In-Reply-To: <046.657252b52c928fa83fef6abad76bac17@haskell.org> References: <046.657252b52c928fa83fef6abad76bac17@haskell.org> Message-ID: <061.8d339e91d51c11d7f5c618c0ca35daa7@haskell.org> #1721: Make GHCi print the entire result of an interactive 'bind' statement -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"8f26728a44be395a41d9dd9cb933e8006f5a6dc4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8f26728a44be395a41d9dd9cb933e8006f5a6dc4" ghc-cabal: force use of UTF8 when writing out `haddock-prologue.txt` This unbreaks the GHC build if a non-UTF8 locale such as LANG=C is active See also haskell/cabal#1721 and haskell/haddock#286 Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 12:40:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 12:40:01 -0000 Subject: [GHC] #286: GADTs Syntax Infelicity with {;} In-Reply-To: <047.2988934571f2c1965530cfb6a0473215@haskell.org> References: <047.2988934571f2c1965530cfb6a0473215@haskell.org> Message-ID: <062.ff24f68a41b3bae3b016d4ada1a4d7ec@haskell.org> #286: GADTs Syntax Infelicity with {;} --------------------------------+-------------------- Reporter: ashley-y | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.4 Resolution: Fixed | Keywords: --------------------------------+-------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"8f26728a44be395a41d9dd9cb933e8006f5a6dc4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8f26728a44be395a41d9dd9cb933e8006f5a6dc4" ghc-cabal: force use of UTF8 when writing out `haddock-prologue.txt` This unbreaks the GHC build if a non-UTF8 locale such as LANG=C is active See also haskell/cabal#1721 and haskell/haddock#286 Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 16:17:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 16:17:35 -0000 Subject: [GHC] #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test (was: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(dyn) test) In-Reply-To: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> References: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> Message-ID: <063.4945c1e620caf20d56422ceda7be8011@haskell.org> #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Compile-time | Difficulty: Easy (less than 1 crash | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 17:28:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 17:28:21 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.239219e647d8ed0803ef80c579639b07@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Changes (by carter): * owner: => carter Comment: i just rebased my cpp-settings branch ontop of today ghc-7.8 tip, validate seems to be succeeding. Will paste test results shortly nb: im expect the objc tests to fail because my gcc is gcc-4.8 https://github.com/cartazio/ghc/compare/ghc:ghc-7.8...rb_cpp_settings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 17:54:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 17:54:36 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.3361bc50087cc51dec620e3242292d99@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): {{{ == Start post-install package check Timestamp 2014-03-23 17:32:46 UTC for /Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/lib/ghc-7.8.0.20140323/package.conf.d/package.cache Timestamp 2014-03-23 17:32:46 UTC for /Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/lib/ghc-7.8.0.20140323/package.conf.d (same as cache) using cache: /Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/lib/ghc-7.8.0.20140323/package.conf.d/package.cache == End post-install package check ===--- building phase 0 /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print- directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print- directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print- directory -f ghc.mk phase=final validate_build_xhtml cd libraries/xhtml && "/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/bin/ghc" --make Setup [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... cd libraries/xhtml && ./Setup configure --with- ghc="/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/bin/ghc" --with- haddock="/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/bin/haddock" --enable-shared --disable-library-vanilla --disable- library-prof --global --builddir=dist-bindist --prefix="/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir" Configuring xhtml-3000.2.1... cd libraries/xhtml && ./Setup build --builddir=dist-bindist Building xhtml-3000.2.1... Preprocessing library xhtml-3000.2.1... ghc: could not execute: make[1]: *** [validate_build_xhtml] Error 1 make: *** [validate_build_xhtml] Error 2 }}} I'm thinking something relating to ` validate_build_xhtml` in ghc.mk is the cuplrit -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 18:49:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 18:49:28 -0000 Subject: [GHC] #8893: -XPolyKinds causes "*** Exception: Prelude.(!!): index too large" In-Reply-To: <044.75b9ae16eaafc02be44ca541a7f043cc@haskell.org> References: <044.75b9ae16eaafc02be44ca541a7f043cc@haskell.org> Message-ID: <059.8a2d1c47e4c684ffbe265c39fac17f66@haskell.org> #8893: -XPolyKinds causes "*** Exception: Prelude.(!!): index too large" ---------------------------------------+----------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ffed708c30f2d1d4b4c5cd08d9c19aeb0bb623ec/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ffed708c30f2d1d4b4c5cd08d9c19aeb0bb623ec" Apply the kind subst to the (kinds of the) quanitifed tyvars in deriveTyData I've elaboated Note [Unify kinds in deriving] to explain what is going on here. The change fixes Trac #8893. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 18:49:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 18:49:29 -0000 Subject: [GHC] #8649: Disambiguate Repeated Identifiers for data types in error messages In-Reply-To: <049.6bf3d73425bf24e65a9a228212868f45@haskell.org> References: <049.6bf3d73425bf24e65a9a228212868f45@haskell.org> Message-ID: <064.874cecc857fc64790912bc3ea2303bc8@haskell.org> #8649: Disambiguate Repeated Identifiers for data types in error messages ---------------------------------------+----------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: ghci/scripts/T8649 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"28e8d878b63d06824001ac3a631254679e0f1960/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="28e8d878b63d06824001ac3a631254679e0f1960" Simplify handling of the interactive package; fixes Trac #8831 This patch is really a fix to the big commint 73c08ab10e4077e18e459a1325996bff110360c3 Re-work the naming story for the GHCi prompt (Trac #8649) which introduced the 'interactive' package See Note [The interactive package] in HscTypes The original commit set both (a) The tcg_mod field of TcGblEnv to 'interactive:Ghci4' (say) (b) The thisPackage field of DynFlags to 'interactive' But the second step interacts badly with linking. :loaded modules are in the package set by 'thisPackage' (usually 'main'); if you change that, then we try to link package 'main', but can't find it, and that is what happened in #8831. The fix was simple: do (a) but not (b). I changed Note [The interactive package] in HscTypes to describe this. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 18:49:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 18:49:34 -0000 Subject: [GHC] #8831: Cannot use Template Haskell splice in ghci In-Reply-To: <047.1688ea3628125d840e5d96b182466527@haskell.org> References: <047.1688ea3628125d840e5d96b182466527@haskell.org> Message-ID: <062.fa2222814d62beacfff95cd93f5d37f7@haskell.org> #8831: Cannot use Template Haskell splice in ghci -------------------------------------+---------------------------------- Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"28e8d878b63d06824001ac3a631254679e0f1960/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="28e8d878b63d06824001ac3a631254679e0f1960" Simplify handling of the interactive package; fixes Trac #8831 This patch is really a fix to the big commint 73c08ab10e4077e18e459a1325996bff110360c3 Re-work the naming story for the GHCi prompt (Trac #8649) which introduced the 'interactive' package See Note [The interactive package] in HscTypes The original commit set both (a) The tcg_mod field of TcGblEnv to 'interactive:Ghci4' (say) (b) The thisPackage field of DynFlags to 'interactive' But the second step interacts badly with linking. :loaded modules are in the package set by 'thisPackage' (usually 'main'); if you change that, then we try to link package 'main', but can't find it, and that is what happened in #8831. The fix was simple: do (a) but not (b). I changed Note [The interactive package] in HscTypes to describe this. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 18:49:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 18:49:34 -0000 Subject: [GHC] #8893: -XPolyKinds causes "*** Exception: Prelude.(!!): index too large" In-Reply-To: <044.75b9ae16eaafc02be44ca541a7f043cc@haskell.org> References: <044.75b9ae16eaafc02be44ca541a7f043cc@haskell.org> Message-ID: <059.ce68bb48a261e1135f245cb25721599f@haskell.org> #8893: -XPolyKinds causes "*** Exception: Prelude.(!!): index too large" ---------------------------------------+----------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7973bfb87fdbe6e980e64ed5d7b2a90a469effd4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7973bfb87fdbe6e980e64ed5d7b2a90a469effd4" Test Trac #8893 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 18:49:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 18:49:35 -0000 Subject: [GHC] #8831: Cannot use Template Haskell splice in ghci In-Reply-To: <047.1688ea3628125d840e5d96b182466527@haskell.org> References: <047.1688ea3628125d840e5d96b182466527@haskell.org> Message-ID: <062.93ec5ace6c0af4cb496913dd686138a0@haskell.org> #8831: Cannot use Template Haskell splice in ghci -------------------------------------+---------------------------------- Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1a7709ef9b25175566bc040a34b3d479ea8566ed/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1a7709ef9b25175566bc040a34b3d479ea8566ed" Trac #8831 is fixed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 18:54:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 18:54:35 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.56ca0e39d9f7bfb87ce1f09e667d8a4b@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): the results of the the test suite are {{{ OVERALL SUMMARY for test run started at Sun Mar 23 13:57:15 2014 EDT 0:50:45 spent to go through 3930 total tests, which gave rise to 15438 test cases, of which 11846 were skipped 28 had missing libraries 3496 expected passes 63 expected failures 0 caused framework failures 1 unexpected passes 4 unexpected failures Unexpected passes: codeGen/should_run cgrun071 (normal) Unexpected failures: driver/objc objc-hi [exit code non-0] (normal) driver/objc objcpp-hi [exit code non-0] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) }}} this makes me think the issue lies with that xhtml validation step -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 18:59:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 18:59:46 -0000 Subject: [GHC] #8893: -XPolyKinds causes "*** Exception: Prelude.(!!): index too large" In-Reply-To: <044.75b9ae16eaafc02be44ca541a7f043cc@haskell.org> References: <044.75b9ae16eaafc02be44ca541a7f043cc@haskell.org> Message-ID: <059.3a4a2e3c3ce2222e4a7beee6c7446ddf@haskell.org> #8893: -XPolyKinds causes "*** Exception: Prelude.(!!): index too large" -------------------------------------------------+------------------------- Reporter: ghorn | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time crash | PolyKinds Test Case: | Architecture: deriving/should_compile/T8893 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => merge * testcase: => deriving/should_compile/T8893 Comment: Thanks for an excellent test case! Austin, please merge. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 19:00:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 19:00:40 -0000 Subject: [GHC] #8831: Cannot use Template Haskell splice in ghci In-Reply-To: <047.1688ea3628125d840e5d96b182466527@haskell.org> References: <047.1688ea3628125d840e5d96b182466527@haskell.org> Message-ID: <062.fe089437a13df343367280545d6c1a74@haskell.org> #8831: Cannot use Template Haskell splice in ghci ---------------------------------------+---------------------------------- Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghci/scripts/T8831 | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by simonpj): * status: new => merge * testcase: => ghci/scripts/T8831 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 19:29:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 19:29:41 -0000 Subject: [GHC] #8917: :kind! does not work under type constructors In-Reply-To: <047.7c2cbf8df2580654e4b144c0c3c47c5e@haskell.org> References: <047.7c2cbf8df2580654e4b144c0c3c47c5e@haskell.org> Message-ID: <062.b746f8cee50d4d98dc2c1841202e56f8@haskell.org> #8917: :kind! does not work under type constructors ---------------------------------------+----------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: ghci/scripts/T8917 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 19:34:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 19:34:52 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT In-Reply-To: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> References: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> Message-ID: <062.057c3d8f9b4697459ea9723cfd3f6896@haskell.org> #8776: Displaying pattern synonym for a GADT -------------------------------------+------------------------------------ Reporter: monoidal | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: This is all merged into 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 19:38:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 19:38:15 -0000 Subject: [GHC] #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test In-Reply-To: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> References: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> Message-ID: <063.5d7e47e28bd29f2d7f87b2d97c7896ea@haskell.org> #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Compile-time | Difficulty: Easy (less than 1 crash | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by AlainODea): Rich Lowe gave some solid insight on this on smartos-discuss: > You're passing both -lrt and -r, which is likely to cause ld to look for an archive > library (librt.a, which will never exist) and not the shared object, since -r asks for > relocatable output. However, this causes a separate problem with unresolved references: {{{ # /opt/local/gcc47/libexec/gcc/x86_64-sun-solaris2.11/4.7.3/collect2 -R/opt/local/lib/ -Y P,/lib/amd64:/usr/lib/amd64:/opt/local/lib/ -Qy -o topHandler02.o -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3 -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/../../../../x86_64 -sun-solaris2.11/lib/amd64 -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../../amd64 -L/lib/amd64 -L/usr/lib/amd64 -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/../../../../x86_64 -sun-solaris2.11/lib -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../.. -R/opt/local/gcc47/x86_64-sun- solaris2.11/lib/amd64 -R/opt/local/gcc47/lib/amd64 -lrt /tmp/ghc93957_0/ghc93957_6.o /tmp/ghc93957_0/ghc93957_5.o Undefined first referenced symbol in file era /tmp/ghc93957_0/ghc93957_6.o base_GHCziIOziException_zdfExceptionAsyncExceptionzuzdctoException_info /tmp/ghc93957_0/ghc93957_6.o CC_ID /tmp/ghc93957_0/ghc93957_5.o pushCostCentre /tmp/ghc93957_0/ghc93957_6.o CCS_DONT_CARE /tmp/ghc93957_0/ghc93957_6.o CCS_ID /tmp/ghc93957_0/ghc93957_5.o base_GHCziIOziException_zdfExceptionAsyncExceptionzuzdctoException_closure /tmp/ghc93957_0/ghc93957_6.o enterFunCCS /tmp/ghc93957_0/ghc93957_6.o newCAF /tmp/ghc93957_0/ghc93957_6.o CC_LIST /tmp/ghc93957_0/ghc93957_5.o base_GHCziIOziException_UserInterrupt_closure /tmp/ghc93957_0/ghc93957_6.o stg_bh_upd_frame_info /tmp/ghc93957_0/ghc93957_6.o CCS_LIST /tmp/ghc93957_0/ghc93957_5.o stg_IND_STATIC_info /tmp/ghc93957_0/ghc93957_6.o stg_raiseIOzh /tmp/ghc93957_0/ghc93957_6.o base_GHCziTopHandler_runMainIO1_info /tmp/ghc93957_0/ghc93957_6.o base_GHCziTopHandler_runMainIO1_closure /tmp/ghc93957_0/ghc93957_6.o ld: fatal: symbol referencing errors. No output written to topHandler02.o collect2: error: ld returned 1 exit status }}} I don't see the -r option in GNU ld, so this seems to be SunOS/Illumos specific. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 20:38:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 20:38:26 -0000 Subject: [GHC] #8893: -XPolyKinds causes "*** Exception: Prelude.(!!): index too large" In-Reply-To: <044.75b9ae16eaafc02be44ca541a7f043cc@haskell.org> References: <044.75b9ae16eaafc02be44ca541a7f043cc@haskell.org> Message-ID: <059.cd74d4043d76218c1576555ff4d5c98c@haskell.org> #8893: -XPolyKinds causes "*** Exception: Prelude.(!!): index too large" -------------------------------------------------+------------------------- Reporter: ghorn | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: Compile-time crash | Keywords: Test Case: | PolyKinds deriving/should_compile/T8893 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.8.1 Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 20:38:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 20:38:35 -0000 Subject: [GHC] #8892: Ghc panics (variable not found) In-Reply-To: <045.3e8c8bb464ddd3c1e55d55ced44d87a2@haskell.org> References: <045.3e8c8bb464ddd3c1e55d55ced44d87a2@haskell.org> Message-ID: <060.4f5348662af1462bb47f3342d4274111@haskell.org> #8892: Ghc panics (variable not found) ---------------------------------------+----------------------------------- Reporter: jwlato | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.8.1 Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 20:38:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 20:38:45 -0000 Subject: [GHC] #8889: GHCI reports nasty type signatures In-Reply-To: <050.8be9da2264f8ee0e1a82a03f55af16c9@haskell.org> References: <050.8be9da2264f8ee0e1a82a03f55af16c9@haskell.org> Message-ID: <065.108033f8b3df2349fce65afe28cce9bc@haskell.org> #8889: GHCI reports nasty type signatures -------------------------------------------------+------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: Priority: normal | closed Component: GHCi | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Linux | 7.8.1-rc2 Type of failure: Other | Keywords: Test Case: | Architecture: indexed_types/should_compile/T8889 | x86_64 (amd64) Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * version: 7.8.1-rc1 => 7.8.1-rc2 * resolution: => fixed * milestone: => 7.8.1 Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 20:38:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 20:38:55 -0000 Subject: [GHC] #8856: ScopedTypeVariables & PolyKinds lead to weird error message In-Reply-To: <047.c1ddeb6dbc8d4cc1a8ee203edc0ceccf@haskell.org> References: <047.c1ddeb6dbc8d4cc1a8ee203edc0ceccf@haskell.org> Message-ID: <062.b58a3abc5d7c3c91129aa096227c7cf3@haskell.org> #8856: ScopedTypeVariables & PolyKinds lead to weird error message -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: typecheck/should_compile/T8856 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.8.1 Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 20:39:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 20:39:07 -0000 Subject: [GHC] #8831: Cannot use Template Haskell splice in ghci In-Reply-To: <047.1688ea3628125d840e5d96b182466527@haskell.org> References: <047.1688ea3628125d840e5d96b182466527@haskell.org> Message-ID: <062.f1e7b6cd215c2c9ab285b44788bed6fb@haskell.org> #8831: Cannot use Template Haskell splice in ghci ---------------------------------------+---------------------------------- Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghci/scripts/T8831 | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 23 20:54:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Mar 2014 20:54:44 -0000 Subject: [GHC] #8925: :print and :sprint sometimes fully evaluates strings Message-ID: <045.158e5823a1b625f26a808590111b756b@haskell.org> #8925: :print and :sprint sometimes fully evaluates strings ------------------------------------+------------------------------------- Reporter: soapie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Not too confident in my terminology but `:sprint`ing a string that has been evaluated down to its spine seems to fully evaluate the string: {{{ Prelude> let a = map (Debug.Trace.trace "!!!") "abc" Prelude> a `seq` () () Prelude> :sprint a a = _ : _ -- looks fine Prelude> length a 3 Prelude> :sprint a a = "!!! -- strange! a!!! b!!! c" }}} What I expect to see is `a = [_,_,_]`. `:print` behaves similarly. Since neither `:print` nor `:sprint` is supposed to force any evaluation this seems like a bug. At least it can make debugging quite confusing if you're not aware of it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 00:45:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 00:45:33 -0000 Subject: [GHC] #8831: Cannot use Template Haskell splice in ghci In-Reply-To: <047.1688ea3628125d840e5d96b182466527@haskell.org> References: <047.1688ea3628125d840e5d96b182466527@haskell.org> Message-ID: <062.58025e2440980f88be8fdb56a6992504@haskell.org> #8831: Cannot use Template Haskell splice in ghci ---------------------------------------+---------------------------------- Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghci/scripts/T8831 | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by kazu-yamamoto): Thanks, Simon. I confirmed that this bug has been fixed. https://github.com/sol/doctest-haskell/issues/76 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 03:24:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 03:24:27 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.9f6d6b9eafe724f56c189d977ca22f57@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): PROGRESSS! the relevant step of validate that was failing was was {{{ cd libraries/xhtml && ./Setup build --builddir=dist-bindist}}} I took the liberty of running this by hand: {{{ carter libraries/xhtml ?fb9e0bb*? ? ./Setup build --builddir=dist- bindist -v3 1 ? Component build order: library creating dist-bindist/build creating dist-bindist/build/autogen Building xhtml-3000.2.1... Preprocessing library xhtml-3000.2.1... Building library... ("/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/bin/ghc",["--info"]) ("/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/bin/ghc",["--info"]) creating dist-bindist/build Environment: [("Apple_PubSub_Socket_Render","/tmp/launch- IehmnE/Render"),("CAML_LD_LIBRARY_PATH","/Users/carter/.opam/system/lib/stublibs:/usr/local/lib/ocaml/stublibs"),("CLICOLOR","1"),("COLORFGBG","7;0"),("COMMAND_MODE","unix2003"),("DBUS_LAUNCHD_SESSION_BUS_SOCKET","/tmp /launch- kHPpAS/unix_domain_listener"),("DISABLE_AUTO_UPDATE","true"),("DISPLAY","/tmp /launch-7MeZK8/org.macosforge.xquartz:0"),("EDITOR","subl -w -n"),("GNUTERM","x11"),("GREP_COLOR","1;32"),("GREP_OPTIONS","-- color=auto"),("HOME","/Users/carter"),("ITERM_SESSION_ID","w0t1p0"),("LANG","en_US.UTF-8"),("LC_CTYPE","en_US.UTF-8"),("LESS","-R"),("LOGNAME","carter"),("LSCOLORS","Gxfxcxdxbxegedabagacad"),("MANPATH","/Users/carter/.opam/system/man:"),("MYTARCACHE","/Users/carter /.tarsnap-cache/"),("MYTARKEY","/Users/carter/.secureme/tarsnap- 2011MBAir13.key"),("NODE_PATH","/usr/local/lib/node_modules:/usr/local/lib/node"),("OCAML_TOPLEVEL_PATH","/Users/carter/.opam/system/lib/toplevel"),("OLDPWD","/Users/carter/Desktop/repoScratcher/ghc"),("PAGER","less"),("PATH","/Users/carter/.opam/system/bin:/opt/local/bin:/Users/carter/bin:/usr/local/Cellar/smlnj/110.74/libexec/bin:/Applications/Postgres.app/Contents/MacOS/bin:/Users/carter/.scripts:/Users/carter/.cabal/bin:/Users/carter/Library/Haskell/bin:/Users/carter/docTemplates:/usr/local/share/npm/bin:/usr/local/share/python:/usr/local/Cellar/ruby/1.9.3-p194/bin:/usr/local/bin:/usr/local/sbin:/usr/local/cuda/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/texbin:/usr/texbin"),("PKG_CONFIG_PATH","/opt/X11/lib/pkgconfig:"),("PWD","/Users/carter/Desktop/repoScratcher/ghc/libraries/xhtml"),("PYTHONPATH","/usr/local/share/python:/usr/local/lib/python:"),("SECURITYSESSIONID","186a4"),("SHELL","/bin/zsh"),("SHLVL","1"),("SSH_AUTH_SOCK","/tmp /launch-iHEzRI/Listeners"),("TERM","xterm- 256color"),("TERM_PROGRAM","iTerm.app"),("TMPDIR","/var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/"),("USER","carter"),("ZSH","/Users/carter /.oh-my- zsh"),("ZSH_THEME","carter"),("_","/Users/carter/Desktop/repoScratcher/ghc/libraries/xhtml/./Setup"),("__CF_USER_TEXT_ENCODING","0x1F5:0:0"),("__CHECKFIX1436934","1")] ("/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/bin/ghc",["--make","-v","-fbuilding-cabal- package","-O","-dynamic","-fPIC","-osuf","dyn_o","-hisuf","dyn_hi","-outputdir ","dist-bindist/build","-odir","dist-bindist/build","-hidir","dist- bindist/build","-stubdir","dist-bindist/build","-i","-idist- bindist/build","-i.","-idist-bindist/build/autogen","-Idist- bindist/build/autogen","-Idist-bindist/build","-optP-include","-optPdist- bindist/build/autogen/cabal_macros.h","-package-name","xhtml-3000.2.1 ","-hide-all-packages","-no-user-package-db","-package-db","dist- bindist/package.conf.inplace","-package- id","base-4.7.0.0-db909df045884d25c2593604bc4b7fad","-XHaskell98","-XCPP","Text.XHtml","Text.XHtml.Frameset","Text.XHtml.Strict","Text.XHtml.Transitional","Text.XHtml.Debug","Text.XHtml.Table","Text.XHtml.Strict.Attributes","Text.XHtml.Strict.Elements","Text.XHtml.Frameset.Attributes","Text.XHtml.Frameset.Elements","Text.XHtml.Transitional.Attributes","Text.XHtml.Transitional.Elements","Text.XHtml.BlockTable","Text.XHtml.Extras","Text.XHtml.Internals","-Wall"]) Glasgow Haskell Compiler, Version 7.8.0.20140323, stage 2 booted by GHC version 7.8.0.20140311 Using binary package database: /Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/lib/ghc-7.8.0.20140323/package.conf.d/package.cache Using package config file: dist-bindist/package.conf.inplace wired-in package ghc-prim mapped to ghc- prim-0.3.1.0-ed30589de10ea47e88c54710213a68e0 wired-in package integer-gmp mapped to integer- gmp-0.5.1.0-5e6bd420a1279049d72fe1ad55e57662 wired-in package base mapped to base-4.7.0.0-db909df045884d25c2593604bc4b7fad wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.9.0.0-0b1690f10983f893b9e2b88305e78762 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: wired-in package ghc-prim mapped to ghc- prim-0.3.1.0-ed30589de10ea47e88c54710213a68e0 wired-in package integer-gmp mapped to integer- gmp-0.5.1.0-5e6bd420a1279049d72fe1ad55e57662 wired-in package base mapped to base-4.7.0.0-db909df045884d25c2593604bc4b7fad wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.9.0.0-0b1690f10983f893b9e2b88305e78762 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *Text.XHtml,*Text.XHtml.Frameset,*Text.XHtml.Strict,*Text.XHtml.Transitional,*Text.XHtml.Debug,*Text.XHtml.Table,*Text.XHtml.Strict.Attributes,*Text.XHtml.Strict.Elements,*Text.XHtml.Frameset.Attributes,*Text.XHtml.Frameset.Elements,*Text.XHtml.Transitional.Attributes,*Text.XHtml.Transitional.Elements,*Text.XHtml.BlockTable,*Text.XHtml.Extras,*Text.XHtml.Internals Created temporary directory: /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc15554_0 *** C pre-processor: '' -include dist-bindist/build/autogen/cabal_macros.h -I dist- bindist/build -I dist-bindist/build -I dist-bindist/build/autogen -I dist- bindist/build -I '/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/lib/ghc-7.8.0.20140323/base-4.7.0.0/include' -I '/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/lib/ghc-7.8.0.20140323/integer-gmp-0.5.1.0/include' -I '/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/lib/ghc-7.8.0.20140323/include' '-D__GLASGOW_HASKELL__=708' '-Ddarwin_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Ddarwin_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-U __PIC__' -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Text/XHtml.hs -o /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc15554_0/ghc15554_1.hscpp *** Deleting temp files: Deleting: /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc15554_0/ghc15554_1.hscpp Warning: deleting non-existent /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc15554_0/ghc15554_1.hscpp *** Deleting temp dirs: Deleting: /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc15554_0 ghc: could not execute: /Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/bin/ghc returned ExitFailure 1 }}} Still not sure whats happening, but its a bit more explicit whatever it is -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 03:30:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 03:30:34 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.f33aab8d25de285ff2fc3244eda13023@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): {{{ ghc: could not execute: /Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/bin/ghc returned ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 04:32:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 04:32:04 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.2bbd191ef1fce9009a0060e27675736b@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Changes (by carter): * owner: carter => Comment: i've narrowed down whats happening a bit, but I still dont understand this last bit, and i don't have time this week to do that last piece of undirected debugging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 05:52:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 05:52:06 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.609ed6897c6cf2f43b15338f94d7ffc1@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc1 Type of failure: None/Unknown | Keywords: Safe Test Case: | Architecture: should_fail/TcCoercibleFailSafe | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Austin Seipp ): In [changeset:"8f7303774237a8b0787d98c5ab6f605e3e897f19/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8f7303774237a8b0787d98c5ab6f605e3e897f19" Revert "Fix #8745 - GND is now -XSafe compatible." See #8827 - for now, we're making GND unsafe again. This also fixes the tests since they were originally not using the new unicode quote style we're using. This reverts commit a8a01e742434df11b830ab99af12d9045dfcbc4b. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 05:52:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 05:52:07 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.1b7690a358de1a78ce6dc44e6d009286@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"8f7303774237a8b0787d98c5ab6f605e3e897f19/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8f7303774237a8b0787d98c5ab6f605e3e897f19" Revert "Fix #8745 - GND is now -XSafe compatible." See #8827 - for now, we're making GND unsafe again. This also fixes the tests since they were originally not using the new unicode quote style we're using. This reverts commit a8a01e742434df11b830ab99af12d9045dfcbc4b. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 05:53:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 05:53:08 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.178df2fab5f43e86b53112818ae8723d@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"2dbde340fae8122342a4d7c13fea7890ab963d11/base"]: {{{ #!CommitTicketReference repository="base" revision="2dbde340fae8122342a4d7c13fea7890ab963d11" Mark Data.Coerce as Unsafe (#8827) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 05:57:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 05:57:29 -0000 Subject: [GHC] #8736: GHCi doesn't load .dyn_o files appropriately In-Reply-To: <052.b282b771a49ddd09f40719b07cb558fa@haskell.org> References: <052.b282b771a49ddd09f40719b07cb558fa@haskell.org> Message-ID: <067.0d4b9224e1049bb6de1351461030bbba@haskell.org> #8736: GHCi doesn't load .dyn_o files appropriately -------------------------------------+------------------------------------ Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1-rc2 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 thoughtpolice): * milestone: 7.8.1 => 7.8.2 Comment: We're moving this to 7.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 05:59:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 05:59:20 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.a47214fdc6d9d2673d64aa09baadeb05@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by thoughtpolice): * priority: highest => high * milestone: 7.8.1 => 7.8.2 Comment: This is now fixed in the 7.8 branch, so I'm moving this to 7.8.2 tentatively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 06:03:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 06:03:05 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.bd4b8e199106f70696ed3e3ddc965d2e@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: highest | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: 7.8.1 => 7.8.2 Comment: I've looked over the patch more but can't quite see what's wrong yet. Unfortunately time is out, and I'm bumping this to 7.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 06:03:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 06:03:12 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.da112d0fcb4a70d270dac492e1e90641@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: high | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * priority: highest => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 06:40:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 06:40:44 -0000 Subject: [GHC] #8923: Add SmallArray# type In-Reply-To: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> References: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> Message-ID: <059.c108845a2e7177a3131ec178a4e57d68@haskell.org> #8923: Add SmallArray# type -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): simonpj, could you look at the second patch (attachment:0002-Add- SmallArray-type-to-front-end.patch?), which adds the new type to the type system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 07:14:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 07:14:36 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.e6152ef8fc323deb21ea5e63a6d3508e@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by Austin Seipp ): In [changeset:"15b1eb7c67e29c4ad6f6859f89d220b33493fd46/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="15b1eb7c67e29c4ad6f6859f89d220b33493fd46" Revert "change deriveConstants to use nm in a POSIX way (fixes #8781)" It causes a failure on Windows right now. This reverts commit 045b28033a33a48d31951240a8cb35f2b78345dc. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 07:15:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 07:15:49 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.2615724989b353d0748d045c042c719f@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Changes (by thoughtpolice): * owner: kgardas => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 07:18:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 07:18:16 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.5ddd6cbc8ad6cbfaac554d0748dfccae@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Changes (by kgardas): * owner: => kgardas -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 07:53:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 07:53:32 -0000 Subject: [GHC] #8923: Add SmallArray# type In-Reply-To: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> References: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> Message-ID: <059.fd9d4071c60fcda7541099c84b6e3614@haskell.org> #8923: Add SmallArray# type -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Let me know if you prefer to do the code review on GitHub and I'll push my changes there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 08:11:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 08:11:28 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.5889691a490cd2825a6702ebc42e01ad@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * version: 7.8.1-rc2 => 7.9 * milestone: 7.8.1 => 7.10.1 Comment: This is now taken care of in HEAD and 7.8, so I'm moving it out of the milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 08:11:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 08:11:42 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.999aefea21c571e8936dc714ce808650@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: Merged in 7.8, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 08:53:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 08:53:39 -0000 Subject: [GHC] #8378: Cross-compiling from x86_64-unknown-linux-gnu to x86_64-sun-solaris2 with mkGmpConstants workaround fails to build objects for integer-gmp In-Reply-To: <048.61652c3ceceadbb7e8705f58ce1ae24c@haskell.org> References: <048.61652c3ceceadbb7e8705f58ce1ae24c@haskell.org> Message-ID: <063.7d9964a58554cbff5dd2c7b9dabcacd2@haskell.org> #8378: Cross-compiling from x86_64-unknown-linux-gnu to x86_64-sun-solaris2 with mkGmpConstants workaround fails to build objects for integer-gmp -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: solaris,integer- Operating System: Unknown/Multiple | gmp Type of failure: Building GHC | Architecture: Unknown/Multiple failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8373,8366,8361 -------------------------------------+------------------------------------- Comment (by kgardas): As dyson OS is still not using GNU LibC, I guess it is very similar from ABI point of view to Solaris. Perhaps it may be good to start with hacking on Solaris then? See #8910 for first attempt of crosscompiling from i386 solaris to amd64 solaris... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 08:53:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 08:53:58 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.3bb404415b69f94e7ef851725590a0b0@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc1 Type of failure: None/Unknown | Keywords: Safe Test Case: | Architecture: should_fail/TcCoercibleFailSafe | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): Don't miss the long discussion in #8827 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 08:58:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 08:58:41 -0000 Subject: [GHC] #8910: cross compiling for x86_64 solaris2 In-Reply-To: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> References: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> Message-ID: <060.846005ab58883ed76d48a33dfc9cd060@haskell.org> #8910: cross compiling for x86_64 solaris2 ----------------------------------+---------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by kgardas): Well, I've also got that far IIRC in the past and then was blocked by segfaults everywhere. Anyway, back in my head one idea started to appear and that is. Perhaps we don't have ABI right in RTS? Have a look into rts/StgCRun.c -- scroll to x86_64 part and you will see different regs being pushed/poped for MinGW (so Windows). I would seriously suggest to check Solaris AMD64 ABI and check that StgCRun.c is written in correct way for it. If not, then fix it first there. Also if it's over your head now, perhaps you can at least give a try to testsuite. You can run testsuite with stage1 compiler with IIRC: {{{ make stage=1 }}} and let's see if you get at least few tests passing. See http://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running for more information about running the testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 09:00:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 09:00:17 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.b51a91487b7d84864cc2746f9d823c5a@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by simonpj): Replying to [comment:31 ekmett]: > > is somewhat in line with what I've been playing around with to try to work out how we can lift coercions over complex data types. Edward, I'm not following all the details of your comment here (like where is `Coercion` defined?), but it smells to me that you are hitting the the main limitation of the system as-implemented, namely the inability to abstract over a type constructor with a representational argument. Eg {{{ data T f a = MkT (f a) }}} Can I do `Coercible (T f Int) (T f Age)` (where `Age` is a newtype for `Int`)? Only if we are guaranteed that `f` will be instantiated with type constructor with representational roles. So you want higher-order roles. We know how to do that, but rejected it as Too Complicated. We could revisit that I guess. I may also be misunderstanding your problem. Perhaps it would help to exhibit the simplest case that doesn't work. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 09:16:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 09:16:53 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.4f5458fc7c7279418a9661051d44d160@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by juhpetersen): * cc: juhp@? (added) Comment: Right +1 In Fedora, so far I have been working around it by packaging the xhtml library along with the other ghc libraries. Since xhtml is in HP anyway it seems easier/cleaner just to move it to ghc now IMHO. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 09:21:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 09:21:25 -0000 Subject: [GHC] #8819: Testsuite failures in 7.8 RC1 In-Reply-To: <047.078a5163c24ff483458aa1a9649d90bf@haskell.org> References: <047.078a5163c24ff483458aa1a9649d90bf@haskell.org> Message-ID: <062.10b663e3253ac4c9257f127e52176f5d@haskell.org> #8819: Testsuite failures in 7.8 RC1 ------------------------------------------------+-------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by juhpetersen): * cc: juhp@? (added) * priority: normal => high * version: 7.8.1-rc1 => 7.8.1-rc2 Comment: Reproduced also on s390x [1] and I believe ppc64 [2] for 7.8.1 RC2. [1] http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1369051 -> build.log [2] http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1731757 -> build.log -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 09:23:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 09:23:28 -0000 Subject: [GHC] #8819: 64bit Testsuite failures in unregisterised 7.8 RCs (was: Testsuite failures in 7.8 RC1) In-Reply-To: <047.078a5163c24ff483458aa1a9649d90bf@haskell.org> References: <047.078a5163c24ff483458aa1a9649d90bf@haskell.org> Message-ID: <062.9c077d993b27f7f699c55b06ba193b0f@haskell.org> #8819: 64bit Testsuite failures in unregisterised 7.8 RCs ------------------------------------------------+-------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by juhpetersen): * os: Unknown/Multiple => Linux -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 09:23:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 09:23:52 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.4e7a14f4734a7088af8320ce8cb3f297@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): It would be interesting to see the failure. Is the additional "-P" option the problem or is there yet another output format produced for: {{{ nm -P includes/dist-derivedconstants/header/tmp.o }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 09:24:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 09:24:17 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.a114cdf7167b7dea577f39652115223b@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Changes (by gidyn): * cc: gideon@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 09:24:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 09:24:59 -0000 Subject: [GHC] #8228: GHC built under Windows does not generate dyn_hi files In-Reply-To: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> References: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> Message-ID: <060.389580eda586edf9e63bc2141c8b9fc4@haskell.org> #8228: GHC built under Windows does not generate dyn_hi files --------------------------------------------+------------------------------ Reporter: ezyang | Owner: Type: bug | thoughtpolice Priority: highest | Status: new Component: Compiler | Milestone: 7.8.2 Resolution: | Version: 7.7 Operating System: Windows | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: cabal01 | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #7134 --------------------------------------------+------------------------------ Changes (by gidyn): * cc: gideon@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 09:25:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 09:25:11 -0000 Subject: [GHC] #8736: GHCi doesn't load .dyn_o files appropriately In-Reply-To: <052.b282b771a49ddd09f40719b07cb558fa@haskell.org> References: <052.b282b771a49ddd09f40719b07cb558fa@haskell.org> Message-ID: <067.8538be8239dde40b6ed787e72dca06dd@haskell.org> #8736: GHCi doesn't load .dyn_o files appropriately -------------------------------------+------------------------------------ Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1-rc2 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 gidyn): * cc: gideon@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 09:28:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 09:28:51 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.28f6716ca79cd94ec439cd0b641b6423@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by kgardas): It's all discussed on ghc-devs@, I've also provided a fix for this for windows guys testing. The output on windows from gnu nm is three words list: {{{ _derivedConstantCINT_SIZE C 00000005 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 09:57:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 09:57:30 -0000 Subject: [GHC] #8924: Text.ParserCombinators.ReadP needs some kind of "commit" or "cut" to force a single parse.. In-Reply-To: <050.1906743244648eb3189d64db5510846c@haskell.org> References: <050.1906743244648eb3189d64db5510846c@haskell.org> Message-ID: <065.9f1f925756dfcf760bf0929f800e2f59@haskell.org> #8924: Text.ParserCombinators.ReadP needs some kind of "commit" or "cut" to force a single parse.. -------------------------------------+------------------------------------ Reporter: PaulJohnson | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 simonpj): * cc: koen@? (added) Old description: > The ReadP monad maintains all possible parses of its input, rather than > being left-biased as most parsers are. However this is not always quite > the Right Thing. I maintain the Data.Decimal library. The Read instance > for Data.Decimal up to 0.3.1 had the following behaviour: > > reads "34.567e8 foo" :: [(Decimal, String)] = [(34.0,".567e8 > foo"),(34.567,"e8 foo"),(3.4567e9," foo")] > > Clearly only the last parse in the list is the Right Thing, and any > parser which returns "34.0" when given "34.567" is doing it wrong. > > The problem came from the implementation of "optional". In numbers only > the integer part is mandatory, with the fractional and exponent parts > being optional. So I wrote my parser with the fractional part parsed like > this: > > fractPart <- optional "" $ do > _ <- char '.' > munch1 isDigit > > The problem is that "optional" uses the symmetric choice operator (+++). > I wrote this to work around the problem: > > myOpt d p = p <++ return d > > This uses the left-biased choice, so as soon as the parser sees the "." > it commits to the fractional part. > > However this still isn't the Right Thing. > > reads "34." :: [(Double, String)] = [(34.0, ".")] > > but the parser above will fail to read it. Furthermore there are a number > of combinators built on "+++" in ReadP, and it seems wrong to have left- > biased variants of all of them. > > So what seems to be needed is some kind of "cut" operator, analogous to > the Prolog "!" cut, which says that if you have got this far then you > should commit to this parse and forget all the others. But it would have > to be delimited because I only want that cut to apply to my Decimal type: > if someone calls my Decimal parser then I don't want their parser to > commit to an entire parse just because I have. > > So I think the feature I'm looking for is a delimited back-track akin to > "prompt" in delimited continuations. But my monad-fu isn't good enough to > design it. New description: The ReadP monad maintains all possible parses of its input, rather than being left-biased as most parsers are. However this is not always quite the Right Thing. I maintain the Data.Decimal library. The Read instance for Data.Decimal up to 0.3.1 had the following behaviour: {{{ reads "34.567e8 foo" :: [(Decimal, String)] = [(34.0,".567e8 foo"),(34.567,"e8 foo"),(3.4567e9," foo")] }} Clearly only the last parse in the list is the Right Thing, and any parser which returns "34.0" when given "34.567" is doing it wrong. The problem came from the implementation of "optional". In numbers only the integer part is mandatory, with the fractional and exponent parts being optional. So I wrote my parser with the fractional part parsed like this: {{{ fractPart <- optional "" $ do _ <- char '.' munch1 isDigit }}} The problem is that "optional" uses the symmetric choice operator (+++). I wrote this to work around the problem: {{{ myOpt d p = p <++ return d }}} This uses the left-biased choice, so as soon as the parser sees the "." it commits to the fractional part. However this still isn't the Right Thing. {{{ reads "34." :: [(Double, String)] = [(34.0, ".")] }}} but the parser above will fail to read it. Furthermore there are a number of combinators built on "+++" in ReadP, and it seems wrong to have left- biased variants of all of them. So what seems to be needed is some kind of "cut" operator, analogous to the Prolog "!" cut, which says that if you have got this far then you should commit to this parse and forget all the others. But it would have to be delimited because I only want that cut to apply to my Decimal type: if someone calls my Decimal parser then I don't want their parser to commit to an entire parse just because I have. So I think the feature I'm looking for is a delimited back-track akin to "prompt" in delimited continuations. But my monad-fu isn't good enough to design it. -- Comment: Adding Koen, who wrote this library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 10:26:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 10:26:46 -0000 Subject: [GHC] #8913: either bug or confusing error message mixing PolyKinds and TypeFamilies In-Reply-To: <044.30ecf3720077f5e887124dbcf31b88c9@haskell.org> References: <044.30ecf3720077f5e887124dbcf31b88c9@haskell.org> Message-ID: <059.10938a610c25bb3c649731dd1c846d01@haskell.org> #8913: either bug or confusing error message mixing PolyKinds and TypeFamilies -------------------------------------+------------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: PolyKinds, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c89c57e3b72a8f3de9f35e1bd6e0f70d2b18a941/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c89c57e3b72a8f3de9f35e1bd6e0f70d2b18a941" For equalities with incompatible kinds, new IrredCan goes in the inert set, not work list This change makes the code for canIrred markedly simpler (and more efficient) See Note [Equalities with incompatible kinds]. I don't think there was really a bug here, but I came across it when fixing Trac #8913 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 10:26:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 10:26:46 -0000 Subject: [GHC] #8913: either bug or confusing error message mixing PolyKinds and TypeFamilies In-Reply-To: <044.30ecf3720077f5e887124dbcf31b88c9@haskell.org> References: <044.30ecf3720077f5e887124dbcf31b88c9@haskell.org> Message-ID: <059.1a4c447197783bd53d4401b05b60e1f2@haskell.org> #8913: either bug or confusing error message mixing PolyKinds and TypeFamilies -------------------------------------+------------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: PolyKinds, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6ae678e31a5fdd3b0bd1f8613fe164012bb630f4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6ae678e31a5fdd3b0bd1f8613fe164012bb630f4" Flattener preserves synonyms, rewriteEvidence can drop buggy "optimisation" There was a special case in rewriteEvidence, looking like: = return (Just (if ctEvPred old_ev `tcEqType` new_pred then old_ev else old_ev { ctev_pred = new_pred })) But this was wrong: old_pred and new_pred might differ in the kind of a TyVar occurrence, in which case tcEqType would not notice, but we really, really want new_pred. This caused Trac #8913. I solved this by dropping the whole test, and instead making the flattener preserve type synonyms. This was easy because TcEvidence has TcTyConAppCo which (unlike) Coercion, handles synonyms. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 10:26:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 10:26:48 -0000 Subject: [GHC] #8912: Documentation stale: implicit-parameter constraints seem to be allowed in instance declarations now. In-Reply-To: <051.9deb02feaf66c13b5aa3da47e90da868@haskell.org> References: <051.9deb02feaf66c13b5aa3da47e90da868@haskell.org> Message-ID: <066.d52aa447e96c39dfcd139047e65da2de@haskell.org> #8912: Documentation stale: implicit-parameter constraints seem to be allowed in instance declarations now. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: implicit- Operating System: Unknown/Multiple | parameter instance-constraints Type of failure: Documentation | Architecture: Unknown/Multiple bug | Difficulty: Easy (less than 1 Test Case: | hour) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a8b7b28cdb98d14c6fb43d5ad3293fd4a5c1f8b4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a8b7b28cdb98d14c6fb43d5ad3293fd4a5c1f8b4" Implicit parameters should not be allowed in class and instance declarations Trac #8912 pointed out that GHC 7.4 and 7.6 have omitted this test, although 7.2 and earlier had it. This patch puts the test back in, and refactors a little. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 10:28:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 10:28:54 -0000 Subject: [GHC] #8913: either bug or confusing error message mixing PolyKinds and TypeFamilies In-Reply-To: <044.30ecf3720077f5e887124dbcf31b88c9@haskell.org> References: <044.30ecf3720077f5e887124dbcf31b88c9@haskell.org> Message-ID: <059.899604819d17a85f26e211034252100c@haskell.org> #8913: either bug or confusing error message mixing PolyKinds and TypeFamilies -------------------------------------+------------------------------------- Reporter: ghorn | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: PolyKinds, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: indexed_types/should_compile/T8913 | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => indexed_types/should_compile/T8913 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 10:29:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 10:29:46 -0000 Subject: [GHC] #8912: Documentation stale: implicit-parameter constraints seem to be allowed in instance declarations now. In-Reply-To: <051.9deb02feaf66c13b5aa3da47e90da868@haskell.org> References: <051.9deb02feaf66c13b5aa3da47e90da868@haskell.org> Message-ID: <066.176303027b490d6e3380f7985dfc5e02@haskell.org> #8912: Documentation stale: implicit-parameter constraints seem to be allowed in instance declarations now. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: implicit- Operating System: Unknown/Multiple | parameter instance-constraints Type of failure: Documentation | Architecture: Unknown/Multiple bug | Difficulty: Easy (less than 1 Test Case: | hour) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: Quite right. The user manual is right! Fixed. I guess it's worth merging this if poss Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 10:46:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 10:46:38 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.b91ef1fc1ba24e54cf0eca959d7eacd8@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8226, 8745 -------------------------------------+------------------------------------ Comment (by simonpj): OK, so we've essentially decided (for 7.8) * Keep the status quo (as presented in the paper) for 7.8 * But GND and `Data.Coerce` are both out of bounds for Safe Haskell That's ok with me. Subsequent to 7.8, the Davids (or other Safe Haskell folk) may want to propose a concrete plan for getting them back in. Or maybe it just doesn't matter because Safe Haskell clients don't care (enough) about GND or `Coercible`. FWIW I am keen to avoid any solution based on direct user control of `Coercible` instances. We have roles (we need them regardless to guarantee type-soundness); what we want can be expressed through roles or role signatures; adding ''another'' mechanism of control that does almost the same thing should be avoided if at all possible. Indeed, I don't think in terms of instance declarations for `Coercible` at all; instead it's just a matter of what rules are available for solving `Coercible` constraints. To take an analogy, implicit parameters are internally implemented as type-class constraints, with some special rules. They share some stuff in common with type class constraints, but are best thought of separately. Same with `Coercible`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 11:04:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 11:04:47 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.2d31fb2644231a6b9f81e93eaef29402@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: The results for i386 aren't bad either, compile times seem OK as well: {{{ -1 s.d. ----- -2.0% +1 s.d. ----- +1.7% Average ----- -0.2% }}} So I think this ticket can be considered closed - the penalties seem very small overall on GHC, which is the primary case for dynamic linking (and probably the largest). Simon, do re-open if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 11:30:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 11:30:08 -0000 Subject: [GHC] #8923: Add SmallArray# type In-Reply-To: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> References: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> Message-ID: <059.702ade5ba59fb27e7c0863c45fddc286@haskell.org> #8923: Add SmallArray# type -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I have not been following the thread, but it seems surprising to add tow new types to `primpops.txt.pp` with no accompanying primpops to manipulate them. But the front-end changes (which amount only to adding stuff to `PrelNames` and `TysPrim`) look ok to me. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 11:50:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 11:50:43 -0000 Subject: [GHC] #8923: Add SmallArray# type In-Reply-To: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> References: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> Message-ID: <059.a6e6a556f52092b08ddd951ee2175159@haskell.org> #8923: Add SmallArray# type -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Replying to [comment:5 simonpj]: > I have not been following the thread, but it seems surprising to add tow new types to `primpops.txt.pp` with no accompanying primpops to manipulate them. I just wanted some early feedback on the core of the implementation. I will add all the primops in the next step. > But the front-end changes (which amount only to adding stuff to `PrelNames` and `TysPrim`) look ok to me. Great, I will proceed with adding the primops and writing some tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 12:05:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 12:05:08 -0000 Subject: [GHC] #8913: either bug or confusing error message mixing PolyKinds and TypeFamilies In-Reply-To: <044.30ecf3720077f5e887124dbcf31b88c9@haskell.org> References: <044.30ecf3720077f5e887124dbcf31b88c9@haskell.org> Message-ID: <059.d3011b29181d22769405baf75298e39f@haskell.org> #8913: either bug or confusing error message mixing PolyKinds and TypeFamilies -------------------------------------+------------------------------------- Reporter: ghorn | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: PolyKinds, Resolution: fixed | TypeFamilies Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: indexed_types/should_compile/T8913 | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 12:05:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 12:05:19 -0000 Subject: [GHC] #8912: Documentation stale: implicit-parameter constraints seem to be allowed in instance declarations now. In-Reply-To: <051.9deb02feaf66c13b5aa3da47e90da868@haskell.org> References: <051.9deb02feaf66c13b5aa3da47e90da868@haskell.org> Message-ID: <066.d956bfc862456394db23e6f3d9835299@haskell.org> #8912: Documentation stale: implicit-parameter constraints seem to be allowed in instance declarations now. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: fixed | Keywords: implicit- Operating System: Unknown/Multiple | parameter instance-constraints Type of failure: Documentation | Architecture: Unknown/Multiple bug | Difficulty: Easy (less than 1 Test Case: | hour) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 12:14:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 12:14:02 -0000 Subject: [GHC] #8912: Documentation stale: implicit-parameter constraints seem to be allowed in instance declarations now. In-Reply-To: <051.9deb02feaf66c13b5aa3da47e90da868@haskell.org> References: <051.9deb02feaf66c13b5aa3da47e90da868@haskell.org> Message-ID: <066.0317c3378f4e560c9e365661b1654413@haskell.org> #8912: Documentation stale: implicit-parameter constraints seem to be allowed in instance declarations now. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: fixed | Keywords: implicit- Operating System: Unknown/Multiple | parameter instance-constraints Type of failure: Documentation | Architecture: Unknown/Multiple bug | Difficulty: Easy (less than 1 Test Case: | hour) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Comment (by andreas.abel): Ah, too bad, I thought this feature had been implemented. Seemed to work, though. Cheers, A -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 13:04:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 13:04:27 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.181301efced00869aecc3b5b5bdcb2d4@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Concerning the patch, I just looked at the `CoreSyn` changes in https://github.com/scpmw/ghc/commit/d829a088a98b1d716ad4d51593d22deae0e97d0a. I think it's a real improvement. I've left a couple of notes about `Ord` instances, which I hate. I still find the language that specifies what "placement" or "scoping" is, hard to understand. I'd urge you to add a list of all the transformations you can think of, in a table, with their placement/scoping properties. Something like this: {{{ Transformation Before After Placement Scoping ---------------------------------------------------------------- tick t (\x.e) \x.tick t e PlaceNonLam n/a tick t (let x = e in b) let x = e in tick t b --- never -- tick t (let x = e in b) let x = tick t e in tick t b n/a Soft (tick t fun) arg tick t (fun arg) ...etc... ...etc... }}} That would bring focus to the general descriptions. There should pretty be a line of the table for each call that makes use of the properties to allow, or disallow, a transformation. Oh, maybe you need a column for "counts" which is (I believe) a third property of a tick that, with scoped/placement, says which transformations are valid. Maybe you want a third data type rather than a boolean, to highlight this fact? Some comments with `tickishScoped` would be useful. Why are HPC ticks `NoScope`? That sounds as though we can move code outside an HPC tick so it is no longer covered. Or something. As the the wiki page, there is stuff that you take for granted but which forms the big picture * The fact that semantically ticks never have significance. * What it means for a tick to "cover" some code. * The fact that (I think that) ticks have lexical scope, from the point of view of what it means to be "covered". * A little summary of the various kinds of ticks, their significance and a rough sketch of how they work. For example, your new `SourceNotes` turn into something attached to DWARF records which is somehow recovered by a debugger. It's hard to get from the `SourceNote` data constructor to all that relevant other stuff in the compiler. Of course you can put all this big-picture stuff in `CoreSyn` with the data type declarations, but it's getting big. Maybe you want a module for the `Tick` stuff that `CoreSyn` imports, where we can accumulate this overview material. Broadly speaking, though, it looks fine to me. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 14:23:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 14:23:17 -0000 Subject: [GHC] #8900: Strictness analysis regression In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.475461393b2039466801b365729b8d9b@haskell.org> #8900: Strictness analysis regression --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"0b6fa3e95078797f87302780a85607decab806fb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0b6fa3e95078797f87302780a85607decab806fb" Eliminate redundant seq's (Trac #8900) This patch makes the simplifier eliminate a redundant seq like case x of y -> ...y.... where y is used strictly. GHC used to do this, but I made it less aggressive in commit 28d9a03253e8fd613667526a170b684f2017d299 (Jan 2013) However #8900 shows that doing so sometimes loses good transformations; and the transformation is valid according to "A semantics for imprecise exceptions". So I'm restoring the old behaviour. See Note [Eliminating redundant seqs] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 14:26:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 14:26:09 -0000 Subject: [GHC] #8900: Strictness analysis regression In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.79dc1d6361f0bd56ff904d443a6b27c0@haskell.org> #8900: Strictness analysis regression --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): OK I have restored the old behaviour. (No need to merge.) I did a nofib run and found * No visible change in binary size * No change in allocation * Wibbles up and down in runtime but nothing consistent. (On my machine running `k-nucleotide` varies by up to 10% runtime in successive runes, for example.) So I don't think there are significant losses, and Johan definitely has a gain to get. I have not actually tried Johan's example, but perhaps Johan can? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 14:33:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 14:33:27 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.481710bfc68c84e879336d7d9b3114c0@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): Hold the release! I've found the bug. It's in the native codegen. Patch coming soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 14:40:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 14:40:26 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.b7b02a14166cbcd3a29824b5c4342b15@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by simonmar): * priority: high => highest * milestone: 7.8.2 => 7.8.1 Comment: Patch attached. I'll validate it, but I only have one Windows laptop and I'm using it for work, so this might take a while. If someone else can validate more quickly, please go ahead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 14:41:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 14:41:11 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.38de4043768f02817d4b11361e04475c@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): Oh, and you also have to revert a79613a75c7da0d3d225850382f0f578a07113b5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 14:46:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 14:46:59 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.432e8bb2feb5abd0328cc719ff9a856f@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): On the first glance patch looks slightly insufficient because it does not touch 32-bit case. Or did I missed something here? AFAIR, that also was the case of 32-bit GHC segfaults. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 14:51:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 14:51:54 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.bcce7aaba58498f24003f4996d137b34@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: high | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): sounds good to me. Especially since the patch is more future proofing than "needed today". Malcom's remark on devs {{{ This looks like the key information: > Building xhtml-3000.2.1... > Preprocessing library xhtml-3000.2.1... > ghc: could not execute: Ghc is reporting that it could not execute "". This suggests the commandline for external preprocessing is incorrectly formed. }}} is suggestive. I may have to revisit herbert's patch perhaps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 15:08:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 15:08:48 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.8cab5c4af417d6bf6f0c243c75c22c1f@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+------------------------------ Reporter: facundoq | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+------------------------------ Changes (by thoughtpolice): * priority: highest => high * status: new => infoneeded * milestone: 7.8.1 => 7.8.2 Comment: After testing and investigation, we believe this is related to #8834 - but also, we can't easily reproduce this. So I'm lowering the priority and marking this to 7.8.2. I will thoroughly test with the Windows distribution (coming soon). BTW: what version of Windows are you using? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 15:31:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 15:31:12 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.0b41975f01583d2046f06c9e0087d37b@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------------------+------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: Runtime performance bug | Architecture: Test Case: | Unknown/Multiple simplCore/should_compile/T8832 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * owner: simonpj => * status: closed => new * resolution: fixed => Comment: The test fails on 32-bit machines, because we don't have 64-bit primops on a 32-bit machine, so the constant folding doesn't work. Maybe we should have 64-bit primops on a 32-bit machine, but that's a separate story. Meanwhile, we need to fix the test so that it omits the 64-bit test on 32-bit machines. Austin can you do this, post release? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 15:31:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 15:31:47 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.a54bf69555b0a836ce6ae7098c39faf5@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------------------+------------------------- Reporter: hvr | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Compiler | Milestone: Resolution: | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: Runtime performance bug | Keywords: Test Case: | Architecture: simplCore/should_compile/T8832 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * owner: => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 15:41:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 15:41:03 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.7d8d86b3e5620f4f707ec7e7d044346d@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: jstolarek Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): Yeah, this is definitely the cause of the crash on 64-bit Windows, so if 32-bit is also crashing then there must be another bug somewhere. @thoughtpolice is going to test again and see if it's still crashing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 17:22:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 17:22:25 -0000 Subject: [GHC] #8900: Strictness analysis regression In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.c4afadd0df8c8bce24a53f886835b2bc@haskell.org> #8900: Strictness analysis regression --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by tibbe): * status: new => closed * resolution: => fixed Comment: My code now looks good. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 17:26:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 17:26:32 -0000 Subject: [GHC] #8900: Strictness analysis regression In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.03c84491c27f9f232a1639a4fec6923f@haskell.org> #8900: Strictness analysis regression --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Comment 9 you said "While the extra case is definitely a regression, it doesn't seem to be the cause of the time difference". and in comment 14 "without the extra case there is still a small difference". Is that still true? If so there might still be something to track down. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 17:53:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 17:53:55 -0000 Subject: [GHC] #8900: Strictness analysis regression In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.d0f8cfb8ca0a2ce6cd9640d5735e4f75@haskell.org> #8900: Strictness analysis regression --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): Replying to [comment:21 simonpj]: > Comment 9 you said "While the extra case is definitely a regression, it doesn't seem to be the cause of the time difference". and in comment 14 "without the extra case there is still a small difference". > > Is that still true? If so there might still be something to track down. There's still a (quite small) difference in mutator time. I haven't had time to investigate it. The Cmm output by 7.6.3 (attachment:HashMapInsert-7.6.3.dump-opt-cmm) and HEAD (attachment:HashMapInsert-HEAD.dump-opt-cmm) look quite a bit different, at least superficially. For example, 7.6.3 has the core loop split into two functions, `$wpoly_go_info` and `s30b_ret`, while HEAD has just one function, `$wpoly_go_entry`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 18:10:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 18:10:38 -0000 Subject: [GHC] #8900: Strictness analysis regression In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.ad14bce829b5e74b502b0f9b1743aa06@haskell.org> #8900: Strictness analysis regression --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): I've looked a bit more closely and one difference between 7.6.3 and HEAD is the extra stack spilling before the eval check I reported in #8905. Another difference is that the recursive call appears as {{{ jump $wpoly_go_info; // [R6, R5, R4, R3, R2] }}} in 7.6.3 but as {{{ call $wpoly_go_info(R6, R5, R4, R3, R2) returns to c56A, args: 8, res: 8, upd: 8; }}} in HEAD. I don't know if this is just a syntactic difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 18:42:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 18:42:15 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF In-Reply-To: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> References: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> Message-ID: <059.738510d641fdf8753b3bf481854ffc4a@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): I've attached the Cmm for the biggest loss in the nofib run above, `cryptarithm1`. There's definitely more code generated with simonmar's patch (which nofib strangely doesn't report). Just to validate nofib's result, I reran this benchmark manually and grabbed the results for the best out of five runs: master: {{{ real 0m0.328s user 0m0.320s sys 0m0.007s }}} no-spill: {{{ real 0m0.333s user 0m0.325s sys 0m0.007s }}} That's a 1.5% runtime difference. Looking at the mutator time with `+RTS -s` (using five new runs), I can see no difference (`+RTS -s` has lower resolution). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 21:38:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 21:38:24 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.c90bb8cadf21a08f12a9e45a1786735a@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Changes (by kgardas): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 24 23:12:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Mar 2014 23:12:50 -0000 Subject: [GHC] #8926: GHC makes unsound references in object code Message-ID: <052.93f7af489c413776f218da91117a1ded@haskell.org> #8926: GHC makes unsound references in object code ----------------------------+---------------------------------------------- Reporter: | Owner: anton.dubovik | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- To reproduce the bug run script `run.sh` from the attached archive. It will: 1. install `FooPackage` {{{ Resolving dependencies... Configuring FooPackage-0.1... Building FooPackage-0.1... Preprocessing library FooPackage-0.1... [1 of 1] Compiling FooPackage ( src\FooPackage.hs, dist\build\FooPackage.o ) In-place registering FooPackage-0.1... Installing library in C:\Users\Anton\AppData\Roaming\cabal\i386-windows- ghc-7.6.3\FooPackage-0.1 Registering FooPackage-0.1... Installed FooPackage-0.1 }}} 2. compile executable `Client1` which depends on `FooPackage` {{{ [1 of 3] Compiling QuxClient ( QuxClient.hs, obj\QuxClient.o ) [2 of 3] Compiling BarClient ( BarClient.hs, obj\BarClient.o ) [3 of 3] Compiling Client1 ( Client1.hs, obj\Client1.o ) Linking exes/Client1.exe ... }}} 3. compile executable `Client2` which doesn't depend on `FooPackage` At the third step GHC will fall with linker error: {{{ [2 of 2] Compiling Client2 ( Client2.hs, obj\Client2.o ) Linking exes/Client2.exe ... obj\BarClient.o:fake:(.text+0x83): undefined reference to `FooPackagezm0zi1_FooPackage_zdsinsertzuzdsgo5_info' obj\BarClient.o:fake:(.data+0x10): undefined reference to `FooPackagezm0zi1_FooPackage_zdsinsertzuzdsgo5_closure' collect2: ld returned 1 exit status }}} Both `Client1` and `Client2` import `BarClient` module that doesn't depends on `FooPackage`. `Client1` imports `QuxClient` that imports `FooPackage`: {{{ module QuxClient where import FooPackage(foo) import Data.Set qux :: Set String -> Set String qux = foo }}} {{{ module BarClient where import Data.Set bar :: Set String -> Set String bar s = insert "bar" s }}} `FooPackage` uses function `Data.Set.insert` which is marked at `Data.Set` as `INLINABLE`: {{{ module FooPackage where import Data.Set foo :: Set String -> Set String foo s = insert "foo" s }}} GHC emphasizes in interface file, that `FooPackage.o` contains specialized version of `Data.Set.insert`: {{{ > ghc --show-iface FooPackage.hi ... "SPEC Data.Set.Base.insert [GHC.Base.String]" [ALWAYS] forall $dOrd :: GHC.Classes.Ord GHC.Base.String Data.Set.Base.insert @ [GHC.Types.Char] $dOrd = FooPackage.$sinsert ... }}} Later GHC see again the use of `Data.Set.insert at String` at `BarClient` and decides to apply this specialise rule, so that `BarClient` now has reference to `FooPackage`: {{{ > ghc --show-iface BarClient.hi ... bar :: Data.Set.Base.Set GHC.Base.String -> Data.Set.Base.Set GHC.Base.String {- Arity: 1, Strictness: S, Unfolding: (\ s :: Data.Set.Base.Set GHC.Base.String -> FooPackage.$sinsert_$sgo5 BarClient.bar1 s) -} ... }}} `Client2` doesn't depend on `FooPackage`, thus linker throws an error. There are plenty of workarounds here, but all of them are ad hoc (1,2,3) or could affect performance (4): 1. Change the order of `BarClient` and `QuxClient` imports in `Client1` module. 2. Compile `Client1` and `Client2` in opposite order. 3. Add fake import at `Client2` module: {{{ import FooPackage() }}} 4. Build `FooPackage` with ghc-option `-fomit-interface-pragmas`. That will eraise from `FooPackage.hi` all specialisation rules as well as information about strictness and inlining. Some information about the environment: {{{ > ghc-pkg list ... containers-0.5.0.0 base-4.6.0.1 ... > ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 > cabal --version cabal-install version 1.18.0.3 using version 1.18.1.3 of the Cabal library }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 25 08:18:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Mar 2014 08:18:52 -0000 Subject: [GHC] #8900: Strictness analysis regression In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.973814e90caf06b7516129a15eca3592@haskell.org> #8900: Strictness analysis regression --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): > one difference between 7.6.3 and HEAD is the extra stack spilling before the eval check I reported in #8905 I was surprised by this, because I would expect HEAD and 7.6.3 to generate very similar code with respect to spilling before a call. #8905 is about an improvement we can make in the new code generator, that wasn't possible in the old codegen. Looking at your dumps I see this for HEAD in `$wpoly_go_info`: {{{ c5k9: I64[Sp - 40] = PicBaseReg + block_c53R_info; R1 = R6; I64[Sp - 32] = R2; I64[Sp - 24] = R3; P64[Sp - 16] = R4; I64[Sp - 8] = R5; Sp = Sp - 40; if (R1 & 7 != 0) goto c53R; else goto c53S; }}} and this for 7.6.3: {{{ I64[Sp - 32] = R5; I64[Sp - 24] = R4; I64[Sp - 16] = R3; I64[Sp - 8] = R2; R1 = R6; I64[Sp - 40] = PicBaseReg + s30b_info; Sp = Sp - 40; if (R1 & 7 != 0) goto c3zM; }}} they look identical to me modulo reordering and things falling into different stack slots. Maybe the problematic bit is somewhere else - could you point to it? Some of the other differences you're seeing are due to the fact that the new codegen (with the NCG) doesn't break up functions at proc-points, so you see larger chunks of code where 7.6.3 broke things into smaller pieces. Most of the time this won't make any difference to the generated code, unless there's a join point (a let-no-escape) where HEAD should generate better code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 25 08:28:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Mar 2014 08:28:02 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.03f29d268bc3ea48d7d80963308f8b4f@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): Sorry, I don't like this patch as it contains duplicate code. Let's improve it for ghc-7.8.2 (whatever ends up in ghc-7.8.1 now) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 25 08:39:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Mar 2014 08:39:10 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.3f7a85905bb98b1c81bcefc31b30d4e3@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): I propose the code as follows: {{{ parseNmLine xs0 = case words xs0 of x0 : x1 : x2 : r -> case stripPrefix prefix $ dropWhile (== '_') x0 of Just name -> case readHex $ case r of [x3] | x1 /= "C" -> x3 _ -> x2 of [(size, "")] -> Just (name, size) _ -> Nothing _ -> Nothing _ -> Nothing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 25 09:39:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Mar 2014 09:39:46 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.20ee33139919b58bc9019564755577b8@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): Well, it could be much less indented, too, after the first line. If you think, that the second is too long break it after "->" or use single letter names for x0, x1 and x2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 25 10:37:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Mar 2014 10:37:10 -0000 Subject: [GHC] #8900: Strictness analysis regression In-Reply-To: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> References: <044.dc423e8f20f442ffcf7dfd150f68adfa@haskell.org> Message-ID: <059.5972d66e4423b83870925ab9b3e7c14f@haskell.org> #8900: Strictness analysis regression --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): Replying to [comment:24 simonmar]: > I was surprised by this, because I would expect HEAD and 7.6.3 to generate very similar code with respect to spilling before a call. #8905 is about an improvement we can make in the new code generator, that wasn't possible in the old codegen. My mistake. I've been reading too much Cmm lately. > they look identical to me modulo reordering and things falling into different stack slots. Maybe the problematic bit is somewhere else - could you point to it? I have no idea then. There's a lot of Cmm and diff tools don't work well because blocks have been reordered a lot between 7.6.3 and HEAD. Since the difference is so small I suggest we ignore it for now. I'm more interested in getting #8905 into a production-ready state. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 25 14:16:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Mar 2014 14:16:55 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar In-Reply-To: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> References: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> Message-ID: <060.eb65daa3abb027e368176d755acd16b5@haskell.org> #8848: Warning: Rule too complicated to desugar -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"41ba7ccb742278de0abf32cb7571c71b150997a3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="41ba7ccb742278de0abf32cb7571c71b150997a3" Improve the desugaring of RULE left-hand-sides (fixes Trac #8848) I've added detailed comments with Note [Decomposing the left-hand side of a RULE] The result is a noticeable improvement. Previously * we rejected a perfectly decent SPECIALISE (Trac #8848) * and for something like f :: (Eq a) => b -> a -> a {-# SPECIALISE f :: b -> [Int] -> [Int] #-} we ended up with RULE f ($fdEqList $dfEqInt) = f_spec whereas we wanted RULES forall (d:Eq [Int]). f d = f_spec }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 25 14:35:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Mar 2014 14:35:01 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar In-Reply-To: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> References: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> Message-ID: <060.ddc478ec56fcb3f3422f740e1b67e6b5@haskell.org> #8848: Warning: Rule too complicated to desugar -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"88d94524f46df7c99214cde7e2952aacdd3fb6cc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="88d94524f46df7c99214cde7e2952aacdd3fb6cc" Test Trac #8848 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 25 14:36:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Mar 2014 14:36:13 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar In-Reply-To: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> References: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> Message-ID: <060.57bdb55c08e8247d7f1adaef066b2962@haskell.org> #8848: Warning: Rule too complicated to desugar -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: simplCore/should_compile/T8848, T8848a | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => closed * testcase: => simplCore/should_compile/T8848, T8848a * resolution: => fixed Comment: Thank yuu for reporting this. It's led me to an altogether better treatment for the LHS of rules. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 25 15:10:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Mar 2014 15:10:31 -0000 Subject: [GHC] #8927: Multiple case match at once Message-ID: <046.b6a1dc69b4ff427961f031ca91cfb46c@haskell.org> #8927: Multiple case match at once -------------------------------------------+------------------------------- Reporter: vxanica | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.6.3 Keywords: case, multiple | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- In F# we can do {{{ #!div style="font-size: 120%" {{{#!haskell match x with | 1 | 2 | 3 -> "123" | 4 | 5 | 6 -> "456" }}} }}} It will be nice if we have an extension which allows us to do {{{ #!div style="font-size: 120%" {{{#!haskell case x of 1 | 2 | 3 -> "123" 4 | 5 | 6 -> "456" }}} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 25 15:22:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Mar 2014 15:22:24 -0000 Subject: [GHC] #8927: Multiple case match at once In-Reply-To: <046.b6a1dc69b4ff427961f031ca91cfb46c@haskell.org> References: <046.b6a1dc69b4ff427961f031ca91cfb46c@haskell.org> Message-ID: <061.344dc66ea0f929b158b0eed65c08437e@haskell.org> #8927: Multiple case match at once -------------------------------------+------------------------------------- Reporter: vxanica | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 (Parser) | Keywords: case, multiple Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by vxanica): * cc: vxanicauk@? (added) * version: 7.6.3 => 7.8.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 25 15:29:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Mar 2014 15:29:41 -0000 Subject: [GHC] #8927: Multiple case match at once In-Reply-To: <046.b6a1dc69b4ff427961f031ca91cfb46c@haskell.org> References: <046.b6a1dc69b4ff427961f031ca91cfb46c@haskell.org> Message-ID: <061.4ea7a29fe59d43b1a0feb6b504ea29ec@haskell.org> #8927: Multiple case match at once -------------------------------------+------------------------------------- Reporter: vxanica | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 (Parser) | Keywords: case, multiple Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Fuuzetsu): What happens in the case like {{{ #!div style="font-size: 120%" {{{#!haskell case x of Just y | Nothing -> y }}} }}} While I think it'd be nice to have, the utility seems limited to constructors without arguments. Would this work? {{{ #!div style="font-size: 120%" {{{#!haskell data Foo = A Int | B Int | C String case x of A y | B y = "AB" ++ show y C y -> y }}} }}} and would this work? {{{ #!div style="font-size: 120%" {{{#!haskell data Foo = A Int | B () | C Double case x of A y | B y | C y = show y }}} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 25 16:00:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Mar 2014 16:00:43 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar In-Reply-To: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> References: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> Message-ID: <060.aeb59f1254d8d54f765a48cd088f2bc2@haskell.org> #8848: Warning: Rule too complicated to desugar -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: simplCore/should_compile/T8848, T8848a | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by carter): Thank you! Glad I could accidentally help. Any chance this might land in 7.8? :) currently my options otherwise are either 1. unconditionally inline everything (with the associated costs in code complexity) 2. Or write my own hand unrolled routine that has some fast paths for small size inputs, that also gets unconditionally inlined -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 25 16:23:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Mar 2014 16:23:59 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar In-Reply-To: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> References: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> Message-ID: <060.09fadfbd2acc3b0a4b3e4848ae48a4ef@haskell.org> #8848: Warning: Rule too complicated to desugar -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: simplCore/should_compile/T8848, T8848a | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): No, it's too late for 7.8 I'm afraid. Possibly 7.8.2. Maybe you can try {{{ {-# RULE map2 = map2_spec #-} map2_spec :: (a->b->c)-> (Shape Z a )-> Shape Z b -> Shape Z c map2_spec = inline map2 }}} and so on for the other cases. (Untested.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 25 16:54:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Mar 2014 16:54:04 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar In-Reply-To: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> References: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> Message-ID: <060.9d01cccd5602e4c1a4cf8937f622e760@haskell.org> #8848: Warning: Rule too complicated to desugar -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: simplCore/should_compile/T8848, T8848a | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by carter): 7.8.2 would be fine Yeah, I'll be trying out some ideas like that rules soon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 25 17:37:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Mar 2014 17:37:41 -0000 Subject: [GHC] #8928: 64-bit statically linked binary consumes all memory while spinning on 'SIGVTALRM's Message-ID: <046.37d614ce33da563e3a3fd91811396fde@haskell.org> #8928: 64-bit statically linked binary consumes all memory while spinning on 'SIGVTALRM's ----------------------------------+---------------------------------- Reporter: cswarth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I actually have no idea if this is a haskell bug or not, but since the earlier reported symptoms are similar, and the "pandoc" program is compiled with GHC, I thought I would report it here as well. This situation sounds exactly like [https://ghc.haskell.org/trac/ghc/ticket/7344 this bug] reported 17 months ago. Symptoms are 'pandoc --version' hangs and consumes memory until the process eventually dies with an OOM error. This seems to only happen when LC_ALL is set in the environment, and only when running the statically linked pandoc. {{{ $ uname -a Linux server 3.5.0-43-generic #66~precise1-Ubuntu SMP Thu Oct 24 14:52:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $ wget https://s3.amazonaws.com/rstudio-buildtools/pandoc-1.12.3.zip $ unzip pandoc-1.12.3.zip $ file pandoc-1.12.3/linux/debian/x86_64/pandoc pandoc-1.12.3/linux/debian/x86_64/pandoc: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.15, BuildID[sha1]=0x9bc69f51b7c213cf58e9f8692f4b46f9f05fb723, not stripped $ LC_ALL=C strace -e trace=open,close pandoc-1.12.3/linux/debian/x86_64/pandoc --version open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/gconv/gconv-modules", O_RDONLY) = -1 ENOENT (No such file or directory) --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- ^C--- SIGINT (Interrupt) @ 0 (0) --- }}} Note this problem does not occur if I run an older dynamically linked pandoc under the same circumstances. {{{ $ /usr/bin/pandoc --version pandoc 1.9.1.1 Compiled with citeproc-hs 0.3.4, texmath 0.6.0.3, highlighting-kate 0.5.0.5. Syntax highlighting is supported for the following languages: Actionscript, Ada, Alert, Alert_indent, Apache, Asn1, Asp, Awk, Bash, Bibtex, Boo, C, Changelog, Clojure, Cmake, Coffeescript, Coldfusion, Commonlisp, Cpp, Cs, Css, D, Diff, Djangotemplate, Doxygen, Dtd, Eiffel, ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 25 20:37:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Mar 2014 20:37:36 -0000 Subject: [GHC] #8923: Add SmallArray# type In-Reply-To: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> References: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> Message-ID: <059.2a991523df18dfa4261ae73bbeeb384f@haskell.org> #8923: Add SmallArray# type -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): I now got a working implementation. **Both** runtime and allocations are down 8.8% on my unordered-containers insert benchmark, which is already very heavily optimized. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 25 23:57:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Mar 2014 23:57:24 -0000 Subject: [GHC] #8753: Import constructor but not the data type In-Reply-To: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> References: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> Message-ID: <066.f28f737364e3272aaf104bf4a0e5ebdd@haskell.org> #8753: Import constructor but not the data type -------------------------------------+------------------------------------ Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 simonpj): * cc: cactus (added) Comment: You are right that there is no good way to do this, and that the lack is unfortunate. It is, however, possible in GHC 7.8. You can say {{{ import A( pattern D ) }}} provided you use `LANGUAGE PatternSynonyms`. Here `D` is a data constructor, but that's just a degenerate pattern synonym. Similarly in hiding and export lists. Does that help? I see that this point does not (yet) show up in the user manual, and it should. Gergo, might you fix that? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 26 09:40:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Mar 2014 09:40:52 -0000 Subject: [GHC] #8927: Multiple case match at once In-Reply-To: <046.b6a1dc69b4ff427961f031ca91cfb46c@haskell.org> References: <046.b6a1dc69b4ff427961f031ca91cfb46c@haskell.org> Message-ID: <061.e13da1af3514053e8deda5c1d48bff70@haskell.org> #8927: Multiple case match at once -------------------------------------+------------------------------------- Reporter: vxanica | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 (Parser) | Keywords: case, multiple Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by hvr): Replying to [ticket:8927 vxanica]: > {{{#!haskell > case x of > 1 | 2 | 3 -> "123" > 4 | 5 | 6 -> "456" > }}} btw, this concrete syntax would collide with Haskell2010's [http://www.haskell.org/haskellwiki/Pattern_guard Pattern Guards] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 26 14:08:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Mar 2014 14:08:25 -0000 Subject: [GHC] #8910: cross compiling for x86_64 solaris2 In-Reply-To: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> References: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> Message-ID: <060.b19eaa5e43f4dfab580d5a5117ea4530@haskell.org> #8910: cross compiling for x86_64 solaris2 ----------------------------------+---------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by maeder): Obviously, I can create a stage1 cross-compiler showing {{{ ,("Build platform","i386-unknown-solaris2") ,("Host platform","i386-unknown-solaris2") ,("Target platform","x86_64-unknown-solaris2") }}} However, "inplace/bin/ghc-stage2 --info" shows {{{ ,("Build platform","i386-unknown-solaris2") ,("Host platform","x86_64-unknown-solaris2") ,("Target platform","x86_64-unknown-solaris2") }}} which looks wrong, since build and host should be equal. The problem is that the auto-detected build platform always remains i386 -unknown-solaris2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 26 14:42:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Mar 2014 14:42:23 -0000 Subject: [GHC] #8910: cross compiling for x86_64 solaris2 In-Reply-To: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> References: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> Message-ID: <060.0d714e120937529e13cfabd52591e636@haskell.org> #8910: cross compiling for x86_64 solaris2 ----------------------------------+---------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by kgardas): Have you built just stage1 and then configure another ghc tree with this ghc-stage1 passed to --with-ghc param? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 26 15:37:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Mar 2014 15:37:41 -0000 Subject: [GHC] #8910: cross compiling for x86_64 solaris2 In-Reply-To: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> References: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> Message-ID: <060.db35806f61409d0a16ec64671040107d@haskell.org> #8910: cross compiling for x86_64 solaris2 ----------------------------------+---------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by maeder): I'm just trying to use the stage1 cross compiler that I installed using "gmake install" (and adding properly named links) to compile another ghc tree. However, if my "gcc -m64" gcc-script is in the path ./configure shows the following, which cannot really work: {{{ checking build system type... x86_64-pc-solaris2.10 checking host system type... x86_64-pc-solaris2.10 checking target system type... x86_64-pc-solaris2.10 Build platform inferred as: i386-unknown-solaris2 Host platform inferred as: i386-unknown-solaris2 Target platform inferred as: i386-unknown-solaris2 GHC build : i386-unknown-solaris2 GHC host : i386-unknown-solaris2 GHC target : i386-unknown-solaris2 }}} x86_64-pc-solaris2.10 is canonicalized to i386-unknown-solaris2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 26 15:51:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Mar 2014 15:51:45 -0000 Subject: [GHC] #8910: cross compiling for x86_64 solaris2 In-Reply-To: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> References: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> Message-ID: <060.be76993138d000ea963e0f103492f0e6@haskell.org> #8910: cross compiling for x86_64 solaris2 ----------------------------------+---------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by maeder): Even if I add "--build=x86_64-pc-solaris2 --target=x86_64-pc-solaris2 --host=x86_64-pc-solaris2", configure complains: {{{ checking build system type... x86_64-pc-solaris2 checking host system type... x86_64-pc-solaris2 checking target system type... x86_64-pc-solaris2 GHC build : x86_64-unknown-solaris2 GHC host : x86_64-unknown-solaris2 GHC target : x86_64-unknown-solaris2 This GHC (/local/home/maeder/haskell/ghc-7.8-x64/bin/ghc) does not generate code for the build platform GHC target platform : i386-unknown-solaris2 Desired build platform : x86_64-unknown-solaris2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 26 17:20:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Mar 2014 17:20:03 -0000 Subject: [GHC] #8753: Import constructor but not the data type In-Reply-To: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> References: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> Message-ID: <066.171caf68ed39827d6aefa2df9b32c259@haskell.org> #8753: Import constructor but not the data type -------------------------------------+------------------------------------ Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by andreas.abel): That certainly addresses the issue. No need to for a separate syntax for constructors, if it works for patterns in general. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 26 18:12:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Mar 2014 18:12:59 -0000 Subject: [GHC] #8923: Add SmallArray# type In-Reply-To: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> References: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> Message-ID: <059.d72473527e8b54e805073003138d15c5@haskell.org> #8923: Add SmallArray# type -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 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 tibbe): * status: new => patch Comment: Ready for review: https://github.com/tibbe/ghc/commit/f92141b2b2dc209e570cdc6fd727bf3efde450fc The change is relatively large, partly because there's a lot of test code. Once the change is in, I will see if I can refactor the code to have more code sharing with `Array#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 26 18:34:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Mar 2014 18:34:47 -0000 Subject: [GHC] #8929: Deriving Generics broken Message-ID: <044.b3c356894e088206397c6c924ad3062a@haskell.org> #8929: Deriving Generics broken ----------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- I load the following code into ghci: == {-# LANGUAGE DeriveGeneric #-} import GHC.Generics import Data.Binary data Foo = Foo deriving (Show, Generic) instance Binary Foo == Then I execute: (decode . encode $ Foo) :: Foo In 7.6.3 (stage 2 booted 7.6.3), I get an error. In 7.6.3 (stage 2 booted 7.6.2), the desired result "Foo" is shown. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 26 19:28:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Mar 2014 19:28:40 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar In-Reply-To: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> References: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> Message-ID: <060.b895963a1055aba86f52b6d754f1f2b2@haskell.org> #8848: Warning: Rule too complicated to desugar -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.2 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: simplCore/should_compile/T8848, T8848a | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by carter): * milestone: => 7.8.2 Comment: setting milestone for 7.8.2 so its on the list when that roles around -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 26 19:39:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Mar 2014 19:39:18 -0000 Subject: [GHC] #8929: Deriving Generics broken In-Reply-To: <044.b3c356894e088206397c6c924ad3062a@haskell.org> References: <044.b3c356894e088206397c6c924ad3062a@haskell.org> Message-ID: <059.b63090780a02a2ee66216865fc38d859@haskell.org> #8929: Deriving Generics broken -------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by dreixel): What is the error message that you get? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 26 19:47:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Mar 2014 19:47:01 -0000 Subject: [GHC] #8929: Deriving Generics broken In-Reply-To: <044.b3c356894e088206397c6c924ad3062a@haskell.org> References: <044.b3c356894e088206397c6c924ad3062a@haskell.org> Message-ID: <059.2ec168a4a5351deeab1daa671a9ed368@haskell.org> #8929: Deriving Generics broken -------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by kosmikus): I cannot reproduce this (with binary-0.7.1.0). Additionally, it also seems to work with 7.8.1-rc2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 26 20:52:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Mar 2014 20:52:03 -0000 Subject: [GHC] #8929: Deriving Generics broken In-Reply-To: <044.b3c356894e088206397c6c924ad3062a@haskell.org> References: <044.b3c356894e088206397c6c924ad3062a@haskell.org> Message-ID: <059.ae63f0758335aea64d42127ab5b9e616@haskell.org> #8929: Deriving Generics broken -------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by guest): Replying to [comment:1 dreixel]: > What is the error message that you get? during the compilation, I get the WARNING: No explicit method or default declaration for `put' In the instance declaration for `Binary Foo' When running the (decode . encode $ Foo), I get the EXCEPTION: No instance nor default method for class operation Data.Binary.get -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 26 21:22:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Mar 2014 21:22:36 -0000 Subject: [GHC] #8930: GHC API: List of available Pragmas Message-ID: <042.11f7c772aaef0a98faa963bdf382d85a@haskell.org> #8930: GHC API: List of available Pragmas ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | 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: | ------------------------------------+------------------------------------- From https://github.com/kazu-yamamoto/ghc- mod/issues/103#issuecomment-14827257: It would be useful if the GHC API allowed us to query a list of supported pragmas. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 08:45:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 08:45:29 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.c96fa4de04367b5583d8c4042f0ecaf0@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by jberthold): Maybe repetition is not good, but let me suggest to clarify which part is responsible for which variant of nm output. Also, one could use the Maybe monad instead of nested case expressions. how about this one: {{{ parseNmLine xs0 = case words xs0 of -- "_derivedConstantMAX_Vanilla_REG C b 0" Mac OS X -- "derivedConstantMAX_Vanilla_REG C 0000000b 0000000b" GNU -- "_derivedConstantMAX_Vanilla_REG C 000000b" MinGW x0 : "C" : x2 : r -> mkMapping x0 x2 -- "derivedConstantMAX_Vanilla_REG D 1 b" Solaris x0 : _ : x2 : x3 : [] -> mkMapping x0 x3 other -> Nothing mkMapping x0 x2 = do name <- stripPrefix $ dropWhile (== '_') x0 size <- case readHex x2 of [(n,"")] -> return n _ -> fail "not hex" return (name, size) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 09:11:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 09:11:36 -0000 Subject: [GHC] #8929: Deriving Generics broken In-Reply-To: <044.b3c356894e088206397c6c924ad3062a@haskell.org> References: <044.b3c356894e088206397c6c924ad3062a@haskell.org> Message-ID: <059.f90076eb80b0a303b358beeadd427ee4@haskell.org> #8929: Deriving Generics broken -------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Old description: > I load the following code into ghci: > > == > {-# LANGUAGE DeriveGeneric #-} > > import GHC.Generics > import Data.Binary > > data Foo = Foo deriving (Show, Generic) > > instance Binary Foo > == > > Then I execute: > > (decode . encode $ Foo) :: Foo > > In 7.6.3 (stage 2 booted 7.6.3), I get an error. > > In 7.6.3 (stage 2 booted 7.6.2), the desired result "Foo" is shown. New description: I load the following code into ghci: {{{#!hs {-# LANGUAGE DeriveGeneric #-} import GHC.Generics import Data.Binary data Foo = Foo deriving (Show, Generic) instance Binary Foo }}} Then I execute: {{{#!hs (decode . encode $ Foo) :: Foo }}} In 7.6.3 (stage 2 booted 7.6.3), I get an error. In 7.6.3 (stage 2 booted 7.6.2), the desired result "Foo" is shown. -- Comment (by hvr): (fixed up Wiki markup) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 09:28:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 09:28:03 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.d48e7d278121940ba58c2e622efe4cf6@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): Yes, also not bad. The unused "r" in the first case should be a "_". The pattern "x0 : _ : x2 : x3 : []" should be "[x0, _, x2, x3]". Following stripPrefix the actual "prefix" is missing. The actual cases for "case ... of" should be (less indented) on separate lines in order to avoid re-intenting lines when changing (ie. names) in "size <- case readHex x2 of". Also after "do" a line break should follow (for the same reason as after "of") (If the do-notation based on the monad instance is really an improvement is a matter of taste.) The comments clutter the code too much (in my eyes, but that's again a matter of taste) One advantage over my code is, that "C" is matched by a pattern (rather than using the Eq instance). After this style discussion I suggest, that Karel should create an improved patch and Austin decides to apply it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 09:37:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 09:37:10 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.1fef2061734369561513be6fb23acf62@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by kgardas): Replying to [comment:30 jberthold]: > {{{ [...] > -- "derivedConstantMAX_Vanilla_REG D 1 b" Solaris > x0 : _ : x2 : x3 : [] -> mkMapping x0 x3 [...] > }}} IMHO there should be "D" used in the code, since otherwise I'm not sure this will work correctly on Solaris and not match anything else. {{{ x0 : 'D' : x2 : x3 : [] -> mkMapping x0 x3 }}} otherwise also nice! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 09:49:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 09:49:57 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.46b183be11279166105982dda03c62ae@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): No, checking if it is not a 'C' is enough and ensure by the first case. (Surely, one could apply stricter tests, but I think that's unnecessary as no error handling is done anyway.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 09:52:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 09:52:10 -0000 Subject: [GHC] #8931: The type defaulting in GHCi with Typeable Message-ID: <044.24193734a44f208446e00dfc5621ccaf@haskell.org> #8931: The type defaulting in GHCi with Typeable -------------------------------------+------------------------------------- Reporter: skata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Operating System: Unknown/Multiple Keywords: type defaulting, | Type of failure: GHC rejects Typeable | valid program Architecture: Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- The type defaulting in GHCi works in less cases with GHC 7.8.1-rc2 than with older versions, though there is no change in the related part of the documentation (i.e., "2.4.7 Type defaulting in GHCi"). {{{ skata at kata58:~$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228 skata at kata58:~$ ghci GHCi, version 7.8.0.20140228: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :m +Data.Typeable Prelude Data.Typeable> let {f :: Read a => (a->Bool) -> Char; f = undefined} Prelude Data.Typeable> f (\x -> (x == 3)) *** Exception: Prelude.undefined <== This is the expected result. Prelude Data.Typeable> let {f :: Typeable a => (a->Bool) -> Char; f = undefined} Prelude Data.Typeable> f (\x -> (x == 3)) <== Type defaulting does not work in this case. :6:1: No instance for (Typeable a0) arising from a use of ?f? The type variable ?a0? is ambiguous Note: there are several potential instances: instance [overlap ok] Typeable () -- Defined in ?Data.Typeable.Internal? instance [overlap ok] Typeable Bool -- Defined in ?Data.Typeable.Internal? instance [overlap ok] Typeable Char -- Defined in ?Data.Typeable.Internal? ...plus 14 others In the expression: f (\ x -> (x == 3)) In an equation for ?it?: it = f (\ x -> (x == 3)) :6:13: No instance for (Eq a0) arising from a use of ?==? The type variable ?a0? is ambiguous Relevant bindings include x :: a0 (bound at :6:5) Note: there are several potential instances: instance Eq a => Eq (GHC.Real.Ratio a) -- Defined in ?GHC.Real? instance Eq Integer -- Defined in ?integer-gmp:GHC.Integer.Type? instance Eq () -- Defined in ?GHC.Classes? ...plus 33 others In the expression: (x == 3) In the first argument of ?f?, namely ?(\ x -> (x == 3))? In the expression: f (\ x -> (x == 3)) :6:16: No instance for (Num a0) arising from the literal ?3? The type variable ?a0? is ambiguous Relevant bindings include x :: a0 (bound at :6:5) Note: there are several potential instances: instance Num Double -- Defined in ?GHC.Float? instance Num Float -- Defined in ?GHC.Float? instance Integral a => Num (GHC.Real.Ratio a) -- Defined in ?GHC.Real? ...plus 7 others In the second argument of ?(==)?, namely ?3? In the expression: (x == 3) In the first argument of ?f?, namely ?(\ x -> (x == 3))? }}} On the other hand, {{{ skata at kata58:~$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.1 skata at kata58:~$ ghci GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :m +Data.Typeable Prelude Data.Typeable> let {f :: Read a => (a->Bool) -> Char; f = undefined} Prelude Data.Typeable> f (\x -> (x == 3)) *** Exception: Prelude.undefined Prelude Data.Typeable> let {f :: Typeable a => (a->Bool) -> Char; f = undefined} Prelude Data.Typeable> f (\x -> (x == 3)) *** Exception: Prelude.undefined }}} I think the old behavior is compliant with the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 10:04:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 10:04:26 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.af40de005bcb6aac843d6b67165c130b@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by kgardas): No, it's not! Especially if we're doing all those exercises to make this piece of code better. The problem with {{{ x0 : _ : x2 : x3 : [] -> mkMapping x0 x3 }}} is that it matches {{{ tmp.c f 0 0 }}} line which is the last line in Solaris's nm -P tmp.o output. So you match Solaris case and pass it down to mkMapping where stripPrefix will produce Nothing and you ends with (Nothing, 0) pair being returned. IMHO not good. So if you'd like to make this piece of code nice, also please let's make it correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 10:26:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 10:26:55 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.88676ef050bcf1a9737e1fb5171d76a3@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): No, no pair is returned by simply Nothing that is ignored later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 10:36:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 10:36:47 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.aa54cb5a4a80f744f94c63f162f4578d@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by jstolarek): * owner: jstolarek => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 10:41:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 10:41:05 -0000 Subject: [GHC] #8932: Panic with TemplateHaskell and duplicate indentifiers Message-ID: <048.cd6ad88ea09e222679040103b1a3c25b@haskell.org> #8932: Panic with TemplateHaskell and duplicate indentifiers -----------------------------------+--------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.1-rc2 Haskell | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time crash Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- This code causes GHC panic under 7.8.1-RC2: {{{ {-# LANGUAGE TemplateHaskell #-} module TXXXX where $([d| foo :: a -> a foo x = x |]) foo :: a foo = undefined }}} {{{ [killy at xerxes : /dane/projekty/sandbox/haskell] ghc -fforce-recomp TXXXX.hs [1 of 1] Compiling TXXXX ( TXXXX.hs, TXXXX.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 containers-0.5.4.0 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. ghc: panic! (the 'impossible' happened) (GHC version 7.8.0.20140226 for x86_64-unknown-linux): lookupExactOcc foo_a2kL{v} [main:TXXXX.foo{v a2kL} defined at TXXXX.hs:11:1, main:TXXXX.foo{v a2kL} defined at TXXXX.hs:5:3] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 11:07:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 11:07:22 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.4b659ddd4487e2a9929ed0e02d6ac077@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by kgardas): Replying to [comment:35 maeder]: > No, no pair is returned by simply Nothing that is ignored later. Sorry, I don't understand. I still see that four members list is matched and mkMapping is invoked with x0 and x3 as its params. Isn't that true? So if I'm not mistaken then mkMapping is invoked for: {{{ tmp.c f 0 0 }}} which is IMHO not good. Or is it? Please correct me if I'm wrong. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 11:28:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 11:28:50 -0000 Subject: [GHC] #8930: GHC API: List of available Pragmas In-Reply-To: <042.11f7c772aaef0a98faa963bdf382d85a@haskell.org> References: <042.11f7c772aaef0a98faa963bdf382d85a@haskell.org> Message-ID: <057.408155b22aa3f1f9df788556adf88f56@haskell.org> #8930: GHC API: List of available Pragmas -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Afaics, this list would need to be maintained redundantly, as the current pragma identifiers are hardcoded in the parser grammar (see [[GhcFile(compiler/parser/Parser.y.pp)]] around line 254) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 12:01:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 12:01:53 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.857bdd6ba7af2b94399e844ca6a90f4f@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): Yes, mkMapping is invoked and returns Nothing, that is ignored by catMaybes in line 635. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 12:03:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 12:03:02 -0000 Subject: [GHC] #8933: process007: internal error: checkStackFrame: weird activation record found on stack Message-ID: <047.eb1d0af3a88bd3a6aaa02c5018d9d701@haskell.org> #8933: process007: internal error: checkStackFrame: weird activation record found on stack ------------------------------------+---------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: process007 Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------------- On an unregisterised compiler process007 segfaults in all WAYS. Here is a stack trace from a run with {{{+RTS -DS}}} on an x86_64 machine: {{{ Starting program: /home/trp/research/ghc- unreg/ghc-7.8/libraries/process/tests/process007 +RTS -DS [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". cap 0: initialised process007: internal error: checkStackFrame: weird activation record found on stack (0x7ffff69050b8 281051976). (GHC version 7.8.0.20140324 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Program received signal SIGABRT, Aborted. 0x00007ffff6a95849 in raise () from /lib64/libc.so.6 (gdb) where #0 0x00007ffff6a95849 in raise () from /lib64/libc.so.6 #1 0x00007ffff6a96cd8 in abort () from /lib64/libc.so.6 #2 0x00000000008172af in rtsFatalInternalErrorFn ( s=0x894080 "checkStackFrame: weird activation record found on stack (%p %d).", ap=0x7fffffffd968) at rts/RtsMessages.c:170 #3 0x0000000000816ee7 in barf ( s=0x894080 "checkStackFrame: weird activation record found on stack (%p %d).") at rts/RtsMessages.c:42 #4 0x00000000008355e2 in checkStackFrame (c=0x7ffff69050b8) at rts/sm/Sanity.c:165 #5 0x000000000083560a in checkStackChunk (sp=0x7ffff69050b8, stack_end=0x7ffff6905390) at rts/sm/Sanity.c:177 #6 0x0000000000836100 in checkSTACK (stack=0x7ffff6905000) at rts/sm/Sanity.c:497 #7 0x0000000000836254 in checkTSO (tso=0x7ffff6905390) at rts/sm/Sanity.c:535 #8 0x000000000082625a in threadStackOverflow (cap=0xd79740 , tso=0x7ffff6905390) at rts/Threads.c:500 #9 0x000000000082226a in schedule ( initialCapability=0xd79740 , task=0xd9a4e0) at rts/Schedule.c:528 #10 0x00000000008236b3 in scheduleWaitThread (tso=0x7ffff6905390, ret=0x0, pcap=0x7fffffffdcc0) at rts/Schedule.c:2346 #11 0x0000000000824d63 in rts_evalLazyIO (cap=0x7fffffffdcc0, p=0xbd4da0 , ret=0x0) at rts/RtsAPI.c:500 #12 0x00000000008272de in real_main () at rts/RtsMain.c:63 #13 0x00000000008273d1 in hs_main (argc=3, argv=0x7fffffffde48, main_closure=0xbd4da0 , rts_config=...) at rts/RtsMain.c:114 #14 0x000000000040849f in main () }}} Running without the RTS flags: {{{ Program received signal SIGSEGV, Segmentation fault. 0x00000000008307ed in StgRun (f=0xd79758b8e5894855, basereg=0xd79758 ) at rts/StgCRun.c:81 81 f = (StgFunPtr) (f)(); (gdb) where #0 0x00000000008307ed in StgRun (f=0xd79758b8e5894855, basereg=0xd79758 ) at rts/StgCRun.c:81 #1 0x0000000000822022 in schedule ( initialCapability=0xd79740 , task=0xd9a470) at rts/Schedule.c:463 #2 0x00000000008236b3 in scheduleWaitThread (tso=0x7ffff6905390, ret=0x0, pcap=0x7fffffffdcd0) at rts/Schedule.c:2346 #3 0x0000000000824d63 in rts_evalLazyIO (cap=0x7fffffffdcd0, p=0xbd4da0 , ret=0x0) at rts/RtsAPI.c:500 #4 0x00000000008272de in real_main () at rts/RtsMain.c:63 #5 0x00000000008273d1 in hs_main (argc=1, argv=0x7fffffffde58, main_closure=0xbd4da0 , rts_config=...) at rts/RtsMain.c:114 #6 0x000000000040849f in main () }}} The value of f in StgRun looks strange the first three bytes are the same as basereg {{{0xd79758}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 12:12:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 12:12:56 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.73b9d63af0a53c5eef82db82b669cd03@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): However, matching for the 'D' is no bad idea, as it yields Nothing earlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 12:31:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 12:31:15 -0000 Subject: [GHC] #989: Windows "native" port In-Reply-To: <047.96e16f269cc7176052a090de33c91146@haskell.org> References: <047.96e16f269cc7176052a090de33c91146@haskell.org> Message-ID: <062.2061985b79bf84b266f07636df4898d8@haskell.org> #989: Windows "native" port ---------------------------------+---------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Difficult (2-5 days) Test Case: N/A | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------------- Comment (by schyler): Just thought I would make a note that this is kind of blocking visual studio support. It's not easy to make a uniform visual studio extension for Haskell right now because it would be expected that it's able to link with other files in the same solution (.c, .cpp etc) however that's not the case since GHC uses gcc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 12:33:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 12:33:57 -0000 Subject: [GHC] #8927: Multiple case match at once In-Reply-To: <046.b6a1dc69b4ff427961f031ca91cfb46c@haskell.org> References: <046.b6a1dc69b4ff427961f031ca91cfb46c@haskell.org> Message-ID: <061.189eb8547c699bff258ca1204be3b1ef@haskell.org> #8927: Multiple case match at once -------------------------------------+------------------------------------- Reporter: vxanica | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 (Parser) | Keywords: case, multiple Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by schyler): Why not swap out | with , ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 13:05:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 13:05:29 -0000 Subject: [GHC] #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) In-Reply-To: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> References: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> Message-ID: <060.dea51df873ffe3aee5515fcbeb9e28e2@haskell.org> #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #4259 --------------------------------------------+------------------------------ Comment (by goldfire): After being prodded via email to consider this issue further, I've made a tiny bit of progress, but nowhere near an actual solution. It turns out that the closed type family case and the open type family case can indeed be considered separately. Why? Because the compatibility check can usefully be turned off in the closed type family case, but not in the open one. Turning off the compatibility check for closed families reduces the number of reductions possible, but doesn't threaten soundness. On the other hand, turning off the compatibility check for unordered, open families destroys soundness. So, I thought about this: during the compatibility check, I normalized both substituted RHSs, but, during the normalization, I ignored compatibility. This seems like a nice, conservative check, but less conservative than the current one, requiring coincidence. It turned out that implementing the check above was non-trivial (it required delicate ordering among family instances), so I did the following (even better) thing instead (this is available in the `wip/recurs-compat` branch): - The existing compatibility check was left unchanged. - During type family simplification, an extra check was added, in parallel with the apartness check. (This follows more closely what is written up in [http://www.cis.upenn.edu/~eir/papers/2014/axioms/axioms-extended.pdf the paper].) Say the current, matching equation is `e` and the previous one under consideration is `d`. Suppose the target is `t`. - We unify `d` with `t`, possibly producing unifying substitution `ds`. (If unification fails, the new check fails, and no reduction happens. But, note that if `d` and `t` are apart, then the apartness check succeeds, allowing reduction.) - Let `es` be the substitution (sure to exist) that witnesses that `e` matches `t`. - Now, we check if `normalize(ds(d_rhs)) = normalize(ds(es(e_rhs)))`. If this check succeeds, we allow reduction by equation `e`. - The `normalize` function here is special: if it is reducing a closed type family and needs to do a compatibility check, that check ''does not normalize''. Without this restriction, we would often loop, as demonstrated below. There are a few natural questions at this point: - '''Is this type safe?''' I haven't proved anything. But, I believe that it is type safe as long as all type families terminate. Why? Because the type safety proof (appearing in the paper) doesn't seem to be disturbed by this change. That proof requires only ''local'' confluence, meaning that it can take an arbitrary number of steps to recombine two terms after they have diverged. However, I believe that this is '''not''' type-safe in the presence of non-terminating type families. Why? Because the proof in the non-terminating case requires a ''local diamond'' property, which requires single-step recombining after divergence. The normalization step explicitly throws that out. I don't know of a way to repair the proof, so I'm led to think that the property is indeed broken. I have no counter- example, though. - '''Does it work in practice?''' A bit. Take the `PSum` family in comment:3. In GHC 7.8, the third equation won't fire because it conflicts with the second. With the extra check as described here, the third equation can indeed fire. But, the fourth can't, because the compatibility check against the third requires normalization internally to work. I don't see an easy solution to that problem. - '''What about axioms in Core?''' My work didn't touch axioms. So, `-dcore-lint` would fail in my branch if the new checks were used. A real solution here would require changes to Core, essentially to record exactly how two equations are compatible. Given that the proof of compatibility (with normalization) might be arbitrarily large, it would seem to require some new form that is an explicit witness of compatibility. Of course, we could just bake the normalization step into the Core type-checking algorithm, but normalization is potentially non-terminating, so doing so breaks the tenet of "type-checking Core is simple and decidable". - '''Where to go from here?''' I believe that the core problem is that we're currently finding some sort of least fixed point of compatibility, where we really want the greatest fixed point. That is, if we assume that the third and fourth equations of `PSum` are compatible, then we can prove they're compatible. This recursive proof would be productive (that is, there would be a new `'S` constructor), so I think the idea isn't entirely silly. I haven't worked out any details, though. - '''What's the looping example?''' Check this out: {{{ type family F a where F [a] = F a F b = b }}} This is a simple, terminating type family. Yet, if we try to simplify `F c` (which should be stuck), a fully recursive compatibility check would loop, as the check would, in turn, need to simplify `F a`, which is isomorphic to what we started with. Given the complications here (especially the thought of how to update Core), I'm tabling this for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 13:49:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 13:49:55 -0000 Subject: [GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) In-Reply-To: <045.6e47836af0f0e307f79949999a773a19@haskell.org> References: <045.6e47836af0f0e307f79949999a773a19@haskell.org> Message-ID: <060.b1c887df983028755561c95a37dadb2b@haskell.org> #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ---------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by Simon Marlow ): In [changeset:"6189c7674fc5c735db1a446d0b222369a3767369/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6189c7674fc5c735db1a446d0b222369a3767369" --with-gcc overrides CC_STAGE0 when not cross-compiling (#8498) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 13:49:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 13:49:55 -0000 Subject: [GHC] #6017: Reading ./.ghci files raises security issues In-Reply-To: <046.4c80215545a1055cdc72cec5a74c2a85@haskell.org> References: <046.4c80215545a1055cdc72cec5a74c2a85@haskell.org> Message-ID: <061.4f99a517df9753a486788de9c8e6e7e4@haskell.org> #6017: Reading ./.ghci files raises security issues -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Marlow ): In [changeset:"a6f2c852d49313fa8acea2deb3741ab86c6ef995/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a6f2c852d49313fa8acea2deb3741ab86c6ef995" Don't perform permission checks for scripts named with -ghci-script (#6017) The user explicitly requested this script on the command-line, so it's unnecessary to require that the script is also owned by the user. Also, it is currently impossible to make a GHCi wrapper that invokes a custom script without first making a copy of the script to circumvent the permissions check, which seems wrong. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 13:54:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 13:54:06 -0000 Subject: [GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) In-Reply-To: <045.6e47836af0f0e307f79949999a773a19@haskell.org> References: <045.6e47836af0f0e307f79949999a773a19@haskell.org> Message-ID: <060.6dc310ee1e79a9888b88d3f6c1f92054@haskell.org> #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ---------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by simonmar): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 17:26:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 17:26:45 -0000 Subject: [GHC] #6056: INLINABLE pragma prevents worker-wrapper to happen. In-Reply-To: <044.48485356203668916cbd990ce18921d0@haskell.org> References: <044.48485356203668916cbd990ce18921d0@haskell.org> Message-ID: <059.54e1487d17166e230e0d28a6bde44dae@haskell.org> #6056: INLINABLE pragma prevents worker-wrapper to happen. --------------------------------------------+------------------------------ Reporter: milan | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by carter): I tested this just now on current HEAD (well, built 2 weeks ago) here are the three versions {{{ module Test where smallerAndRest :: Ord a => a -> [a] -> (Maybe a, [a]) smallerAndRest x [] = (Nothing, []) smallerAndRest x (y:ys) | y < x = (Just y, ys) | otherwise = smallerAndRest x ys {-# INLINABLE smallerAndRest #-} smallerAndRestGood :: Ord a => a -> [a] -> (Maybe a, [a]) smallerAndRestGood x ys = go x ys where go x [] = (Nothing, []) go x (y:ys) | y < x = (Just y, ys) | otherwise = go x ys {-# INLINABLE smallerAndRestGood #-} smallerAndRestGoodNotInlined :: Ord a => a -> [a] -> (Maybe a, [a]) smallerAndRestGoodNotInlined x ys = go x ys where go x [] = (Nothing, []) go x (y:ys) | y < x = (Just y, ys) | otherwise = go x ys }}} i used {{{ ghc -O1 -ddump-prep test.hs -fforce-recomp }}} with the following results {{{ ==================== CorePrep ==================== Result size of CorePrep = {terms: 123, types: 192, coercions: 0} lvl_r10X :: forall a_aTr. (Data.Maybe.Maybe a_aTr, [a_aTr]) [GblId, Caf=NoCafRefs, Str=DmdType m, Unf=OtherCon []] lvl_r10X = \ (@ a_aTr) -> (Data.Maybe.Nothing @ a_aTr, GHC.Types.[] @ a_aTr) Rec { Test.smallerAndRest [InlPrag=INLINABLE[ALWAYS], Occ=LoopBreaker] :: forall a_aDK. GHC.Classes.Ord a_aDK => a_aDK -> [a_aDK] -> (Data.Maybe.Maybe a_aDK, [a_aDK]) [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType m, Unf=OtherCon []] Test.smallerAndRest = \ (@ a_aTr) ($dOrd_s17b :: GHC.Classes.Ord a_aTr) (x_s17c :: a_aTr) (ds_s17d [Occ=Once!] :: [a_aTr]) -> case ds_s17d of _ [Occ=Dead] { [] -> lvl_r10X @ a_aTr; : y_s17f ys_s17g [Occ=Once*] -> case GHC.Classes.< @ a_aTr $dOrd_s17b y_s17f x_s17c of _ [Occ=Dead] { GHC.Types.False -> Test.smallerAndRest @ a_aTr $dOrd_s17b x_s17c ys_s17g; GHC.Types.True -> let { sat_s17i [Occ=Once] :: Data.Maybe.Maybe a_aTr [LclId, Str=DmdType] sat_s17i = Data.Maybe.Just @ a_aTr y_s17f } in (sat_s17i, ys_s17g) } } end Rec } Test.smallerAndRestGood [InlPrag=INLINABLE[ALWAYS]] :: forall a_aDJ. GHC.Classes.Ord a_aDJ => a_aDJ -> [a_aDJ] -> (Data.Maybe.Maybe a_aDJ, [a_aDJ]) [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType m, Unf=OtherCon []] Test.smallerAndRestGood = \ (@ a_aTb) ($dOrd_s17j :: GHC.Classes.Ord a_aTb) (x_s17k [Occ=Once] :: a_aTb) (ys_s17l [Occ=Once] :: [a_aTb]) -> let { lvl1_s17m [Occ=OnceL!] :: a_aTb -> a_aTb -> GHC.Types.Bool [LclId, Str=DmdType] lvl1_s17m = GHC.Classes.< @ a_aTb $dOrd_s17j } in letrec { $wgo_s17n [Occ=LoopBreaker] :: a_aTb -> [a_aTb] -> (# Data.Maybe.Maybe a_aTb, [a_aTb] #) [LclId, Arity=2, Str=DmdType , Unf=OtherCon []] $wgo_s17n = \ (w_s17o :: a_aTb) (w1_s17p [Occ=Once!] :: [a_aTb]) -> case w1_s17p of _ [Occ=Dead] { [] -> (# Data.Maybe.Nothing @ a_aTb, GHC.Types.[] @ a_aTb #); : y_s17r ys1_s17s [Occ=Once*] -> case lvl1_s17m y_s17r w_s17o of _ [Occ=Dead] { GHC.Types.False -> $wgo_s17n w_s17o ys1_s17s; GHC.Types.True -> let { sat_s17u [Occ=Once] :: Data.Maybe.Maybe a_aTb [LclId, Str=DmdType] sat_s17u = Data.Maybe.Just @ a_aTb y_s17r } in (# sat_s17u, ys1_s17s #) } }; } in case $wgo_s17n x_s17k ys_s17l of _ [Occ=Dead] { (# ww1_s17w [Occ=Once], ww2_s17x [Occ=Once] #) -> (ww1_s17w, ww2_s17x) } Test.$wsmallerAndRestGoodNotInlined :: forall a_aql. GHC.Classes.Ord a_aql => a_aql -> [a_aql] -> (# Data.Maybe.Maybe a_aql, [a_aql] #) [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType , Unf=OtherCon []] Test.$wsmallerAndRestGoodNotInlined = \ (@ a_aql) (w_s17y :: GHC.Classes.Ord a_aql) (w1_s17z [Occ=Once] :: a_aql) (w2_s17A [Occ=Once] :: [a_aql]) -> let { lvl1_s17B [Occ=OnceL!] :: a_aql -> a_aql -> GHC.Types.Bool [LclId, Str=DmdType] lvl1_s17B = GHC.Classes.< @ a_aql w_s17y } in letrec { $wgo_s17C [Occ=LoopBreaker] :: a_aql -> [a_aql] -> (# Data.Maybe.Maybe a_aql, [a_aql] #) [LclId, Arity=2, Str=DmdType , Unf=OtherCon []] $wgo_s17C = \ (w3_s17D :: a_aql) (w4_s17E [Occ=Once!] :: [a_aql]) -> case w4_s17E of _ [Occ=Dead] { [] -> (# Data.Maybe.Nothing @ a_aql, GHC.Types.[] @ a_aql #); : y_s17G ys_s17H [Occ=Once*] -> case lvl1_s17B y_s17G w3_s17D of _ [Occ=Dead] { GHC.Types.False -> $wgo_s17C w3_s17D ys_s17H; GHC.Types.True -> let { sat_s17J [Occ=Once] :: Data.Maybe.Maybe a_aql [LclId, Str=DmdType] sat_s17J = Data.Maybe.Just @ a_aql y_s17G } in (# sat_s17J, ys_s17H #) } }; } in $wgo_s17C w1_s17z w2_s17A Test.smallerAndRestGoodNotInlined [InlPrag=INLINE[0]] :: forall a_aql. GHC.Classes.Ord a_aql => a_aql -> [a_aql] -> (Data.Maybe.Maybe a_aql, [a_aql]) [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType m, Unf=OtherCon []] Test.smallerAndRestGoodNotInlined = \ (@ a_aql) (w_s17K [Occ=Once] :: GHC.Classes.Ord a_aql) (w1_s17L [Occ=Once] :: a_aql) (w2_s17M [Occ=Once] :: [a_aql]) -> case Test.$wsmallerAndRestGoodNotInlined @ a_aql w_s17K w1_s17L w2_s17M of _ [Occ=Dead] { (# ww1_s17O [Occ=Once], ww2_s17P [Occ=Once] #) -> (ww1_s17O, ww2_s17P) } }}} this seems to hint that doing worker wrapper by hand works, whether or not you marked it INLINEABLE. (i don't know enough about this topic to judge if that means its resolved or still a problem mind you) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 20:05:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 20:05:03 -0000 Subject: [GHC] #8933: process007: internal error: checkStackFrame: weird activation record found on stack In-Reply-To: <047.eb1d0af3a88bd3a6aaa02c5018d9d701@haskell.org> References: <047.eb1d0af3a88bd3a6aaa02c5018d9d701@haskell.org> Message-ID: <062.a2efe0f12bd10ea0365ed826f65b3b92@haskell.org> #8933: process007: internal error: checkStackFrame: weird activation record found on stack ----------------------------------+------------------------------------ Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: process007 | Blocked By: Blocking: | Related Tickets: #8819 ----------------------------------+------------------------------------ Changes (by trommler): * related: => #8819 Comment: Using the RC2 bindist from haskell.org I confirmed the test also segfaults on powerpc64 but only in WAYS normal,hpc,threaded1,dyn,optllvm I did not observe the strange pattern in the parameters to StgRun that I saw on x86_64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 20:59:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 20:59:57 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.2bd37e97da5a5e7cadd0e6681966c2b8@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"c4eeacdfdf4578eb6e75bbf2e067bfe70ec94ab0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c4eeacdfdf4578eb6e75bbf2e067bfe70ec94ab0" Use the correct callClobberedRegs on Windows/x64 (#8834) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 27 21:01:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Mar 2014 21:01:45 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.1b97bf7b5e1b6276ee9e265d32090978@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by thoughtpolice): Simon's patch works on x86_64 windows, with or without SPJ's temporary workaround committed. Cabal works properly. The testsuite looks quite clean modulo some perf numbers. Looks good! So I think technically this bug is fixed. But there's still an alleged 32bit error somewhere that Ganesh had, and Simon also had. I've had reports of Windows 7 being problematic in particular, so I'm looking to reproduce it right now with my build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 00:31:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 00:31:18 -0000 Subject: [GHC] #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test In-Reply-To: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> References: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> Message-ID: <063.98e3ab2237b3c709b3ccf5e9f5a90918@haskell.org> #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Compile-time | Difficulty: Easy (less than 1 crash | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by AlainODea): This line needs to be removed: https://github.com/ghc/ghc/blob/master/compiler/main/DynFlags.hs#L1216 It will break -profthreaded on all Solaris and Illumos OSes released since 2006. It leads to a paradox where gcc is handed -r (relocatable) and -lrt (link librt) which combined requires librt.a which doesn't and won't ever exist on any Solaris or Illumos system. I'll provide a patch once I've done some more testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 01:49:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 01:49:28 -0000 Subject: [GHC] #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test In-Reply-To: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> References: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> Message-ID: <063.858bac0a93f047cb10ebadf164d1a448@haskell.org> #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Compile-time | Difficulty: Easy (less than 1 crash | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by AlainODea): With the attached IllumosSolarisLinkerOptions.patch the topHandler02 tests all pass on SmartOS modulo the defect in the test framework that miscalculates the exit code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 05:12:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 05:12:28 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.b0702fe17cf45989c8cdeff665868db9@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: high | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): figured out what i was missing (thanks @archblob on irc for helping!), theres another configure.ac, distrib/configure.ac.in thats used for configure at install time! http://github.com/cartazio/ghc/tree/cpp_silly-contrib-configure-in is the current patch set with that fix, will clean it up a bit, and it probably needs some refactoring and such. seems to validate (running test suite now, but no longer failing on the test install xhmtl stuff, will do a full clean validate tomorrow evening) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 06:28:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 06:28:27 -0000 Subject: [GHC] #8928: 64-bit statically linked binary consumes all memory while spinning on 'SIGVTALRM's In-Reply-To: <046.37d614ce33da563e3a3fd91811396fde@haskell.org> References: <046.37d614ce33da563e3a3fd91811396fde@haskell.org> Message-ID: <061.8d4ab00297b5f6cabf2584a3bf4e7eab@haskell.org> #8928: 64-bit statically linked binary consumes all memory while spinning on 'SIGVTALRM's ----------------------------------+---------------------------------- Reporter: cswarth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by cswarth): This bug is almost certainly the same as this one: https://ghc.haskell.org/trac/ghc/ticket/7695 Hang when locale-archive and gconv-modules are not there -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 07:02:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 07:02:21 -0000 Subject: [GHC] #8928: 64-bit statically linked binary consumes all memory while spinning on 'SIGVTALRM's In-Reply-To: <046.37d614ce33da563e3a3fd91811396fde@haskell.org> References: <046.37d614ce33da563e3a3fd91811396fde@haskell.org> Message-ID: <061.e7d36dbc358b5c95f8cb4c9202b11f11@haskell.org> #8928: 64-bit statically linked binary consumes all memory while spinning on 'SIGVTALRM's -----------------------------------+---------------------------------- Reporter: cswarth | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 7695,7344 -----------------------------------+---------------------------------- Changes (by cswarth): * cc: simonmar (added) * owner: => simonmar * component: Compiler => Runtime System * related: => 7695,7344 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 09:15:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 09:15:09 -0000 Subject: [GHC] #8899: StdGen does not generate 0 In-Reply-To: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> References: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> Message-ID: <065.e2177872c38fda8fe24cf279df0399f6@haskell.org> #8899: StdGen does not generate 0 -------------------------------------+------------------------------------ Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * cc: rrnewton (added) Comment: I've enabled auto-CC'ing rrnewton for the `random` component, so he will get spammed automatically in future :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 09:21:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 09:21:12 -0000 Subject: [GHC] #7644: Hackage docs for base library contain broken links In-Reply-To: <048.2cecb456976c34b85b0536b320a18c3d@haskell.org> References: <048.2cecb456976c34b85b0536b320a18c3d@haskell.org> Message-ID: <063.b2a12fc69dcf6bde090738e323c37208@haskell.org> #7644: Hackage docs for base library contain broken links -------------------------------------+------------------------------------ Reporter: JulesBean | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.6.1 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): * owner: => hvr Comment: I'll pay attention to this when generating & uploading the docs to Hackage for [hackage:base] et al. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 12:26:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 12:26:21 -0000 Subject: [GHC] #8934: Advice To Help You Lose Weight ORIGINAL GARCINIA CAMBOGIA Message-ID: <047.14eb32bb8968977882668d84f02d401d@haskell.org> #8934: Advice To Help You Lose Weight ORIGINAL GARCINIA CAMBOGIA ------------------------------------+------------------------------------- Reporter: governer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | 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: | ------------------------------------+------------------------------------- As slim and skinny became the opening faith during this reproduction, unit reduction product has gained rank quality. The marketplace has been booming of these sorts of product. To exact some, these conservative valuate tea, slimming irregular, slimming pills, slimming belts, butterflies and lots of others. It is proliferated to a large difference that it is usually troublesome to request unconnected that among the different angulate measures rattling hearty and impressive. A word on a come of the fluid same tea and pills are tackled on this book to assistance yo [http://originalgarciniacambogiaresults.com/ ORIGINAL GARCINIA CAMBOGIA] u opt for that to use. Turn 24 Pro There conservative express numerous articles that assure tea as a acceptable slimming broker. Fit, there\'s any emancipationist to that still tea solitary cannot fulfil. Erst you eat in repast or alimentation second a day, you\'ll be fit to really retrogress cardinal to eighty calories on a daily cornerstone. This can be done thanks to the method of thermogenesis, a method of hotness production in organisms equivalent humans. With this, your metabolism can amount siamese to still exertion module increase our metastasis. With inflated metabolism, you\'ll be willing to contract the content that you rightful decrease a quicker peak of a discount of phoebe century to one grand calories on a daily foundation so as to advise that one to 2 blow weight exit. Tea cannot full vibration that. If that is the person then you bed got to eat the peak days as tercet month on a daily part. Thence, tea gift solely use as an Link in Nursing help. Fasting and workout conservativist amount plant more unimaginative than but uptake small 24 pro. Slimm 24 Pro Working Slimm 24 Pro fluid guarantees to mend out its personalty in a real victimize assets of your dimension. Siamese to the different consume, slimming powder should be punctually formal by a pupil. They're honest value reasons behindhand this. For one, slimming set number step ideally formal if and as extended as diet and apply tract instrument well-tried to be useless. Other instance, pills entails risks and complications. Connatural to the separate chemical devoured value accountable when making a selection what to gazump up and what ought to be excreted within the embody. Since these tablets or capsules aren\'t just confiscate on one part solely object for a become of your term (sometimes modify dual doses a day), it carries the danger of morbidity. Formerly our embody is overfull of toxins, it damages our great meat specially the liver and kidneys. These 2 parcel assess unexpendable that is why we change to tell superior reparation of them. http://originalgarciniacambogiaresults.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 14:15:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 14:15:18 -0000 Subject: [GHC] #8910: cross compiling for x86_64 solaris2 In-Reply-To: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> References: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> Message-ID: <060.5c789f2848bab038d446ac453f52a373@haskell.org> #8910: cross compiling for x86_64 solaris2 ----------------------------------+---------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by maeder): Running the testsuite with the stage1 cross-compiler fails directly with: {{{ mk/boilerplate.mk:127: *** Cannot find hp2ps ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 14:26:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 14:26:01 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi Message-ID: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> #8935: Obscure linker bug leads to crash in GHCi ------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Rocket Science | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I have a build of GHC (with `DYNAMIC_GHC_PROGRAMS=NO`) that exhibits the following crash: {{{ $ ghc -e 'System.Environment.getEnvironment' }}} I tracked it down, eventually, to a bad reference to the symbol `environ` from `__hscore_environ` in `libraries/base/includes/HsBase.h`. Somehow, `environ` had got linked to the wrong address. Lots more investigation lead me to discover this: `internal_dlsym()` in `Linker.c` tries to look up a symbol in all the different shared libraries we have loaded so far, one by one. (see be497c202b790999c3fd0ddc4a4176b8cf6acf7e). Unfortunately, this seems to break things in my case. Here's a simple test program that works on Ubuntu 12.04: {{{ #include #include char *so = "/usr/lib/x86_64-linux-gnu/libgmp.so"; char *so2 = "/usr/lib/x86_64-linux-gnu/libpthread.so"; extern char**environ; int main(int argc, char *argv[]) { void *deflt, *hdl; deflt = dlopen(NULL, RTLD_LAZY | RTLD_GLOBAL); printf("environ = %p\n", &environ); printf("dlsym(deflt, \"environ\") = %p\n", dlsym(deflt,"environ")); hdl = dlopen(so, RTLD_LAZY); printf("dlsym(\"libgmp\", \"environ\") = %p\n", dlsym(hdl,"environ")); hdl = dlopen(so2, RTLD_LAZY); printf("dlsym(\"libpthread\", \"environ\") = %p\n", dlsym(hdl,"environ")); } }}} And the output: {{{ environ = 0x601040 dlsym(deflt, "environ") = 0x601040 dlsym("libgmp", "environ") = 0x2aaaab290568 dlsym("libpthread", "environ") = 0x601040 }}} Note that the value we get from looking up `environ` in `libgmp` is different to the others. The correct value is `0x601040`. gdb thinks that `0x2aaaab290568` is also `environ`: {{{ (gdb) p4 0x2aaaab290568 0x2aaaab290580 : 0x0 0x2aaaab290578: 0x0 0x2aaaab290570 : 0x0 0x2aaaab290568 : 0x0 }}} but note that it contains zero. The real one is: {{{ (gdb) p4 0x601040 0x601058: 0x0 0x601050 : 0x0 0x601048 : 0x0 0x601040 : 0x7fffffffe268 }}} In GHC we're loading `libgmp` when we load the `integer-gmp` package, and this causes future references to `environ` to go wrong. I've locally fixed this by changing `internal_dlsym` to `dlsym`, but since there was a reason to make this change in the first place I haven't pushed it to master. Suggestions welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 14:26:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 14:26:27 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.9f7e142064d4e13d4941e07e257f07dc@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Rocket Science Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * version: 7.6.3 => 7.8.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 15:25:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 15:25:09 -0000 Subject: [GHC] #8874: Warning: Couldn't figure out linker information! In-Reply-To: <046.d67a2973b6290e10568e89b029230c9a@haskell.org> References: <046.d67a2973b6290e10568e89b029230c9a@haskell.org> Message-ID: <061.528d380cbd4ecfa56eaf41944442e89d@haskell.org> #8874: Warning: Couldn't figure out linker information! -------------------------------------------------+------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | x86_64 (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: 8825 -------------------------------------------------+------------------------- Changes (by maeder): * cc: Christian.Maeder@? (added) * os: Linux => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 17:46:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 17:46:16 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.825c1fecde5ea9946dd945428eecc3aa@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+------------------------------ Reporter: facundoq | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+------------------------------ Comment (by facundoq): I'm using Windows 7 32 bits; I don't have the time/experience to build ghc with patches, but can test binary distributions to see if the problem disappeared. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 18:01:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 18:01:07 -0000 Subject: [GHC] #8936: Irrefutable pattern failed in ghc 7.4.1 Message-ID: <048.f1b3e4aafeb6db4f191a0edc00f8ccbc@haskell.org> #8936: Irrefutable pattern failed in ghc 7.4.1 ----------------------------------+--------------------------------- Reporter: gahuber95 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- Thanks for your attention! Gary (newbie) ########################################## class Show a => Show_Listable a where show_list :: [a] -> IO() instance Show_Listable a -> Show a where show_list lst = do print "gen list"; print lst lst :: Int -> [Int] lst i = [1,2,3] main = do show_list (lst 1) ###################################################### Output: $ ghc bull.hs -o bull [1 of 1] Compiling Main ( bull.hs, bull.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for x86_64-unknown-linux): compiler/rename/RnSource.lhs:429:14-81: Irrefutable pattern failed for pattern Data.Maybe.Just (inst_tyvars, _, SrcLoc.L _ cls, _) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 18:15:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 18:15:45 -0000 Subject: [GHC] #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test In-Reply-To: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> References: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> Message-ID: <063.2a678e4b11f2348168e860af4e84e2ed@haskell.org> #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Compile-time | Difficulty: Easy (less than 1 crash | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by AlainODea): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 18:15:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 18:15:58 -0000 Subject: [GHC] #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test In-Reply-To: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> References: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> Message-ID: <063.4a50cd040911e5d6b7bdd80a6f5c514c@haskell.org> #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: AlainODea Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Compile-time | Difficulty: Easy (less than 1 crash | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by AlainODea): * owner: => AlainODea -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 19:05:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 19:05:53 -0000 Subject: [GHC] #8899: StdGen does not generate 0 In-Reply-To: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> References: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> Message-ID: <065.f4c655bfb05413a47e657e292807af08@haskell.org> #8899: StdGen does not generate 0 -------------------------------------+------------------------------------ Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rrnewton): Hi all, late to the party but I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 19:13:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 19:13:04 -0000 Subject: [GHC] #8819: 64bit Testsuite failures in unregisterised 7.8 RCs In-Reply-To: <047.078a5163c24ff483458aa1a9649d90bf@haskell.org> References: <047.078a5163c24ff483458aa1a9649d90bf@haskell.org> Message-ID: <062.26d99ab970435a5ffc487c1f39b35518@haskell.org> #8819: 64bit Testsuite failures in unregisterised 7.8 RCs ------------------------------------------------+-------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Linux | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: 8933 | Related Tickets: ------------------------------------------------+-------------------------- Changes (by trommler): * blockedby: => 8933 Comment: I created a separate ticket (#8933) for the segfault in process007 and added stack traces and debug output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 19:15:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 19:15:43 -0000 Subject: [GHC] #8936: Irrefutable pattern failed in ghc 7.4.1 In-Reply-To: <048.f1b3e4aafeb6db4f191a0edc00f8ccbc@haskell.org> References: <048.f1b3e4aafeb6db4f191a0edc00f8ccbc@haskell.org> Message-ID: <063.8abe2d0ea3760897a4546aec74721cbe@haskell.org> #8936: Irrefutable pattern failed in ghc 7.4.1 ---------------------------------+---------------------------------- Reporter: gahuber95 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. This is already fixed in GHC 7.6: #5951. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 19:24:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 19:24:52 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.e72930bf4b0f75a2244b3d4a43e417fa@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Rocket Science Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by trommler): I tried the test program on openSUSE 12.3: {{{ environ = 0x601060 dlsym(deflt, "environ") = 0x601060 dlsym("libgmp", "environ") = 0x601060 dlsym("libpthread", "environ") = 0x601060 }}} Here is my libgmp: {{{ ls /usr/lib64/libgmp.so* /usr/lib64/libgmp.so /usr/lib64/libgmp.so.10 /usr/lib64/libgmp.so.10.0.5 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 20:01:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 20:01:23 -0000 Subject: [GHC] #8898: Overall improvement for randomIvalInteger In-Reply-To: <050.d45afe73360610d848e4eba302442e5f@haskell.org> References: <050.d45afe73360610d848e4eba302442e5f@haskell.org> Message-ID: <065.5f86440593c58a8722066af6d09dd882@haskell.org> #8898: Overall improvement for randomIvalInteger -------------------------------------+------------------------------------- Reporter: novadenizen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: #5278 #5280 #1120 -------------------------------------+------------------------------------- Changes (by rrnewton): * cc: rrnewton (added) * status: new => closed * resolution: => fixed Comment: Merged! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 20:55:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 20:55:17 -0000 Subject: [GHC] #8937: Wrong jump target in stg_maskUninterruptiblezh Message-ID: <045.b6d0729cad4aed01f58fdf55a078a77f@haskell.org> #8937: Wrong jump target in stg_maskUninterruptiblezh ------------------------------------+------------------------------------- Reporter: hsjunn | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | 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 stack check there reads: STK_CHK_P_LL (WDS(1)/* worst case */, stg_maskAsyncExceptionszh, R1); Isn't that supposed to be STK_CHK_P_LL (WDS(1)/* worst case */, stg_maskUninterruptiblezh, R1); ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 21:18:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 21:18:43 -0000 Subject: [GHC] #8938: Should fallback instead of EXIT_FAILURE on clock_gettime failure Message-ID: <043.a14957746ae331f43904850115d79702@haskell.org> #8938: Should fallback instead of EXIT_FAILURE on clock_gettime failure -------------------------------------------+------------------------------- Reporter: uznx | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- In GHC 7.6, `rts/posix/GetTime.c, Time getProcessCPUTime(void)`: if the result of `clock_gettime` is not zero (success), then the function should fall back to getrusage below instead of aborting with {{{ sysErrorBelch("clock_gettime"); stg_exit(EXIT_FAILURE); }}} The following patch demonstrates a possible fix: {{{ --- pre/rts/posix/GetTime.c 2013-04-18 17:22:47.000000000 -0400 +++ ghc-7.6.3/rts/posix/GetTime.c 2014-03-28 09:52:08.537125998 -0400 @@ -64,10 +64,8 @@ res = clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &ts); if (res == 0) { return SecondsToTime(ts.tv_sec) + NSToTime(ts.tv_nsec); - } else { - sysErrorBelch("clock_gettime"); - stg_exit(EXIT_FAILURE); } + // else fallback } #endif }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 21:29:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 21:29:46 -0000 Subject: [GHC] #8939: Should check the return value of clock_gettime Message-ID: <043.a2c7af0ae4422e35397ef595bd0448d7@haskell.org> #8939: Should check the return value of clock_gettime -------------------------------------------+------------------------------- Reporter: uznx | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- In `ghc-7.6.3/rts/posix/GetTime.c`, function `StgWord64 getMonotonicNSec(void)`: The return value of `clock_gettime` should be checked, and if the value is not 0 (success), it should fall back to `gettimeofday`. The following patch demonstrates a possible fix: {{{ --- pre/rts/posix/GetTime.c 2013-04-18 17:22:47.000000000 -0400 +++ ghc-7.6.3/rts/posix/GetTime.c 2014-03-28 09:52:08.537125998 -0400 @@ -84,19 +82,22 @@ #ifdef HAVE_CLOCK_GETTIME struct timespec ts; + int res= clock_gettime(CLOCK_ID, &ts); + if(res==0) return (StgWord64)ts.tv_sec * 1000000000 + (StgWord64)ts.tv_nsec; #elif defined(darwin_HOST_OS) uint64_t time = mach_absolute_time(); return (time * timer_scaling_factor_numer) / timer_scaling_factor_denom; -#else +#endif + { //fallback struct timeval tv; gettimeofday(&tv, (struct timezone *) NULL); return (StgWord64)tv.tv_sec * 1000000000 + (StgWord64)tv.tv_usec * 1000; -#endif + } } Time getProcessElapsedTime(void) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 21:38:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 21:38:56 -0000 Subject: [GHC] #8940: "make help" fails Message-ID: <043.56b6e22a9950cbc1198cdc30c7e96b87@haskell.org> #8940: "make help" fails ------------------------------------+------------------------------------- Reporter: uznx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | 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: | ------------------------------------+------------------------------------- Although `make help` exists as a target in the GHC source Makefile, it fails because the file `MAKEHELP` does not exist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 28 22:14:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Mar 2014 22:14:17 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.ed4db99f6cb79a46038b3a2378980825@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: patch Priority: high | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Changes (by carter): * owner: => carter -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 29 00:43:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Mar 2014 00:43:25 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.35a236ddfade1c1ed7fe42556fc20dfd@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.2 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by George): I can no longer reproduce this using 7.8rc2. I believe I am using a real gcc and perhaps was before. gcc --version gcc (GCC) 4.8.2 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. bash-3.2$ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/local/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.0.20140228") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-7.8.0.20140228") ,("Global Package DB","/usr/local/lib/ghc-7.8.0.20140228/package.conf.d") ] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 29 10:02:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Mar 2014 10:02:33 -0000 Subject: [GHC] #8940: "make help" fails In-Reply-To: <043.56b6e22a9950cbc1198cdc30c7e96b87@haskell.org> References: <043.56b6e22a9950cbc1198cdc30c7e96b87@haskell.org> Message-ID: <058.b978f35d8860d4b517db424b1bc3b368@haskell.org> #8940: "make help" fails -------------------------------------+------------------------------------ Reporter: uznx | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.6.3 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 schyler): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 29 10:18:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Mar 2014 10:18:34 -0000 Subject: [GHC] #8933: process007: internal error: checkStackFrame: weird activation record found on stack In-Reply-To: <047.eb1d0af3a88bd3a6aaa02c5018d9d701@haskell.org> References: <047.eb1d0af3a88bd3a6aaa02c5018d9d701@haskell.org> Message-ID: <062.3f76ca2a20a3761f6b3f3fece1a3c389@haskell.org> #8933: process007: internal error: checkStackFrame: weird activation record found on stack ----------------------------------+------------------------------------ Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: process007 | Blocked By: Blocking: 8819 | Related Tickets: #8819 ----------------------------------+------------------------------------ Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 29 10:24:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Mar 2014 10:24:51 -0000 Subject: [GHC] #8923: Add SmallArray# type In-Reply-To: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> References: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> Message-ID: <059.f61640afa111b87d4da8949ae3959745@haskell.org> #8923: Add SmallArray# type -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Johan Tibell ): In [changeset:"90329b6cc183b3cd05956ae6bdeb6ac6951549c2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="90329b6cc183b3cd05956ae6bdeb6ac6951549c2" Add SmallArray# and SmallMutableArray# types These array types are smaller than Array# and MutableArray# and are faster when the array size is small, as they don't have the overhead of a card table. Having no card table reduces the closure size with 2 words in the typical small array case and leads to less work when updating or GC:ing the array. Reduces both the runtime and memory allocation by 8.8% on my insert benchmark for the HashMap type in the unordered-containers package, which makes use of lots of small arrays. With tuned GC settings (i.e. `+RTS -A6M`) the runtime reduction is 15%. Fixes #8923. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 29 10:27:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Mar 2014 10:27:43 -0000 Subject: [GHC] #8923: Add SmallArray# type In-Reply-To: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> References: <044.c906ba2e6828adda6252724bc9b6d334@haskell.org> Message-ID: <059.1a947633bf2cba94e090b5018fb306b2@haskell.org> #8923: Add SmallArray# type -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tibbe): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 29 16:35:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Mar 2014 16:35:42 -0000 Subject: [GHC] #7687: ghc panic on TH and deriveJSON In-Reply-To: <044.a32c208c745370fae93ea4e1da30c72b@haskell.org> References: <044.a32c208c745370fae93ea4e1da30c72b@haskell.org> Message-ID: <059.1cc80148862bcb2d83574cad4076db94@haskell.org> #7687: ghc panic on TH and deriveJSON ---------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.4.2 Resolution: | Keywords: TH Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by George): When I try to compile the code above in Description I get Couldn't match expected type ?Options? with actual type ?a0 -> a0? Probable cause: ?id? is applied to too few arguments In the first argument of ?deriveJSON?, namely ?id? In the expression: deriveJSON id ''Test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 29 22:06:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Mar 2014 22:06:32 -0000 Subject: [GHC] #8941: Module that causes GHC-7.8 to exhaust memory compiled with -O2 Message-ID: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> #8941: Module that causes GHC-7.8 to exhaust memory compiled with -O2 ------------------------------------+--------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- The module is JSON.Render in http://src.seereason.com/o2bug. When compiled ghc uses up at least 16GB of RAM and then dies. I haven't been able to simplify it very much, almost any change to JSON.Render causes it to start working properly. I did get it to fail using only packages available in hackage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 29 22:07:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Mar 2014 22:07:00 -0000 Subject: [GHC] #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 (was: Module that causes GHC-7.8 to exhaust memory compiled with -O2) In-Reply-To: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> References: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> Message-ID: <059.3b0150940d853cdce78ecfa716c862f4@haskell.org> #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 ---------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 30 01:38:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Mar 2014 01:38:10 -0000 Subject: [GHC] #8942: Duplicate symbol error when loading an archive twice Message-ID: <046.0073cee3c08e66b73b01434c442d5dd0@haskell.org> #8942: Duplicate symbol error when loading an archive twice ------------------------------------+------------------------------- Reporter: gelisam | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------- ghci can load packages from object files (*.o) and from archive files (*.a). When an object file is loaded twice, the second attempt is silently ignored. When an archive file is loaded twice, ghci aborts with the message "fatal error: I found a duplicate definition for symbol ''s''", for the first symbol ''s'' in the archive. === Patch The attached patch changes {{{rts/Linker.c}}} so that loading an archive file twice silently ignores the second attempt, just like it does with object files. === Repro steps Install a package using Cabal 1.18.*, as that version only produces archives and not objects. Then, force ghci to load that package twice. One way to do this is to use hint inside ghci to load a value from the package. {{{ $ ghci > import Hello > import Language.Haskell.Interpreter > r <- runInterpreter $ setImports ["Hello"] >> interpret "Hello" (as :: Hello) Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package filepath-1.3.0.1 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package unix-2.6.0.1 ... linking ... done. Loading package directory-1.2.0.1 ... linking ... done. Loading package old-time-1.1.0.1 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package process-1.1.0.2 ... linking ... done. Loading package Cabal-1.16.0 ... linking ... done. Loading package binary-0.5.1.1 ... linking ... done. Loading package bin-package-db-0.0.0.0 ... linking ... done. Loading package hoopl-3.9.0.0 ... linking ... done. Loading package hpc-0.6.0.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package ghc-7.6.3 ... linking ... done. Loading package utf8-string-0.3.8 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package hello-0.1.0.0 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package exceptions-0.3.3.1 ... linking ... done. Loading package extensible-exceptions-0.1.1.4 ... linking ... done. Loading package ghc-mtl-1.1.0.0 ... linking ... done. Loading package ghc-paths-0.1.0.9 ... linking ... done. Loading package random-1.0.1.1 ... linking ... done. Loading package hint-0.4.0.0 ... linking ... done. GHCi runtime linker: fatal error: I found a duplicate definition for symbol ___stginit_hellozm0zi1zi0zi0_Hello whilst processing object file /Users/gelisam/.cabal/lib/x86_64-osx- ghc-7.6.3/hello-0.1.0.0/libHShello-0.1.0.0.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. }}} A minimal definition for the hello package is attached, but doesn't contain anything relevant to the issue. It's just a dummy datatype: {{{#!haskell {-# LANGUAGE DeriveDataTypeable #-} module Hello where import Data.Typeable data Hello = Hello deriving Typeable }}} === Workaround Use Cabal 1.16, which (also) installs object files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 30 01:44:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Mar 2014 01:44:11 -0000 Subject: [GHC] #8942: Duplicate symbol error when loading an archive twice In-Reply-To: <046.0073cee3c08e66b73b01434c442d5dd0@haskell.org> References: <046.0073cee3c08e66b73b01434c442d5dd0@haskell.org> Message-ID: <061.94b526d25126baac41d6e24779a84806@haskell.org> #8942: Duplicate symbol error when loading an archive twice -----------------------------------+------------------------------------ Reporter: gelisam | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by gelisam): Might be a duplicate of #8614, which has the same symptoms but different repro steps (which I can't replicate because of Honi's dependencies) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 30 06:48:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Mar 2014 06:48:01 -0000 Subject: [GHC] #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 In-Reply-To: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> References: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> Message-ID: <059.5388843343034248e7009ed611a16059@haskell.org> #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 ---------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by gidyn): * cc: gideon@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 30 07:12:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Mar 2014 07:12:30 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.b439e4e146f3b734a6ecca1a9d1cdf2a@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by thoughtpolice): I've definitely managed to reproduce this finally after a bunch of hunting - it doesn't really seem related to OS version, JUST related to MSYS2. #8870 is the same thing, I'm quite certain (failure at `CPSZ` output during segfault if you check `-v3`). It just doesn't make sense to me why the testsuite runs clean on my machine where I built the bindist, and everything works and compiles, but it fails for users and here. I'm running the testsuite right now and I can see some isolated failures that I'm quite sure are illegitimate (several segfaults), i'll report the results here, `./validate` is about half done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 30 07:29:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Mar 2014 07:29:56 -0000 Subject: [GHC] #8929: Deriving Generics broken In-Reply-To: <044.b3c356894e088206397c6c924ad3062a@haskell.org> References: <044.b3c356894e088206397c6c924ad3062a@haskell.org> Message-ID: <059.417ad525cd785b3e2a7dcca9cfc84354@haskell.org> #8929: Deriving Generics broken -------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by dreixel): I've just built GHC 7.6.3 with 7.6.3 (x86 linux), but I cannot reproduce this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 30 09:37:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Mar 2014 09:37:29 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.dec7a6d4770bf33fe0e912386af1b1f5@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by thoughtpolice): I see no actual suspicious testsuite failures (even in `codeGen`) that indicate anything is wrong - the only failures I get are due to the compiler itself segfaulting on a test. More soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 30 12:55:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Mar 2014 12:55:40 -0000 Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@haskell.org> References: <047.bea78f01cbb904765ad77c751bc8d3af@haskell.org> Message-ID: <062.0f74da1edc7be3a231504fe5c8a44678@haskell.org> #595: Overhaul GHC's overlapping/non-exhaustive pattern checking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Difficult (2-5 warning at compile-time | days) Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by mbassett): * cc: michael.b.bassett@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 30 15:24:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Mar 2014 15:24:14 -0000 Subject: [GHC] #8943: Add System.Process.createPipe Message-ID: <044.78c29afcb2d7ba48a111dfadbe70b4a3@haskell.org> #8943: Add System.Process.createPipe -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/process | 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: | -------------------------------------+------------------------------------- As agreed in: http://comments.gmane.org/gmane.comp.lang.haskell.libraries/21373 I've validated the patch on OS X, but I need someone to validate on Windows. I originally wrote this code for cabal and tested it on all platforms back then. I no longer have a Windows machine and the imports in `System.Process` are messy enough that someone needs to check that it still builds on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 30 15:24:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Mar 2014 15:24:52 -0000 Subject: [GHC] #8943: Add System.Process.createPipe In-Reply-To: <044.78c29afcb2d7ba48a111dfadbe70b4a3@haskell.org> References: <044.78c29afcb2d7ba48a111dfadbe70b4a3@haskell.org> Message-ID: <059.e4ec5ffbb0e490ce2d340b0007cfa2f3@haskell.org> #8943: Add System.Process.createPipe --------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries/process | Version: 7.6.3 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 tibbe): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 00:35:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 00:35:27 -0000 Subject: [GHC] #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 In-Reply-To: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> References: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> Message-ID: <059.08421e603dd11d1db2280cad611f095b@haskell.org> #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 ---------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by guest): * cc: marco.vax91@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 03:28:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 03:28:15 -0000 Subject: [GHC] #8944: Warn instead of stopping on misplaced Haddock comments Message-ID: <047.5551abebc2213482bde9e949bb62029b@haskell.org> #8944: Warn instead of stopping on misplaced Haddock comments -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Given a simple module like {{{ module H where data F = F () -- ^ Comment for first type argument () }}} and trying to run Haddock on it, we'll get back {{{ /tmp/H.hs:4:12: parse error on input ?(? }}} The error message is rather sub-par in this scenario. It'd be great if we could instead print a warning saying that a Haddock comment is unexpected in that position and then continue on parsing. Best case scenario would be a more informative message such as ?Documenting each constructor argument is not supported? but that might be quite a bit harder. Filing on GHC Trac as it's the parser that needs changing I believe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 06:25:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 06:25:13 -0000 Subject: [GHC] #8945: Organa Slim ORIGINAL GARCINIA CAMBOGIA Message-ID: <049.901b809e37f223aeea3d7b03c203e5dc@haskell.org> #8945: Organa Slim ORIGINAL GARCINIA CAMBOGIA ------------------------------------+------------------------------------- Reporter: sawradvan1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Slimming pills pay us all an fantabulous occurrence to organise our thought and behaviours around nutrient by dynamical our eating habits. Pills that are unbleached and unhazardous are an fantabulous way to win metric and food intake when victimized decent.[http://originalgarciniacambogiaoz.com/ ORIGINAL GARCINIA CAMBOGIA] Slenderize pills or slimming pills engage anyone sensing to sterilise their body coefficient a new way to difference their uptake habits. The represent that most people are obesity has many to do with emotion than nutrient but eating when not hungry is a habit that can be insensitive to score alter with the good give in the experience so using a spontaneous p[enation that instrument hap these habits can transform to commence slimming pills to aid coefficient death are: They reserve us to ruin jaundiced uptake habits by changing the necessity to eat. By removing the requirement to eat a somebody is supposal the possibleness to re asses their consumption habits and introduces different ones into their number. By removing the advocate to eat the spontaneous impact that creates thirst can be re-introduced solon easily. For anyone who eats more that their embody needs, the intelligent 'intuition' of hurt has been over ridden or obscuoured by emotions. By using slimming tablets to 'myopic racetrack' the existing scheme a human can get rearwards in ouch with the unprocessed belief of desire that subsist within them. They are spontaneous and acquisition with the body's noesis and not against it allowing added earthy walk for born feeding to cover the post of the existing annihilating patterns. Monthlong long coefficient management can be achieved only through use of innate processes. If a human achieves their paragon metric finished eerie or mental processes there is no uncertainty the unit instrument be put endorse when needful. During the metric release appendage there will be present when a being has the motivation to over eat: this is commonly when they are reorganising their little processes, emotions that would in the tense conduce to them feeding author than they requirement. When a cause recognises this notion they are competent to concentrate their (uncanny) feeling of hurt with slimming tablets until they hold resolved the gushy issues. Erstwhile the diet/weight failure outgrowth has smooth the slimming pills are not used again different the pricey read wheel odd in the predicament of the bedroom never to be misused. Unaffected slimming pills can victimized then unnoticed providing zealous view for money. '''ORIGINAL GARCINIA CAMBOGIA''' Although not the most tangible deciding for galore, slim pills that are earthy, unhurt and reduce the appetency of a soul can be far more potent at breaking old uptake habits than the valuable gym membership that galore undergo up. http://originalgarciniacambogiaoz.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 07:01:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 07:01:57 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.f5957e489d77dc1d7efc3c8692a8a16e@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by thoughtpolice): Okay, I spent some time boiling some things down, and I've at least determined the approximate location of the segfault in the code during compilation, which is `stmtToInstrs` in `compiler/nativeGen/X86/CodeGen.hs`. Here's just a quick dump (to not loose findings) and I'll keep looking around. The fault is when compiling `System.Time` in profiling. Run under gdb: {{{ $ gdb --args "inplace/bin/ghc-stage2.exe" -v3 -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -H32m -O -package-name old-time-1.i -ilibraries/old-time/. -ilibraries/old-time/dist-install/build -ilibraries /old-time/dist-install/build/autogen -Ilibraries/old-timearies/old-time /dist-install/build/autogen -Ilibraries/old-time/include -optP-include -optPlibraries/old-time/dist-install/build/auage base-4.7.0.0 -package old-locale-1.0.0.6 -Wall -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/old-time/distaries/old-time/dist-install/build -stubdir libraries/old-time/dist-install/build -c libraries/old-time/dist- install/build/System/Tie/dist-install/build/System/Time.p_o +RTS -DS GNU gdb (GDB) 7.6.1 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-msys". For bug reporting instructions, please see: ... Traceback (most recent call last): File "", line 3, in ImportError: No module named libstdcxx.v6.printers /etc/gdbinit:6: Error in sourced command file: Error while executing Python code. Reading symbols from /home/Administrator/ghc/inplace/bin/ghc- stage2.exe...done. warning: File "/home/Administrator/ghc/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto- load". To enable execution of this file add add-auto-load-safe-path /home/Administrator/ghc/.gdbinit line to your configuration file "/home/Administrator/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/Administrator/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" (gdb) load .gdbinit You can't do that when your target is `exec' (gdb) source .gdbinit (gdb) r Starting program: /home/Administrator/ghc/inplace/bin/ghc-stage2.exe -v3 -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -H32m -O -package-name old-time-1.1.0.2 -hide-all-packages -i -ilibraries/old-time/. -ilibraries /old-time/dist-install/build -ilibraries/old-time/dist- install/build/autogen -Ilibraries/old-time/dist-install/build -Ilibraries /old-time/dist-install/build/autogen -Ilibraries/old-time/include -optP- include -optPlibraries/old-time/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package old-locale-1.0.0.6 -Wall -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/old-time/dist-install/build -hidir libraries/old-time/dist-install/build -stubdir libraries/old-time /dist-install/build -c libraries/old-time/dist- install/build/System/Time.hs -o libraries/old-time/dist- install/build/System/Time.p_o +RTS -DS [New Thread 1136.0xcc8] cc8: cap 0: initialised [New Thread 1136.0x15e8] [New Thread 1136.0x1658] [New Thread 1136.0x11b8] [New Thread 1136.0x11e8] [New Thread 1136.0x1718] Glasgow Haskell Compiler, Version 7.9.20140329, stage 2 booted by GHC version 7.6.3 Using binary package database: C:\Users\Administrator\Desktop\msys32\home\Administrator\ghc\inplace\lib\package.conf.d\package.cache wired-in package ghc-prim mapped to ghc-prim-0.3.1.0-inplace wired-in package integer-gmp mapped to integer-gmp-0.5.1.0-inplace wired-in package base mapped to base-4.7.0.0-inplace wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-inplace wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: *** Checking old interface for old-time-1.1.0.2:System.Time: *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 5,701, types: 3,843, coercions: 29} ... *** Tidy Core: Result size of Tidy Core = {terms: 15,413, types: 10,079, coercions: 582} Created temporary directory: C:\Users\Administrator\Desktop\msys32\tmp\ghc1136_0 *** CorePrep: Result size of CorePrep = {terms: 18,936, types: 12,028, coercions: 582} *** Stg2Stg: *** CodeOutput: *** New CodeGen: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: Program received signal SIGSEGV, Segmentation fault. 0x02137032 in c1hhA_info () (gdb) bt #0 0x02137032 in c1hhA_info () Cannot access memory at address 0x28a874 (gdb) disassemble Dump of assembler code for function c1hhA_info: 0x02137024 <+0>: sub $0x3510,%esp 0x0213702a <+6>: mov 0x8(%ebp),%eax 0x0213702d <+9>: mov 0x4(%ebp),%ecx 0x02137030 <+12>: mov %esi,%edx => 0x02137032 <+14>: mov %eax,0x184(%esp) 0x02137039 <+21>: mov -0x1(%edx),%eax 0x0213703c <+24>: movzwl -0x2(%eax),%eax 0x02137040 <+28>: cmp $0x1e,%eax 0x02137043 <+31>: ja 0x214916f 0x02137049 <+37>: mov %eax,0x190(%esp) 0x02137050 <+44>: mov 0x1c(%ebp),%eax 0x02137053 <+47>: mov %eax,0xa0(%esp) 0x0213705a <+54>: mov 0x190(%esp),%eax 0x02137061 <+61>: jmp *0x2b86708(,%eax,4) 0x02137068 <+68>: inc %edx 0x02137069 <+69>: add %al,(%eax) 0x0213706b <+71>: add %ah,(%eax) 0x0213706d <+73>: add %al,(%eax) 0x0213706f <+75>: add %al,0x3510ec(%ecx) End of assembler dump. (gdb) (gdb) info registers eax 0x6b3b05d 112439389 ecx 0x6b49524 112497956 edx 0x67a40a9 108675241 ebx 0x2bc3470 45888624 esp 0x28a874 0x28a874 ebp 0x4697cc8 0x4697cc8 esi 0x67a40a9 108675241 edi 0x6b4ac20 112503840 eip 0x2137032 0x2137032 eflags 0x10202 [ IF RF ] cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x53 83 gs 0x2b 43 (gdb) p8 $ebp 0x4697ce4: 0x6b488d9 0x4697ce0: 0x6b4ac18 0x4697cdc: 0x6300ef1e 0x4697cd8: 0x6b4954d 0x4697cd4: 0x67a40a9 0x4697cd0: 0x6b3b05d 0x4697ccc: 0x6b49524 0x4697cc8: 0x2137024 (gdb) pinfo &c1hhA_info $1 = {layout = {payload = {ptrs = 903, nptrs = 0}, bitmap = 903, large_bitmap_offset = 903, selector_offset = 903}, type = 32, srt_bitmap = 7, code = 0x2137024 "\201\354\020\065"} (gdb) prinfo &c1hhA_info $2 = {srt_offset = 8706840, i = {layout = {payload = {ptrs = 903, nptrs = 0}, bitmap = 903, large_bitmap_offset = 903, selector_offset = 903}, type = 32, srt_bitmap = 7, code = 0x2137024 "\201\354\020\065"}} }}} The fault is in `c1hhA_info`. Finding that symbol: {{{ $ find compiler/stage2 -type f | xargs grep c1hhA_info Binary file compiler/stage2/build/libHSghc-7.9.20140329.a matches Binary file compiler/stage2/build/X86/CodeGen.o matches }}} It's in `./nativeGen/X86/CodeGen.hs` - check the `-ddump-opt-cmm` out to get corresponding optimized code, finding the closure for the info table: {{{ ==================== Optimised Cmm ==================== a292_rFAj_entry() // [] { [(c18OH, block_c18OH_info: const u1hJf_srtd-block_c18OH_info; const 1; const 4294901792;), (c18OQ, block_c18OQ_info: const u1hJg_srtd-block_c18OQ_info; const 3; const 4294901792;), ... ... ... (c1hhA, block_c1hhA_info: const SUys_srt-block_c1hhA_info+2332; const 903; const 458784;), ... ... ... c1hyQ: I32[Hp - 8] = $w$j_sSgL_info; I32[Hp - 4] = I32[Sp + 24]; I32[Hp] = I32[Sp + 20]; I32[Sp] = block_c1hhA_info; R1 = P32[Sp + 12]; P32[Sp + 24] = Hp - 8; if (R1 & 3 != 0) goto c1hhA; else goto c1hhB; c1hhB: call (I32[R1])(R1) returns to c1hhA, args: 4, res: 4, upd: 4; c1hhA: _sSgE::P32 = P32[Sp + 8]; _sSgI::P32 = P32[Sp + 4]; _sSmu::P32 = R1; _c1hub::I32 = %MO_UU_Conv_W16_W32(I16[I32[_sSmu::P32 - 1] - 2]); if (_c1hub::I32 > 30) goto c1hug; else goto c1hue; ... ... }}} We can see this matches pretty closely with the assembly generated around the offending code (`-ddump-asm`): {{{ _c1hyQ: movl $$w$j_sSgL_info,-8(%edi) movl 24(%ebp),%eax movl %eax,-4(%edi) movl 20(%ebp),%eax movl %eax,(%edi) movl $block_c1hhA_info,(%ebp) movl 12(%ebp),%esi leal -8(%edi),%eax movl %eax,24(%ebp) testl $3,%esi jne _n1kED ... .text .align 4,0x90 .long SUys_srt-(block_c1hhA_info)+2332 .long 903 .long 458784 block_c1hhA_info: _c1hhA: subl $13584,%esp _n1kED: movl 8(%ebp),%eax movl 4(%ebp),%ecx movl %esi,%edx movl %eax,388(%esp) movl -1(%edx),%eax movzwl -2(%eax),%eax cmpl $30,%eax ja _c1hug }}} Next, looking at the STG output, `a292_rFAj` looks like: {{{ a292_rFAj :: forall e_a94q x_a94r. CmmNode.CmmNode e_a94q x_a94r -> NCGMonad.NatM_State -> (X86.CodeGen.InstrBlock, NCGMonad.NatM_State) ... }}} If you search for calls to this, there is one call to it from `a290_rFAh`, which looks like: {{{ a290_rFAh :: CmmMachOp.CallishMachOp -> Data.Maybe.Maybe CmmNode.CmmFormal -> [CmmNode.CmmActual] -> NCGMonad.NatM_State -> (X86.CodeGen.InstrBlock, NCGMonad.NatM_State) ... let { sat_sMWp [Occ=Once] :: CmmNode.CmmNode Compiler.Hoopl.Block.O Compiler.Hoopl.Block.O [LclId, Str=DmdType] = NO_CCS CmmNode.CmmUnsafeForeignCall! [GHC.Prim.coercionToken# GHC.Prim.coercionToken# sat_sMWb sat_sMWd sat_sMWo]; } in a292_rFAj sat_sMWp st'_sMWa; }}} The only thing that has a type of `CallishMachOp -> ...` is `outOfLineCmmOp`, which does indeed call `stmtToInstrs (CmmUnsafeForeignCall ...)` like in the above snippet. The type of `stmtToInstrs` also matches the (desugared) type of `a292_rFAj`. So this is certainly where the fault is occurring. Unfortunately `stmtToInstrs` becomes incredibly large it seems, so pinning it down further is proving challening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 07:14:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 07:14:06 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.3522cfb2d4c4ba9b066ca893bd65a4a8@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by thoughtpolice): I'll also note that it seems turning off the sinking pass seems to make no difference (that is, `-fno-cmm-sink` in `compiler/nativeGen/X86/CodeGen.hs`) to cause this bug to still trigger, although I haven't verified it faults in exactly the same spot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 07:20:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 07:20:51 -0000 Subject: [GHC] #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 In-Reply-To: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> References: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> Message-ID: <059.5248d02ab4e03824d49e5be268dd04b7@haskell.org> #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 ---------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by bjp): I had a similar problem one month ago and believe that it is caused by https://ghc.haskell.org/trac/ghc/ticket/7068 in my case. I temporarily fixed it by adding a `-fno-spec-constr` option, maybe you want to try that as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 08:02:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 08:02:11 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.d605592702c561a37f3207e5ab14a8a0@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by thoughtpolice): The only way I can get this to *not* segfault is if I completely disable optimization with `{-# OPTIONS_GHC -O0 #-}` in `CodeGen.hs`. I'm going to see if the build completes and run the testsuite again to see what it says... (BTW, this is a typical performance build, so everything will be compiled with -O, at least). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 08:20:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 08:20:43 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.b0a7b7ddba52c37bed76bcb3b3058404@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): {{{ 0x02137024 <+0>: sub $0x3510,%esp 0x0213702a <+6>: mov 0x8(%ebp),%eax 0x0213702d <+9>: mov 0x4(%ebp),%ecx 0x02137030 <+12>: mov %esi,%edx => 0x02137032 <+14>: mov %eax,0x184(%esp) }}} Oh wow, this function needs a *lot* of spill space on the C stack. I bet the problem is that we're bumping `%esp` by more than one page, and Windows doesn't like that, it expect the stack to grow by one page at a time. So the fix would be to write to the intervening pages one at a time. This is another bug in the NCG. I'm also interested in why this function needs quite so much extra stack. (also, shouldn't we be discussing this on #8870? The bug in this ticket is fixed, I think). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 09:03:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 09:03:45 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.cdb16791ceeaad1f2a6d6c7b1eb04b19@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Whoops, yes, this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 09:04:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 09:04:24 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.22f7c6de5d90a47fd4f7b69cb909ab04@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+------------------------------ Reporter: facundoq | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+------------------------------ Comment (by thoughtpolice): Note the discussion continuing on from https://ghc.haskell.org/trac/ghc/ticket/8834#comment:79 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 09:04:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 09:04:44 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.ce85f50a495153f91128bc704f8fa59a@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+------------------------------ Reporter: facundoq | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+------------------------------ Changes (by thoughtpolice): * milestone: 7.8.2 => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 09:27:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 09:27:43 -0000 Subject: [GHC] #8946: Tuck In Problem Areas ORIGINAL GARCINIA CAMBOGIA Message-ID: <049.fafda2cc808247c5403f25f45d4c7f06@haskell.org> #8946: Tuck In Problem Areas ORIGINAL GARCINIA CAMBOGIA ------------------------------------+------------------------------------- Reporter: sguiq6paq1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- When you're feat to the syndicate or the beach, you requisite to care your individual. However, your curves aren't enhanced and your problem areas are not concealed by most cleansing suits. Slimming swimwear does what standing suits can't do-- washing suits that decrease you downed are the lastest way to seem and await grotesque at the puddle, the beach or symmetrical only when you are lacing in your posterior field [http://originalgarciniacambogiaoz.com/ ORIGINAL GARCINIA CAMBOGIA] Raise Your Curves: Slimming swimwear is major for women of all sizes. Whether you are a size 2 or 20, slimming swimwear's underwire bra amount and loyal cloth that offers connection and tones problem areas can ameliorate intensify your curves. Slenderize Your Waist: Slimming swimwear is generally constructed with only high-quality fabrics that can commit women the agree and slimming looking they status. Await for cleanup suits that are prefab of polyamide or spandex for a peachy and fixed fit. Mold Your Body: Slimming washing suits can support you care your good. With a turn gun that slims your down and a top make that is designed for maximum connection, two-piece lavation suits can still give you the embody enhancement you necessary if you are fain to resign the model viscus reportage provided by a one-piece. Get a Trade Fit: Choosing a cleaning prettify in a "miniature," "line" and "whopping" situation isn't quite the nonsuch join for most women. It is alpha to be healthy to take your prettify according to your cup filler. You can get the individual gettable fit for your day at the water, whether you are an A or DD, by judgement a garment in your precise cup filler. Be Capable in Your Swimwear More grouping say that friendship is the most beautiful caliber that anyone can hump. The way you appear in your bathing gibe is not as beta as how you property. '''ORIGINAL GARCINIA CAMBOGIA''' Slimming swimwear not only enhances your undyed curves, it also helps to intensify your status and rase of self- confidence. Whether you're in a one-piece or a two-piece, slimming swimwear can sword in your job areas and heighten your body's favourite features. Choose from a show of colors and patterns that let you demo off your unparalleled style. Get the slimming swimwear that is perfect for you today and reason assured this season when thrashing by the syndicate or ornamentation out on the beach http://originalgarciniacambogiaoz.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 10:23:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 10:23:54 -0000 Subject: [GHC] #8936: Irrefutable pattern failed in ghc 7.4.1 In-Reply-To: <048.f1b3e4aafeb6db4f191a0edc00f8ccbc@haskell.org> References: <048.f1b3e4aafeb6db4f191a0edc00f8ccbc@haskell.org> Message-ID: <063.b9129b97ef18819d1b11768fb4743119@haskell.org> #8936: Irrefutable pattern failed in ghc 7.4.1 ---------------------------------+---------------------------------- Reporter: gahuber95 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Changes (by hvr): * cc: hvr (removed) * component: GHCi => Compiler * milestone: => 7.6.1 Old description: > Thanks for your attention! Gary (newbie) > > ########################################## > class Show a => Show_Listable a where > show_list :: [a] -> IO() > > instance Show_Listable a -> Show a where > show_list lst = do > print "gen list"; > print lst > > lst :: Int -> [Int] > lst i = [1,2,3] > > main = do > show_list (lst 1) > > ###################################################### > Output: > > $ ghc bull.hs -o bull > [1 of 1] Compiling Main ( bull.hs, bull.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 7.4.1 for x86_64-unknown-linux): > compiler/rename/RnSource.lhs:429:14-81: Irrefutable pattern > failed for pattern Data.Maybe.Just (inst_tyvars, > _, > SrcLoc.L _ cls, > _) > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: Thanks for your attention! Gary (newbie) {{{#!haskell class Show a => Show_Listable a where show_list :: [a] -> IO() instance Show_Listable a -> Show a where show_list lst = do print "gen list"; print lst lst :: Int -> [Int] lst i = [1,2,3] main = do show_list (lst 1) }}} Output: {{{ $ ghc bull.hs -o bull [1 of 1] Compiling Main ( bull.hs, bull.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for x86_64-unknown-linux): compiler/rename/RnSource.lhs:429:14-81: Irrefutable pattern failed for pattern Data.Maybe.Just (inst_tyvars, _, SrcLoc.L _ cls, _) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 10:29:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 10:29:27 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.9b3ee836c0b19c957ac4bb020b0a1f02@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+------------------------------ Reporter: facundoq | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+------------------------------ Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 11:04:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 11:04:15 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.9f191b49967576474f33c38d84c79a97@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by archblob): * owner: => archblob Comment: I will work on this if no one else is, so if someone is, please tell me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 11:05:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 11:05:24 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.4245b35bcae1a515b536922057b0f5ce@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by archblob): * cc: fcsernik@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 11:20:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 11:20:56 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.c8e398339902d6fb8eff7ea799108670@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Great, thank you. Would you be willing to have a Skype call so we can discuss specifics? Preferably after you have read your way into the code, Gergo's recent changes, but before you have committed much time to doing something new. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 11:48:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 11:48:03 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.03a27f9d616baa50b93123a5d7e2f5cd@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by archblob): Yes I am willing but this is my first time looking into the GHC codebase and I think it will take some time before we can have a meaningful discussion and not just waste your time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 12:09:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 12:09:03 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.fc8d22432ff0c338d1a80322e8ca3aad@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+------------------------------ Reporter: facundoq | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+------------------------------ Comment (by thoughtpolice): @Simon, I've tried sprinkling some `NOINLINE` to see if it has any effect on pressure the codegen might be under - indeed, if I sprinkle a few `NOINLINE` here and there like on `genCCall` (a massive piece of code in its own right), then `System.Time` does compile, but DPH fails to compile later on: {{{ libraries/dph/dph-lifted-vseg/ghc.mk:5: recipe for target 'libraries/dph /dph-lifted-vseg/dist- install/build/Data/Array/Parallel/PArray/PData/Base.p_o' failed make[1]: *** [libraries/dph/dph-lifted-vseg/dist- install/build/Data/Array/Parallel/PArray/PData/Base.p_o] Segmentation fault }}} I'm checking if this is the same thing as before right now. I will note that in the example I posted in the other comment, `a292_rFAj` at the STG level - which roughly corresponds to `stmtToInstrs` - is ''absolutely massive'' - by itself, it's on the order of 24,000 lines of intermediate code long. `X86.CodeGen` really only exports `cmmTopCodeGen`, so it probably goes to town on the module, inlining like crazy, since `stmtToInstrs` is at the heart of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 12:32:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 12:32:39 -0000 Subject: [GHC] #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 In-Reply-To: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> References: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> Message-ID: <059.ecc7d70b408d4ac9693263ba2da9a184@haskell.org> #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 ---------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by guest): I will give that a try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 13:25:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 13:25:11 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.84aa31f294788bb658daccb091b1dfc9@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Changes (by archblob): * related: => #8776 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 14:53:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 14:53:45 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.0e9f80c1b11b4981c1631ba4c28a2343@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+------------------------------ Reporter: facundoq | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+------------------------------ Comment (by awson): I don't quite understand [https://ghc.haskell.org/trac/ghc/ticket/8834#comment:77 how could I reproduce it]. Even running GHC under MSYS2 I can't get it segfaulting. If sitting on 64-bit windows shall I use 32-bit MSYS2 to reproduce it? Also [https://ghc.haskell.org/trac/ghc/ticket/8834#comment:82 growing stack by more than 1 page] is a *definite* bug in Windows. And there are many discussions on this here and there. As a temporary workaround could we simply increase reserved *and* committed stack size in an executable's header making GHC invoke linker with right options when producing executables - something like `-optl- Xlinker -optl--stack=0x800000,0x800000`? This would make things more or less like they are under Linux/OSX. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 15:00:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 15:00:54 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.105607aa1bf99fb5c7dff997d54bb7c7@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+------------------------------ Reporter: facundoq | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+------------------------------ Comment (by simonmar): Does committing more stack space have any adverse effects? Startup time and/or making our processes unnecessarily large? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 15:05:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 15:05:48 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.a2fdab0ae1f4c82acb7598bac668986a@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+------------------------------ Reporter: facundoq | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+------------------------------ Comment (by awson): Replying to [comment:15 simonmar]: > Does committing more stack space have any adverse effects? Startup time and/or making our processes unnecessarily large? These effects look absolutely negligible to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 18:21:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 18:21:43 -0000 Subject: [GHC] #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test In-Reply-To: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> References: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> Message-ID: <063.b90fda8986e5681808d5229d432715a0@haskell.org> #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: AlainODea Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Compile-time | Difficulty: Easy (less than 1 crash | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by AlainODea): This will break Solaris 9 and earlier. On Solaris 10, OpenSolaris, Illumos, and Solaris 11 librt in libc. I don't think GHC 7.8 can reasonably support Solaris 9 due to issues with porting the needed GCC toolchain. An alternative would be to identify recent Solaris/Illumos operating systems as something other than '''OSSolaris2''' when generating '''GHCConstantsHaskellType'''. That seems far more problematic as it would require changes everywhere '''OSSolaris2''' is used. Doing a similar trick for Solaris 9 and earlier would have the same problem. Solaris 10 was released on 2005-01-31. Solaris 9's latest release is 9/05 which was released on 2005-09-03. I think support for **-profthreaded** on Solaris 9 and earlier can be safely excluded by default. Users who need **--profthreaded** on GHC 7.8+ on those systems can easily reverse this patch in their build process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 19:17:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 19:17:13 -0000 Subject: [GHC] #7066: isInstance does not work for compound types In-Reply-To: <044.f26fdb7a0d5666f6e8ecfbb0861afaff@haskell.org> References: <044.f26fdb7a0d5666f6e8ecfbb0861afaff@haskell.org> Message-ID: <059.cb721a74fb6c6f2400045ad9698d7367@haskell.org> #7066: isInstance does not work for compound types -------------------------------------+------------------------------------ Reporter: edsko | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by mojojojo): I just got hit by this issue. I would expect {{{ isInstance clss typs }}} to return True if and only if I can safely generate code (in my Template Haskell code) that relies on 'typs' being an instance of 'clss'. In the example above, I can not safely generate code that relies on a Show instance for (Int, A) because there is no Show instance for A. I expected exactly the same. That's why I believe that the current behaviour of the function is unintuitive to say the least. The documentation has no info concerning such behaviour either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 20:11:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 20:11:58 -0000 Subject: [GHC] #8929: Deriving Generics broken In-Reply-To: <044.b3c356894e088206397c6c924ad3062a@haskell.org> References: <044.b3c356894e088206397c6c924ad3062a@haskell.org> Message-ID: <059.94868154872ff2df0449f3416c8e55ea@haskell.org> #8929: Deriving Generics broken -------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by hvr): * status: new => closed * resolution: => invalid Comment: After talking to OP, I'm closing this as this was most likely caused by a broken installation/pkg-db -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 21:41:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 21:41:25 -0000 Subject: [GHC] #8945: GHC produces grouped declarations in a weird order Message-ID: <047.12aea71633961830ba977b69f47ef451@haskell.org> #8945: GHC produces grouped declarations in a weird order ------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider very simple module like {{{#!haskell module J where class A a where f, g, h, i :: a -> () }}} Now when we ask GHC about declarations in the module and extract function signatures, we don't get {{{f, g, h, i :: a -> ()}}} as we could expect. We instead get {{{f, i, h, g :: a -> ()}}}. The pattern is that the first name is in a correct position and the rest is reversed. This leads to whatever uses the API get the names in order different than that in the source file. See http://trac.haskell.org/haddock/ticket/188 for an example when this matters. I have prepared an example using GHC API which you can run on your machine with your own test files and see the results for yourselves. {{{#!haskell -- GHC.Paths requires the very small ghc-paths package. -- if you don't want it, libdir = ghc --print-libdir module Main where import Control.Monad (ap, liftM2) import Data.Functor ((<$>)) import System.Environment (getArgs) import Digraph (flattenSCCs) import GHC import GHC.Paths (libdir) import Outputable (text, ppr, showSDoc, (<>), (<+>)) main :: IO () main = do (dfs, modules) <- getArgs >>= withGhc Nothing . processModules let r = map (showSDoc dfs . (\(x,y) -> text x <> text ":" <+> ppr y) . f) modules putStrLn $ unlines r where f (s, t) = (ms_hspp_file s, (\(x,_,_,_) -> x) <$> tm_renamed_source t) type ModuleName' = String withGhc :: Maybe DynFlags -> Ghc a -> IO (DynFlags, a) withGhc d act = runGhc (Just libdir) $ do dynflags <- case d of Nothing -> getSessionDynFlags Just d' -> return d' _ <- setSessionDynFlags dynflags liftM2 (,) getSessionDynFlags act processModules :: [ModuleName'] -> Ghc [(ModSummary, TypecheckedModule)] processModules modules = do mg <- depAnalysis let sortedMods = flattenSCCs $ topSortModuleGraph False mg Nothing mapM (\x -> return (\y -> (x,y)) `ap` (parseModule x >>= typecheckModule >>= loadModule)) sortedMods where depAnalysis :: Ghc ModuleGraph depAnalysis = do targets <- mapM (\f -> guessTarget f Nothing) modules setTargets targets depanal [] False }}} In this case, using the tiny module I posted at the beginning, I get: {{{ *Main> :main "/tmp/J.hs" /tmp/J.hs: Just class J.A a where J.f, J.i, J.h, J.g :: a -> () }}} It looks to me like it's just an oversight somewhere in the API and should be an easy fix for someone familiar with that part. I'd rather save myself many hours trying to find it on my own. PS: Are the rules for when grouping happens documented somewhere? Grouping functions in class definitions is the only sure-fire way I can get a grouped signature but I'm sure there were others in the past that no longer work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 31 23:39:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Mar 2014 23:39:42 -0000 Subject: [GHC] #7066: isInstance does not work for compound types In-Reply-To: <044.f26fdb7a0d5666f6e8ecfbb0861afaff@haskell.org> References: <044.f26fdb7a0d5666f6e8ecfbb0861afaff@haskell.org> Message-ID: <059.b7e88dcb9ba7d3c1b6f11257f0b92b24@haskell.org> #7066: isInstance does not work for compound types -------------------------------------+------------------------------------ Reporter: edsko | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by mojojojo): I've just released "fixed" versions of {{{reifyInstances}}} and {{{isInstance}}} as the [http://hackage.haskell.org/package/th-instance- reification th-instance-reification library], which work as edsko and I expected. -- Ticket URL: GHC The Glasgow Haskell Compiler