From ghc-devs at haskell.org Thu May 1 08:19:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 May 2014 08:19:39 -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.ed5b8d4b54bc26e4d0e8274ea52442f0@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.3 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): Replying to [comment:6 dagit]: > The difference is that libpthread depends on ld-linux.so as a shared object dependency (grep the readelf -Wa output for `NEEDED`) and ld- linux.so defines a `LOCAL` symbol for environ. As I understand it, that means the dynamic linker thinks libpthread defines environ as `LOCAL` (so it goes to look for a different definition and ends up with the right one). For libgmp it looks in libc.so and finds a `WEAK` definition and uses it because there is no other `GLOBAL` definition. > > To help demonstrate this, consider this example. On my system, libz.so has dependencies similar to libgmp.so: > {{{ > $ readelf -Wa /usr/lib64/libgmp.so.10 | grep NEEDED > 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] > $ readelf -Wa /usr/lib64/libz.so.1 | grep NEEDED > 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] > }}} > > > I'm still fuzzy on some of the details, but it seems that `WEAK` and `LOCAL` mean very different things to the dynamic linker. `WEAK` is the same as `GLOBAL` but the link priority is lower, while `LOCAL` means the symbol should not be exported. As far as I can tell, when it finds `LOCAL` it continues the search whereas with `WEAK` it stops earlier because technically it has found an exported symbol. I checked on openSUSE 13.1 (x86_64 and powerpc64) and I have the same {{{NEEDED}}} for libc.so. {{{environ}}} is a {{{WEAK}}} symbol in my libc.so, too. Here is my libc.so.6 on powerpc64: {{{ 00000000001d7ce0 0000056600000026 R_PPC64_ADDR64 00000000001da1f0 __environ + 0 00000000001d7d00 0000056600000026 R_PPC64_ADDR64 00000000001da1f0 __environ + 0 00000000001d7ee8 0000056600000026 R_PPC64_ADDR64 00000000001da1f0 __environ + 0 00000000001d7ef0 0000056600000026 R_PPC64_ADDR64 00000000001da1f0 __environ + 0 00000000001d8018 0000056600000026 R_PPC64_ADDR64 00000000001da1f0 __environ + 0 00000000001d84a0 0000056600000026 R_PPC64_ADDR64 00000000001da1f0 __environ + 0 00000000001d84a8 0000056600000026 R_PPC64_ADDR64 00000000001da1f0 __environ + 0 00000000001d84b0 0000056600000026 R_PPC64_ADDR64 00000000001da1f0 __environ + 0 00000000001d8570 0000056600000026 R_PPC64_ADDR64 00000000001da1f0 __environ + 0 00000000001d8928 0000056600000026 R_PPC64_ADDR64 00000000001da1f0 __environ + 0 00000000001d81e8 0000013100000026 R_PPC64_ADDR64 00000000001da1f0 _environ + 0 305: 00000000001da1f0 8 OBJECT WEAK DEFAULT 32 _environ@@GLIBC_2.3 1026: 00000000001da1f0 8 OBJECT WEAK DEFAULT 32 environ@@GLIBC_2.3 1382: 00000000001da1f0 8 OBJECT GLOBAL DEFAULT 32 __environ@@GLIBC_2.3 178: 00000000001d8fa8 8 OBJECT LOCAL DEFAULT 32 last_environ 2904: 00000000001c9628 1436 FUNC LOCAL DEFAULT 28 __add_to_environ 4138: 00000000001da1f0 8 OBJECT WEAK DEFAULT 32 _environ 4843: 00000000001da1f0 8 OBJECT GLOBAL DEFAULT 32 __environ 4957: 00000000001da1f0 8 OBJECT WEAK DEFAULT 32 environ }}} On x86_64 it looks similar to comment [comment:5] except the line with environ.c is missing. Do openSUSE patch their system linker? I'll go ask on their mailing list and report back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 1 12:00:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 May 2014 12:00:34 -0000 Subject: [GHC] #8972: Investigate adding fast compare-and-swap Int type/primops In-Reply-To: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> References: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> Message-ID: <059.fb1fd0fc93f8674ad638e587a4b70efd@haskell.org> #8972: Investigate adding fast compare-and-swap Int type/primops -------------------------------------+------------------------------------ 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: #8157, #7883 -------------------------------------+------------------------------------ Changes (by hvr): * related: 8157, 7883 => #8157, #7883 * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 1 12:32:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 May 2014 12:32:06 -0000 Subject: [GHC] #9061: Warnings for redundant imports doesn't take name shadowing into account (Regression) Message-ID: <047.b503cfbcf30b76a6eb3638265399e795@haskell.org> #9061: Warnings for redundant imports doesn't take name shadowing into account (Regression) -------------------------+------------------------------------------------- Reporter: | Owner: bergmark | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Reproduction: {{{ module Log where import Prelude hiding (log) f :: () f = log where log = () }}} Compiling this with -Wall On GHC 7.8.2: {{{ > ghc Log.hs -Wall [1 of 1] Compiling Log ( Log.hs, Log.o ) Log.hs:3:1: Warning: The import of ?Prelude? is redundant except perhaps to import instances from ?Prelude? To import instances alone, use: import Prelude() }}} The suggestion is incorrect since removing the import statement gives the following warning: {{{ Log.hs:4:15: Warning: This binding for ?log? shadows the existing binding imported from ?Prelude? at Log.hs:1:8-10 (and originally defined in ?GHC.Float?) }}} On GHC 7.6.3 the Reproduction does not give any warnings (which is correct). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 1 13:10:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 May 2014 13:10:57 -0000 Subject: [GHC] #9038: Foreign calls don't make their arguments look strict In-Reply-To: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> References: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> Message-ID: <059.a98b338279d0a3bafc2048f0214d4400@haskell.org> #9038: Foreign calls don't make their arguments look strict -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 1592 -------------------------------------+------------------------------------ Comment (by tibbe): Here's a trivially simple example: Test.hs: {{{ {-# LANGUAGE BangPatterns #-} module Test ( f ) where f :: Int -> IO () f !val = do cFunction1 cFunction2 val foreign import ccall unsafe "function1" cFunction1 :: IO () foreign import ccall unsafe "function2" cFunction2 :: Int -> IO () }}} Compile with: {{{ ghc -c -O2 -ddump-simpl Test.hs }}} Here's the core: {{{ f1 :: Int -> State# RealWorld -> (# State# RealWorld, () #) f1 = \ (val_aeK :: Int) (eta_B1 :: State# RealWorld) -> case val_aeK of _ { I# ipv_sfl -> case {__pkg_ccall main function1 State# RealWorld -> (# State# RealWorld #)}_df8 eta_B1 of _ { (# ds_df6 #) -> case {__pkg_ccall main function2 Int# -> State# RealWorld -> (# State# RealWorld #)}_df4 ipv_sfl ds_df6 of _ { (# ds1_df2 #) -> (# ds1_df2, () #) } } } f :: Int -> IO () f = f1 `cast` ... }}} Adding the bang pattern has one effect: the argument gets unboxed earlier. It doesn't make the function take an unboxed argument however (i.e. there's no worker-wrapper). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 1 14:14:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 May 2014 14:14:51 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.2af9ee453615263a8cac282647e51285@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): Simon Marlow's response is this: "Compile your program with `-prof`, run with `+RTS -xc`" and you'll get exactly the backtrace you want". You have to compile a profiled version of the packages you install, but you can do that by adding `--enable-pofiling` to Cabal, and you can put that in your `~/.cabal` file. Doesn't that do it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 1 16:08:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 May 2014 16:08:32 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.91f9d54180df5b4f53950b0f12a59857@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 nh2): Not really. In my view giving this kind of good error message really doesn't have to do much with ''profiling''. Sure, profiling currently improves error messages, but ideally (and practically) I don't want to compile with profiling to get a very orthogonal feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 1 16:56:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 May 2014 16:56:56 -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.a3330615282c7a4ab2ed025b4b121d28@haskell.org> #8933: process007: internal error: checkStackFrame: weird activation record found on stack ----------------------------------+------------------------------------ Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: ppc 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 trommler): * status: infoneeded => closed * resolution: => fixed Comment: Test process007 passes with tip of ghc-7.8 branch on powerpc64, too. Thanks for the fix Simon M! Closing the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 1 17:04:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 May 2014 17:04:03 -0000 Subject: [GHC] #9021: [CID43168] rts/linker.c has a memory leak in the dlopen/dlerror code In-Reply-To: <046.338d06ed46ba2865fda90272f333c349@haskell.org> References: <046.338d06ed46ba2865fda90272f333c349@haskell.org> Message-ID: <061.474637d18a7192cd3514cc613a374de1@haskell.org> #9021: [CID43168] rts/linker.c has a memory leak in the dlopen/dlerror code -------------------------------------+------------------------------------- Reporter: hgolden | Owner: hgolden Type: bug | Status: patch Priority: low | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: linker, memory Operating System: POSIX | leak, coverity Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Changes (by hgolden): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 1 17:04:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 May 2014 17:04:50 -0000 Subject: [GHC] #9021: [CID43168] rts/linker.c has a memory leak in the dlopen/dlerror code In-Reply-To: <046.338d06ed46ba2865fda90272f333c349@haskell.org> References: <046.338d06ed46ba2865fda90272f333c349@haskell.org> Message-ID: <061.f468bc9c08f2633b3f490507b732a1ab@haskell.org> #9021: [CID43168] rts/linker.c has a memory leak in the dlopen/dlerror code -------------------------------------+------------------------------------- Reporter: hgolden | Owner: simonmar Type: bug | Status: patch Priority: low | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: linker, memory Operating System: POSIX | leak, coverity Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Changes (by hgolden): * owner: hgolden => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 1 21:33:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 May 2014 21:33:53 -0000 Subject: [GHC] #9050: Panic when compiling cmm file together with -outputdir In-Reply-To: <044.0c851e057b25561ca3c3a92b801901b3@haskell.org> References: <044.0c851e057b25561ca3c3a92b801901b3@haskell.org> Message-ID: <059.2181f306f6aba00e8133464a4a391424@haskell.org> #9050: Panic when compiling cmm file together with -outputdir ---------------------------------------+----------------------------------- Reporter: Yuras | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 Yuras): * status: new => patch Comment: This issue is a bit annoying for me. I'm working with manually written cmm files, and I'm using -outputdir option a lot. I tried to replace the `panic` with dummy module, and it works. But I'm a bit concerned about module name clashes. Instead I removed the code that forces the thunk, ghc doesn't support compiling external core anyway. Probably it is better to replace `Module` with `Maybe Module` to be explicit, but it leads to a huge diff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 1 21:37:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 May 2014 21:37:33 -0000 Subject: [GHC] #8996: mark more things as const in C codegen In-Reply-To: <045.8247ddb295df41a75076302911e81bc2@haskell.org> References: <045.8247ddb295df41a75076302911e81bc2@haskell.org> Message-ID: <060.6c80bfe42f4140a1a14494005f4561af@haskell.org> #8996: mark more things as const in C codegen ---------------------------------------+----------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.8.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 simonmar): I think the comment dates back to when we used to figure out what was static data by knowing the boundaries of sections. We haven't done that for a long time, so the comment is out of date. Let's kill it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 1 23:46:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 May 2014 23:46:01 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.3b52e513bd5cf6fadeb15b9a17485965@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 carter): am i correct in understanding that the current state of things is a) the best option for now is to build with profiling? b) the feature request will be subsumed by the work on stacktraces thats (hopefully slated) for ghc 7.10? (or is there some nuance i'm missing?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 2 01:34:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 May 2014 01:34:38 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.b3f0682990ed206abc42da39312a46d7@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 nh2): @carter a) I believe so. b) I do not know much about the stacktraces work, but as with profiling, these kind of run-time things still seem very orthogonal to embedding a source location into an error string. Of course ''any'' form of better error messages is very appreciated, just not sure if these should be treated as the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 2 03:05:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 May 2014 03:05:25 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.3682b6aa1319b73a7dedb54073a74bf7@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------ Reporter: GregWeber | 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 GregWeber): So next week took over 4 months, but I am going to try to do this during the hackathon 2 weeks from now. Nathaniel Howell me about a -ddump-to-file flag. It doesn't seem to work with -ddump-splices or -ddump-tc, but Nate told be I should be looking into {{{ TcRnMonad.dumpTcRn should call ErrUtils.dumpIfSet_dyn }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 2 18:49:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 May 2014 18:49:23 -0000 Subject: [GHC] #9063: Default associated type instances are too general In-Reply-To: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> References: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> Message-ID: <062.b9e80d9b6f72d854c9f302a73ec4e5e5@haskell.org> #9063: Default associated type instances are too general -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): This problem also exists for instances, possibly leading to spurious overlapping instance errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 2 08:15:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 May 2014 08:15:48 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.2c56b686e7a296496a8f3f4ae9cd4e68@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): I've revised [wiki:ExplicitCallStack] to discuss alternatives. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 2 10:40:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 May 2014 10:40:06 -0000 Subject: [GHC] #9038: Foreign calls don't make their arguments look strict In-Reply-To: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> References: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> Message-ID: <059.e4b5e2299f0864f7c6a6424fe1c78088@haskell.org> #9038: Foreign calls don't make their arguments look strict -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 1592 -------------------------------------+------------------------------------ Comment (by simonpj): Are you sure? I get this: {{{ simonpj at cam-05-unx:~/tmp$ ghc -c -O -ddump-simpl T9038.hs ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 20, types: 28, coercions: 5} T9038.f1 :: GHC.Types.Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType , Unf=Unf{Src=InlineStable, TopLvl=True, Arity=2, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=False) Tmpl= \ (val_arX [Occ=Once!] :: GHC.Types.Int) (eta_B1 [Occ=Once] :: GHC.Prim.State# GHC.Prim.RealWorld) -> case val_arX of _ [Occ=Dead] { GHC.Types.I# ipv_sKN [Occ=Once] -> case {__pkg_ccall main function1 GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld #)}_dKB eta_B1 of _ [Occ=Dead] { (# ds_dKz [Occ=Once] #) -> case {__pkg_ccall main function2 GHC.Prim.Int# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld #)}_dKx ipv_sKN ds_dKz of _ [Occ=Dead] { (# ds1_dKv [Occ=Once] #) -> (# ds1_dKv, GHC.Tuple.() #) } } }}] T9038.f1 = \ (val_arX :: GHC.Types.Int) (eta_B1 :: GHC.Prim.State# GHC.Prim.RealWorld) -> case val_arX of _ [Occ=Dead] { GHC.Types.I# ipv_sKN -> case {__pkg_ccall main function1 GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld #)}_dKB eta_B1 of _ [Occ=Dead] { (# ds_dKz #) -> case {__pkg_ccall main function2 GHC.Prim.Int# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld #)}_dKx ipv_sKN ds_dKz of _ [Occ=Dead] { (# ds1_dKv #) -> (# ds1_dKv, GHC.Tuple.() #) } } } T9038.f :: GHC.Types.Int -> GHC.Types.IO () [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType , Unf=Unf{Src=InlineStable, TopLvl=True, Arity=0, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True) Tmpl= T9038.f1 `cast` (_R -> Sym (GHC.Types.NTCo:IO[0] <()>_R) :: (GHC.Types.Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #)) ~# (GHC.Types.Int -> GHC.Types.IO ()))}] T9038.f = T9038.f1 `cast` (_R -> Sym (GHC.Types.NTCo:IO[0] <()>_R) :: (GHC.Types.Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #)) ~# (GHC.Types.Int -> GHC.Types.IO ())) simonpj at cam-05-unx:~/tmp$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.2 simonpj at cam-05-unx:~/tmp$ cat T9038.hs {-# LANGUAGE BangPatterns #-} module T9038 ( f ) where f :: Int -> IO () f !val = do cFunction1 cFunction2 val foreign import ccall unsafe "function1" cFunction1 :: IO () foreign import ccall unsafe "function2" cFunction2 :: Int -> IO () }}} So GHC has decided that the function is small enough to inline bodily (rather than do w/w). But the inlining is there all right, and the strictness info. I'm puzzled about why you get different results with GHC 7.8.2. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 2 17:57:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 May 2014 17:57:27 -0000 Subject: [GHC] #9063: Default associated type instances are too general Message-ID: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> #9063: Default associated type instances are too general ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I compile the following with `-ddump-tc` and `-fprint-explicit-kinds`: {{{ {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies, TypeOperators, UndecidableInstances #-} module Bug where import Data.Type.Equality import Data.Proxy class kproxy ~ 'KProxy => PEq (kproxy :: KProxy a) where type (:==) (x :: a) (y :: a) :: Bool type x :== y = x == y }}} and I see {{{ TYPE SIGNATURES TYPE CONSTRUCTORS PEq :: forall (a :: BOX). KProxy a -> Constraint class (~) (KProxy a) kproxy (KProxy a) => PEq (a::BOX) (kproxy::KProxy a) Roles: [nominal, nominal] RecFlag NonRecursive type family (:==) (a::BOX) (x::a) (y::a) :: Bool (open) Defaults: [(k, BOX), (x, k), (y, k)] k x y = (==) k x y COERCION AXIOMS axiom Bug.NTCo:PEq :: PEq a kproxy = (~) (KProxy a) kproxy ('KProxy a) }}} The problem is the `Defaults:` line. That `k` should be an `a`. This is not a printing/tidying problem -- the default does not work when it should. For example, if I add the following {{{ instance PEq ('KProxy :: KProxy Bool) foo :: Proxy (True :== True) -> Proxy (True == True) foo = id }}} I get {{{ Couldn't match type ?(:==) Bool 'True 'True? with ?'True? Expected type: Proxy Bool ((:==) Bool 'True 'True) -> Proxy Bool ((==) Bool 'True 'True) Actual type: Proxy Bool 'True -> Proxy Bool 'True In the expression: id In an equation for ?foo?: foo = id }}} Adding kind signatures (that is `:: a`) to the arguments of the type family default fixes the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 2 18:02:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 May 2014 18:02:58 -0000 Subject: [GHC] #9064: Support default class method signatures in Template Haskell Message-ID: <047.e88ba6dee52425f96ee400d414e6b173@haskell.org> #9064: Support default class method signatures in Template Haskell ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.2 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 {{{ blah = [d| class C a where foo :: a -> String default foo :: Show a => a -> String foo = show |] }}} I get {{{ Illegal default signature for ?[foo]? Default signatures are not supported by Template Haskell }}} I would like this feature. I will implement this in due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 2 13:26:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 May 2014 13:26:46 -0000 Subject: [GHC] #8972: Investigate adding fast compare-and-swap Int type/primops In-Reply-To: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> References: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> Message-ID: <059.49952127201ee295374fbfab5e8b823d@haskell.org> #8972: Investigate adding fast compare-and-swap Int type/primops -------------------------------------+------------------------------------ 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: #8157, #7883 -------------------------------------+------------------------------------ Comment (by nominolo): Replying to [comment:6 rrnewton]: > I suspect the problem with atomicModifyIORef's poor behavior may have to do with blackholes? Tracing ghc events will perturb these workloads a bunch I guess, but maybe threadscope could still tell us something wrt blackhole events. We were affected by this issue and looked at the thread status of all threads and noticed that they all get blocked on a blackhole. We suspect there are two issues here: 1. Poor cache behaviour due to the CAS retry busy loop. 2. All the threads get queued up waiting for the thread that currently owns the blackhole to get scheduled again. The second point is a potential issue for many other applications (e.g,. if a thread is holding on to an MVar). In the operating system world they deal with those kinds of issues either using: - interrupt blocking: i.e., a thread cannot be de-scheduled while holding the lock - time-slice donation / priority boosting: If a thread enters a critical section and still has some alotted compute time left, it "donates" that time to the thread owning the critical section, so that it will make progress and leave the critical section. If you have thread priorities then you can temporarily raise the priority of the thread in the critical section. This rather complicated because priority boosting may have to be recursive (you have to boost to the priority of the highest-priority thread waiting), so not everyone likes this method. For GHC, I think it could be useful to have both mechanisms available. Marking a thread as non-interruptable could be exported from a "Here be dragons" module for using when you know that a thread will hold a lock/MVar only for a very short time. For thunks, when a thread blocks on a blackhole, the scheduler should probably then schedule that thread next. This way, the time spent evaluating a blackhole will be proportional to the number of threads waiting on it. I don't know if the reduced fairness causes issues here, though. You could mark a blackhole as "boosted" meaning, that as soon the blackhole is updated we not just wake up all threads in the run-queue, but also yield to the first thread in the blackhole. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 2 11:11:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 May 2014 11:11:29 -0000 Subject: [GHC] #9061: Warnings for redundant imports doesn't take name shadowing into account (Regression) In-Reply-To: <047.b503cfbcf30b76a6eb3638265399e795@haskell.org> References: <047.b503cfbcf30b76a6eb3638265399e795@haskell.org> Message-ID: <062.854c75364a73ac3307f7aa015c313ff1@haskell.org> #9061: Warnings for redundant imports doesn't take name shadowing into account (Regression) -------------------------------------------------+------------------------- Reporter: bergmark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): Ah yes, thank you. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 2 19:38:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 May 2014 19:38:57 -0000 Subject: [GHC] #9065: Segfault in a memory-heavy program Message-ID: <045.86dc56312636a72599585bcd2679dd19@haskell.org> #9065: Segfault in a memory-heavy program ----------------------------------+---------------------------------- Reporter: rotsor | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | 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've got a program compiled with GHC 7.6.3 crashing with "Segmentation fault". It does not crash with GHC 7.8.2 so the bug might have been fixed already. This is the backtrace I'm getting from gdb: {{{ #0 0x00000000004a0450 in alloc_mega_group () #1 0x00000000004a0930 in allocGroup.part.1 () #2 0x00000000004c3c00 in alloc_todo_block () #3 0x00000000004c3d73 in todo_block_full () #4 0x0000000000403df9 in evacuate () #5 0x00000000004051e4 in scavenge_block () #6 0x00000000004bf785 in scavenge_loop () #7 0x00000000004a16c5 in GarbageCollect () #8 0x0000000000499d6f in scheduleDoGC.isra.21 () #9 0x000000000049a81d in scheduleWaitThread () #10 0x000000000049e1be in real_main () #11 0x000000000049e2bc in hs_main () #12 0x0000000000418a8b in main () }}} The problem only triggers when I run the program on large input values: it uses 7Gb of memory and dies after 7 minutes of runtime. The version compiled with 7.8.2 exhibits similar memory usage pattern, but successfully completes within 15 minutes. Compiler command line I use: {{{ ghc -O2 -rtsopts eu468 }}} RTS command line: {{{ ./eu468 +RTS -K1000000000 }}} The program in question is eu468.hs at https://github.com/Rotsor/euler.git. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 2 16:05:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 May 2014 16:05:54 -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.2b890f516f918faff4b24701df10435e@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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 trommler): * status: new => infoneeded Comment: Could you post the output of {{{LD_DEBUG=symbols ./check-environ}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 2 06:43:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 May 2014 06:43:00 -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.12472d33894f3aa83b48fcec2d8ee3c5@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.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by slyfox): * cc: slyfox@? (added) Comment: hoopl/transformers are only used by exported 'ghc' library. To make users load it into, say, ghci you need to export it completely (ghci -package ghc). xhtml used by haddock binary, terminfo/haskeline used by ghc binary (--interactive mode, aka GHCi). Thus they need only dynamic libs, no need to export them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 2 05:38:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 May 2014 05:38:55 -0000 Subject: [GHC] #9062: Role: ~# should be ~R# Message-ID: <044.7f1566c191cb9df0ca4c1915de3a4096@haskell.org> #9062: Role: ~# should be ~R# ------------------------------------+--------------------------------- Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- The following coercion showed up in Core. Richard Eisenberg pointed out that the `~#` should be `~R#`. {{{ _R -> NTCo:Sum[0] _R :: (Tree N0 Int -> Sum Int) ~# (Tree N0 Int -> Int) }}} I can dig up more information if needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 2 19:49:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 May 2014 19:49:31 -0000 Subject: [GHC] #9065: Segfault in a memory-heavy program In-Reply-To: <045.86dc56312636a72599585bcd2679dd19@haskell.org> References: <045.86dc56312636a72599585bcd2679dd19@haskell.org> Message-ID: <060.1a8ea4288c6a2faf63e2599574f1cd3e@haskell.org> #9065: Segfault in a memory-heavy program -----------------------------------+---------------------------------- Reporter: rotsor | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: Probably #7762. I'll close this as a dup, but if it reappears in 7.8+ please open the ticket again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 2 20:05:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 May 2014 20:05:05 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.14c382e495e8aea777fb4244a2a0d654@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonmar): I actually like the wiki:ExplicitCallStack/ImplicitLocations idea, I'm just worried that if we have it then we'll have people who want location- abstracted versions of all the partial functions in base, and that's a lot of extra clutter. If we could provide the feature but draw the line at using it in APIs (except for `error`, `undefined`, `throw`, and other things that explicitly raise exceptions) then I'm all for it. I realise that then you don't get automatic `head []` locations. But it doesn't stop someone from defining their own location-abstracted `head`, or indeed making a package of location-abstracted partial functions from base. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 2 20:56:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 May 2014 20:56:26 -0000 Subject: [GHC] #9066: Template Haskell cannot splice an infix declaration for a data constructor Message-ID: <047.316ce5f75a1c71475de4d088845130df@haskell.org> #9066: Template Haskell cannot splice an infix declaration for a data constructor ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I say {{{ $([d| data Blargh = (:<=>) Int Int infix 4 :<=> |]) }}} I get {{{ Illegal variable name: ?:<=>? When splicing a TH declaration: infix 4 :<=>_0 }}} The code inside the TH quote works when not used with TH. I will fix in due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 3 01:04:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 May 2014 01:04:25 -0000 Subject: [GHC] #9067: Optimize clearNursery by short-circuiting when we get to currentNursery Message-ID: <045.c7f02cf5a52be23a613e87f34c2ef3ee@haskell.org> #9067: Optimize clearNursery by short-circuiting when we get to currentNursery ------------------------------+-------------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.9 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- This is a note to myself so I don't forget about this. Essentially, we can do something like this (this particular patch variant untested): {{{ diff --git a/rts/sm/Storage.c b/rts/sm/Storage.c index 36776b9..0311042 100644 --- a/rts/sm/Storage.c +++ b/rts/sm/Storage.c @@ -598,6 +598,11 @@ clearNursery (Capability *cap) ASSERT(bd->gen_no == 0); ASSERT(bd->gen == g0); IF_DEBUG(sanity,memset(bd->start, 0xaa, BLOCK_SIZE)); + if (bd == cap->r.rCurrentNursery) { + IF_DEBUG(sanity, for (bd = bd->link; bd; bd = bd->link) + ASSERT(bd->free == bd->start)); + break; + } } } } }}} This is due to invariants about how we manage the currentNursery pointer. But we need a note about it, and I need to test it more carefully. This optimization probably doesn't help too much on normal GHC, but when I have lots of nurseries it helps quite a bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 3 07:55:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 May 2014 07:55:55 -0000 Subject: [GHC] #9068: Don't uninstall signal handlers if none were installed Message-ID: <044.7794aa4ce82ed5ecdcf0c07847cdd3ac@haskell.org> #9068: Don't uninstall signal handlers if none were installed --------------------------+------------------------------------------------ Reporter: tomgr | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 Runtime System | Operating System: Windows Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ GHC 7.8.2 calls resetSignalHandlers even when --install-signal-handlers=no is specified. On windows this results in the call to SetConsoleCtrlHandler failing. The attached patch only calls resetSignalHandlers when there are signal handlers to remove (it mirrors the logic used when installing the handlers). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 3 08:47:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 May 2014 08:47:40 -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.8ffdb581efc79096780d51e7b3c311f1@haskell.org> #8819: 64bit Testsuite failures in unregisterised 7.8 RCs ------------------------------------------------+-------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 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): * milestone: => 7.8.3 Comment: Now that #8933 is fixed, here is an update of branch ghc-7.8 on powerpc64: {{{ Unexpected results from: TEST="T4891 joao-circular ghcilink003 ghcilink004 ghcilink006 linker_unload divbyzero T5423 T5435_v_gcc testwsdeque T5435_v_asm T7919 T3424 T7815 T7574 jmp_tbl massive_array rangeTest T8628 ghcApi T8639_api tcrun045 dph-quickhull-vseg-fast dph-quickhull-copy-fast readRun002 T5550 T7702 T3016 T5321FD T5030 T4801 T5631 T783 T5642 T3064 parsing001 T1969 T5321Fun T5837 T8958 safePkg01 T3245 T3586 T3736 annrun01 T6135 T7689 T367 callstack001 dynCompileExpr barton-mangler-bug T5313 haddock.Cabal haddock.compiler haddock.base T7837 hpc_fork integerConversions integerBits cholewo-eval print022 enum01 fixed enum02 showDouble dph- nbody-copy-fast dph-nbody-vseg-fast T7600 cgrun018 T2838 cgrun044 cgrun034 cgrun014 encoding004 num010 num009 andy_cherry qq007 qq008 numrun012 arith014 arith002 arith003 T8726 arith005 arith011 arith004 arith012" }}} There are lots of arithmetic failures and at least all arith* tests are regressions from 7.6.3. Also note the regressions in rts tests since the 7.8 RCs. Setting milestone to 7.8.3 because of those regressions. Here are the details: {{{ Unexpected failures: ../../libraries/base/tests enum01 [bad stdout] (profasm,dyn,profthreaded,optllvm) ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,threaded1) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [bad stdout] (hpc,profasm,dyn,profthreaded,optllvm) ../../libraries/base/tests fixed [bad stdout] (normal,hpc,profasm,threaded1,dyn,profthreaded,optllvm) ../../libraries/base/tests fixed [bad stdout or stderr] (ghci) ../../libraries/base/tests showDouble [bad stdout] (hpc,profasm,dyn,profthreaded,optllvm) ../../libraries/base/tests/IO encoding004 [bad exit code] (threaded1) ../../libraries/base/tests/Numeric num009 [bad stdout] (normal,threaded1) ../../libraries/base/tests/Numeric num009 [bad stdout or stderr] (ghci) ../../libraries/base/tests/Numeric num010 [bad stdout] (normal,hpc,profasm,threaded1,dyn,profthreaded,optllvm) ../../libraries/base/tests/Numeric num010 [bad stdout or stderr] (ghci) ../../libraries/hpc/tests/fork hpc_fork [bad heap profile] (profasm) ../../libraries/random/tests rangeTest [bad exit code] (normal,ghci,threaded1,dyn,profthreaded,optllvm) ../../libraries/random/tests rangeTest [exit code non-0] (hpc,profasm) annotations/should_run annrun01 [exit code non-0] (optllvm) codeGen/should_compile T7574 [stderr mismatch] (normal,hpc,profasm) codeGen/should_compile jmp_tbl [exit code non-0] (optllvm) codeGen/should_compile massive_array [exit code non-0] (optllvm) codeGen/should_run T2838 [bad stdout] (normal,hpc,profasm,threaded1,dyn,profthreaded,optllvm,g1) codeGen/should_run T7600 [bad stdout] (normal,hpc,profasm,threaded1,dyn,profthreaded,optllvm,g1) codeGen/should_run T7600 [bad stdout or stderr] (ghci) codeGen/should_run cgrun014 [bad stdout] (hpc,profasm,dyn,profthreaded,optllvm) codeGen/should_run cgrun018 [bad stdout] (hpc,dyn,optllvm) codeGen/should_run cgrun034 [bad exit code] (hpc,profasm,dyn,profthreaded,optllvm) codeGen/should_run cgrun044 [bad stdout] (hpc,profasm,dyn,profthreaded,optllvm) concurrent/should_run T367 [bad exit code] (profasm,profthreaded) dph/nbody dph-nbody-copy-fast [exit code non-0] (normal,threaded1) dph/nbody dph-nbody-vseg-fast [exit code non-0] (normal,threaded1) dph/quickhull dph-quickhull-copy-fast [exit code non-0] (normal,threaded1) dph/quickhull dph-quickhull-vseg-fast [exit code non-0] (normal,threaded1) driver T5313 [bad exit code] (normal,hpc,profasm,threaded1,profthreaded,optllvm) ghc-api T8628 [bad exit code] (normal) ghc-api T8639_api [bad exit code] (normal) ghc-api ghcApi [exit code non-0] (normal) ghc-api/T4891 T4891 [bad exit code] (normal) ghc-api/dynCompileExpr dynCompileExpr [bad exit code] (normal,hpc,threaded1,optllvm) ghci.debugger/scripts print022 [bad stdout] (ghci) ghci/linking ghcilink003 [bad exit code] (normal) ghci/linking ghcilink004 [bad exit code] (normal) ghci/linking ghcilink006 [bad exit code] (normal) indexed-types/should_compile T7837 [stderr mismatch] (profasm) lib/integer integerBits [bad stdout] (normal,hpc,profasm,threaded1,dyn,profthreaded,optllvm) lib/integer integerBits [bad stdout or stderr] (ghci) lib/integer integerConversions [bad stdout] (normal,hpc,profasm,threaded1,dyn,profthreaded,optllvm) lib/integer integerConversions [bad stdout or stderr] (ghci) numeric/should_run T8726 [bad exit code] (normal,hpc,profasm,ghci,threaded1,dyn,profthreaded,optllvm) numeric/should_run arith002 [bad stdout] (normal,hpc,profasm,threaded1,dyn,profthreaded,optllvm) numeric/should_run arith002 [bad stdout or stderr] (ghci) numeric/should_run arith003 [bad stdout] (normal,hpc,profasm,threaded1,dyn,profthreaded,optllvm) numeric/should_run arith003 [bad stdout or stderr] (ghci) numeric/should_run arith004 [bad stdout] (normal,hpc,profasm,threaded1,dyn,profthreaded,optllvm) numeric/should_run arith004 [bad stdout or stderr] (ghci) numeric/should_run arith005 [bad stdout] (normal,hpc,profasm,threaded1,dyn,profthreaded,optllvm) numeric/should_run arith005 [bad stdout or stderr] (ghci) numeric/should_run arith011 [bad stdout] (normal,hpc,threaded1,dyn,optllvm) numeric/should_run arith011 [exit code non-0] (profasm,profthreaded) numeric/should_run arith011 [bad stdout or stderr] (ghci) numeric/should_run arith012 [bad stdout] (normal,hpc,profasm,threaded1,dyn,profthreaded,optllvm) numeric/should_run arith012 [bad stdout or stderr] (ghci) numeric/should_run arith014 [bad stdout] (normal,hpc,profasm,threaded1,dyn,profthreaded,optllvm) numeric/should_run arith014 [bad stdout or stderr] (ghci) numeric/should_run numrun012 [bad stdout] (hpc,profasm,dyn,profthreaded,optllvm) parser/should_run readRun002 [bad stdout] (normal,hpc,profasm,threaded1,dyn,profthreaded,optllvm) parser/should_run readRun002 [bad stdout or stderr] (ghci) perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [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 T783 [stat not good enough] (normal) perf/compiler parsing001 [stat not good enough] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) perf/should_run T3245 [bad stdout or stderr] (ghci) perf/should_run T3586 [exit code non-0] (normal) perf/should_run T3736 [bad stderr] (normal) primops/should_run T6135 [bad stdout] (hpc,profasm,dyn,profthreaded,optllvm) primops/should_run T7689 [bad stdout] (hpc,profasm,dyn,profthreaded,optllvm) profiling/should_run callstack001 [bad stdout] (prof) programs/andy_cherry andy_cherry [exit code non-0] (hpc,profasm,dyn,profthreaded,optllvm) programs/barton-mangler-bug barton-mangler-bug [exit code non-0] (normal,hpc,profasm,threaded1,dyn,profthreaded,optllvm) programs/cholewo-eval cholewo-eval [bad stdout] (hpc,profasm,dyn,profthreaded,optllvm) programs/joao-circular joao-circular [exit code non-0] (normal,hpc,profasm,threaded1,dyn,profthreaded,optllvm) quasiquotation/qq007 qq007 [exit code non-0] (profasm) quasiquotation/qq008 qq008 [exit code non-0] (profasm) roles/should_compile T8958 [stderr mismatch] (normal) rts T3424 [exit code non-0] (normal,threaded1) rts T5423 [bad stderr] (normal) rts T5435_v_asm [bad exit code] (normal) rts T5435_v_gcc [bad exit code] (normal) rts T7815 [bad exit code] (threaded1) rts T7919 [bad exit code] (threaded1) rts T7919 [exit code non-0] (hpc,profasm,dyn,profthreaded,optllvm) rts divbyzero [bad exit code] (normal,hpc,profasm,ghci,threaded1,dyn,profthreaded,optllvm) rts linker_unload [bad exit code] (normal) rts testwsdeque [bad exit code] (threaded1) safeHaskell/check/pkg01 safePkg01 [bad stderr] (normal) simplCore/should_compile T3016 [exit code non-0] (hpc,profasm,optllvm) simplCore/should_compile T5550 [exit code non-0] (profasm) simplCore/should_compile T7702 [stat not good enough] (hpc) simplCore/should_compile T7702 [stat too good] (optllvm) simplCore/should_compile T7702 [exit code non-0] (profasm) typecheck/should_run tcrun045 [exit code non-0] (normal,hpc,profasm,threaded1,dyn,profthreaded,optllvm) typecheck/should_run tcrun045 [bad stdout or stderr] (ghci) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 3 11:46:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 May 2014 11:46:15 -0000 Subject: [GHC] #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable Message-ID: <054.98121a1976ff390c1bc22f999087be97@haskell.org> #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable ------------------------------------+------------------------------------- Reporter: sjoerd_visscher | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In the discussion in #2953 it was concluded that it would be best to have separate flags for deriving Functor, Foldable and Traversable. I agree with that conclusion, but it seems that it wasn't considered to have -XDeriveTraversable imply -XDeriveFunctor and -XDeriveFoldable. I can't think of a reason not to want that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 3 14:29:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 May 2014 14:29:05 -0000 Subject: [GHC] #9070: "Simplifier ticks exhausted" Message-ID: <048.992ee320aaea58308e183d3ff9448d87@haskell.org> #9070: "Simplifier ticks exhausted" ----------------------------------+------------------------------------- Reporter: dermesser | 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 know nothing more than what GHC said (I'm on debian, installed from the repositories). {{{ (GHC version 7.6.3 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone base:GHC.Base.$fMonadIO_$c>>={v rJ2} [gid] 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: 31764 }}} The code triggering the error is the code commented out in lines 52-54: {{{ 42 redis_family_raw <- getEnv redisFamilyVar 43 redis_addr <- getEnv redisAddressVar 44 redis_port <- getEnv redisPortVar 45 46 (family,redis_family) <- case (parseFamily family_raw,parseFamily redis_family_raw) of 47 (Just fam, Just rfam) -> return (fam,rfam) 48 x -> fail $ "Unknown address family: " ++ show x 49 50 sockaddr <- getSockAddr family broker_address broker_port_raw 51 52 --redis_conn <- case redis_family of 53 -- WAFamilyInet -> R.connect $ defaultConnectInfo { connectHost = redis_addr, connectPort = Service redis_port } 54 -- WAFamilyUnix -> R.connect $ defaultConnectInfo { connectPort = UnixSocket redis_addr } }}} However, this bug occurs only when compiling with cabal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 3 16:59:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 May 2014 16:59:45 -0000 Subject: [GHC] #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module Message-ID: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module -----------------------------------+--------------------------------------- Reporter: bens | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- == Mu in the same file == ''src/Main.hs'' {{{ {-# LANGUAGE DeriveFunctor #-} module Main where newtype Mu f = Mu (f (Mu f)) newtype K a b = K a newtype F a = F (Mu (K a)) deriving Functor main :: IO () main = return () }}} ---- {{{ $ cabal build Building panic-0.1.0.0... Preprocessing executable 'panic' for panic-0.1.0.0... [1 of 1] Compiling Main ( src/Main.hs, dist/build/panic/panic- tmp/Main.o ) src/Main.hs:7:37: No instance for (Functor Mu) arising from the first field of ?F? (type ?Mu (K a)?) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Functor F) }}} == Mu in a separate file == ''src/Mu.hs'' {{{ module Mu where newtype Mu f = Mu (f (Mu f)) }}} ''src/Main.hs'' {{{ {-# LANGUAGE DeriveFunctor #-} module Main where import Mu newtype K a b = K a newtype F a = F (Mu (K a)) deriving Functor main :: IO () main = return () }}} ---- {{{ $ cabal build Building panic-0.1.0.0... Preprocessing executable 'panic' for panic-0.1.0.0... [1 of 2] Compiling Mu ( src/Mu.hs, dist/build/panic/panic- tmp/Mu.o ) [2 of 2] Compiling Main ( src/Main.hs, dist/build/panic/panic- tmp/Main.o ) src/Main.hs:8:37:ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Prelude.(!!): index too large 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 Sat May 3 19:07:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 May 2014 19:07:48 -0000 Subject: [GHC] #9072: RankNTypes composition now requires ImpredicativeTypes Message-ID: <046.967894a9b8d693d100d00fd5d2992bdd@haskell.org> #9072: RankNTypes composition now requires ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: gelisam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{ {-# LANGUAGE RankNTypes #-} instantiateId :: (forall a. a -> a) -> Int -> Int instantiateId f = f passes :: [Int] -> [Int] passes = map (instantiateId id) -- Couldn't match type ?a0 -> a0? with ?forall a. a -> a? fails :: [Int] -> [Int] fails = (map . instantiateId) id }}} works with ghc 7.6, fails with ghc 7.8, works with ghc 7.8 + `ImpredicativeTypes`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 3 19:45:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 May 2014 19:45:20 -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.8f8de020460ccffd2995c8dc5035528b@haskell.org> #8819: 64bit Testsuite failures in unregisterised 7.8 RCs ------------------------------------------------+-------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 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: ------------------------------------------------+-------------------------- Comment (by trommler): Here are the test failures for x86_64 unregisterised: {{{ Unexpected results from: TEST="T4891 T5423 T7815 T7919 T7574 T8639_api tcrun045 readRun002 T5550 T3016 T7702 T1969 T783 T8958 safePkg01 T3736 T6135 T7689 T367 callstack001 andy_cherry barton-mangler-bug T5313 T7837 integerConversions integerBits cholewo-eval enum01 fixed enum02 showDouble cgrun018 cgrun034 cgrun044 cgrun014 T2838 num010 num009 memcpy-unroll-conprop memcpy memcpy-unroll qq007 qq008 numrun012 arith014 arith002 arith003 T8726 arith005 arith011 arith004 arith012" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 4 01:37:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 May 2014 01:37:04 -0000 Subject: [GHC] #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module In-Reply-To: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> References: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> Message-ID: <058.567f0534d0d2867b82b918dec951a76f@haskell.org> #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module ---------------------------------------+----------------------------------- Reporter: bens | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 bens): It also crashes when running ghc directly, as in `ghc --make -isrc src/Main.hs` with any level of optimisation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 4 01:39:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 May 2014 01:39:00 -0000 Subject: [GHC] #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module In-Reply-To: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> References: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> Message-ID: <058.02b542b5b8dd98888530a88a6166d6e6@haskell.org> #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module ---------------------------------------+----------------------------------- Reporter: bens | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 bens): * cc: ben.d.sinclair@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 4 01:43:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 May 2014 01:43:36 -0000 Subject: [GHC] #9073: small SPECIALIZE INLINE program taking gigabytes of memory to compile Message-ID: <044.c7df3af78adcc74c7d6499ca7d538f54@haskell.org> #9073: small SPECIALIZE INLINE program taking gigabytes of memory to compile -------------------------+------------------------------------------------- Reporter: dagit | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.8.2 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- I have a small program that is taking 1+ GB of memory to compile. I've distilled the troublesome input down to the following: {{{ {-# LANGUAGE BangPatterns #-} import Data.Vector knot :: Vector Double -> Int -> Double knot vs k = vs ! idx0 where !idx0 = abs k `mod` 16 {-# SPECIALIZE INLINE knot :: Vector Double -> Int -> Double #-} noise :: Vector Double -> Int -> Double noise vs k = knot vs k + knot vs k + knot vs k + knot vs k + knot vs k + knot vs k + knot vs k + knot vs k }}} Compiled with `ghc -fprof-auto -prof -O2 -Wall`. As far as I can tell, prof-auto, prof, and optimizations of at least -O1 are required to trigger it. I'm using ghc-7.8.2 64bit for Windows. vector is version 0.10.9.1 (currently the latest on hackage). Same code worked fine on ghc 7.6.2. Also worth noting: Even though the `SPECIALIZE` isn't needed, if you remove the `SPECIALIZE` or the `INLINE` the problem goes away. If you remove even one of the duplicated calls to `knot vs k` in the body of `noise` then the amount of memory required drops dramatically. Add more to increase the requirements. I've been able to push it up around 10 GB, but I don't have enough memory to test beyond that! Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 4 02:35:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 May 2014 02:35:58 -0000 Subject: [GHC] #9073: small SPECIALIZE INLINE program taking gigabytes of memory to compile In-Reply-To: <044.c7df3af78adcc74c7d6499ca7d538f54@haskell.org> References: <044.c7df3af78adcc74c7d6499ca7d538f54@haskell.org> Message-ID: <059.0664cb66c0bea912aa6d3f10d5a6fc46@haskell.org> #9073: small SPECIALIZE INLINE program taking gigabytes of memory to compile -------------------------------------------------+------------------------- Reporter: dagit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by dagit): Adding `-fno-full-laziness` makes the problem go away (that is, the memory usage goes back to normal). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 4 02:40:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 May 2014 02:40:17 -0000 Subject: [GHC] #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files Message-ID: <048.42d4a7f7acd8ddc9572d2421e0cac286@haskell.org> #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files ------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I have a package that bundles in C library sources. I never had a problem with this when using GHC 7.6. In GHC 7.8, the order of the c-sources in the cabal file now matters. Sources must be listed earlier if they have symbols that subsequently loaded object files will need. If the c-sources are in the wrong order, when running "cabal repl" I get Loading object (static) dist/build/decnumber/src/decQuad.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc14294_0/ghc14294_1.so: undefined symbol: DECSTICKYTAB Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug When using the same code and cabal file with GHC 7.6, "cabal repl" works fine: GHCi loads each static object (regardless of ordering in the cabal file), links up the necessary symbols, and launches successfully. Haskell Cafe discussion here: http://www.haskell.org/pipermail/haskell-cafe/2014-May/114041.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 4 04:12:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 May 2014 04:12:24 -0000 Subject: [GHC] #703: all binaries built by ghc have executable stacks In-Reply-To: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> References: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> Message-ID: <060.af769b9c9d69ad3c49ec92962510bfd0@haskell.org> #703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: ezyang Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): Jens reported to me that 7.8 appears to fix the problem on 64-bit as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 4 08:02:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 May 2014 08:02:51 -0000 Subject: [GHC] #9075: Per-thread weak pointer list (remove global lock on mkWeak#) Message-ID: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> #9075: Per-thread weak pointer list (remove global lock on mkWeak#) ------------------------------+-------------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.9 System | Operating System: Unknown/Multiple Keywords: easy | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Currently, we have to take out the storage manager lock when a weak pointer is allocated. If you're making a lot of weak pointers, this could become a bottleneck. We should maintain a per-thread weak pointer list per generation, so that we don't have to take out a lock. Marking priority as low since I don't think anyone actually is trying to allocate tons of weak pointers on multiple threads, but I think this optimization should be relatively cheap. Probably a good starter ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 4 09:03:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 May 2014 09:03:22 -0000 Subject: [GHC] #9076: GHC.Exts docs don't contain all primops Message-ID: <044.7f5e83fa2b570d1940647f1b6e5da393@haskell.org> #9076: GHC.Exts docs don't contain all primops ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I would expect the docs for `GHC.Exts`: https://www.haskell.org/ghc/docs/7.8.2/html/libraries/base-4.7.0.0/GHC- Exts.html to contain all the primops from `GHC.Prim`: http://hackage.haskell.org/package/ghc-prim-0.3.1.0/docs/GHC-Prim.html as `GHC.Exts` is the recommended module to import the primops from. However, `GHC.Exts` are missing loads of the primops. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 4 10:45:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 May 2014 10:45:37 -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.1887fa8d3f24aebb1d94816ff3cee486@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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): Replying to [comment:12 dagit]: Great, thanks! > {{{ > 5823: symbol=environ; lookup in file=/usr/lib64/libgmp.so [0] > 5823: symbol=environ; lookup in file=/lib64/libc.so.6 [0] > }}} That looks like we have found the reason, why openSUSE behaves differently here: On openSUSE {{{libgmp.so}}} is never checked for {{{environ}}} because {{{ld.so}}} looks in {{{check-environ}}} first. {{{check-environ}}} has symbol {{{environ}}}, because of the {{{extern char** environ;}}} in line 7. According to gABI [http://refspecs.linuxbase.org/elf/gabi4+/ch5.dynamic.html] this is the default behavior. To override that one can set set the flag {{{DF_SYMBOLIC}}} in the shared library's header and I suspect Fedora does that. The behavior is defined as follows in gABI: DF_SYMBOLIC If this flag is set in a shared object library, the dynamic linker's symbol resolution algorithm for references within the library is changed. Instead of starting a symbol search with the executable file, the dynamic linker starts from the shared object itself. If the shared object fails to supply the referenced symbol, the dynamic linker then searches the executable file and other shared objects as usual. Could you post the output of {{{readelf -h /usr/lib64/libgmp.so.10}}} to confirm. Replace 10 with the version on your system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 4 15:43:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 May 2014 15:43:16 -0000 Subject: [GHC] #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable In-Reply-To: <054.98121a1976ff390c1bc22f999087be97@haskell.org> References: <054.98121a1976ff390c1bc22f999087be97@haskell.org> Message-ID: <069.f8d43b87ad086e8a3dcb9e887a15705c@haskell.org> #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable -------------------------------------+------------------------------------ Reporter: sjoerd_visscher | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 sjoerd_visscher): I.e. add this to the `impliedFlags` list: {{{ , (Opt_DeriveTraversable, turnOn, Opt_DeriveFunctor) , (Opt_DeriveTraversable, turnOn, Opt_DeriveFoldable) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 4 18:45:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 May 2014 18:45:06 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.46116046d3c93d825be95e3604b6ee49@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.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 ocharles): * cc: ollie@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 4 19:16:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 May 2014 19:16:04 -0000 Subject: [GHC] #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable In-Reply-To: <054.98121a1976ff390c1bc22f999087be97@haskell.org> References: <054.98121a1976ff390c1bc22f999087be97@haskell.org> Message-ID: <069.37a8fdf5849fbd485c34f165d7f20fab@haskell.org> #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable -------------------------------------+------------------------------------ Reporter: sjoerd_visscher | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 sjoerd_visscher): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 4 19:17:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 May 2014 19:17:33 -0000 Subject: [GHC] #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable In-Reply-To: <054.98121a1976ff390c1bc22f999087be97@haskell.org> References: <054.98121a1976ff390c1bc22f999087be97@haskell.org> Message-ID: <069.4361e091defb24af39b4a6f8eb91a308@haskell.org> #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable -------------------------------------+------------------------------------ Reporter: sjoerd_visscher | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 sjoerd_visscher): Note: this is my first GHC patch! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 4 19:19:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 May 2014 19:19:05 -0000 Subject: [GHC] #9070: "Simplifier ticks exhausted" In-Reply-To: <048.992ee320aaea58308e183d3ff9448d87@haskell.org> References: <048.992ee320aaea58308e183d3ff9448d87@haskell.org> Message-ID: <063.1a36c5f816096990d10cbe05dc3a3b57@haskell.org> #9070: "Simplifier ticks exhausted" -------------------------------------+---------------------------------- Reporter: dermesser | 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 DinoMorelli): I am seeing this now with a project starting with 7.8.2. I haven't seen any bugs here for this 'Simplifier ticks exhausted' problem with 7.8.2, should I start a new ticket? This is on Arch Linux, 64-bit, ghc installed from the standard repositories (from Extra via pacman) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 4 19:26:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 May 2014 19:26:55 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.fa67554bc79aa7203a6255201dc77d84@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.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 acowley): * cc: acowley@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 04:35:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 04:35:13 -0000 Subject: [GHC] #9070: "Simplifier ticks exhausted" In-Reply-To: <048.992ee320aaea58308e183d3ff9448d87@haskell.org> References: <048.992ee320aaea58308e183d3ff9448d87@haskell.org> Message-ID: <063.b3aa68b7aefe31d09edff1cd8bfd3272@haskell.org> #9070: "Simplifier ticks exhausted" -------------------------------------+---------------------------------- Reporter: dermesser | 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 carter): could you provide a link to the full codebase? also could you try building with -fno-full-laziness? (theres a few projects where ghc blows up in 7.8 that are Resolved by building with that flag) is this with O1 or O2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 08:15:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 08:15:49 -0000 Subject: [GHC] #9062: Role: ~# should be ~R# In-Reply-To: <044.7f1566c191cb9df0ca4c1915de3a4096@haskell.org> References: <044.7f1566c191cb9df0ca4c1915de3a4096@haskell.org> Message-ID: <059.6a5f6ae5ca8b243cdd22501c232bee9d@haskell.org> #9062: Role: ~# should be ~R# ---------------------------------+------------------------------------ Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 simonpj): I can't say for sure (would need to reproduce), but I think that a coercion `(co1 -> co2)` is represented by a `TyConAppCo`, which in turn carries a role. So it looks as if the role on that `TyConAppCo` with `(->)` in the type constructor position is plain wrong. Is this with your plugin, or is this plain GHC? How can we reproduce? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 08:35:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 08:35:46 -0000 Subject: [GHC] #9072: RankNTypes composition now requires ImpredicativeTypes In-Reply-To: <046.967894a9b8d693d100d00fd5d2992bdd@haskell.org> References: <046.967894a9b8d693d100d00fd5d2992bdd@haskell.org> Message-ID: <061.4604a3263bb071eaadf78df18d1793cb@haskell.org> #9072: RankNTypes composition now requires ImpredicativeTypes ----------------------------------------------+---------------------------- Reporter: gelisam | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: This is, I guess, a bug in 7.6. You really do need impredicative instantiation for the application of `(.)` to work. So I don't think this is a bug in 7.8. Yell if you disagree. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 08:47:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 08:47:38 -0000 Subject: [GHC] #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable In-Reply-To: <054.98121a1976ff390c1bc22f999087be97@haskell.org> References: <054.98121a1976ff390c1bc22f999087be97@haskell.org> Message-ID: <069.d91ea5e7a42032fc607a43748c4bab70@haskell.org> #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable -------------------------------------+------------------------------------ Reporter: sjoerd_visscher | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): Ah -- but you forgot to update the user manual! Also can you just articulate the reasoning behind having `-XDeriveTraversable` imply the other two, and perhaps summarise that reasoning in the user-manual entry? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 08:53:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 08:53:54 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.ee7f387c6e2a75f1f68312533f8b57b8@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.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: | -------------------------------+------------------------------------------- Comment (by simonpj): ollie, acowley: if you have a real-life use case for injective type families, do give the details here. Currently we don't have many compelling examples. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 09:03:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 09:03:41 -0000 Subject: [GHC] #9070: "Simplifier ticks exhausted" In-Reply-To: <048.992ee320aaea58308e183d3ff9448d87@haskell.org> References: <048.992ee320aaea58308e183d3ff9448d87@haskell.org> Message-ID: <063.4dd539ddc72233d75932b37db1aeb3f6@haskell.org> #9070: "Simplifier ticks exhausted" -------------------------------------+---------------------------------- Reporter: dermesser | 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 simonpj): Exhausting the ticks isn't a real bug... it's just an indication that your program is doing an unusually large amount of simplification/optimisation work, given its size. That's intriguing (it'd be interesting to know why), but you should feel free to bump up the `-fsimpl-tick-factor` to make the warning go away. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 09:16:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 09:16:52 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.ab94ca0d4de7d5ddbd2a744bb0c4c170@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.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: | -------------------------------+------------------------------------------- Comment (by ocharles): It's a little hard to say whether or not injective type families would actually help with what I'm doing - it could well be that I don't just understand this type level magic enough! However, in a few cases where I've got stuck I've moved things to a GADT to witness the relation between types instead, which I believe does get me injectivity and from that points things seemed to "just work" - albeit requiring a bit more effort. I'll keep my eyes out, and try and provide examples here if I find anything concrete. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 10:07:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 10:07:30 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.005fecc00468433106e68ba6e18fae00@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.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 ocharles): * status: new => patch Comment: I have a branch that adds almost all the above mentioned type clasess at https://github.com/ocharles/ghc/tree/generics-instances. I didn't do Data, mostly because I ran out of steam - if people feel strongly about that I can come back and add it. What are the next steps to take? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 10:10:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 10:10:37 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM5MDU3OiBSZW1vdmUgL3Vzci9iaW4v4oCmIHJl?= =?utf-8?q?ferences?= In-Reply-To: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> References: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> Message-ID: <062.b64d946e70e2f2e326155e31b6485227@haskell.org> #9057: Remove /usr/bin/? references -------------------------------+------------------------------------------- Reporter: Fuuzetsu | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.8.2 System | 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: | -------------------------------+------------------------------------------- Comment (by Fuuzetsu): Ah, while I did say /usr/bin/perl, I should have perhaps said /usr/bin/anything. {{{ ./libraries/terminfo/Setup.lhs:#!/usr/local/bin/runhaskell ./libraries/containers/benchmarks/bench-cmp.pl:#!/usr/bin/perl ./distrib/cross-port:#! /bin/bash ./configure: echo '#! /bin/cat ./testsuite/tests/rename/prog006/Setup.lhs:#!/usr/bin/runhaskell ./utils/count_lines/count_lines.lprl:#! /usr/bin/perl ./utils/pvm/debugger.emacs:#!/bin/csh -f ./utils/pvm/debugger2:#!/bin/csh -f ./compiler/count_bytes:#! /usr/local/bin/perl ./autom4te.cache/output.1: echo '#! /bin/cat ./autom4te.cache/output.0: echo '#! /bin/cat }}} Should I create a separate ticket for above? There are some in ./libraries so I should probably be filing with them, but many aren't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 10:11:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 10:11:24 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.370cb602d2d721cbc58eda973787f92b@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.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 ekmett): For the `Data` instances can we just get away with using `DeriveDataTypeable` / standalone deriving? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 10:11:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 10:11:47 -0000 Subject: [GHC] #9031: ghc panic: RegAlloc.Liveness.computeLivenss In-Reply-To: <045.282178438a787f7ffeeca849ab71135d@haskell.org> References: <045.282178438a787f7ffeeca849ab71135d@haskell.org> Message-ID: <060.1e8aa0907c4047e4ba891f4916e66d41@haskell.org> #9031: ghc panic: RegAlloc.Liveness.computeLivenss ---------------------------------------+----------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 phaul): Hi, I think I am hitting the same issue after upgrading from 7.6.3 to 7.8.2. Previously the same code was building fine. I have my code on github. https://github.com/phaul/chess/tree/ghc-7.8.2. (You need the ghc-7.8.2 branch) The problematic module is '''Chess.Move.Generator'''. I get: {{{ [18 of 30] Compiling Chess.Move.Generator ( Chess/Move/Generator.hs, dist/build/chess/chess-tmp/Chess/Move/Generator.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for i386-unknown-linux): RegAlloc.Liveness.computeLivenss SCCs aren't in reverse dependent order bad blockId c1AEd [NONREC c1AEI: }}} Can you try to use my code to reproduce the issue? Thanks Paul. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 10:11:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 10:11:53 -0000 Subject: [GHC] #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module In-Reply-To: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> References: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> Message-ID: <058.cb7ad7481742b5d157972df0462ef99c@haskell.org> #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module ---------------------------------------+----------------------------------- Reporter: bens | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): * owner: => simonpj Comment: Ugh. Good catch. Fixing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 10:28:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 10:28:36 -0000 Subject: [GHC] #9077: Forcing the type to be IO {} instead of IO() causes a "panic! The impossible has happened" output. Message-ID: <048.bf4e6160222a10b78f2f4ca8e5795447@haskell.org> #9077: Forcing the type to be IO {} instead of IO() causes a "panic! The impossible has happened" output. -------------------------+------------------------------------------------- Reporter: | Owner: Westycoot | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: x86 | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Below is the source code in which the bug occurs. It is easily reproduce- able, by having the type be IO{} instead of IO(). When ran, this code will produce the "panic! The impossible has happened" output. Which told me to report the bug here. By changing IO() to IO{} (which I did by accident), no exception is thrown, it simply tells the user to panic! {{{ main :: IO {} main = do e1 <- getLine e2 <- getLine print ((read e1) + (read e2)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 10:33:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 10:33:14 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM5MDU3OiBSZW1vdmUgL3Vzci9iaW4v4oCmIHJl?= =?utf-8?q?ferences?= In-Reply-To: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> References: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> Message-ID: <062.270e801ee5a8403799eebfe5a7406ab1@haskell.org> #9057: Remove /usr/bin/? references -------------------------------+------------------------------------------- Reporter: Fuuzetsu | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.2 System | 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 nomeata): * status: closed => new * resolution: fixed => Comment: I?ve reopened the ticket. You can also create a patch (or branch on your github fork) if you feel like it. How should arguments like in `/bin/csh -f` be treated? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 10:42:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 10:42:25 -0000 Subject: [GHC] #9031: ghc panic: RegAlloc.Liveness.computeLivenss In-Reply-To: <045.282178438a787f7ffeeca849ab71135d@haskell.org> References: <045.282178438a787f7ffeeca849ab71135d@haskell.org> Message-ID: <060.c8ce9722936420f7509bc40f12e8e422@haskell.org> #9031: ghc panic: RegAlloc.Liveness.computeLivenss ---------------------------------------+----------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 phaul): My code from above builds fine after changing ''-O2'' to ''-O0'' in the cabal file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 10:57:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 10:57:05 -0000 Subject: [GHC] #9031: ghc panic: RegAlloc.Liveness.computeLivenss In-Reply-To: <045.282178438a787f7ffeeca849ab71135d@haskell.org> References: <045.282178438a787f7ffeeca849ab71135d@haskell.org> Message-ID: <060.a260e888d8b9b6f71b9cadc84486a6e2@haskell.org> #9031: ghc panic: RegAlloc.Liveness.computeLivenss ---------------------------------------+----------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 phaul): * cc: sonkoly.pal@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 11:10:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 11:10:54 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.dd22e10875f7eec3002b57d8a22ff5ff@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.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 hvr): @ocharles I have to nitpick: could you please separate whitespace changes occurring in parts other than the lines you change into a separate commit? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 11:15:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 11:15:48 -0000 Subject: [GHC] #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable In-Reply-To: <054.98121a1976ff390c1bc22f999087be97@haskell.org> References: <054.98121a1976ff390c1bc22f999087be97@haskell.org> Message-ID: <069.3c8dcc2323eb353bf81086a0096755cf@haskell.org> #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable -------------------------------------+------------------------------------ Reporter: sjoerd_visscher | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 sjoerd_visscher): Right, thanks, I will do that! The main reason is that currently you have to quite a bit to just get a derived `Traversable` instance: 1. You have to add `deriving (Functor, Foldable, Traversable)` 2. You have to import `Data.Foldable` and `Data.Traversable` 3. You have to turn on 3 extensions. Item 1 is fine, we don't want any magic. Item 2 could be solved by moving `Foldable` and `Traversable` to the prelude. So the only thing that I can do right now is improve item 3. If you derive the `Traversable` instance it would be invalid to have an instance for `Functor` or `Foldable` that is not equiavalent to the derived instances, so it makes sense to turn those extensions on automatically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 11:22:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 11:22:54 -0000 Subject: [GHC] #9063: Default associated type instances are too general In-Reply-To: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> References: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> Message-ID: <062.6619786dbe4953dd81302d9518638996@haskell.org> #9063: Default associated type instances are too general -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): Can you give an example for instances? There is a design question here. For a start, the associated type should really mention at least one of the class variables. This should be prohibited: {{{ class C a where type F b :: * }}} Second, the default instances should mention the same class variable in the same position, not some pattern. For example {{{ class C a where type F a b :: * type instance F a Int = Int -- OK type instance F a Bool = Char -- OK type instance F Int a = Bool -- Definitely not OK! type instance F [a] b = Char -- Not OK }}} Reason: the default instances are simply templates, from which you can create the real `type instance` in the instance decl. For example {{{ instance C Float -- type instance F Float Int = Int -- type instance F Float Bool = Char }}} How would one instantiate the "not-ok" defaults here?? We are not currently checking any of this, nor is it documented. [http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/type-families.html #assoc-decl-defs Current manual entry] Before moving to fix it, let's just check that we agree. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 11:32:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 11:32:13 -0000 Subject: [GHC] #9077: Forcing the type to be IO {} instead of IO() causes a "panic! The impossible has happened" output. In-Reply-To: <048.bf4e6160222a10b78f2f4ca8e5795447@haskell.org> References: <048.bf4e6160222a10b78f2f4ca8e5795447@haskell.org> Message-ID: <063.2c9a7201750ad41a3ee98d8eb49a4c11@haskell.org> #9077: Forcing the type to be IO {} instead of IO() causes a "panic! The impossible has happened" output. -------------------------------------------------+------------------------- Reporter: Westycoot | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Compile-time performance bug | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): I can't reproduce your crash. Can you show exact output and which compiler you are using? Like this: {{{ bash$ ghc -c T9077.hs T9077.hs:3:12: Record syntax is illegal here: {} bash$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.2 bash$ cat T9077.hs module Main where main :: IO {} main = do e1 <- getLine e2 <- getLine print ((read e1) + (read e2)) }}} I speculate that you are not using 7.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 12:20:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 12:20:54 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.0571c2daa89e3bf151a790a573915550@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.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 ocharles): hvr - as mentioned on Github, I was somewhat intending to squash this down into a single commit when I'm done. If you'd like, I could simply omit whitespace changes from this. My editor does it for me, so I sometimes forget it is happening :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 12:47:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 12:47:02 -0000 Subject: [GHC] #9062: Role: ~# should be ~R# In-Reply-To: <044.7f1566c191cb9df0ca4c1915de3a4096@haskell.org> References: <044.7f1566c191cb9df0ca4c1915de3a4096@haskell.org> Message-ID: <059.2b9d7ba0cd5b9c671f37dc472be95670@haskell.org> #9062: Role: ~# should be ~R# ---------------------------------+------------------------------------ Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 goldfire): I asked Conal to post the report. The problem is just in the pretty- printer, which should produce `~R#` if the coercion is representational (as it is, in this case). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 13:23:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 13:23:40 -0000 Subject: [GHC] #9078: Segfault with makeStableName Message-ID: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> #9078: Segfault with makeStableName ------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Calling `makeStableName` on the same object many times causes a segfault. The following triggers this behaviour on both OSX and Linux-x86_64, provided it is compiled (it doesn't seem to occur if the call to `makeStableName` is interpreted). {{{ module Main where import Control.Monad import System.Mem.StableName main :: IO () main = replicateM_ 100000 (makeStableName foo) foo :: Int foo = 1 }}} It seems to happen largely at random. The 100000 calls to `makeStableName` in the above example essentially guarantee its occurrence, but I have observed it happen with far fewer. The reason this bug was discovered is it is causing frequent failures in Accelerate on 7.8.2. See [https://github.com/AccelerateHS/accelerate/issues/162]. In that case it seems to be causing more `strange closure type` errors than segfaults, but I assume it is the same root cause. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 13:55:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 13:55:05 -0000 Subject: [GHC] #9070: "Simplifier ticks exhausted" In-Reply-To: <048.992ee320aaea58308e183d3ff9448d87@haskell.org> References: <048.992ee320aaea58308e183d3ff9448d87@haskell.org> Message-ID: <063.a415491b6f05e15d52d40ce49caf6074@haskell.org> #9070: "Simplifier ticks exhausted" -------------------------------------+---------------------------------- Reporter: dermesser | 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 DinoMorelli): carter: The project is epub-metadata. Available on Hackage, but I have already released a newer version with adjusted -fsimpl-tick-factor, so get the prior version: {{{ $ cabal unpack epub-metadata-4.0 }}} The error says: {{{ When trying UnfoldingDone base:GHC.Base.build{v 04} }}} Still fails with just -fno-full-laziness, but the message changes to: {{{ When trying UnfoldingDone hxt-9.3.1.4:Control.Arrow.IOStateListArrow.$fCategory*IOSLA_$c.{v rzUB} }}} Also, I'm not specifying any -O switches at all, I'm not sure what the default optimization level is for GHC. simonpj: I was wondering about that, if this is normal-ish and just requires params. Do you need me to provide more details here, perhaps with `-ddump-simpl- stats` ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 14:26:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 14:26:57 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.59015ac4d587874e6c6c19515809cfb9@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 tmcdonell): * cc: tmcdonell@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 17:50:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 17:50:22 -0000 Subject: [GHC] #9021: [CID43168] rts/linker.c has a memory leak in the dlopen/dlerror code In-Reply-To: <046.338d06ed46ba2865fda90272f333c349@haskell.org> References: <046.338d06ed46ba2865fda90272f333c349@haskell.org> Message-ID: <061.2ac7214614547a67a66d5362fbc7283e@haskell.org> #9021: [CID43168] rts/linker.c has a memory leak in the dlopen/dlerror code -------------------------------------+------------------------------------- Reporter: hgolden | Owner: simonmar Type: bug | Status: patch Priority: low | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: linker, memory Operating System: POSIX | leak, coverity Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Comment (by hgolden): I am withdrawing my patch. The one posted to Coverity Scan was better. Please use that instead. (I don't know who wrote the Coverity Scan patch, but it may have been nicolast.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 17:53:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 17:53:50 -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.e36fa58221443a2d59c49c8e6583b6d4@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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 dagit): {{{ $ readelf -h /usr/lib64/libgmp.so.10 ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: DYN (Shared object file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x31fba0c080 Start of program headers: 64 (bytes into file) Start of section headers: 488144 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 7 Size of section headers: 64 (bytes) Number of section headers: 31 Section header string table index: 30 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 18:09:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 18:09:35 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.e8c9aea0a49c3f2273287009644e36e1@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 hvr): Maybe interesting to know, which `cabal-install` version was used? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 18:27:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 18:27:53 -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.9878d4a40bf937ebd2009422fc500b51@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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): Replying to [comment:14 dagit]: My bad! The flags we need to check are in the dynamic section and not in the ELF header. Could you run {{{readelf -d /usr/lib64/libgmp.so.10}}} instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 18:30:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 18:30:49 -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.b6f49c06dfdac0779c1ccbfbe724adc0@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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 dagit): Hmm...I still don't see the flag you're looking for. {{{ $ readelf -d /usr/lib64/libgmp.so.10 Dynamic section at offset 0x6dce0 contains 27 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000e (SONAME) Library soname: [libgmp.so.10] 0x000000000000000c (INIT) 0x31fba0aab8 0x000000000000000d (FINI) 0x31fba5e5f0 0x0000000000000019 (INIT_ARRAY) 0x31fbc6d8e0 0x000000000000001b (INIT_ARRAYSZ) 8 (bytes) 0x000000000000001a (FINI_ARRAY) 0x31fbc6d8e8 0x000000000000001c (FINI_ARRAYSZ) 8 (bytes) 0x000000006ffffef5 (GNU_HASH) 0x31fba001f0 0x0000000000000005 (STRTAB) 0x31fba05170 0x0000000000000006 (SYMTAB) 0x31fba01570 0x000000000000000a (STRSZ) 10633 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000003 (PLTGOT) 0x31fbc6e000 0x0000000000000002 (PLTRELSZ) 8232 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x31fba08a90 0x0000000000000007 (RELA) 0x31fba08070 0x0000000000000008 (RELASZ) 2592 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffe (VERNEED) 0x31fba08000 0x000000006fffffff (VERNEEDNUM) 1 0x000000006ffffff0 (VERSYM) 0x31fba07afa 0x000000006ffffff9 (RELACOUNT) 52 0x000000006ffffdf8 (CHECKSUM) 0xcc8edcb1 0x000000006ffffdf5 (GNU_PRELINKED) 2013-12-20T11:44:15 0x0000000000000000 (NULL) 0x0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 18:38:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 18:38:35 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.0c89e78402369e93f671f97406df33bc@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 Feuerbach): I can reproduce this with recent cabal HEAD (84a768094, Apr 27). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 20:05:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 20:05:54 -0000 Subject: [GHC] #9079: Foreign.C.Types in haskell2010 Message-ID: <046.0c2f3309095eee33947f42c0af9aa93f@haskell.org> #9079: Foreign.C.Types in haskell2010 -----------------------------------------+--------------------------------- Reporter: tensor5 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -----------------------------------------+--------------------------------- According to Haskell 2010, a marshallable foreign type has to be a `newtype` of a basic type with exposed constructor. Why constructors are not exposed in the module `Foreign.C.Types` from `haskell2010`? When I replace `base` with `haskell2010` in {{{ module Test where import Foreign.C foreign import ccall unsafe "sys/mount.h umount" umount :: CString -> IO CInt }}} I get {{{ Unacceptable result type in foreign declaration: IO CInt When checking declaration: foreign import ccall unsafe "static sys/mount.h umount" umount :: CString -> IO CInt }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 20:37:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 20:37:24 -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.5367de4d3a4192421e5133987e448a82@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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 simonmar): `libgmp` is not symbolic on my system either. Symbol information and relocs for the program: {{{ $ objdump --syms --dynamic-syms --reloc --dynamic-reloc ./a.out | grep envir 0000000000000000 l df *ABS* 0000000000000000 check- environ.c 0000000000601060 w O .bss 0000000000000008 environ@@GLIBC_2.2.5 0000000000601060 g O .bss 0000000000000008 __environ@@GLIBC_2.2.5 0000000000601060 w DO .bss 0000000000000008 GLIBC_2.2.5 _environ 0000000000601060 w DO .bss 0000000000000008 GLIBC_2.2.5 environ 0000000000601060 g DO .bss 0000000000000008 GLIBC_2.2.5 __environ 0000000000601060 R_X86_64_COPY __environ }}} Note there are 3 symbols at the same location (`environ`, `_environ`, and `__environ`). The first two are weak, the third is global. The third is also a copy reloc, which means its contents is copied to this location when the program starts up. Symbol information and relocs for libc: {{{ $ objdump --syms --dynamic-syms --reloc --dynamic-reloc /lib/x86_64-linux- gnu/libc-2.17.so | grep envir 00000000003c44e8 w DO .bss 0000000000000008 GLIBC_2.2.5 _environ 00000000003c44e8 w DO .bss 0000000000000008 GLIBC_2.2.5 environ 00000000003c44e8 g DO .bss 0000000000000008 GLIBC_2.2.5 __environ 00000000003c0de0 R_X86_64_GLOB_DAT _environ 00000000003c0ea8 R_X86_64_GLOB_DAT __environ }}} Again we have 3 symbols at the same location, all 8 bytes long. There are no mentions of any `environ` symbol in `libgmp`'s symbol table or relocations. `LD_DEBUG=all` shows a normal lookup like this: {{{ 23419: symbol=environ; lookup in file=./a.out [0] 23419: binding file ./a.out [0] to ./a.out [0]: normal symbol `environ' }}} but the lookup in `libgmp` looks like this: {{{ 23419: symbol=environ; lookup in file=/usr/lib/x86_64-linux- gnu/libgmp.so [0] 23419: symbol=environ; lookup in file=/lib/x86_64-linux- gnu/libc.so.6 [0] 23419: binding file /usr/lib/x86_64-linux-gnu/libgmp.so [0] to /lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `environ' }}} I still have no idea why the lookup in `libgmp` is behaving differently from the others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 20:44:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 20:44:10 -0000 Subject: [GHC] #8972: Investigate adding fast compare-and-swap Int type/primops In-Reply-To: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> References: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> Message-ID: <059.0d921300ccd173e8be33fc06702c0815@haskell.org> #8972: Investigate adding fast compare-and-swap Int type/primops -------------------------------------+------------------------------------ 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: #8157, #7883 -------------------------------------+------------------------------------ Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 20:47:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 20:47:54 -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.efaaef1db820d1604505d53d304a2f72@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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 dagit): Simon, did you read my explanation above about `LOCAL` vs. `GLOBAL`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 21:07:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 21:07:34 -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.eed66d533d54b8044055447abc61ae36@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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 simonmar): I read it, but I don't think I understand the difference between local and global. So do you have an explanation for what we're seeing? The impression I got from what you wrote above is that there was still some guesswork involved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 21:10:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 21:10:23 -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.1d98860758d383f074b203dc7d7c9b03@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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 simonmar): Also, on my system `ld-linux.so` doesn't have a symbol for `environ`, local or otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 21:20:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 21:20:21 -0000 Subject: [GHC] #9067: Optimize clearNursery by short-circuiting when we get to currentNursery In-Reply-To: <045.c7f02cf5a52be23a613e87f34c2ef3ee@haskell.org> References: <045.c7f02cf5a52be23a613e87f34c2ef3ee@haskell.org> Message-ID: <060.4def78a7a7e69ea9d33b8e0921b60991@haskell.org> #9067: Optimize clearNursery by short-circuiting when we get to currentNursery --------------------------------------------+------------------------------ Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: low | Milestone: Component: Runtime System | 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): Andreas Voellmy and I talked about some similar ideas. I doubt that you want to rely on `CurrentNursery`, because we want to reset that after every GC, but instead I think the right approach is to assume that every block from `CurrentNursery` onwards needs to have its free pointer reset before we use it. It's a somewhat subtle invariant and something else we have to get right, but the win seems to be worthwhile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 21:37:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 21:37:33 -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.7cc0d1e83c1b0827d62e629416c62f8c@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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 dagit): Simon, at the moment I'm just trying to understand this whole thing better myself. My uncertainty is in these areas: * How the `dlsym()` search should work. For example, I'm not sure if `dlsym()` is supposed to look in the `NEEDED` dependencies or not. It seems to look in them. * Whether glibc implements the above search correctly. * Finally, I have no idea what is the right way to fix ghc's linker. I assume you're already familiar with the elf linking spec, but here is the link just to make sure we're looking at the same doc: http://refspecs.linuxbase.org/elf/elf.pdf It says: * STB_LOCAL Local symbols are not visible outside the object file containing their definition. Local symbols of the same name may exist in multiple files without interfering with each other. * STB_GLOBAL Global symbols are visible to all object files being combined. One file's definition of a global symbol will satisfy another file's undefined reference to the same global symbol. * STB_WEAK Weak symbols resemble global symbols, but their definitions have lower precedence. I'd say, based on what I see on my machine that `WEAK` seems to be even lower priority than `LOCAL`. It's interesting that your ld-linux.so doesn't have `environ`, when I grep mine I get these hits: {{{ $ readelf -Wa /usr/lib64/ld-linux-x86-64.so.2 | grep environ 143: 0000000000000000 0 FILE LOCAL DEFAULT ABS dl-environ.c 179: 0000000000000000 0 FILE LOCAL DEFAULT ABS environ.c 268: 00000031e4022168 8 OBJECT LOCAL DEFAULT 21 _environ 275: 00000031e4022168 8 OBJECT LOCAL DEFAULT 21 __environ 300: 00000031e4022168 8 OBJECT LOCAL DEFAULT 21 environ }}} For your libgmp.so does `environ` get defined in any of the deps listed by `ldd`? The `dlsym` manpage has this (potentially) interesting comment: > External references in the library are resolved using the libraries in that library's dependency list and any other libraries previously opened with the RTLD_GLOBAL flag. If the executable was linked with the flag "-rdynamic" (or, synonymously, "--export-dynamic"), then the global symbols in the executable will also be used to resolve references in a dynamically loaded library. Please let me know if there is more I can do to help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 21:44:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 21:44:48 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.16785ce888978cd8e16ce256730bf696@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.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 ocharles): Alright, I've responded to some comments and added more instances. Could people please have another look? I wrote out Data instances, but I have never actually used Data.Data, so I may have got that wrong. Is it possible to write Data instances for (:+:) and friends? My initial attempt was no, but I may have missed something. Latest code is at https://github.com/ocharles/ghc/tree/generics-instances (as before). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 21:52:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 21:52:22 -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.7619f75154bcd943d253bc26cb4dbf72@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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): Let's look at comment:12 again. We see that even for symbols defined in libgmp.so the dynamic linker searches ./check-environ (and libdl and libc and ld-linux) before it finally finds the symbol in libgmp.so {{{ 5823: symbol=__gmp_default_free; lookup in file=./check-environ [0] 5823: symbol=__gmp_default_free; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_default_free; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_default_free; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_default_free; lookup in file=/usr/lib64/libgmp.so [0] }}} And then for {{{environ}}} the search starts in {{{libgmp.so}}}. Perhaps because {{{environ}}} is a weak symbol. It seems that openSUSE ignores the weak attribute of symbols in the dynamic linker and treats them as strong and hence starts the search in {{{./check-environ}}}. This seems to be correct as Drepper [http://www.akkadia.org/drepper/dsohowto.pdf] says on p. 6: "Note that a definition in a DSO being weak has no effects. Weak definitions only play a role in static linking." It seems Ubuntu and Fedora do not agree. There is also an environment variable {{{LD_DYNAMIC_WEAK}}} (see ld.so(8)) to allow overriding weak symbols. Is that environment variable set on your systems? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 21:58:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 21:58:48 -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.b89783cdf16a3974b3cf54757c360552@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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 dagit): The value of `LD_DYNAMIC_WEAK` doesn't make a difference on my system. I've also tried printing the result of `dlerror()` before/after calls to `dlsym()`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 22:05:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 22:05:41 -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.a8a33a6a551fd734d169fa7c4bd67eb9@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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): Replying to [comment:23 dagit]: > The value of `LD_DYNAMIC_WEAK` doesn't make a difference on my system. I've also tried printing the result of `dlerror()` before/after calls to `dlsym()`. What happens if there is no `LD_DYNAMIC_WEAK` in the environment? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 22:41:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 22:41:56 -0000 Subject: [GHC] #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable In-Reply-To: <054.98121a1976ff390c1bc22f999087be97@haskell.org> References: <054.98121a1976ff390c1bc22f999087be97@haskell.org> Message-ID: <069.2b9425a02f8bc145598c714ff4e4ec45@haskell.org> #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable -------------------------------------+------------------------------------ Reporter: sjoerd_visscher | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 sjoerd_visscher): That second patch replaces the first. (I forgot to check the checkmark, and there seems to be no way to fix it afterwards.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 22:54:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 22:54:46 -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.cf7eb1d66d83afa2f1067d217c3d6185@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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): Arrrg! Now I see what I was doing wrong! The libraries were specified with paths that do not exist on openSUSE. With this program I can reproduce the problem: {{{ #include #include char *so = "libgmp.so"; char *so2 = "libpthread.so"; extern char**environ; int main(int argc, char *argv[]) { void *deflt, *hdl; deflt = dlopen(NULL, RTLD_LAZY | RTLD_GLOBAL); printf("&environ = %p, environ = %p\n", &environ, environ); char ***dflt_env = dlsym(deflt,"environ"); printf("dlsym(deflt, \"environ\") = %p, *dflt_env = %p\n", dflt_env, *dflt_env ); hdl = dlopen(so, RTLD_LAZY); char ***env = dlsym(hdl,"environ"); printf("dlsym(\"libgmp\", \"environ\") = %p\n", env); printf("*env = %p\n", *env); hdl = dlopen(so2, RTLD_LAZY); printf("dlsym(\"libpthread\", \"environ\") = %p\n", dlsym(hdl,"environ")); } }}} I also added code that shows the content of the pointer returned from `dlsym` called with `libgmp.so`. {{{ peter at montebre:~/tmp> ./a.out &environ = 0x601060, environ = 0x7fffc82ce4b8 dlsym(deflt, "environ") = 0x601060, *dflt_env = 0x7fffc82ce4b8 dlsym("libgmp", "environ") = 0x7f9dcb870fd8 *env = (nil) dlsym("libpthread", "environ") = 0x601060 }}} Now, playing some more, I removed `extern char **environ;` and the print statements and the `NULL` pointer issue is gone: {{{ #include #include char *so = "libgmp.so"; char *so2 = "libpthread.so"; // extern char**environ; int main(int argc, char *argv[]) { void *deflt, *hdl; deflt = dlopen(NULL, RTLD_LAZY | RTLD_GLOBAL); // printf("&environ = %p, environ = %p\n", &environ, environ); char ***dflt_env = dlsym(deflt,"environ"); printf("dlsym(deflt, \"environ\") = %p, *dflt_env = %p\n", dflt_env, *dflt_env ); hdl = dlopen(so, RTLD_LAZY); char ***env = dlsym(hdl,"environ"); printf("dlsym(\"libgmp\", \"environ\") = %p\n", env); printf("*env = %p\n", *env); hdl = dlopen(so2, RTLD_LAZY); printf("dlsym(\"libpthread\", \"environ\") = %p\n", dlsym(hdl,"environ")); } }}} {{{ peter at montebre:~/tmp> ./a.out dlsym(deflt, "environ") = 0x7f4a0181bfd8, *dflt_env = 0x7fff2d021848 dlsym("libgmp", "environ") = 0x7f4a0181bfd8 *env = 0x7fff2d021848 dlsym("libpthread", "environ") = 0x7f4a0181bfd8 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 22:57:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 22:57:43 -0000 Subject: [GHC] #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable In-Reply-To: <054.98121a1976ff390c1bc22f999087be97@haskell.org> References: <054.98121a1976ff390c1bc22f999087be97@haskell.org> Message-ID: <069.a49076560a6173ea725bd3eb9279134f@haskell.org> #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable -------------------------------------+------------------------------------ Reporter: sjoerd_visscher | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 sjoerd_visscher): By the way, how can I test the documentation? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 23:22:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 23:22:15 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.a130572ed64a389eb7881e5c1201a668@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.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 ekmett): I'll show you how to write the instances for `(:+:)` and the like on IRC when I get a chance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 23:50:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 23:50:23 -0000 Subject: [GHC] #9063: Default associated type instances are too general In-Reply-To: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> References: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> Message-ID: <062.844d83a66fe3936d469222a4e30fbdbd@haskell.org> #9063: Default associated type instances are too general -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): Here is an example where this problem bites in instances: {{{ {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies, TypeOperators #-} module Bug where import Data.Proxy class kproxy ~ 'KProxy => PEq (kproxy :: KProxy a) where type (:==) (x :: a) (y :: a) :: Bool instance PEq ('KProxy :: KProxy Bool) where type False :== False = True type False :== True = False type True :== False = False type True :== True = True instance PEq ('KProxy :: KProxy ()) where type x :== y = True }}} I get {{{ Type indexes must match class instance head Found ?k? but expected ?()? In the type instance declaration for ?:==? In the instance declaration for ?PEq (KProxy :: KProxy ())? }}} That's not an overlapping instance error -- I was wrong in my post above. I guess I didn't look closely at the error. But, GHC should be able to figure out what I mean here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 5 23:59:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 May 2014 23:59:49 -0000 Subject: [GHC] #9063: Default associated type instances are too general In-Reply-To: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> References: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> Message-ID: <062.81fc0ee7679951de43045dbd11009db4@haskell.org> #9063: Default associated type instances are too general -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): I agree with most of Simon's analysis. The "not OK" instances are definitely not OK, and should be rejected. But, my case is subtly different, in that I'm not asking for magic, just kind-checking. What makes my case different is that the class parameter is a kind variable. Here is how I want GHC to reason, in the example in my original report: - The type family declaration introduces the identifier `(:==)`, with kind `a -> a -> Bool`, where `a` is the class (kind) variable. - When kind-checking the default instance, we kind-check with expected kind `a` for `x` and expected kind `a` for `y`. - The kind-checked, desugared LHS of the default instance indeed does mention a class variable `a`, in exactly the right spot. - Definition accepted. In the instance case, a similar analysis works out: we kind-check the instance for `(:==)` using the instantiated kind (`() -> () -> Bool` in the second instance in my comment above), and everything works out. I ''do'' see the counterargument here, that it seems I'm asking for magic. But, I respectfully disagree with that stance. And, it would seem that the implementation here would be rather straightforward and I'm happy to do it. Regardless of the outcome, we should probably flesh out that manual entry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 00:04:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 00:04:20 -0000 Subject: [GHC] #9063: Default associated type instances are too general In-Reply-To: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> References: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> Message-ID: <062.5e8cea6bbf2d1d4d766954311ad000ba@haskell.org> #9063: Default associated type instances are too general -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): It might help to note ''why'' I'm pushing this. I'm working on expanding the promotion algorithm in the `singletons` package to include classes and instances. I want to promote method definitions to associated type family instances. Currently, something like this is peachy: {{{ instance Eq () where _ == _ = True }}} However, with the current treatment of associated type instances as discussed here, the promoted version of this (in my "instance example" above) does not work without explicit kind annotations. My implementation currently has to store method types, do a lookup on method definitions, and then do a type substitution to produce the needed kind annotations. This isn't terribly hard, really, but it just seems unnecessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 00:41:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 00:41:20 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.c9774063c7d5f963ad5445810476e7e5@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 ezyang): Reproduced; when run with the debug build we get an assert failure: {{{ Starting program: /home/ezyang/test +RTS -DS -C0 -V0 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". cap 0: initialised test: internal error: ASSERTION FAILED: file rts/Stable.c, line 337 (GHC version 7.9.20140410 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Program received signal SIGABRT, Aborted. 0x00007ffff6eaef79 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff6eaef79 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff6eb2388 in __GI_abort () at abort.c:89 #2 0x000000000067edef in rtsFatalInternalErrorFn (s=0x6e63c0 "ASSERTION FAILED: file %s, line %u\n", ap=0x7fffffff9878) at rts/RtsMessages.c:170 #3 0x000000000067ea27 in barf (s=0x6e63c0 "ASSERTION FAILED: file %s, line %u\n") at rts/RtsMessages.c:42 #4 0x000000000067ea8a in _assertFail (filename=0x6e6d44 "rts/Stable.c", linenum=337) at rts/RtsMessages.c:57 #5 0x0000000000682c03 in lookupStableName (p=0x9076b0) at rts/Stable.c:337 #6 0x00000000006a2f46 in stg_makeStableNamezh () #7 0x0000000000000000 in ?? () (gdb) f 5 #5 0x0000000000682c03 in lookupStableName (p=0x9076b0) at rts/Stable.c:337 337 ASSERT(stable_name_table[sn].addr == p); }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 01:17:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 01:17:26 -0000 Subject: [GHC] #8972: Investigate adding fast compare-and-swap Int type/primops In-Reply-To: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> References: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> Message-ID: <059.47bb89c147ffd6b1c1c57afb1c919869@haskell.org> #8972: Investigate adding fast compare-and-swap Int type/primops -------------------------------------+------------------------------------ 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: #8157, #7883 -------------------------------------+------------------------------------ Comment (by jberryman): Replying to [comment:10 nominolo]: > For GHC, I think it could be useful to have both mechanisms available. Marking a thread as non-interruptable could be exported from a "Here be dragons" module for using when you know that a thread will hold a lock/MVar only for a very short time. > Would this be something like `mask` but for scheduling? If so I want. From a library-writers point of view this would be a really easy way to get rid of a lot of bad scheduling effects, e.g. in probably every use of `modifyMVar`. Sorry if I'm not understanding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 07:40:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 07:40:08 -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.e8b25a07c7bae307b8de3c7ce5cd0ea3@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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): Adding error handling: {{{ hdl = dlopen(so2, RTLD_LAZY); if (hdl == NULL) { printf("failed to open libpthread: %s\n", dlerror()); return 1; } printf("dlsym(\"libpthread\", \"environ\") = %p\n", dlsym(hdl,"environ")); }}} I get: {{{ &environ = 0x601068, environ = 0x7fffd170d688 dlsym(deflt, "environ") = 0x601068, *dflt_env = 0x7fffd170d688 dlsym("libgmp", "environ") = 0x7fcc61a82fd8 *env = (nil) failed to open libpthread: /usr/lib64/libpthread.so: invalid ELF header }}} `libgmp.so` is not special after all. On openSUSE `libpthread.so` is a linker script. `dlopen()` cannot open it and returns `NULL`. `RTLD_DEFAULT` is defined as `(void *) 0` so `NULL` so dlsym did not fail but return the symbol from the default SO (the program itself). Trying `libpthread.so.0` instead shows the same problem as `libgmp.so`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 07:57:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 07:57:31 -0000 Subject: [GHC] #9079: Foreign.C.Types in haskell2010 In-Reply-To: <046.0c2f3309095eee33947f42c0af9aa93f@haskell.org> References: <046.0c2f3309095eee33947f42c0af9aa93f@haskell.org> Message-ID: <061.9188f490016f70423d47a46fd50d6268@haskell.org> #9079: Foreign.C.Types in haskell2010 ------------------------------------------+-------------------------------- Reporter: tensor5 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.8.2 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Changes (by simonpj): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => worksforme Comment: Interesting. `Foreign.C.Types` does export `CInt(..)`. And compiling the module you show works just fine for me: {{{ bash$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.2 bash$ ghc -c T9079.hs -fforce-recomp bash$ cat T9079.hs module T9079 where import Foreign.C foreign import ccall unsafe "sys/mount.h umount" umount :: CString -> IO CInt }}} Perhaps you aren't using 7.8.2? I'll close as "worksforme" but if you disagree then please do re-open with more details. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 08:11:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 08:11:47 -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.39f4e761334ed6e106c2d44cc2479660@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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 have the following fix in mind: In `internal_dlsym` search the default handle first and then the list of SOs opened so far. But there are a few things in `Linker.c` that I don't understand yet: 1. `hdl` is `dl_prog_handle` in all two call sites. Do we need that parameter or could we instead use the static variable `dl_prog_handle` directly? 1. With `hdl` being `dl_prog_handle`: In `internal_dlsym` the SO pointed to by `hdl` is searched last. Why can I not look there first? 1. In `internal_dlopen` the SO is opened with `RTLD_GLOBAL` but we want to be able to override symbols later when we reload a library. Why is `RTLD_GLOBAL` needed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 08:40:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 08:40:14 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.4998158212c865dc38985f55e4065465@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 ezyang): I believe the bug is when we free stable-name entries (in gcStableTables), we also need to remove the stable name from the hash table. updateStableTables will not catch this because it only iterates over live stable names. The bug is masked because if we immediately make another stable pointer, it will probably be put in the right slot, but the ASSERT catches the problem immediately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 08:43:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 08:43:19 -0000 Subject: [GHC] #9061: Warnings for redundant imports doesn't take name shadowing into account (Regression) In-Reply-To: <047.b503cfbcf30b76a6eb3638265399e795@haskell.org> References: <047.b503cfbcf30b76a6eb3638265399e795@haskell.org> Message-ID: <062.ab2321ca912950821619af3502063909@haskell.org> #9061: Warnings for redundant imports doesn't take name shadowing into account (Regression) -------------------------------------------------+------------------------- Reporter: bergmark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9f3e39d5f8686e511ffca406a6e056dec4095e53/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9f3e39d5f8686e511ffca406a6e056dec4095e53" Fix over-zealous unused-import warning See Note [Un-warnable import decls] in RnNames. Fixes Trac #9061. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 08:43:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 08:43:19 -0000 Subject: [GHC] #9061: Warnings for redundant imports doesn't take name shadowing into account (Regression) In-Reply-To: <047.b503cfbcf30b76a6eb3638265399e795@haskell.org> References: <047.b503cfbcf30b76a6eb3638265399e795@haskell.org> Message-ID: <062.e9a9e0e0bef24a442764f03a57c7f3af@haskell.org> #9061: Warnings for redundant imports doesn't take name shadowing into account (Regression) -------------------------------------------------+------------------------- Reporter: bergmark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5b73dc5fda1941d51827ea72614782c10a355a3d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5b73dc5fda1941d51827ea72614782c10a355a3d" Second go at fixing #9061 My first attempt introduce a bug in -fprint-minimal-imports, but fortunately a regression test caught it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 08:43:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 08:43:20 -0000 Subject: [GHC] #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module In-Reply-To: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> References: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> Message-ID: <058.e175108eec5f0d6225832d4603ebdd16@haskell.org> #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module ---------------------------------------+----------------------------------- Reporter: bens | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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:"13a330e87cf459311a7f164e1e57baf877741da6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="13a330e87cf459311a7f164e1e57baf877741da6" Fix Trac #9071, an egregious bug in TcDeriv.inferConstraints The constraints for Functor don't line up 1-1 with the arguments (they are fetched out from sub-terms of the type), but the surrounding code was mistakenly assuming they were in 1-1 association. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 08:43:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 08:43:20 -0000 Subject: [GHC] #9063: Default associated type instances are too general In-Reply-To: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> References: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> Message-ID: <062.f477f7b695d7ec4c54bc6c7ebc7c567a@haskell.org> #9063: Default associated type instances are too general -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 Simon Peyton Jones ): In [changeset:"02227ddddf56301a9c9bafac81742c0585e9a108/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="02227ddddf56301a9c9bafac81742c0585e9a108" Add a bit more typechecker tracing This is in pursuit of Trac #9063 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 08:46:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 08:46:21 -0000 Subject: [GHC] #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module In-Reply-To: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> References: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> Message-ID: <058.c51657beed831f1f15c64cb172e73c0a@haskell.org> #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module ---------------------------------------+----------------------------------- Reporter: bens | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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:"59b4e6d0ba504b33cc7064d489b8ec485a7703f4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="59b4e6d0ba504b33cc7064d489b8ec485a7703f4" Adding missing test files for #9071 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 08:48:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 08:48:11 -0000 Subject: [GHC] #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module In-Reply-To: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> References: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> Message-ID: <058.c6734aa8f723978577f6a6fa26d1e48c@haskell.org> #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module -------------------------------------------------+------------------------- Reporter: bens | Owner: Type: bug | simonpj Priority: normal | Status: merge Component: Compiler | Milestone: Resolution: | Version: 7.8.2 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time crash | Architecture: Test Case: deriving/should_fail/T9071, | Unknown/Multiple T9071_2 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => merge * testcase: => deriving/should_fail/T9071, T9071_2 Comment: Fixed. Please merge to 7.8 branch. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 08:49:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 08:49:21 -0000 Subject: [GHC] #9061: Warnings for redundant imports doesn't take name shadowing into account (Regression) In-Reply-To: <047.b503cfbcf30b76a6eb3638265399e795@haskell.org> References: <047.b503cfbcf30b76a6eb3638265399e795@haskell.org> Message-ID: <062.9227a254932caa3b3a87d1bb91f32a0d@haskell.org> #9061: Warnings for redundant imports doesn't take name shadowing into account (Regression) -------------------------------------------------+------------------------- Reporter: bergmark | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: module/T9061 | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => merge * testcase: => module/T9061 Comment: Just about worth merging to 7.8, but hardly a big deal. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 08:59:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 08:59:55 -0000 Subject: [GHC] #9062: Role: ~# should be ~R# In-Reply-To: <044.7f1566c191cb9df0ca4c1915de3a4096@haskell.org> References: <044.7f1566c191cb9df0ca4c1915de3a4096@haskell.org> Message-ID: <059.44a7b81ed1165e6f268b33ab689997c8@haskell.org> #9062: Role: ~# should be ~R# ---------------------------------+------------------------------------ Reporter: conal | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 simonpj): * owner: => goldfire Comment: OK, Richard, so you know what's going on and can fix? Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 09:00:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 09:00:30 -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.fb0a2bb9fbf1137e5005436a018379a1@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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): And another question: From `internal_dlopen()`: {{{ if (hdl == NULL) { /* dlopen failed; return a ptr to the error msg. */ errmsg = dlerror(); if (errmsg == NULL) errmsg = "addDLL: unknown error"; errmsg_copy = stgMallocBytes(strlen(errmsg)+1, "addDLL"); strcpy(errmsg_copy, errmsg); errmsg = errmsg_copy; } o_so = stgMallocBytes(sizeof(OpenedSO), "addDLL"); o_so->handle = hdl; o_so->next = openedSOs; openedSOs = o_so; }}} If dlopen() fails we are adding a `NULL` handle to `openedSOs`. Which on my system means `RTLD_DEFAULT`. Is that what we want? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 09:21:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 09:21:28 -0000 Subject: [GHC] #9079: Foreign.C.Types in haskell2010 In-Reply-To: <046.0c2f3309095eee33947f42c0af9aa93f@haskell.org> References: <046.0c2f3309095eee33947f42c0af9aa93f@haskell.org> Message-ID: <061.abf38a52083adca021723206fae25aad@haskell.org> #9079: Foreign.C.Types in haskell2010 ------------------------------------------+-------------------------------- Reporter: tensor5 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.8.2 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by tensor5): I'm talking about compiling using `haskell2010`: {{{ ghc -package haskell2010 -hide-package base Test.hs }}} As I see from [http://git.haskell.org/packages/haskell2010.git/blob/HEAD:/Foreign/C/Types.hs this source] the constructors for C types are not exposed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 09:22:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 09:22:28 -0000 Subject: [GHC] #9079: Foreign.C.Types in haskell2010 In-Reply-To: <046.0c2f3309095eee33947f42c0af9aa93f@haskell.org> References: <046.0c2f3309095eee33947f42c0af9aa93f@haskell.org> Message-ID: <061.d5bd66782dd384fa5b1b14511ba17427@haskell.org> #9079: Foreign.C.Types in haskell2010 ------------------------------------------+-------------------------------- Reporter: tensor5 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.8.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 tensor5): * status: closed => new * resolution: worksforme => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 09:31:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 09:31:42 -0000 Subject: [GHC] #9079: Foreign.C.Types in haskell2010 In-Reply-To: <046.0c2f3309095eee33947f42c0af9aa93f@haskell.org> References: <046.0c2f3309095eee33947f42c0af9aa93f@haskell.org> Message-ID: <061.c50949ddaa118052a4804b306b85e6ec@haskell.org> #9079: Foreign.C.Types in haskell2010 ------------------------------------------+-------------------------------- Reporter: tensor5 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.8.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 hvr): I believe this is related to the breaking change that went into GHC 7.6.1: {{{ Warning: newtype `CInt' is used in an FFI declaration, but its constructor is not in scope. This will become an error in GHC 7.6.1. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 10:55:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 10:55:45 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.5ecf6257af243ca6f84bede347eccf61@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 ezyang): This patch seems to do the trick. {{{ diff --git a/rts/Stable.c b/rts/Stable.c index ec74b0d..431b7c6 100644 --- a/rts/Stable.c +++ b/rts/Stable.c @@ -246,6 +246,7 @@ STATIC_INLINE void freeSnEntry(snEntry *sn) { ASSERT(sn->sn_obj == NULL); + removeHashTable(addrToStableHash, (W_)sn->old, NULL); sn->addr = (P_)stable_name_free; stable_name_free = sn; } }}} Alas, there are a bunch of validate failures at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 13:34:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 13:34:53 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.c96d472d3a878e084e477520aee54367@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.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 --------------------------------------------+------------------------------ Comment (by archblob): I have implemented what we have discussed in comment 28 as {{{ data IfaceType = .... | IfaceTyConApp IfaceTyCon [IfaceTcArg] | ... data IfaceTcArg = ITC_Type IfaceType | ITC_Kind IfaceKind }}} because as I understood it all we want are tags, so I have found this easier to work with than ad hoc lists, please correct me if I am wrong. I also saw that you have changed the way we print foralls, so I will implement that approach in this case too. We will also have to add extra information to one of {{{IfaceClosedSynFamilyTyCon}}} or {{{IfaceSyn}}} constructors in order to print closed type families the way we do now, but this should not be a problem. I have run the tests and the implementation works except when printing qualified names, for example: {{{ data Int = GHC.Types.I# GHC.Prim.Int# }}} prints like {{{data Int = I# GHC.Prim.Int#}}} this is T8469, and we have more of the same for ghci051 with {{{ -data Ghci1.T = A | ... -- Defined at :3:10 -data Ghci4.T = B | ... -- Defined at :6:12 +data T = A | ... -- Defined at :3:10 +data T = B | ... -- Defined at :6:12 }}} I will look into this after I sorted out all the other stuff, but in the mean time any suggestions would be nice. I wrote this as a progress update, and if everything goes well i'll have the patch ready in a couple of days. Andrei -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 14:12:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 14:12:54 -0000 Subject: [GHC] #8849: Unregisterised compiler: arithmetic failure In-Reply-To: <047.9ee4d36bdad2511c808fcc03f7b6b140@haskell.org> References: <047.9ee4d36bdad2511c808fcc03f7b6b140@haskell.org> Message-ID: <062.4dc471f469debf964d28e3c111659511@haskell.org> #8849: Unregisterised compiler: arithmetic failure ------------------------------------------------+-------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 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: 8819 | Difficulty: | Unknown | Blocked By: | Related Tickets: #8819 ------------------------------------------------+-------------------------- Changes (by trommler): * blocking: => 8819 * milestone: => 7.8.3 Comment: As this is a regression from 7.6.3 we should look into this for 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 14:32:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 14:32:25 -0000 Subject: [GHC] #9080: GHC error on Win 8.1 64bit Message-ID: <043.c0aa3d5bf848f70ddef90000b43fffd8@haskell.org> #9080: GHC error on Win 8.1 64bit ----------------------------------+--------------------------------------- Reporter: maun | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- Hi, i get the following error when building GHCJS: {{{ Loading package conduit-1.1.1 ... linking ... done. Loading package yaml-0.8.8.2 ... ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-mingw32): loadObj "C:\\Users\\Manuel\\AppData\\Roaming\\cabal\\x86_64 -windows-ghc- 7.8.2\\yaml-0.8.8.2\\HSyaml-0.8.8.2.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghc.exe: Unknown PEi386 section name `.text.unlikely' (while processing: C:\User s\Manuel\AppData\Roaming\cabal\x86_64-windows- ghc-7.8.2\yaml-0.8.8.2\HSyaml-0.8. 8.2.o) cabal: Error: some packages failed to install: ghcjs-0.1.0 failed during the building phase. The exception was: ExitFailure 1 }}} Also reported this for ghcjs (https://github.com/ghcjs/ghcjs/issues/170) I am not using the haskell plattform, but the 7.8.2 binaries + MinGW and MSYS. I also tried mingw-w64 but this made no difference. I am also using the recent ghcjs cabal branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 15:18:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 15:18:22 -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.7e117b0a07abc2b920873cc43e0dc4d9@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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 simonmar): My apologies for making a buggy test program :-) Thanks for eliminating the strangeness there. So it seems that `dlsym` always returns a bogus result for `environ`. Your proposed fix only works if we load libraries with `RTLD_LOCAL` rather than `RTLD_GLOBAL`, I think. That is probably fine, but it needs testing. This commit that introduced `internal_dlsym` explains the rationale: be497c202b790999c3fd0ddc4a4176b8cf6acf7e I'm fine with refactoring away the `hdl` argument. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 16:18:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 16:18:03 -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.ab98fd48102ce9626c66fee50c37cac3@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.3 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 trommler): * status: infoneeded => new Comment: Replying to [comment:29 simonmar]: > My apologies for making a buggy test program :-) Thanks for eliminating the strangeness there. No problem! I learned a lot about dynamic linking! > So it seems that `dlsym` always returns a bogus result for `environ`. No, no, it does not look bad at all. The address looks strange but that is caused by the fact that it was created by the dynamic linker. Look at `*defl_env` and `*env` in the second program in comment:25. The addresses match and I checked they really point to the environment array! In the first program the static linker creates the reference for environ because we take its address `&environ` to print it. So there is a static symbol already there and that confuses the dynamic linker when it searches in `libgmp` and then finds `environ` in `libc`. Once we have fixed this bug I will read the ELF specs again and see if giving us a defunct symbol when we load a weak symbol again is really allowed by the specification. > > Your proposed fix only works if we load libraries with `RTLD_LOCAL` rather than `RTLD_GLOBAL`, I think. That is probably fine, but it needs testing. This commit that introduced `internal_dlsym` explains the rationale: be497c202b790999c3fd0ddc4a4176b8cf6acf7e > > I'm fine with refactoring away the `hdl` argument. There is a branch on my github [https://github.com/trommler/ghc/tree/rtld-8935] where I implemented that and what I proposed above. While my AMD 64 bit and my old PowerMac G5 build ghc, I will read up on the rationale for `internal_dlsym`. If validate succeeds and I am sufficiently confident I understand what `internal_dlsym` needs to do. I'll post my patches. We can remove the info needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 16:28:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 16:28:45 -0000 Subject: [GHC] #9081: Template Haskell gets confused with scoped kind variables in a class declaration Message-ID: <047.fe8a263339c672a80ffdf52fdaf5cb15@haskell.org> #9081: Template Haskell gets confused with scoped kind variables in a class declaration ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TemplateHaskell, DataKinds, PolyKinds, TypeFamilies #-} module Bug where import Data.Proxy $( [d| class kproxy ~ 'KProxy => C (kproxy :: KProxy a) where type TF (x :: a) :: Bool |]) }}} I get {{{ /Users/rae/temp/Bug.hs:7:4: Kind variable also used as type variable: ?a_asJA? In the declaration for class C_asJy /Users/rae/temp/Bug.hs:7:4: The exact Name ?kproxy_asJB? is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful }}} The code in the TH quote compiles fine on its own. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 17:23:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 17:23:51 -0000 Subject: [GHC] #9081: Template Haskell gets confused with scoped kind variables in a class declaration In-Reply-To: <047.fe8a263339c672a80ffdf52fdaf5cb15@haskell.org> References: <047.fe8a263339c672a80ffdf52fdaf5cb15@haskell.org> Message-ID: <062.504780be89701f76b4500f5c4bdb29e2@haskell.org> #9081: Template Haskell gets confused with scoped kind variables in a class declaration -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.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 goldfire): This problem came up in a slightly different context. Compiling this module {{{ {-# LANGUAGE TemplateHaskell, TypeFamilies, PolyKinds #-} module A where import Language.Haskell.TH $( do a <- newName "a" k <- newName "k" b <- newName "b" return [ ClassD [] (mkName "C") [KindedTV a (VarT k)] [] [ FamilyD TypeFam (mkName "TF") [KindedTV b (VarT k)] Nothing ] ] ) $(do infoC <- reify ''C infoTF <- reify ''TF runIO $ do putStrLn (show infoC) putStrLn (show infoTF) return []) }}} produces {{{ ClassI (ClassD [] A.C [KindedTV a_1627506463 (VarT k_1627506468)] [] []) [] FamilyI (FamilyD TypeFam A.TF [KindedTV b_1627506465 (VarT k_1627506464)] (Just StarT)) [] }}} Note that the uniques in the `k` variables in the output are different. It's possible that these are two separate bugs, but my hunch is that they are the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 17:31:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 17:31:34 -0000 Subject: [GHC] #8100: Standalone deriving using template haskell In-Reply-To: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> References: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> Message-ID: <059.db38f2ef0d890f5e06b45fbfac395c97@haskell.org> #8100: Standalone deriving using template haskell -------------------------------------+------------------------------------ Reporter: acube | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 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): At the least, if this remains unimplemented, quoting a use of standalone deriving should result in an error, instead of silent ignoring. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 17:32:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 17:32:09 -0000 Subject: [GHC] #9081: Template Haskell gets confused with scoped kind variables in a class declaration In-Reply-To: <047.fe8a263339c672a80ffdf52fdaf5cb15@haskell.org> References: <047.fe8a263339c672a80ffdf52fdaf5cb15@haskell.org> Message-ID: <062.64a0ad27039fbc590cad954e6adcf537@haskell.org> #9081: Template Haskell gets confused with scoped kind variables in a class declaration -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.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 goldfire): Confirmed reproducible in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 18:30:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 18:30:37 -0000 Subject: [GHC] #9015: A documented way to differentiate between statements, declarations, imports, etc. In-Reply-To: <054.7f6a461675f798415503e3e2ad38cdb0@haskell.org> References: <054.7f6a461675f798415503e3e2ad38cdb0@haskell.org> Message-ID: <069.b7c85fdaa89dd085b3087d9aec28f683@haskell.org> #9015: A documented way to differentiate between statements, declarations, imports, etc. -------------------------------------+------------------------------------- Reporter: splinterofchaos | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Moderate (less bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by splinterofchaos): On second thought, my computer bricked and I lost my internet connection. Might be quite a while. If someone else could pick this up, I'd appreciate it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 19:05:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 19:05:34 -0000 Subject: [GHC] #9082: Unexpected behavior involving closed type families and repeat occurrences of variables Message-ID: <044.a66f2386692a9917075df18ca55ea3d0@haskell.org> #9082: Unexpected behavior involving closed type families and repeat occurrences of variables -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I'd expect both of these to work fine, but GHC always picks the instance that is mentioned first: {{{ {-# LANGUAGE TypeFamilies, DataKinds #-} type family Bad a b where Bad (f a) a = False Bad a a = True bad :: ( Bad (f a) a ~ False , Bad a a ~ True ) => () bad = () -- Swapping the lines around does not change the behavior much: type family Bad' a b where Bad' a a = True Bad' (f a) a = False bad' :: ( Bad' (f a) a ~ False , Bad' a a ~ True ) => () bad' = () {- ctf.hs:7:8: Could not deduce (Bad a0 a0 ~ 'True) from the context (Bad (f a) a ~ 'False, Bad a a ~ 'True) bound by the type signature for bad :: (Bad (f a) a ~ 'False, Bad a a ~ 'True) => () at ctf.hs:(7,8)-(9,14) The type variable ?a0? is ambiguous In the ambiguity check for: forall (f :: * -> *) a. (Bad (f a) a ~ 'False, Bad a a ~ 'True) => () To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ?bad?: bad :: (Bad (f a) a ~ False, Bad a a ~ True) => () ctf.hs:18:9: Could not deduce (Bad' (f0 a0) a0 ~ 'False) from the context (Bad' (f a) a ~ 'False, Bad' a a ~ 'True) bound by the type signature for bad' :: (Bad' (f a) a ~ 'False, Bad' a a ~ 'True) => () at ctf.hs:(18,9)-(20,14) The type variables ?f0?, ?a0? are ambiguous In the ambiguity check for: forall (f :: * -> *) a. (Bad' (f a) a ~ 'False, Bad' a a ~ 'True) => () To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ?bad'?: bad' :: (Bad' (f a) a ~ False, Bad' a a ~ True) => () -} }}} Trying to turn this into an open type family instead somewhat hints at the issue: {{{ type family Bad'' a b :: Bool type instance Bad'' a a = True type instance Bad'' (f a) a = False {- ctf.hs:58:15: Conflicting family instance declarations: Bad'' a a -- Defined at ctf.hs:58:15 Bad'' (f a) a -- Defined at ctf.hs:59:15 -} }}} It seems like GHC thinks these two family definitions conflict, yet to me they seem distinct - as a type that would match both would imply f a ~ a and hence be infinite. Can anybody offer insight into this issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 19:17:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 19:17:25 -0000 Subject: [GHC] #9082: Unexpected behavior involving closed type families and repeat occurrences of variables In-Reply-To: <044.a66f2386692a9917075df18ca55ea3d0@haskell.org> References: <044.a66f2386692a9917075df18ca55ea3d0@haskell.org> Message-ID: <059.3b260d104ccdf99df23857b77a05effa@haskell.org> #9082: Unexpected behavior involving closed type families and repeat occurrences of variables ----------------------------------------------+---------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by haasn): Oh, while simplifying the example it seems I simplified too much, this bug goes away if you make ?a? and ?b? less ambiguous. I'll have to think a bit more about the un-simplified example that fails to work, I may close this ticket again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 19:25:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 19:25:31 -0000 Subject: [GHC] #9082: Unexpected behavior involving closed type families and repeat occurrences of variables In-Reply-To: <044.a66f2386692a9917075df18ca55ea3d0@haskell.org> References: <044.a66f2386692a9917075df18ca55ea3d0@haskell.org> Message-ID: <059.a0dfcf653127077823da4f8434e6fd6d@haskell.org> #9082: Unexpected behavior involving closed type families and repeat occurrences of variables ----------------------------------------------+---------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by haasn): Here's an updated example that fails. It seems the issue is more complicated, GHC picks the right case in the latter examples (regardless of order), but it fails on either ?bar? or ?foo? depending on the order of the cases in the type family Bad. {{{ {-# LANGUAGE TypeFamilies, DataKinds #-} type family Bad a b where Bad (m a -> b) a = b Bad (a -> b) a = b foo :: Monad m => (m a -> b) -> a -> Bad (m a -> b) a foo f a = f (return a) bar :: (a -> b) -> a -> Bad (a -> b) a bar f a = f a {- ctf.hs:11:11: Couldn't match expected type ?Bad (a -> b) a? with actual type ?b? ?b? is a rigid type variable bound by the type signature for bar :: (a -> b) -> a -> Bad (a -> b) a at ctf.hs:10:8 Relevant bindings include a :: a (bound at ctf.hs:11:7) f :: a -> b (bound at ctf.hs:11:5) bar :: (a -> b) -> a -> Bad (a -> b) a (bound at ctf.hs:11:1) In the expression: f a In an equation for ?bar?: bar f a = f a Failed, modules loaded: none. -} -- But this type-checks just fine: type family Bad' a b where Bad' (m a -> b) a = True Bad' (a -> b) a = False foo' :: (Monad m, Bad' (m a -> b) a ~ True) => (m a -> b) -> a -> b foo' f a = f (return a) bar' :: Bad' (a -> b) a ~ False => (a -> b) -> a -> b bar' f a = f a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 19:51:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 19:51:21 -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.0d2a8699275edc1a08f8f94d61483bef@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.3 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): Validating on x86_64 Linux: {{{ Unexpected failures: codeGen/should_run cgrun051 [bad exit code] (normal) ffi/should_compile cc004 [stderr mismatch] (normal) ffi/should_run T2276_ghci [bad stdout or stderr] (ghci) ghci/scripts T8696 [bad stderr] (ghci) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) }}} So two dynamic linking related test failures: T2276_ghci and T8696. T2276_ghci: {{{ =====> T2276_ghci(ghci) 3154 of 3962 [0, 0, 0] cd ./ffi/should_run && $MAKE -s --no-print-directory T2276_ghci_setup T2276_ghci_c.c:4:1: warning: ?stdcall? attribute ignored [-Wattributes] { ^ cd ./ffi/should_run && '/local/home/peter/ghc-validate/inplace/bin/ghc- stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-ghci-history T2276_ghci.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS -fobject-code T2276_ghci_c.o T2276_ghci.interp.stdout 2>T2276_ghci.interp.stderr Actual stderr output differs from expected: --- /dev/null 2014-05-06 16:04:29.720620754 +0200 +++ ./ffi/should_run/T2276_ghci.run.stderr 2014-05-06 21:35:41.193750997 +0200 @@ -0,0 +1,6 @@ +ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.9.20140506 for x86_64-unknown-linux): + Loading temp shared object failed: /tmp/ghc18005_0/ghc18005_5.so: undefined symbol: test + }}} The warning about `stdcall` is strange. and T8696: {{{ =====> T8696(ghci) 3619 of 3962 [0, 0, 0] cd ./ghci/scripts && HC='/local/home/peter/ghc-validate/inplace/bin/ghc- stage2' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-ghci-history ' '/local/home/peter/ghc- validate/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history T8696.run.stdout 2>T8696.run.stderr Actual stderr output differs from expected: --- /dev/null 2014-05-06 16:04:29.720620754 +0200 +++ ./ghci/scripts/T8696.run.stderr 2014-05-06 21:37:54.034299041 +0200 @@ -0,0 +1,6 @@ +ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.9.20140506 for x86_64-unknown-linux): + Loading temp shared object failed: /tmp/ghc18096_0/ghc18096_4.so: undefined symbol: T8696A_a_closure + }}} The performance tests pass when I run them from the command line (I validated with `CPUS=4`) and I seem to remember that `cgrun051` exit code was discussed on `ghc-devs` recently. I have no idea what to make of `cc004` and the warning about `stdcall` calling convention not implemented on my platform. And last but not least: {{{ghc -e 'System.Environment.getEnvironment'}}} does not segfault but prints the actual environment. I'll prepare a patch and attach it to the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 20:38:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 20:38:09 -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.4729fd3cdc89109768f2bb6e46adf1fd@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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 trommler): * status: new => patch Comment: I attached four patches for review. I'll check if I see the test failures also in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 20:43:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 20:43:34 -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.bf0e0a90adf9903227243751bd5ba757@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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 simonmar): > No, no, it does not look bad at all. The address looks strange but that is caused by the fact that it was created by the dynamic linker. Look at *defl_env and *env in the second program in comment:25. The addresses match and I checked they really point to the environment array! Well, every time we call `dlsym` passing the handle of a `dlopen`'d library, we get a bogus result. This happens for both `libgmp` and `libpthread` (after modifying the `libpthread` path to point to the real .so, not the linker script). {{{ #include #include #include char *so = "/usr/lib/x86_64-linux-gnu/libgmp.so"; char *so2 = "/lib/x86_64-linux-gnu/libpthread.so.0"; extern char**environ; int main(int argc, char *argv[]) { void *deflt, *hdl; char ***env; deflt = dlopen(NULL, RTLD_LAZY | RTLD_GLOBAL); printf("&environ = %p, environ = %p\n", &environ, environ); env = dlsym(deflt,"environ"); printf("dlsym(deflt, \"environ\") = %p, *env = %p\n", env, *env ); hdl = dlopen(so, RTLD_LAZY); if (hdl == NULL) { printf("%s\n", dlerror()); exit(1); } env = dlsym(hdl,"environ"); printf("dlsym(\"libgmp\", \"environ\") = %p, *env = %p\n", env, *env); hdl = dlopen(so2, RTLD_LAZY); if (hdl == NULL) { printf("%s\n", dlerror()); exit(1); } env = dlsym(hdl,"environ"); printf("dlsym(\"libpthread\", \"environ\") = %p, *env = %p\n", env, *env); } }}} output: {{{ $ ./a.out &environ = 0x601078, environ = 0x7fffc44c2008 dlsym(deflt, "environ") = 0x601078, *env = 0x7fffc44c2008 dlsym("libgmp", "environ") = 0x2ba8772b64e8, *env = (nil) dlsym("libpthread", "environ") = 0x2ba8772b64e8, *env = (nil) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 21:22:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 21:22:03 -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.faf2aff6131794a21687c19634c0923b@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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): Replying to [comment:33 simonmar]: > > No, no, it does not look bad at all. The address looks strange but that is caused by the fact that it was created by the dynamic linker. Look at *defl_env and *env in the second program in comment:25. The addresses match and I checked they really point to the environment array! > > Well, every time we call `dlsym` passing the handle of a `dlopen`'d library, we get a bogus result. This happens for both `libgmp` and `libpthread` (after modifying the `libpthread` path to point to the real .so, not the linker script). Yes, that is consistent with what I expect from our previous experiments. I don't say I understand yet why the dynamic linker gives us a broken symbol and if this behavior is correct. What I know is that the dynamic linker treats weak symbols the same as strong symbols. And then there is a conflict: In the program there is a symbol `environ` created by the static linker and now there is another symbol `environ` and that is not permitted and instead of failing we get this `NULL` pointer. I bet all libraries that depend on libc directly or indirectly will exhibit the behavior we see. But that was not my point. I wanted to say, when we look for `environ` in `RTLD_DEFAULT` we will get a properly set up pointer to the environment. My second test program (in comment:25) was meant to demonstrate that this is also true when we do not refer to `environ` in the program itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 21:23:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 21:23:45 -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.fdf0f3cee06375856e711c547eb7913f@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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): Replying to [comment:32 trommler]: > I attached four patches for review. > > I'll check if I see the test failures also in HEAD. The validate on HEAD just finished. The two failures I reported earlier are regressions. I will look into these on Thursday. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 22:16:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 22:16:54 -0000 Subject: [GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0 In-Reply-To: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> References: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> Message-ID: <065.2d39e0078caa406d76395827e5225299@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 ----------------------------------------+--------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Driver | Version: 7.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Changes (by nomeata): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 22:18:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 22:18:26 -0000 Subject: [GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0 In-Reply-To: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> References: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> Message-ID: <065.0a553618477d4c4ffa102f172f334481@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 ----------------------------------------+--------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Driver | Version: 7.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by nomeata): Having this fixed in 7.8.3 would be greatly appreciated by Debian as well. Is Karel aware of this bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 6 23:10:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 May 2014 23:10:35 -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.c7f2b53625183d9f0b7c27cdbcd7c12d@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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 dagit): Here is the test program I use: {{{ #include #include #include int jason; extern char**environ; char envname[] = "environ"; char jasname[] = "jason"; char weakname[] = "weak_jason"; void dlsym_check(void *handle, char * lib, char * sym){ void * e = dlsym(handle,sym); fprintf(stderr, "dlsym(\"%s\", \"%s\") = %p\n", lib, sym, e); char * error = dlerror(); if( error != NULL ) fprintf(stderr, "Errors: %s\n", error); } int main(int argc, char *argv[]) { if( argc < 3 ){ printf("usage: ./check-environ \n"); exit(1); } char* so = argv[1]; char* so2 = argv[2]; void *deflt, *hdl, *hdl2; deflt = dlopen(NULL, RTLD_LAZY | RTLD_GLOBAL); dlsym_check(deflt, so, envname); hdl = dlopen(so, RTLD_LAZY | RTLD_GLOBAL); if( hdl == NULL ){ fprintf(stderr, "Error: %s", dlerror()); exit(1); } hdl2 = dlopen(so2, RTLD_LAZY | RTLD_GLOBAL); if( hdl2 == NULL ){ fprintf(stderr, "Error: %s", dlerror()); exit(1); } fprintf(stderr, "\nFind a symbol that is located here and libc\n"); dlsym_check(deflt, so, envname); dlsym_check(hdl, so, envname); dlsym_check(RTLD_DEFAULT, so, envname); dlsym_check(RTLD_NEXT, so, envname); fprintf(stderr, "\nFind a symbol that is only defined in this executable\n"); dlsym_check(deflt, so, jasname); dlsym_check(hdl, so, jasname); dlsym_check(RTLD_DEFAULT, so, jasname); dlsym_check(RTLD_NEXT, so, jasname); fprintf(stderr, "\nFind a symbol that is only defined weak in a shared object\n"); dlsym_check(deflt, so2, weakname); dlsym_check(hdl2, so2, weakname); dlsym_check(RTLD_DEFAULT, so2, weakname); dlsym_check(RTLD_NEXT, so2, weakname); } }}} That lives in check-environ.c, so I build that with: {{{ LDFLAGS=-ldl CFLAGS=-rdynamic make check-environ }}} (No actual build file required, I just use implicit rules.) I also have test.c, containing just one line: {{{ int __attribute__((weak)) weak_jason; }}} Built with: `gcc -shared -fpic test.c -o test.so` Notice I've added a symbol "jason" that is not defined anywhere but in the executable. I use `-rdynamic` as the manpage for `dlsym` suggests. The test.so shared object has a weak symbol definition for `weak_jason` (you should double check me). I've also duplicated the handle options to `dlsym` just so we can see how they change the behavior. When I run it: {{{ $ ./check-environ libgmp.so ./test.so 2>&1 dlsym("libgmp.so", "environ") = 0x31e45bd508 Find a symbol that is located here and libc dlsym("libgmp.so", "environ") = 0x31e45bd508 dlsym("libgmp.so", "environ") = 0x31e45bd508 dlsym("libgmp.so", "environ") = 0x31e45bd508 dlsym("libgmp.so", "environ") = 0x31e45bd508 Find a symbol that is only defined in this executable dlsym("libgmp.so", "jason") = 0x60208c dlsym("libgmp.so", "jason") = (nil) Errors: /lib64/libgmp.so: undefined symbol: jason dlsym("libgmp.so", "jason") = 0x60208c dlsym("libgmp.so", "jason") = (nil) Find a symbol that is only defined weak in a shared object dlsym("./test.so", "weak_jason") = 0x7f8de2f1e02c dlsym("./test.so", "weak_jason") = 0x7f8de2f1e02c dlsym("./test.so", "weak_jason") = 0x7f8de2f1e02c dlsym("./test.so", "weak_jason") = 0x7f8de2f1e02c }}} I then ran it with `LD_DEBUG=all`, and looked at the output for `environ`. {{{ Find a symbol that is located here and libc 21283: symbol=environ; lookup in file=./check-environ [0] 21283: symbol=environ; lookup in file=/lib64/libdl.so.2 [0] 21283: symbol=environ; lookup in file=/lib64/libc.so.6 [0] 21283: binding file ./check-environ [0] to /lib64/libc.so.6 [0]: normal symbol `environ' dlsym("libgmp.so", "environ") = 0x31e45bd508 21283: symbol=environ; lookup in file=/lib64/libgmp.so [0] 21283: symbol=environ; lookup in file=/lib64/libc.so.6 [0] 21283: binding file /lib64/libgmp.so [0] to /lib64/libc.so.6 [0]: normal symbol `environ' dlsym("libgmp.so", "environ") = 0x31e45bd508 21283: symbol=environ; lookup in file=./check-environ [0] 21283: symbol=environ; lookup in file=/lib64/libdl.so.2 [0] 21283: symbol=environ; lookup in file=/lib64/libc.so.6 [0] 21283: binding file ./check-environ [0] to /lib64/libc.so.6 [0]: normal symbol `environ' dlsym("libgmp.so", "environ") = 0x31e45bd508 21283: symbol=environ; lookup in file=/lib64/libdl.so.2 [0] 21283: symbol=environ; lookup in file=/lib64/libc.so.6 [0] 21283: binding file ./check-environ [0] to /lib64/libc.so.6 [0]: normal symbol `environ' dlsym("libgmp.so", "environ") = 0x31e45bd508 }}} In each cases, once it found the definition in libc it stopped looking (even though it's `WEAK`). The search for `weak_jason` is similar, but it has to keep looking until it gets to test.so. I think it's safe to say that the behavior is not specific to environ or libc: {{{ Find a symbol that is only defined weak in a shared object 21283: symbol=weak_jason; lookup in file=./check-environ [0] 21283: symbol=weak_jason; lookup in file=/lib64/libdl.so.2 [0] 21283: symbol=weak_jason; lookup in file=/lib64/libc.so.6 [0] 21283: symbol=weak_jason; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 21283: symbol=weak_jason; lookup in file=/lib64/libgmp.so [0] 21283: symbol=weak_jason; lookup in file=./test.so [0] 21283: binding file ./check-environ [0] to ./test.so [0]: normal symbol `weak_jason' dlsym("./test.so", "weak_jason") = 0x7f0e99fbd02c 21283: symbol=weak_jason; lookup in file=./test.so [0] 21283: binding file ./test.so [0] to ./test.so [0]: normal symbol `weak_jason' dlsym("./test.so", "weak_jason") = 0x7f0e99fbd02c 21283: symbol=weak_jason; lookup in file=./check-environ [0] 21283: symbol=weak_jason; lookup in file=/lib64/libdl.so.2 [0] 21283: symbol=weak_jason; lookup in file=/lib64/libc.so.6 [0] 21283: symbol=weak_jason; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 21283: symbol=weak_jason; lookup in file=/lib64/libgmp.so [0] 21283: symbol=weak_jason; lookup in file=./test.so [0] 21283: binding file ./check-environ [0] to ./test.so [0]: normal symbol `weak_jason' dlsym("./test.so", "weak_jason") = 0x7f0e99fbd02c 21283: symbol=weak_jason; lookup in file=/lib64/libdl.so.2 [0] 21283: symbol=weak_jason; lookup in file=/lib64/libc.so.6 [0] 21283: symbol=weak_jason; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 21283: symbol=weak_jason; lookup in file=/lib64/libgmp.so [0] 21283: symbol=weak_jason; lookup in file=./test.so [0] 21283: binding file ./check-environ [0] to ./test.so [0]: normal symbol `weak_jason' dlsym("./test.so", "weak_jason") = 0x7f0e99fbd02c }}} In the case of the `jason` symbol: {{{ Find a symbol that is only defined in this executable 21283: symbol=jason; lookup in file=./check-environ [0] 21283: binding file ./check-environ [0] to ./check-environ [0]: normal symbol `jason' dlsym("libgmp.so", "jason") = 0x60208c 21283: symbol=jason; lookup in file=/lib64/libgmp.so [0] 21283: symbol=jason; lookup in file=/lib64/libc.so.6 [0] 21283: symbol=jason; lookup in file=/lib64/ld-linux-x86-64.so.2 [0] 21283: /lib64/libgmp.so: error: symbol lookup error: undefined symbol: jason (fatal) dlsym("libgmp.so", "jason") = (nil) 21283: symbol=__dcgettext; lookup in file=./check-environ [0] 21283: symbol=__dcgettext; lookup in file=/lib64/libdl.so.2 [0] 21283: symbol=__dcgettext; lookup in file=/lib64/libc.so.6 [0] 21283: binding file /lib64/libdl.so.2 [0] to /lib64/libc.so.6 [0]: normal symbol `__dcgettext' [GLIBC_2.2.5] 21283: symbol=__asprintf; lookup in file=./check-environ [0] 21283: symbol=__asprintf; lookup in file=/lib64/libdl.so.2 [0] 21283: symbol=__asprintf; lookup in file=/lib64/libc.so.6 [0] 21283: binding file /lib64/libdl.so.2 [0] to /lib64/libc.so.6 [0]: normal symbol `__asprintf' [GLIBC_2.2.5] 21283: symbol=free; lookup in file=./check-environ [0] 21283: symbol=free; lookup in file=/lib64/libdl.so.2 [0] 21283: symbol=free; lookup in file=/lib64/libc.so.6 [0] 21283: binding file /lib64/libdl.so.2 [0] to /lib64/libc.so.6 [0]: normal symbol `free' [GLIBC_2.2.5] Errors: /lib64/libgmp.so: undefined symbol: jason 21283: symbol=jason; lookup in file=./check-environ [0] 21283: binding file ./check-environ [0] to ./check-environ [0]: normal symbol `jason' dlsym("libgmp.so", "jason") = 0x60208c 21283: symbol=jason; lookup in file=/lib64/libdl.so.2 [0] 21283: symbol=jason; lookup in file=/lib64/libc.so.6 [0] 21283: symbol=jason; lookup in file=/lib64/ld-linux-x86-64.so.2 [0] 21283: symbol=jason; lookup in file=/lib64/libgmp.so [0] 21283: symbol=jason; lookup in file=./test.so [0] dlsym("libgmp.so", "jason") = (nil) }}} The point though, is that `dlsym` is doing exactly what it should: It returns the first global definition it finds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 01:31:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 01:31:59 -0000 Subject: [GHC] #9082: Unexpected behavior involving closed type families and repeat occurrences of variables In-Reply-To: <044.a66f2386692a9917075df18ca55ea3d0@haskell.org> References: <044.a66f2386692a9917075df18ca55ea3d0@haskell.org> Message-ID: <059.7b4377b0006376f456f84e022078e364@haskell.org> #9082: Unexpected behavior involving closed type families and repeat occurrences of variables ----------------------------------------------+---------------------------- Reporter: haasn | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: As far as I can tell, GHC is doing the right thing here, but "the right thing" is subtle, indeed. We're at the intersection of closed type families, non-linear patterns, and infinite types, and that is a strange place indeed. I encourage you to read Section 6 of [http://www.cis.upenn.edu/~eir/papers/2014/axioms/axioms.pdf the closed type families paper]. I will try to apply the logic there to your situation. Let's focus on your first (simpler) example, as I think the reasoning there extends to the more complicated one in your most recent comment: {{{ type family Bad a b where Bad (f a) a = False Bad a a = True }}} Now, consider the following beast: {{{ type family G a where G a = Maybe (G a) }}} How can we reduce the target `Bad (G Int) (G Int)`? The first equation doesn't seem to match, and the second does. But, now we must do the apartness check with the first equation... is it ever possible for the first one to match? Sure it is, if the first `(G Int)` steps to `(Maybe (G Int))` (with `f |-> Maybe` and `a |-> G Int`). So, the first equation isn't apart from our target, so the second equation can't be used. Perhaps GHC will be clever enough to reduce the first `(G Int)` and then apply the first equation, but I wouldn't hold my breath. How does this affect you, without such a `G`? If we try to reduce a target `Bad x x`, GHC will be stuck. The first equation clearly doesn't match, and the second equation does. But, the first equation is ''not'' apart from `Bad x x`, because of the possibility that someone will define `G` and then instantiate `x` with `G Int`. This case is ''subtle'', and it took years of living with type families before we realized that this bizarre situation can actually cause a crash with open type families. See #8162. Though that bug deals with open families, I can imagine an adaptation that would cause a crash with closed ones. An ideal world would produce an error report with a link to the paper, etc., in your situation, but detecting the situation is hard -- I believe we would have to run both the infinite unification algorithm as well as a normal unification algorithm, notice that the results are different, and then know we are in this place. I'm happy to see suggestions for a better way. If you do have suggestions, do please reopen. Or, perhaps it's worth putting in a feature request for a better error message, even without a way to achieve that goal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 02:39:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 02:39:49 -0000 Subject: [GHC] #9082: Unexpected behavior involving closed type families and repeat occurrences of variables In-Reply-To: <044.a66f2386692a9917075df18ca55ea3d0@haskell.org> References: <044.a66f2386692a9917075df18ca55ea3d0@haskell.org> Message-ID: <059.daad9b313daf1725c0e23e474b3e1785@haskell.org> #9082: Unexpected behavior involving closed type families and repeat occurrences of variables ----------------------------------------------+---------------------------- Reporter: haasn | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by haasn): Thanks for the feedback. As I understand it, {{{G}}} breaks this because it actually expands to an infinite type, and hence breaks my assumption that {{{f a ~ a}}} is impossible. This is also the reason why it requires {{{UndecidableInstances}}}. However, it is also my understanding that this type of infinite type family expansion is actually undecidable, in that answering {{{:k! Bad (G Int) (G Int)}}} actually fails to terminate. Do you know if there's an example of such a similarly ill-behaved {{{G}}} that either doesn't require {{{UndecidableInstances}}} or otherwise terminates with an incorrect result/breaks the type system if resolving {{{Bad}}} according to the reasoning outlined earlier? As of now, I don't grok why this would be an actual problem. I'll probably have to look at the papers involved and also #8162 to answer this myself, but I thought I'd quickly ask here first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 04:03:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 04:03:11 -0000 Subject: [GHC] #9083: symbol constructors declared prefix missing a leading colon are accepted Message-ID: <045.d6e80f1e05d9625fe7529f524436071f@haskell.org> #9083: symbol constructors declared prefix missing a leading colon are accepted -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{ data M = (++) Int data N = (?) Int data Ok = (:++) Int -- correctly accepted }}} I believe ghc should reject M and N. Instead `M` and `N` are accepted, but there seems to be no way to use that constructor (besides say a Data instance) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 05:45:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 05:45:42 -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.73c2df8a1936815ee88cf6c97cae8e48@haskell.org> #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ---------------------------------------+---------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 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 MagnusTherning): Now I've managed to figure out what causes the build failure. It's the combination of me using {{{git clone --bare --mirror}}} into a local mirror and the use of submodules with relative paths. This means that I will need to also mirror all the relevant package repos. AFAIU this basically means that the {{{-r}}} argument to {{{sync-all}}} won't work as I think it was intended. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 07:27:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 07:27:28 -0000 Subject: [GHC] #9083: symbol constructors declared prefix missing a leading colon are accepted In-Reply-To: <045.d6e80f1e05d9625fe7529f524436071f@haskell.org> References: <045.d6e80f1e05d9625fe7529f524436071f@haskell.org> Message-ID: <060.ed1f33571263f310e829a1434a211289@haskell.org> #9083: symbol constructors declared prefix missing a leading colon are accepted --------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.8.2 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 monoidal): * status: new => closed * resolution: => duplicate Comment: Thanks for the report; it's a duplicate of #8556. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 07:34:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 07:34:26 -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.7a7f5fa735118a01f0cb9a977f402144@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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 simonmar): > The point though, is that dlsym is doing exactly what it should: It returns the first global definition it finds. That's right, but let me add that weak symbols are a red herring. Let me demonstrate this without using weak symbols or `environ`. foo.c: {{{ int bar = 1; int getbar(void) { return bar; } }}} Compile it like this: {{{ $ gcc -fPIC foo.c -shared -o libfoo.so }}} Now the test program, `test.c`: {{{ #include #include #include extern int bar; extern int getbar(void); int main(int argc, char *argv[]) { void *deflt, *hdl; int *pbar; int (*pgetbar)(void); bar = 2; printf("&bar = %p, bar = %d, getbar() = %d\n", &bar, bar, getbar()); deflt = dlopen(NULL, RTLD_LAZY | RTLD_GLOBAL); if (hdl == NULL) { printf("%s\n", dlerror()); exit(1); } pbar = dlsym(deflt, "bar"); printf("dlsym(deflt, \"bar\") = %p, *pbar = %d\n", pbar, *pbar); pgetbar = dlsym(deflt, "getbar"); printf("dlsym(deflt, \"getbar\") = %p, pgetbar() = %d\n", pgetbar, (*pgetbar)()); hdl = dlopen("libfoo.so", RTLD_LAZY); if (hdl == NULL) { printf("%s\n", dlerror()); exit(1); } pbar = dlsym(hdl, "bar"); printf("dlsym(\"./libfoo.so\", \"bar\") = %p, *pbar = %d\n", pbar, *pbar); pgetbar = dlsym(hdl, "getbar"); printf("dlsym(deflt, \"getbar\") = %p, pgetbar() = %d\n", pgetbar, (*pgetbar)()); } }}} Note that we have `extern` references for both the data variable `bar` and the function `getbar`. Compile and run it like this: {{{ $ gcc test.c -ldl libfoo.so $ LD_LIBRARY_PATH=. ./a.out }}} {{{ $ LD_LIBRARY_PATH=. ./a.out &bar = 0x601060, bar = 2, getbar() = 2 dlsym(deflt, "bar") = 0x601060, *pbar = 2 dlsym(deflt, "getbar") = 0x2b9809ab259c, pgetbar() = 2 dlsym("./libfoo.so", "bar") = 0x2b9809cb3010, *pbar = 1 dlsym(deflt, "getbar") = 0x2b9809ab259c, pgetbar() = 2 }}} Note that: * the address of the function `getbar` is the same, regardless of whether we look it up in the main program or `libfoo.so` * the data variable `bar` has one address in the main program, and another one in `libfoo.so`. * the version in `libfoo.so` has the initial value 1, it wasn't updated by the assignment `bar = 2` in the main program * Calling `getbar()` returns the correct value 2, because the refernce to `bar` in `libfoo.so` has been relocated to point to the version of `bar` in the main program, not the one in `libfoo.so`. So I'm pretty sure that this is all due to the copy semantics that moves data variables into the main program. It means that if you use `dlsym` to find the address of a data variable, you might get the wrong answer. In any case, the correct fix for GHC ought to be to use `RTLD_LOCAL` and look up in the main program first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 11:19:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 11:19:12 -0000 Subject: [GHC] #9082: Unexpected behavior involving closed type families and repeat occurrences of variables In-Reply-To: <044.a66f2386692a9917075df18ca55ea3d0@haskell.org> References: <044.a66f2386692a9917075df18ca55ea3d0@haskell.org> Message-ID: <059.00592ebb0229123052d1332a404b4764@haskell.org> #9082: Unexpected behavior involving closed type families and repeat occurrences of variables ----------------------------------------------+---------------------------- Reporter: haasn | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by goldfire): I'm confident that any ill-behaved `G` ''would'' require `UndecidableInstances`. But, note that while that extension is needed in order to ''define'' `G`, it is not needed in order to ''use'' `G`. So, even if you do not have `UndecidableInstances` in your module, you are still under threat from such an attack. Looking at the example in #8162, the problem would be exactly the same if the family `F` (the equivalent to your `Bad`) were a closed type family. Open type families `LA` and `LB` are used to expose the crash, but the family with the overlap could be made closed, as all of its instances are declared together. Note that `F` is defined ''without'' `UndecidableInstances`. There is the possibility that some very clever analysis (and restrictions on things like `G` and/or `UndecidableInstances`) could allow `Bad` to behave as you might like. Indeed, we haven't actually proved type safety in the presence of non-linear (i.e., with a repeated variable on the LHS) and non-terminating type families, even taking infinite unification into account. That proof seems to require a solution to a recognized [http://www.win.tue.nl/rtaloop/problems/79.html open problem]. This lack of a proof actually extends to ''open'' type families as well -- the published proofs about non-terminating open type families implicitly (and very subtly) assumed linear patterns. After spending a Long Time working on this proof and failing to either find a proof or a counterexample, we (the authors of the "Closed Type Families" paper) were happy enough to conjecture type safety and keep non-linear patterns in the language. All of this does add up to a slightly bumpy surface area for the closed type families feature. I'm quite aware of this and am somewhat disappointed about it. But, my thought is not to let the great become the enemy of the good here -- most uses of closed type families work in an intuitive way and are really helpful to people. Then, some uses work in a really unintuitive way, and people get confused. I still think it's a good trade-off. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 15:40:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 15:40:31 -0000 Subject: [GHC] #9084: Template Haskell should warn when it encounters an unencodable pragma Message-ID: <047.5f052e5338f2346c8cf2671e4bbc517e@haskell.org> #9084: Template Haskell should warn when it encounters an unencodable pragma ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I say this {{{ {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -Wall #-} module Bug where $([d| class C a where meth :: a -> a meth = undefined -- give a (silly) default {-# MINIMAL meth #-} |]) instance C Int }}} I get no warnings. I'm not surprised that TH doesn't handle every pragma that GHC knows about, but it should issue a (suppressable) warning when it discards one. I can fix this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 15:46:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 15:46:31 -0000 Subject: [GHC] #9085: Inaccessible equations in a closed type family should be a warning, not an error Message-ID: <047.6f253560297252689a57f29dc4617e22@haskell.org> #9085: Inaccessible equations in a closed type family should be a warning, not an error ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 {{{ foo _ = () foo False = () }}} I get {{{ /Users/rae/temp/Bug.hs:2:1: Warning: Pattern match(es) are overlapped In an equation for ?foo?: foo False = ... }}} But, if I say {{{ {-# LANGUAGE TypeFamilies #-} type family Foo a where Foo x = () Foo Bool = () }}} I get {{{ /Users/rae/temp/Bug.hs:5:3: Inaccessible family instance equation: Foo Bool = () In the equations for closed type family ?Foo? In the type family declaration for ?Foo? }}} If this issues a warning at the term level, it probably should do the same at the type level. This was my design decision that I'm changing, and I will fix. The warning will be controlled by the same flag that controls the term-level version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 15:58:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 15:58:35 -0000 Subject: [GHC] #9086: main :: IO Int does different things with runghc and when compiled Message-ID: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> #9086: main :: IO Int does different things with runghc and when compiled --------------------------+------------------------------------------------ Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.2 Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Consider {{{ main :: IO Int main = return 1 }}} This does different things when compiled and when run with `runghc`/`runhaskell` (it prints an extra `1` with the latter). For practical purposes, I think it is beneficial if either of the two ways to run a Haskell program have the same output. Or did somebody intend this to happen? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 16:30:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 16:30:54 -0000 Subject: [GHC] #9087: Executables in the 7.8.2 Linux i386 binary tarball are not stripped Message-ID: <045.32e06e6ec3c181db27d068784d01610c@haskell.org> #9087: Executables in the 7.8.2 Linux i386 binary tarball are not stripped ----------------------------+-------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+-------------------------- At least on i386 Linux, the executables inside the GHC binary tarball seem to come with debug information. Stripping it noticeably reduces the binary sizes: {{{ $ file /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x6012a4c86cd3f410ca0e59ab4ac872ce740d03c6, not stripped $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc 1,4M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc $ strip -s /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc 1021K /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock 3,2M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock $ strip -s /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock 2,3M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock }}} Do we really need to include the debug info for exes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 17:03:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 17:03:30 -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.cf04d0c1512e5d8a555c2d826cf9b53f@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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 dagit): Great and thanks for the examples! By the way, weak not making a difference is the other half of the point I wanted to make :) I'm glad we're on the same page. I feel like I've learned something useful that I can use elsewhere. You might also look at `RTLD_DEEPBIND` for doing the initial symbol match up (when you use `RTLD_LOCAL`). I can't be certain, but I think it may help when reloading a shared object (presumably with new definitions inside). As far as I can tell, that option was added specifically for uses like this (I found some mailing list threads about it). I suspect the point with that option is that it allows consistent behavior even if something you don't have control over passes `RTLD_GLOBAL` to `dlopen`. My prediction is that if you switch to using `RTLD_LOCAL`, then you won't need `RTLD_DEEPBIND` in 99% of cases. Also, I played with `RTLD_NEXT`, to see if I could locate the last symbol loaded, but I couldn't figure out when I had reached the end and I also wasn't able to lookup the symbol in the executable that way. I wish I understood what they mean by next. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 18:57:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 18:57:31 -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.42fb6fe3f598ffe2260995b52b36c797@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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 dagit): After playing with your example a bit I see what you mean about the copy semantics. I found this article: http://netwinder.osuosl.org/users/p/patb/public_html/elf_relocs.html Interestingly, [http://src.gnu-darwin.org/src/libexec/rtld- elf/amd64/reloc.c.html glibc] has these comments: {{{ /* * Process the special R_X86_64_COPY relocations in the main program. These * copy data from a shared object into a region in the main program's BSS * segment. * * Returns 0 on success, -1 on failure. */ int do_copy_relocations(Obj_Entry *dstobj) }}} And: {{{ case R_X86_64_COPY: /* * These are deferred until all other relocations have * been done. All we do here is make sure that the COPY * relocation is not in a shared library. They are allowed * only in executable files. */ }}} The elf interpreter delays processing of the `R_COPY`'s so that it gets the correct behavior. I think this supports your earlier hypothesis. At this point, I noticed that I can switch `environ` in the executable between `R_X86_64_GLOB_DAT` and `R_X86_64_COPY` by adding `-fPIC` (you probably already knew that). Specifically, without `-fPIC` I get copy and with it I get glob dat. Test program again: {{{ #define _GNU_SOURCE #include #include #include extern char**environ; char envname[] = "environ"; void dlsym_check(void *handle, char * lib, char * sym){ void * e = dlsym(handle,sym); fprintf(stderr, "dlsym(\"%s\", \"%s\") = %p\n", lib, sym, e); char * error = dlerror(); if( error != NULL ) fprintf(stderr, "Errors: %s\n", error); } int main(int argc, char *argv[]) { if( argc < 2 ){ printf("usage: ./check-environ \n"); exit(1); } char* so = argv[1]; void *deflt, *hdl; fprintf(stderr, "environ = %p\n", &environ); deflt = dlopen(NULL, RTLD_LAZY | RTLD_GLOBAL); fprintf(stderr, "\nFind a symbol after passing NULL to dlopen:\n"); dlsym_check(deflt, NULL, envname); hdl = dlopen(so, RTLD_LAZY | RTLD_GLOBAL); if( hdl == NULL ){ fprintf(stderr, "Error: %s", dlerror()); exit(1); } fprintf(stderr, "\nFind a symbol that is located here and libc (handle comes from dlopen on %s)\n", so); dlsym_check(hdl, so, envname); } }}} {{{ $ ./check-environ-without-pic /usr/lib64/libgmp.so.10 environ = 0x601070 Find a symbol after passing NULL to dlopen: dlsym("(null)", "environ") = 0x601070 Find a symbol that is located here and libc (handle comes from dlopen on /usr/lib64/libgmp.so.10) dlsym("/usr/lib64/libgmp.so.10", "environ") = 0x31e45bd508 $ ./check-environ-with-pic /usr/lib64/libgmp.so.10 environ = 0x31e45bd508 Find a symbol after passing NULL to dlopen: dlsym("(null)", "environ") = 0x31e45bd508 Find a symbol that is located here and libc (handle comes from dlopen on /usr/lib64/libgmp.so.10) dlsym("/usr/lib64/libgmp.so.10", "environ") = 0x31e45bd508 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 19:15:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 19:15:08 -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.c060e188b9aca380c8e2775d784f44ea@haskell.org> #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ---------------------------------------+---------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 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 MagnusTherning): I've just confirmed that {{{haskell-src-exts}}} versions 1.14.0.1 and 1.15.0.1 can be built with profiling information using the tip of the ghc-7.8 branch ({{{8404e800a35380281a218c78a6799ed6836b6fad}}}). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 19:51:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 19:51:32 -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.8a4198f223398e03d05b467e33ffb65c@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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): Thanks for the great examples! Coming back to comment:31 where I reported two failing tests: I think some changes in the creation of the SOs that ghci loads are required. Could you tell me where in the code those SOs are created? May I temporarily own the ticket for that fix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 20:08:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 20:08:46 -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.3bf5b7440510010f6af7929ea4fe1631@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: trommler Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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): * owner: simonmar => trommler Comment: @trommler, giving you the ticket. Thinking about it, I'm less sure that `RTLD_LOCAL` will work now, because it won't allow us to load new libraries that depend on libraries we've previously loaded, and we definitely need to be able to do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 20:30:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 20:30:35 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.14973eadc740d71580e12ee848317fdd@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.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 --------------------------------------------+------------------------------ Comment (by archblob): We will also need extra information on {{{IfaceTyCon}}}, if it's a promoted data constructor or promoted type constructor in order to quote it when appropriate (promoted type constructors are only quoted when using {{{-dppr-debug}}}). This extra information is only needed in the case of {{{IfaceTyConApp}}} but the current {{{newtype IfaceTyCon = IfaceTc { ifaceTyConName :: IfExtName } }}} is also used for coercion constructors so we might need to use a separate representation for type constructors in the context of {{{IfaceTyConApp}}} that contains this extra information. I was thinking something like: {{{#!haskell -- I'm not really fond of the names IfacePTyCon = IfacePDataCon IfExtName | IfacePTyCon IfExtName | IfaceStdTyCon IfExtName }}} This would not really change things, it is again just more tagging. Andrei -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 20:59:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 20:59:39 -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.015d1aa72a93e0ab85097f8622a3114f@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: trommler Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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): Replying to [comment:41 simonmar]: > @trommler, giving you the ticket. Thanks! > > Thinking about it, I'm less sure that `RTLD_LOCAL` will work now, because it won't allow us to load new libraries that depend on libraries we've previously loaded, and we definitely need to be able to do that. For libraries (SOs) coming from installed packages everything should be fine. The have a `NEEDED` tag for all dependencies and the system linker will `dlopen()` them and resolve the symbols. So for new libraries temporary SOs need to be produced the same way SOs in packages are, with `NEEDED` tags for all previously loaded libraries. The new library could potentially depend on all previously loaded libraries. I am thinking of something along the lines of: {{{ ld -shared temp.o ... < -l for each library loaded so far > }}} Perhaps we could remove libraries from the list that are not needed by the new library by using `--as-needed` but I want to check first if this flag is GNU ld specific. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 21:08:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 21:08:56 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.a2b4bd18b9676dc3e76a958926dd6cac@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.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: | -------------------------------+------------------------------------------- Comment (by MikeIzbicki): Here's a real worldish use case. Let's try to write a modified Functor class that lets us map over not just the last type variable, but any type variable. This would be useful, for example, with the Either type. The class might look something like: {{{ class Functor loc f where fmap :: proxy loc -> (a -> b) -> SetLocation f loc a -> SetLocation f loc b }}} Where loc is a type that uniquely identifies the position of the argument we want to map over. We can't make an instance of this class unless the SetLocation type family is injective. With a little syntactic sugar, we can convert the above class into something that looks very much like the current Functor class, but is quite a bit more powerful: {{{ class Functor loc f where fmap :: proxy loc -> (a -> b) -> f { loc = a } -> f { loc = b } }}} I don't think you can get something nearly that clean without injective type families. And, of course, this applies to any parametric classes currently in use, not just Functor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 7 21:46:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 May 2014 21:46:31 -0000 Subject: [GHC] #9088: Per-thread Haskell thread list/numbering (remove global lock from thread allocation) Message-ID: <045.0885dbb8600d45ba5fd812b42676d6c5@haskell.org> #9088: Per-thread Haskell thread list/numbering (remove global lock from thread allocation) ------------------------------+-------------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.9 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Currently, we take out the scheduler lock when a thread is allocated, in order to make sure we allocate a fresh thread ID and can attach it to the global thread list in the nursery. If we partition the thread ID space per originating capability and maintain thread lists per OS thread, we can remove this lock. Marking low priority because no one seems to be running into this as their particular scaling problem (and there may be other reasons why high thread churn doesn't scale across cores). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 8 01:54:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 May 2014 01:54:53 -0000 Subject: [GHC] #9088: Per-thread Haskell thread list/numbering (remove global lock from thread allocation) In-Reply-To: <045.0885dbb8600d45ba5fd812b42676d6c5@haskell.org> References: <045.0885dbb8600d45ba5fd812b42676d6c5@haskell.org> Message-ID: <060.9b8ede99d5196bf981c9b4227f96a6a4@haskell.org> #9088: Per-thread Haskell thread list/numbering (remove global lock from thread allocation) --------------------------------------------+------------------------------ Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | 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: --------------------------------------------+------------------------------ Changes (by rrnewton): * cc: rrnewton@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 8 05:55:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 May 2014 05:55:15 -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.c550b4d43d40305523ffbe63525cd828@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: trommler Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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 simonmar): > For libraries (SOs) coming from installed packages everything should be fine. The have a NEEDED tag for all dependencies and the system linker will dlopen() them and resolve the symbols. But won't that reload all the dependencies every time we load a library? We'll end up with multiple copies of `ghc-prim`, `base`, etc. etc. It's not just a question of wasted memory, but multiple copies of `base` causes problems because we have multiple `stdout`s and other CAFs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 8 06:49:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 May 2014 06:49:25 -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.31a91152d92461eaef4cac9a308d554a@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: trommler Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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): No, the library would not be loaded again. POSIX says: Only a single copy of an object file is brought into the address space, even if dlopen() is invoked multiple times in reference to the file, and even if different pathnames are used to reference the file. The Linux man page: If the same library is loaded again with dlopen(), the same file handle is returned. The dl library maintains reference counts for library handles, so a dynamic library is not deallocated until dlclose() has been called on it as many times as dlopen() has succeeded on it. The _init() routine, if present, is called only once. But a subsequent call with RTLD_NOW may force symbol resolution for a library earlier loaded with RTLD_LAZY. So I think we will be good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 8 07:34:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 May 2014 07:34:14 -0000 Subject: [GHC] #9087: Executables in the 7.8.2 Linux i386 binary tarball are not stripped In-Reply-To: <045.32e06e6ec3c181db27d068784d01610c@haskell.org> References: <045.32e06e6ec3c181db27d068784d01610c@haskell.org> Message-ID: <060.1b7c4c05c5de56e964b0c5d2d2981214@haskell.org> #9087: Executables in the 7.8.2 Linux i386 binary tarball are not stripped -----------------------------+--------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+--------------------------- Changes (by gidyn): * cc: gideon@? (added) Comment: Also in x86_64 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 8 10:04:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 May 2014 10:04:00 -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.54494f7f581d79bb4b9f77e3e5ea25f8@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: trommler Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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 simonmar): I didn't believe you, so I made a test program, and now I believe you :) It's somewhat surprising that a library we loaded with `RTLD_LOCAL` can be used to satisfy a dependency of another library we loaded with `RTLD_LOCAL`, but it does indeed seem to be the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 8 11:32:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 May 2014 11:32:33 -0000 Subject: [GHC] #9079: Foreign.C.Types in haskell2010 In-Reply-To: <046.0c2f3309095eee33947f42c0af9aa93f@haskell.org> References: <046.0c2f3309095eee33947f42c0af9aa93f@haskell.org> Message-ID: <061.620a8dcc1bfb226ff9b52c5e73ed1479@haskell.org> #9079: Foreign.C.Types in haskell2010 ------------------------------------------+-------------------------------- Reporter: tensor5 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.8.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): Well, this looks to me like a bug in the [http://www.haskell.org/onlinereport/haskell2010/ Haskell 2010 report] * [http://www.haskell.org/onlinereport/haskell2010/haskellch8.html Section 8.4.2 ] says that newtypes must have their constructors visible, and claims that `Foreign.C.Types` follows this convention. * But [http://www.haskell.org/onlinereport/haskell2010/haskellch28.html Chapter 28] which shows `Foreign.C.Types` manifestly does '''not''' follow this convention. That looks like an outright contradiction. I think we should export all the data constructors in `Foreign.C.Types` in the `haskell2010` package. Does anyone disagree? Meanwhile, I'm adding Simon M to the cc list, as editor of the H2010 report. Autin: could you act on this after a suitable delay? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 8 11:55:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 May 2014 11:55:14 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.a619c764e65a7b904a32cb3c5c504b8d@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.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 --------------------------------------------+------------------------------ Comment (by simonpj): Some responses * On the `IfaceTcArg` thing (comment 35), I suggested a whole new list type because it'll be more compact and faster to parse in interface files. Rather than two bytes and two decisions (nil/cons, and type/kind) there'll just be one. But the data type would need a Note to explain that reasoning. * On the qualified names point (also comment 35), I can see that `IfaceDecl`s only have an `OccName` in them because interface declarations "know" their host module. That's no longer true when converting arbitrary `TyThings` to `IfaceSyn`. So the `ifName` field of `IfaceDecl` will have to become `IfExtName`. Probably not too bad. * Re promotion (comment 36), yes I agree. All of these things will make interface files a little more verbose. It probably won't have any effect, but could you do some performance checks? With these changes alone: * Measure the effect on `.hi` file sizes for libraries (eg `base`) * Measure the effect on compile times (or, easier to get at, compiler allocation), say when bootstrapping GHC, or compiling the base libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 8 13:14:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 May 2014 13:14:06 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.eb9cd67566be961860fac41c30df2ff0@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.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 --------------------------------------------+------------------------------ Comment (by archblob): I didn't really consider the parsing aspect on the lists although every time I added another abstraction I wondered how much bigger and slower the interface files will get. I'll be changing the representation of {{{IfaceTcArg}}} as we discussed, and I'll also do the necessary measurements of everything I add on top of the existing representation. I also added another field to {{{IfaceClosedSynFamilyTyCon}}} so now it's represented like {{{IfaceClosedSynFamilyTyCon IfExtName [IfaceAxBranch]}}} in order to print closed type families the right way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 8 13:19:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 May 2014 13:19:24 -0000 Subject: [GHC] #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable In-Reply-To: <054.98121a1976ff390c1bc22f999087be97@haskell.org> References: <054.98121a1976ff390c1bc22f999087be97@haskell.org> Message-ID: <069.a1d2a10bcb184b2aa0f0d0c5fdc3e54a@haskell.org> #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable -------------------------------------+------------------------------------ Reporter: sjoerd_visscher | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): OK, thanks. You missed the flag reference summary list [http://www.haskell.org/ghc/docs/latest/html/users_guide/flag- reference.html Section 4.20.12], where flag implications should be summarised. But that's not surprising since `DeriveTraversable` and friends aren't even listed there. Could you do us a favour? * Add the `Derive`X extensions to that table * Put the whole table in alphabetical order of extension name * Check that there are no more missing one * Check that all implications are listed. That would be a very useful service. It could be a separate patch. Meanwhile, Austin, please commit. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 8 13:50:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 May 2014 13:50:55 -0000 Subject: [GHC] #9089: Local .ghci_history Message-ID: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> #9089: Local .ghci_history ------------------------------------+------------------------------------- Reporter: jcristovao | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hello, It would be nice to allow a local .ghci_history to be used (when available) instead of the global .ghc/ghci_history. This would be similar in behaviour to the .ghci rules: http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/ghci-dot-files.html And I believe this should not be too complicated to do (I can even try it myself, if there is interest). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 8 18:25:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 May 2014 18:25:37 -0000 Subject: [GHC] #9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies Message-ID: <047.6b2af23e852e3dacdefeac6524bf6813@haskell.org> #9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I have the following module {{{ {-# LANGUAGE RankNTypes, ConstraintKinds, TypeFamilies #-} import GHC.Exts (Constraint) type family D (c :: Constraint) :: Constraint type instance D (Eq a) = Eq a -- checks f :: Eq b => (forall a. D (Eq a) => f a -> Bool) -> f b -> Bool f g x = g x -- checks f' :: Eq b => (forall a. Eq a => f a -> Bool) -> f b -> Bool f' = f -- checks, so GHC seems to think that both types are interchangeable f'' :: Eq b => (forall a. D (Eq a) => f a -> Bool) -> f b -> Bool f'' = f' -- checks test' y = f' (\ (Just x) -> x /= x) y -- fails test y = f (\ (Just x) -> x /= x) y -- fails too, unsurprisingly test'' y = f'' (\ (Just x) -> x /= x) y }}} The module checks with GHC-7.6.3, but fails in GHC-7.8.2 and GHC-7.9.20140430 with {{{ src/Test.hs:24:16: Couldn't match type ?f? with ?Maybe? ?f? is untouchable inside the constraints (D (Eq a)) bound by a type expected by the context: (D (Eq a)) => f a -> Bool at src/Test.hs:24:10-35 ?f? is a rigid type variable bound by the inferred type of test :: Eq b => f b -> Bool at src/Test.hs:24:1 Possible fix: add a type signature for ?test? Expected type: f a Actual type: Maybe a Relevant bindings include y :: f b (bound at src/Test.hs:24:6) test :: f b -> Bool (bound at src/Test.hs:24:1) In the pattern: Just x In the first argument of ?f?, namely ?(\ (Just x) -> x /= x)? In the expression: f (\ (Just x) -> x /= x) y src/Test.hs:27:20: Couldn't match type ?f? with ?Maybe? ?f? is untouchable inside the constraints (D (Eq a)) bound by a type expected by the context: (D (Eq a)) => f a -> Bool at src/Test.hs:27:12-39 ?f? is a rigid type variable bound by the inferred type of test'' :: Eq b => f b -> Bool at src/Test.hs:27:1 Possible fix: add a type signature for ?test''? Expected type: f a Actual type: Maybe a Relevant bindings include y :: f b (bound at src/Test.hs:27:8) test'' :: f b -> Bool (bound at src/Test.hs:27:1) In the pattern: Just x In the first argument of ?f''?, namely ?(\ (Just x) -> x /= x)? In the expression: f'' (\ (Just x) -> x /= x) y }}} I'd expect it to typecheck. At first, I thought this might be related in some way to #8985. That's why I tested with HEAD, but while #8985 seems indeed to be fixed, this is still a problem there. Also, while my simplified test case compiles with GHC-7.6.3, my original more complicated program does not, so there might be another report forthcoming if I manage to isolate the difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 8 18:39:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 May 2014 18:39:54 -0000 Subject: [GHC] #9091: print and/or apply constraints when showing info for typed holes Message-ID: <047.d95c0766523b082befd3b58cd013d678@haskell.org> #9091: print and/or apply constraints when showing info for typed holes -------------------------------------------+------------------------------- Reporter: kosmikus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Typed holes are fantastic already, but could be even better. Consider the following three examples: == Example 1 == {{{ f :: Eq a => a -> a -> Bool f x y = _ }}} GHC-7.8.2 shows: {{{ Found hole ?_? with type: Bool Relevant bindings include y :: a (bound at THC.hs:4:5) x :: a (bound at THC.hs:4:3) f :: a -> a -> Bool (bound at THC.hs:4:1) In the expression: _ In an equation for ?f?: f x y = _ }}} GHC additionally knows that `Eq a` holds. It would be great if it would print that, too. == Example 2 == {{{ g :: (forall a. Eq a => a -> Bool) -> Bool g f = f _ }}} GHC-7.8.2 shows: {{{ Found hole ?_? with type: a0 Where: ?a0? is an ambiguous type variable Relevant bindings include f :: forall a. Eq a => a -> Bool (bound at THC.hs:7:3) g :: (forall a. Eq a => a -> Bool) -> Bool (bound at THC.hs:7:1) In the first argument of ?f?, namely ?_? In the expression: f _ In an equation for ?g?: g f = f _ }}} GHC additionally knows the `Eq a0` must hold. It would be nice if it could indicate that. == Example 3 == {{{ data X a where Y :: X Int h :: X a -> a -> a h Y x = _ }}} GHC-7.8.2 shows: {{{ Found hole ?_? with type: Int Relevant bindings include x :: a (bound at THC.hs:13:5) h :: X a -> a -> a (bound at THC.hs:13:1) In the expression: _ In an equation for ?h?: h Y x = _ }}} Interestingly, GHC shows that we have to produce an `Int`. Unfortunately, it shows that `x` is of type `a`. GHC additionally knows that `a ~ Int`. It would be nice if GHC could either apply the constraint to show that `x :: Int` or at least show the constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 9 05:59:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 May 2014 05:59:17 -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.d57eaccecee0f0746cc87ca9a6671dff@haskell.org> #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ---------------------------------------+---------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 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 CoreyOConnor): Same as Magnus: Reproduced on NixOS 64 bit using GHC 7.8.2. Could not reproduce using ghc-7.8 branch (8404e800a35380281a218c78a6799ed6836b6fad) Same build process was used in each case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 9 09:21:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 May 2014 09:21:43 -0000 Subject: [GHC] #9091: print and/or apply constraints when showing info for typed holes In-Reply-To: <047.d95c0766523b082befd3b58cd013d678@haskell.org> References: <047.d95c0766523b082befd3b58cd013d678@haskell.org> Message-ID: <062.d8dd93e76d0c0d6531002e25f29b03ae@haskell.org> #9091: print and/or apply constraints when showing info for typed holes --------------------------------------------+------------------------------ Reporter: kosmikus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.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): It would be easy to also show the in-scope "given" constraints. But how would you like to see them. For Ex 1, 2 can you show what error message you'd like to see? Something like (for Ex 1) {{{ Found hole ?_? with type: Bool Relevant bindings include y :: a (bound at THC.hs:4:5) x :: a (bound at THC.hs:4:3) f :: a -> a -> Bool (bound at THC.hs:4:1) Given constraints: Eq a In the expression: _ In an equation for ?f?: f x y = _ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 9 09:37:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 May 2014 09:37:34 -0000 Subject: [GHC] #9091: print and/or apply constraints when showing info for typed holes In-Reply-To: <047.d95c0766523b082befd3b58cd013d678@haskell.org> References: <047.d95c0766523b082befd3b58cd013d678@haskell.org> Message-ID: <062.82b6a0253c7786c0f618f78e3777650e@haskell.org> #9091: print and/or apply constraints when showing info for typed holes --------------------------------------------+------------------------------ Reporter: kosmikus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.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 kosmikus): Yes, what you suggest would be fine. I don't attach much meaning to the word ``Given'', so I'd probably just say {{{ Constraints: Eq a }}} For example 2, I'd be happy with a very similar line saying {{{ Constraints: Eq a0 }}} The situation is different from Ex 1 in the sense that `Eq a` in Ex 1 is a constraint you can use, whereas `Eq a0` in Ex 2 is a constraint that you're required to adhere to while filling the hole. But this information is already available from the fact that `a0` in Ex 2 appears only in the type of the hole itself, so I think I'd be happy enough if the constraints are shown in the same way. For Ex 3, I'd like either {{{ Found hole ?_? with type: Int Relevant bindings include x :: Int (bound at THC.hs:13:5) }}} or {{{ Found hole ?_? with type: Int Relevant bindings include x :: a (bound at THC.hs:13:5) [...] Constraints: a ~ Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 9 11:49:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 May 2014 11:49:17 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.78196679eb4a73e70828caa94eca79ad@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.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 --------------------------------------------+------------------------------ Comment (by simonmar): @archblob asked me about this on IRC. I suggested that rather than making `ifName` a qualified name, it would be better to pass in the `Name` when pretty printing the `IfaceDecl`. There's only one `ifName` per `IfaceDecl`, so passing it in separately should be fine. I wonder about things like constructor names (`ifConOcc`), record field names (`ifConFields`), and method names though. Perhaps they need to be qualified too. In which case you'll need to pass in more `Name`s for those. Another thought I had is that perhaps it would be better to reify the stuff into `THSyn` and print that instead. `THSyn` is closer to Haskell than `IfaceSyn`. But perhaps that would mean duplicating the tidying logic? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 9 12:17:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 May 2014 12:17:02 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.d30c222c35975c9ffbd36390841e2884@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.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 --------------------------------------------+------------------------------ Comment (by archblob): @simonmar suggestion would be easier because we already pass a name to {{{pprIfaceDecl}}} in order to print things in context and elide everything not searched for, so when needing qualified names we could get everything to the left of the last (.) in the supplied name and prefix the occ names with that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 9 13:05:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 May 2014 13:05:04 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.3d9d633c8b96ad542543b284af8c9cad@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.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 --------------------------------------------+------------------------------ Comment (by simonpj): Simon is right about `ifConOcc`. Good point. Rather than pass in the `Name` of the type constructor, you could simply pass in the `Module` in which this `IfaceDecl` lives. Then you can easily make a `Name` for all of these things. It's bit of a nuisance, but perhaps better than making them all `IfaceExtNames`. Perhaps pass in a `Maybe Module`, where `Nothing` means "just print the `OccName`"? > @simonmar suggestion would be easier because we already pass a name to {{{pprIfaceDecl}}} in order to print things in context and elide everything not searched for Not exactly. We pass in a `ShowSub` (or that's what it used to be called in `PprTyThing`. So yes, `ShowSub` could be augmented with that `Maybe Module` and then it is already being plumbed to all the right places. The TH route is certainly a plausible alternative; a good thought. As I say above, I'm not wedded to doing all this via `IfaceSyn`. And better printing for TH stuff would be good; perhaps even better than better printing for Iface stuff (which only hard-core people will look at). The place to look is `TcSplice.reifyThing` which is the moral equivalent of `MkIface.tyThingToIfaceDecl`. You'll see that `reifyThing` is monadic, but the only reason for that is that it can fail, if TH syntax isn't rich enough to deal with the result. Arguably it'd be good to remove the possibility of failure, and thereby force ourselves to enhance TH syntax to cope. I notice also that `reifyThing` is not doing the requisite tidying (which `tyThingToIfaceDecl` is careful to do) so I think there are lurking bugs there. But (and I have not got time to think this through right now), TH syntax models source syntax, and so doesn't have explicit kinds, whereas Iface syntax does.... Probably worth completing the Iface route for now. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 9 13:07:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 May 2014 13:07:13 -0000 Subject: [GHC] #9092: ghc: panic! (the 'impossible' happened) Message-ID: <046.b9f7cb051e72bab7727c2bd0d31fa554@haskell.org> #9092: ghc: panic! (the 'impossible' happened) -----------------------------------+--------------------------------------- Reporter: alex404 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: panic | Operating System: Linux impossible | Type of failure: Compile-time crash Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I'm not sure *why* this is happening, but I know where. The code for this library is available here: http://hub.darcs.net/alex404/hsl-random So as is, I can run the script called multivariate and get the expected results, but when I try to compile I get ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): attempt to prod-split usage call demand C(C1(U(U,U,U,U,U,U))) If at line 317 in Scientific.Random.Distributions.hs, I replace the statement sgma = ... with sgma = undefined, the code will compile, though obviously it cannot be used. If I transform the code in other ways which are meant to preserve the results, I can get it to compile, but then the script hangs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 9 13:47:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 May 2014 13:47:14 -0000 Subject: [GHC] #7662: Improve GC of mutable objects In-Reply-To: <045.1df59d879ca14d9200a5a4cc6e9474e1@haskell.org> References: <045.1df59d879ca14d9200a5a4cc6e9474e1@haskell.org> Message-ID: <060.f7f7e981f52aca261dade2b1790effde@haskell.org> #7662: Improve GC of mutable objects -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Runtime System | 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 simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 9 15:22:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 May 2014 15:22:50 -0000 Subject: [GHC] #9091: print and/or apply constraints when showing info for typed holes In-Reply-To: <047.d95c0766523b082befd3b58cd013d678@haskell.org> References: <047.d95c0766523b082befd3b58cd013d678@haskell.org> Message-ID: <062.a9ee5f7e4dd35d514b2fc2257cf52798@haskell.org> #9091: print and/or apply constraints when showing info for typed holes --------------------------------------------+------------------------------ Reporter: kosmikus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.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 goldfire): Bikeshedding a bit, I would rather distinguish givens and wanteds in these messages. How about something slightly more verbose, like {{{ Found hole ?_? with type: Bool Relevant bindings include y :: a (bound at THC.hs:4:5) x :: a (bound at THC.hs:4:3) f :: a -> a -> Bool (bound at THC.hs:4:1) We know that the following constraints hold: Eq a In the expression: _ In an equation for ?f?: f x y = _ }}} Or, for the "wanted" case, `We require the following to hold:` Is it also helpful to give the provenance of the constraints (e.g., that the `Eq a` above is from the type signature)? I don't know. How do we print implication constraints? Do these come up? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 9 17:37:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 May 2014 17:37:49 -0000 Subject: [GHC] #9091: print and/or apply constraints when showing info for typed holes In-Reply-To: <047.d95c0766523b082befd3b58cd013d678@haskell.org> References: <047.d95c0766523b082befd3b58cd013d678@haskell.org> Message-ID: <062.368a729ada5b357aeba5d8c1e1074a53@haskell.org> #9091: print and/or apply constraints when showing info for typed holes --------------------------------------------+------------------------------ Reporter: kosmikus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.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 kosmikus): I'd certainly also be ok with distinguishing givens and wanteds, and I agree that it may make things much clearer in practice. I'd prefer slightly shorter messages than the ones you suggest, but that's a minor point. Regarding implication constraints: perhaps I'm missing something, but aren't these always global? I wouldn't include global knowledge in hole information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 9 23:49:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 May 2014 23:49:49 -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.4b03fb7d0abfe034c0b63e162da9ded0@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: trommler Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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 dagit): Simon, that is surprising. Do you still have your test setup? Could I take a look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 10 01:42:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 May 2014 01:42:53 -0000 Subject: [GHC] #9093: Type synonym accepted with out-of-scope kind variable Message-ID: <047.673f36a41cc96d4d0b95f272aa32aaf9@haskell.org> #9093: Type synonym accepted with out-of-scope kind variable --------------------------+------------------------------------------------ Reporter: | Owner: goldfire | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: GHC accepts invalid program Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ When I say {{{ {-# LANGUAGE PolyKinds #-} import Data.Proxy import GHC.Exts type X = Proxy (Any :: k) }}} I get no error. If I then ask GHCi about `X` (with `-fprint-explicit- kinds`), I see this: {{{ *Main> :i X type X = Proxy AnyK (Any AnyK) }}} I think my original code should be rejected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 10 02:03:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 May 2014 02:03:17 -0000 Subject: [GHC] #9094: remove RAW_CPP Message-ID: <045.99520725c7120b8fcb5e4c616ee15b05@haskell.org> #9094: remove RAW_CPP ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: 8683 | Blocking: Related Tickets: #8683 | ------------------------------------+------------------------------------- once the CPP settings ticket is merged #8683 one cleanup task is to remove the RAW_CPP bits from the ghc build system because they're not longer needed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 10 02:17:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 May 2014 02:17:43 -0000 Subject: [GHC] #9095: make sdist picks up test files Message-ID: <045.5bc6b697ad76318e7d59aba1132cfee1@haskell.org> #9095: make sdist picks up test files ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | 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: | ------------------------------------+------------------------------------- I recently ran 'make sdist' and discovered that I my source tarball was nearly a gigabyte large. Closer inspection revealed that sdist had slurped up executable files for tests that I had run at some point. It would be preferable if 'make sdist' did not do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 10 13:04:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 May 2014 13:04:09 -0000 Subject: [GHC] #9096: GADT definition not accepted in prefix notation Message-ID: <047.0e9543e62d37f36829980e750c64d3ad@haskell.org> #9096: GADT definition not accepted in prefix notation ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Brian Nguyen writes on haskell-cafe: The following does not work: {{{ data Foo a where {Foo :: (->) a (Foo a)} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 10 16:49:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 May 2014 16:49:38 -0000 Subject: [GHC] #7898: SpecConstr explodes when compiling module BSP of frag-1.1.2 In-Reply-To: <049.1dc64d9da3fa936aad83b3c8f408b65e@haskell.org> References: <049.1dc64d9da3fa936aad83b3c8f408b65e@haskell.org> Message-ID: <064.969d83c08706ec1e2edb0ee356bc7560@haskell.org> #7898: SpecConstr explodes when compiling module BSP of frag-1.1.2 ---------------------------------------+----------------------------------- Reporter: tinctorius | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 carter): a related instance of spec constr blowup was found in idris when built with O2 where the javascript codegen module https://github.com/idris-lang/Idris- dev/blob/a68c5fa403145e7ce9ea0dc2d369c23ed6854e6d/src/IRTS/CodegenJavaScript.hs likewise http://pastebin.com/cvawjiCc the last line of the log is {{{ *** SpecConstr: }}} not sure if this should be its own ticket or not, for now adding it here -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 11 02:58:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 May 2014 02:58:04 -0000 Subject: [GHC] #9097: Change GHC.Exts.Any to a type family Message-ID: <047.47dea3c2ecf59fa4dca4d4cf3a712a78@haskell.org> #9097: Change GHC.Exts.Any to a type family ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I just had this slightly alarming interchange with GHCi: {{{ Prelude> import Data.Type.Equality Prelude Data.Type.Equality> import GHC.Exts Prelude Data.Type.Equality GHC.Exts> :kind! ((Any :: Bool) == (Any :: Bool)) ((Any :: Bool) == (Any :: Bool)) :: Bool = 'False }}} After staring at the result in disbelief, I figured out why. The instance for `==` at kind `Bool` looks like this: {{{ type family EqBool a b where EqBool False False = True EqBool True True = True EqBool a b = False type instance (a :: Bool) == (b :: Bool) = EqBool a b }}} Well, `Any` isn't `False`, `Any` isn't `True`, so `Any == Any` must be `False`! The solution to this, of course, is to make `Any` a type family, not a datatype. Then, it wouldn't be apart from the equations in `EqBool`. I believe this idea has been floated previously but was not implemented as it would have disturbed !TypeLits and/or singletons. These libraries have been updated, and it's time. I'm happy to do this myself in due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 04:25:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 04:25: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.76e9e457876dc9852eb031375b87eb08@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.3 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: 9094 | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by dagit): Mixing `clang` and `gcc` in the same build may lead to weird issues in some cases. I don't think it will be common, but it's something to watch out for. Imagine this scenario: You're making an FFI binding and `clang` and `gcc` use different definitions in their respective libraries. Or stranger yet, someone has written their library to behave differently depending on whether it's compiled with `clang` or `gcc` (let's hope no one does that). Thinking about this lead to realizing that cabal + hsc2hs exhibits a related problem: https://github.com/haskell/cabal/issues/1858 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 04:50:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 04:50:26 -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.d00d20c3755de8fdeffdde7c7f75351b@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.3 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: 9094 | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): actually mixing clang and gcc is the only way to fix certain issues on OS X pre Xcode 5. Its imposible to correctly compile SIMD codes with xcode 4s GCC 4.2, so i've had to have custom SETUP.hs files for OS X code that invokes clang on c codes, even if ghc is using gcc for its own needs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 04:55:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 04:55:13 -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.ee46a2ae9e6aa938a32b23ada45bd222@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.3 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: 9094 | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): point being, similar issues arise on supported platforms even if you fix to using only clang or gcc. my pesonal GHC setup actually uses the hybrid of clang + gcc (which IS NOT the default for this patch, merely in my personal config after i built my ghc) eg, you can't built hfsevents on mac unless you use Clang as the CC for ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 07:43:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 07:43:31 -0000 Subject: [GHC] #9097: Change GHC.Exts.Any to a type family In-Reply-To: <047.47dea3c2ecf59fa4dca4d4cf3a712a78@haskell.org> References: <047.47dea3c2ecf59fa4dca4d4cf3a712a78@haskell.org> Message-ID: <062.5eb8b168a251710ae43c66d13e46caa1@haskell.org> #9097: Change GHC.Exts.Any to a type family -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.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 * priority: normal => high * milestone: => 7.10.1 Comment: Absolutely. Go for it. Please add a Note that mentions this ticket, or at least gives this example; it's a useful one, and we totally didn't think about before. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 09:00:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 09:00:44 -0000 Subject: [GHC] #9093: Type synonym accepted with out-of-scope kind variable In-Reply-To: <047.673f36a41cc96d4d0b95f272aa32aaf9@haskell.org> References: <047.673f36a41cc96d4d0b95f272aa32aaf9@haskell.org> Message-ID: <062.090dea023495b5cd8b50cb38d641a5ec@haskell.org> #9093: Type synonym accepted with out-of-scope kind variable ------------------------------------------------+-------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by simonpj): Currently it's deliberate. How else could you declare a poly-kinded type synonym `X`? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 10:48:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 10:48:15 -0000 Subject: [GHC] #9098: Don't use unsafe coerce when desugaring lazy pattersn Message-ID: <046.1ef28c3d659d1cd6dc51da5793970ffc@haskell.org> #9098: Don't use unsafe coerce when desugaring lazy pattersn ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Christiaan Baaij asks (on ghc-devs): when I ask for the desugaring of: {{{ module PatError where paterror :: Maybe Int -> Int paterror (Just i) = i }}} I get the following: {{{ PatError.paterror = \ (ds_dIS :: Data.Maybe.Maybe GHC.Types.Int) -> break<1>() case ds_dIS of _ [Occ=Dead] { __DEFAULT -> (\ _ [Occ=Dead, OS=OneShot] -> Control.Exception.Base.patError @ GHC.Types.Int "PatError.hs:4:1-21|function paterror"#) GHC.Prim.void#; Data.Maybe.Just i_aqG -> break<0>(i_aqG) i_aqG } }}} Where `Control.Exception.Base.patError` is applied to `Int`. However, when I compile the almost identical code with an irrefutable pattern: {{{ module PatError2 where patError :: Maybe Int -> Int patError ~(Just i) = i }}} I get the following core: {{{ PatError2.paterror = \ (ds_dIT :: Data.Maybe.Maybe GHC.Types.Int) -> break<1>() let { i_aqG :: GHC.Types.Int [LclId, Str=DmdType] i_aqG = case ds_dIT of _ [Occ=Dead] { __DEFAULT -> (\ _ [Occ=Dead, OS=OneShot] -> (Control.Exception.Base.irrefutPatError @ () "PatError2.hs:4:1-22|(Data.Maybe.Just i)"#) `cast` (UnivCo representational () GHC.Types.Int :: () ~# GHC.Types.Int)) GHC.Prim.void#; Data.Maybe.Just i_aqG -> i_aqG } } in break<0>(i_aqG) i_aqG }}} Where `Control.Exception.Base.patError` is first applied to `()` after which it is casted to `GHC.Types.Int`. Out of the `[Note]` for the `UnivCo` coercion: {{{ The UnivCo ("universal coercion") serves two rather separate functions: - the implementation for unsafeCoerce# - placeholder for phantom parameters in a TyConAppCo }}} It seems to be used in the `unsafeCoerce#` role here. My question is: why can't the irrefutable pattern be translated to `Control.Exception.Base.irrefutPatError' applied to 'Int'? Instead of using this 'cast'? I find the cast-less version much more readable. Greetings, Christiaan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 10:49:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 10:49:04 -0000 Subject: [GHC] #9098: Don't use unsafe coerce when desugaring lazy pattersn In-Reply-To: <046.1ef28c3d659d1cd6dc51da5793970ffc@haskell.org> References: <046.1ef28c3d659d1cd6dc51da5793970ffc@haskell.org> Message-ID: <061.02776fbbef46cb78f208009f745b16a4@haskell.org> #9098: Don't use unsafe coerce when desugaring lazy pattersn -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): Excellent point. The unsafeness here is entirely unnecessary. I'll fix this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 11:35:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 11:35:53 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.c9398414888ac529fec6469b41e402ab@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.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 thoughtpolice): * priority: normal => high * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 12:42:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 12:42:14 -0000 Subject: [GHC] #9099: Add strict fmap Message-ID: <045.7f6cb28f3b97baef1a99c0725efe4db9@haskell.org> #9099: Add strict fmap -------------------------------------------+------------------------------- Reporter: quchen | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: None | Version: 7.8.2 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: -------------------------------------------+------------------------------- Add a strict version of fmap to the standard libraries. {{{ infixl 4 <$!> (<$!>) :: Monad m => (a -> b) -> m a -> m b f <$!> m = do x <- m return $! f x {-# INLINE (<$!>) #-} }}} Libraries discussions: Take 1: http://www.haskell.org/pipermail/libraries/2013-November/021728.html Take 3: http://www.haskell.org/pipermail/libraries/2014-April/022864.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 13:55:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 13:55:22 -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.c589b08643f7da1b283c64ff9ac16afb@haskell.org> #8228: GHC built under Windows does not generate dyn_hi files --------------------------------------------+------------------------------ Reporter: ezyang | Owner: Type: bug | thoughtpolice Priority: high | Status: new Component: Compiler | Milestone: 7.8.3 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 thoughtpolice): * priority: highest => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 13:56:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 13:56:15 -0000 Subject: [GHC] #5757: zero unexpected failures on all tier 1 platforms In-Reply-To: <047.3b6881d640a4e0fd41999b488e43799d@haskell.org> References: <047.3b6881d640a4e0fd41999b488e43799d@haskell.org> Message-ID: <062.ad66091d589fb2ca58358d029118c905@haskell.org> #5757: zero unexpected failures on all tier 1 platforms -------------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.3 Component: Test Suite | 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: #5785 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * priority: highest => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 13:56:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 13:56:22 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.6e064d001541db3e19de0ba4d8dcad17@haskell.org> #5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------ Reporter: igloo | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3658 | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * priority: highest => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 13:56:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 13:56:51 -0000 Subject: [GHC] #7478: setSessionDynFlags does not always work In-Reply-To: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> References: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> Message-ID: <059.33e48225f85208facf9faf2fa607c30d@haskell.org> #7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 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: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * priority: highest => high Comment: Lowering priority to be a bit more realistic on the milestone page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 13:59:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 13:59:07 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.cb45098cafcafb3af87df4073e2da4f7@haskell.org> #7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Runtime System | Version: Resolution: | Keywords: thread-local Operating System: MacOS X | state, TLS clang Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: highest => high Comment: I have a patch incoming Real Soon for this. Yay! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 14:15:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 14:15:00 -0000 Subject: [GHC] #9001: unexpected runtime crash In-Reply-To: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> References: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> Message-ID: <060.970f33c296d77551beb5380f819567f7@haskell.org> #9001: unexpected runtime crash -------------------------------------+------------------------------------ Reporter: jwlato | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by simonpj: Old description: > Apologies for the poor summary, I'm not sure how to be more descriptive. > I don't see anything dodgy here. > > Compiling the attached program `ghc -O -dcore-lint Test.hs` and running > it results in a runtime crash. Various incarnations of this code have > resulted in > > Test: internal error: scavenge_one: strange object 0 > > Test: internal error: stg_ap_p_ret > > and core dumps with no further information. > > I've been able to reproduce this with ghc-7.8.2 and ghc-7.6.3. New description: Apologies for the poor summary, I'm not sure how to be more descriptive. I don't see anything dodgy here. Compiling the attached program `ghc -O -dcore-lint Test.hs` and running it results in a runtime crash. Various incarnations of this code have resulted in {{{ Test: internal error: scavenge_one: strange object 0 Test: internal error: stg_ap_p_ret }}} and core dumps with no further information. I've been able to reproduce this with ghc-7.8.2 and ghc-7.6.3. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 14:48:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 14:48:24 -0000 Subject: [GHC] #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 In-Reply-To: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> References: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> Message-ID: <065.bfed8090a1b7dab4cbe0074b4f006e74@haskell.org> #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 ---------------------------------------+----------------------------------- Reporter: MichalGajda | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: cabal install hPDB | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7068, #7898 ---------------------------------------+----------------------------------- Changes (by thoughtpolice): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 15:04:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 15:04:15 -0000 Subject: [GHC] #9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies In-Reply-To: <047.6b2af23e852e3dacdefeac6524bf6813@haskell.org> References: <047.6b2af23e852e3dacdefeac6524bf6813@haskell.org> Message-ID: <062.e2d26c67baf90a1a6620e4374d50278f@haskell.org> #9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2745164acfd582d930cbc5080fdf052f61f6893e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2745164acfd582d930cbc5080fdf052f61f6893e" Comments only, on inert_fsks and inert_no_eqs I wrote these when studying Trac #9090 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 15:04:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 15:04:16 -0000 Subject: [GHC] #9096: GADT definition not accepted in prefix notation In-Reply-To: <047.0e9543e62d37f36829980e750c64d3ad@haskell.org> References: <047.0e9543e62d37f36829980e750c64d3ad@haskell.org> Message-ID: <062.eccaf9680dc4d1cee2fd44779379a265@haskell.org> #9096: GADT definition not accepted in prefix notation -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 Simon Peyton Jones ): In [changeset:"770e16fceee60db0c2f79e3b77f6fc619bc1d864/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="770e16fceee60db0c2f79e3b77f6fc619bc1d864" In splitHsFunType, take account of prefix (->) This fixes Trac #9096 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 15:04:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 15:04:16 -0000 Subject: [GHC] #9098: Don't use unsafe coerce when desugaring lazy pattersn In-Reply-To: <046.1ef28c3d659d1cd6dc51da5793970ffc@haskell.org> References: <046.1ef28c3d659d1cd6dc51da5793970ffc@haskell.org> Message-ID: <061.9ef2e9678e9a5ff45620edda80977871@haskell.org> #9098: Don't use unsafe coerce when desugaring lazy pattersn -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 Simon Peyton Jones ): In [changeset:"b5cf17f2f39993595e6ec7bd6bfe000c58a09fd8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b5cf17f2f39993595e6ec7bd6bfe000c58a09fd8" Improve desugaring of lazy pattern match This patch implements a simpler, and nicer, desugaring for lazy pattern matching, fixing Trac #9098 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 15:05:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 15:05:30 -0000 Subject: [GHC] #9096: GADT definition not accepted in prefix notation In-Reply-To: <047.0e9543e62d37f36829980e750c64d3ad@haskell.org> References: <047.0e9543e62d37f36829980e750c64d3ad@haskell.org> Message-ID: <062.2c538a909e15a3258423073b2d1347b0@haskell.org> #9096: GADT definition not accepted in prefix notation -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.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): * status: new => merge Comment: It's very much a corner case, but an easy merge to 7.8.3 so probably worth doing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 15:06:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 15:06:11 -0000 Subject: [GHC] #9098: Don't use unsafe coerce when desugaring lazy pattersn In-Reply-To: <046.1ef28c3d659d1cd6dc51da5793970ffc@haskell.org> References: <046.1ef28c3d659d1cd6dc51da5793970ffc@haskell.org> Message-ID: <061.5dd3bfc834d7266cee8f620fb9cbc0ba@haskell.org> #9098: Don't use unsafe coerce when desugaring lazy pattersn -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 Comment: Thanks for the suggestion. I don't think it's worth a regression test -- there wasn't really a bug before. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 16:51:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 16:51:38 -0000 Subject: [GHC] #8555: Simplify given `Coercible` constraints In-Reply-To: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> References: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> Message-ID: <061.691342634254f5ad1d71b62b62791fc0@haskell.org> #8555: Simplify given `Coercible` constraints ----------------------------------------------+---------------------------- Reporter: nomeata | Owner: archblob Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8503 | #8555 ----------------------------------------------+---------------------------- Changes (by archblob): * cc: fcsernik@? (added) * owner: => archblob Comment: This looks like a good place to further my understanding of ghc internals so I'll give it a try if no one else is doing it currently, so if someone is, please say so and don't let me waste my time :-P. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 18:02:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 18:02:02 -0000 Subject: [GHC] #8555: Simplify given `Coercible` constraints In-Reply-To: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> References: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> Message-ID: <061.1761cb1b6585bcc06ecfffd225165f1c@haskell.org> #8555: Simplify given `Coercible` constraints ----------------------------------------------+---------------------------- Reporter: nomeata | Owner: archblob Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8503 | #8555 ----------------------------------------------+---------------------------- Comment (by nomeata): Nobody is working on it, so if you feel like it, please give it a shot. (But also beware that in the last months, nobody was missing the feature, so it may have a limited impact ? don?t let that lessen your motivation!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 20:04:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 20:04:26 -0000 Subject: [GHC] #9100: Cannot build crypto-pubkey with GHC 7.8.2 and profiling Message-ID: <050.9608f139c137bdcc7b58020f3ff0d914@haskell.org> #9100: Cannot build crypto-pubkey with GHC 7.8.2 and profiling ----------------------------------+--------------------------------------- Reporter: JohnWiegley | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I configure crypto-pubkey with: {{{ configure flags: --disable-split-objs --enable-library-profiling --enable- shared --enable-library-vanilla --enable-executable-dynamic --enable-tests }}} And on building get: {{{ Building crypto-pubkey-0.2.4... Preprocessing library crypto-pubkey-0.2.4... [ 1 of 15] Compiling Crypto.PubKey.ECC.Prim ( Crypto/PubKey/ECC/Prim.hs, dist/build/Crypto/PubKey/ECC/Prim.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-apple-darwin): Ix{Int}.index: Index (75497475) out of range ((0,1333)) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Running Haddock for crypto-pubkey-0.2.4... Preprocessing library crypto-pubkey-0.2.4... Haddock coverage: haddock: internal error: Ix{Int}.index: Index (75497475) out of range ((0,1333)) }}} If I disable library profiling, it builds cleanly: {{{ Building crypto-pubkey-0.2.4... Preprocessing library crypto-pubkey-0.2.4... [ 1 of 15] Compiling Crypto.PubKey.ECC.Prim ( Crypto/PubKey/ECC/Prim.hs, dist/build/Crypto/PubKey/ECC/Prim.o ) [ 2 of 15] Compiling Crypto.PubKey.ECC.Generate ( Crypto/PubKey/ECC/Generate.hs, dist/build/Crypto/PubKey/ECC/Generate.o ) [ 3 of 15] Compiling Crypto.PubKey.DH ( Crypto/PubKey/DH.hs, dist/build/Crypto/PubKey/DH.o ) [ 4 of 15] Compiling Crypto.PubKey.HashDescr ( Crypto/PubKey/HashDescr.hs, dist/build/Crypto/PubKey/HashDescr.o ) [ 5 of 15] Compiling Crypto.PubKey.MaskGenFunction ( Crypto/PubKey/MaskGenFunction.hs, dist/build/Crypto/PubKey/MaskGenFunction.o ) [ 6 of 15] Compiling Crypto.PubKey.DSA ( Crypto/PubKey/DSA.hs, dist/build/Crypto/PubKey/DSA.o ) [ 7 of 15] Compiling Crypto.PubKey.ECC.ECDSA ( Crypto/PubKey/ECC/ECDSA.hs, dist/build/Crypto/PubKey/ECC/ECDSA.o ) [ 8 of 15] Compiling Crypto.PubKey.ElGamal ( Crypto/PubKey/ElGamal.hs, dist/build/Crypto/PubKey/ElGamal.o ) [ 9 of 15] Compiling Crypto.PubKey.Internal ( Crypto/PubKey/Internal.hs, dist/build/Crypto/PubKey/Internal.o ) [10 of 15] Compiling Crypto.PubKey.RSA.Types ( Crypto/PubKey/RSA/Types.hs, dist/build/Crypto/PubKey/RSA/Types.o ) [11 of 15] Compiling Crypto.PubKey.RSA.Prim ( Crypto/PubKey/RSA/Prim.hs, dist/build/Crypto/PubKey/RSA/Prim.o ) [12 of 15] Compiling Crypto.PubKey.RSA ( Crypto/PubKey/RSA.hs, dist/build/Crypto/PubKey/RSA.o ) [13 of 15] Compiling Crypto.PubKey.RSA.PKCS15 ( Crypto/PubKey/RSA/PKCS15.hs, dist/build/Crypto/PubKey/RSA/PKCS15.o ) [14 of 15] Compiling Crypto.PubKey.RSA.OAEP ( Crypto/PubKey/RSA/OAEP.hs, dist/build/Crypto/PubKey/RSA/OAEP.o ) [15 of 15] Compiling Crypto.PubKey.RSA.PSS ( Crypto/PubKey/RSA/PSS.hs, dist/build/Crypto/PubKey/RSA/PSS.o ) In-place registering crypto-pubkey-0.2.4... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 20:35:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 20:35:42 -0000 Subject: [GHC] #9100: Cannot build crypto-pubkey with GHC 7.8.2 and profiling In-Reply-To: <050.9608f139c137bdcc7b58020f3ff0d914@haskell.org> References: <050.9608f139c137bdcc7b58020f3ff0d914@haskell.org> Message-ID: <065.8b2c35ad0a2fef7fba5f8311df36e694@haskell.org> #9100: Cannot build crypto-pubkey with GHC 7.8.2 and profiling ---------------------------------------+---------------------------------- Reporter: JohnWiegley | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by simonpj): Could conceivably be out-of-date .hi files. Make sure you `rm *.hi` everywhere. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 21:08:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 21:08:13 -0000 Subject: [GHC] #9100: Cannot build crypto-pubkey with GHC 7.8.2 and profiling In-Reply-To: <050.9608f139c137bdcc7b58020f3ff0d914@haskell.org> References: <050.9608f139c137bdcc7b58020f3ff0d914@haskell.org> Message-ID: <065.8c30bcea49e42ff85cd466860aba83bb@haskell.org> #9100: Cannot build crypto-pubkey with GHC 7.8.2 and profiling ---------------------------------------+---------------------------------- Reporter: JohnWiegley | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by JohnWiegley): I'm building this with Nix, so it should be a fresh build tree every time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 12 21:31:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 May 2014 21:31:07 -0000 Subject: [GHC] #9101: Build 7.8.2 from sources on Windows/msys2 Message-ID: <047.9aaf79de73007bb10bd989466d9c86e1@haskell.org> #9101: Build 7.8.2 from sources on Windows/msys2 ------------------------------------+--------------------------------- Reporter: cchantep | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Hi, Trying to build GHC 7.8.2 from sources on Windows 7, from msys2 shell, required binaries such as gcc, ld, ar are forced to those in inplace directories (windows-extra), even system/env provide such tools (e.g. using pacman package manager in msys2): https://ghc.haskell.org/trac/ghc/browser/ghc/configure.ac#L274 . It leads to issues as tools in inplace are quite old. Particularly it can be critical about linking: GHC will be working with old ld, but you can have built/linked libraries using the more recent ld. Then, what's built using system tool can't be used throught GHC (ld version conflict). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 02:34:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 02:34:47 -0000 Subject: [GHC] #9052: Support a "stable heap" which doesn't get garbage collected In-Reply-To: <045.cef633f00b20a59333331a11354e10ec@haskell.org> References: <045.cef633f00b20a59333331a11354e10ec@haskell.org> Message-ID: <060.81d9886ac0be59e5e057d4fb1dfc8919@haskell.org> #9052: Support a "stable heap" which doesn't get garbage collected ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by carter): This would be very handy for some of my own workloads. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 02:43:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 02:43:05 -0000 Subject: [GHC] #9088: Per-thread Haskell thread list/numbering (remove global lock from thread allocation) In-Reply-To: <045.0885dbb8600d45ba5fd812b42676d6c5@haskell.org> References: <045.0885dbb8600d45ba5fd812b42676d6c5@haskell.org> Message-ID: <060.732dcad67940526cfd056000f89725b8@haskell.org> #9088: Per-thread Haskell thread list/numbering (remove global lock from thread allocation) --------------------------------------------+------------------------------ Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | 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: --------------------------------------------+------------------------------ Changes (by carter): * cc: carter.schonwald@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 05:09:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 05:09:59 -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.a16a368ecde13a118116659cf1482bbd@haskell.org> #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ---------------------------------------+---------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 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 ihameed): * cc: idhameed@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 05:14:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 05:14:32 -0000 Subject: [GHC] #9102: Assertion failure in CoreUtils.lhs Message-ID: <048.72681b4014e365b606ae951bed049559@haskell.org> #9102: Assertion failure in CoreUtils.lhs ------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I happened to be using a debug build of ghc-7.8.2, and got this assertion failure compiling [http://hackage.haskell.org/package/fclabels-2.0.1 fclabels]. {{{ [ 7 of 10] Compiling Data.Label.Total ( src/Data/Label/Total.hs, dist/build/Data/Label/Total.o ) : ghc: panic! (the 'impossible' happened) (GHC version 7.8.2.20140429 for x86_64-unknown-linux): ASSERT failed! file compiler/coreSyn/CoreUtils.lhs line 194 coercion Nth:0 dt{v d7gF} [lid] passed to mkCast base:Control.Category.id{v rkl} [gid[ClassOp]] @ ghc- prim:GHC.Prim.*{(w) tc 34d} @ fclabels-2.0.1:Data.Label.Point.Total{tc r1Pm} (base:Control.Arrow.$p1Arrow{v r1s} [gid[ClassOp]] @ fclabels-2.0.1:Data.Label.Point.Total{tc r1Pm} (base:Control.Arrow.$p1ArrowApply{v rp} [gid[ClassOp]] @ fclabels-2.0.1:Data.Label.Point.Total{tc r1Pm} $dArrowApply{v a72o} [lid])) @ f{tv a8m6} [tv] f{v a8hw} [lid] has wrong role nominal }}} Problem does not appear with `-O0`. I couldn't test with HEAD because fclabels isn't compatible with the changes to Template Haskell yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 05:28:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 05:28:46 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.7c7b85797e8effc6e8efbb7d2aeedcd7@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 chak): @ezyang Thanks for chasing this, but I'm a bit surprised that the problem is with freeing stable names as the example program only allocated them (and they should never be freed by the GC). @robertce Could you please build a GHC with this patch included and check whether it solves our problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 05:29:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 05:29:45 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.5448c4e41e77a30bc7f74a57df8e5516@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.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 chak): * cc: chak@? (added) * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 05:39:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 05:39:17 -0000 Subject: [GHC] #9102: Assertion failure in CoreUtils.lhs In-Reply-To: <048.72681b4014e365b606ae951bed049559@haskell.org> References: <048.72681b4014e365b606ae951bed049559@haskell.org> Message-ID: <063.097c8e72a67ac08bf210b963213a6062@haskell.org> #9102: Assertion failure in CoreUtils.lhs -------------------------------------+------------------------------------ Reporter: tmcdonell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 tmcdonell): Sorry, forgot to mention: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.2.20140429 }}} Test system is Ubuntu 12.04, x86_64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 06:16:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 06:16:19 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.a698af4fe66b26bbc73318efcd23f053@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.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 robertce): @chak I have just patched GHC and it does seem to solve our problem. I can run all of our testsuite without problem, something that was previously impossible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 07:00:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 07:00:04 -0000 Subject: [GHC] #9103: hackage's type-level-0.2.4 fails to compile Message-ID: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> #9103: hackage's type-level-0.2.4 fails to compile -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Attached trimmed-down dependencyless archive. Steps to reproduce: {{{ $ tar -xzf type-level-0.2.4.tar.gz $ ghci -hide-all-packages -package=base -package=template-haskell Data/TypeLevel.hs }}} The error on 7.8.2 and in -HEAD is: {{{ [6 of 8] Compiling Data.TypeLevel.Num.Ops ( Data/TypeLevel/Num/Ops.hs, interpreted ) Data/TypeLevel/Num/Ops.hs:90:10: Illegal instance declaration for ?Succ' (x, x) (x, x) D0 D0 True? The liberal coverage condition fails in class ?Succ'? for functional dependency: ?yh yl yz -> xh xl? Reason: lhs types ?D0?, ?D0?, ?True? do not jointly determine rhs types ?(x, x)?, ?(x, x)? In the instance declaration for ?Succ' (x, x) (x, x) D0 D0 True? ... }}} Typechecked fine on ghc-7.6.3 {{{ [1 of 8] Compiling Data.TypeLevel.Num.Reps ( Data/TypeLevel/Num/Reps.hs, interpreted ) [2 of 8] Compiling Data.TypeLevel.Num.Sets ( Data/TypeLevel/Num/Sets.hs, interpreted ) [3 of 8] Compiling Data.TypeLevel.Num.Aliases.TH ( Data/TypeLevel/Num/Aliases/TH.hs, interpreted ) [4 of 8] Compiling Data.TypeLevel.Num.Aliases ( Data/TypeLevel/Num/Aliases.hs, interpreted ) Generating and compiling a zillion numerical type aliases, this might take a while [5 of 8] Compiling Data.TypeLevel.Bool ( Data/TypeLevel/Bool.hs, interpreted ) [6 of 8] Compiling Data.TypeLevel.Num.Ops ( Data/TypeLevel/Num/Ops.hs, interpreted ) [7 of 8] Compiling Data.TypeLevel.Num ( Data/TypeLevel/Num.hs, interpreted ) [8 of 8] Compiling Data.TypeLevel ( Data/TypeLevel.hs, interpreted ) Ok, modules loaded: Data.TypeLevel, Data.TypeLevel.Num, Data.TypeLevel.Bool, Data.TypeLevel.Num.Reps, Data.TypeLevel.Num.Aliases, Data.TypeLevel.Num.Sets, Data.TypeLevel.Num.Ops, Data.TypeLevel.Num.Aliases.TH. *Data.TypeLevel> }}} I have failed to decipher an error message, but looks like it tries to instantiate a thing it should not. My apologies if it's not-a-bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 08:32:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 08:32:45 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.b285c767d1891dd0fc912b7842caf289@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.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 thoughtpolice): * priority: high => highest * status: new => patch * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 10:18:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 10:18:16 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.3446f0b5ca9c4210b781588dac19aaa4@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.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 chak): @robertce Thanks! @thoughtpolice What is the current timeline for 7.8.3? This bug is basically a killer for Accelerate as it leads to intermittent failures and it doesn't seem as if we can work around it. (Would be a pity if it ends up in the HP.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 11:32:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 11:32:21 -0000 Subject: [GHC] #9099: Add strict fmap In-Reply-To: <045.7f6cb28f3b97baef1a99c0725efe4db9@haskell.org> References: <045.7f6cb28f3b97baef1a99c0725efe4db9@haskell.org> Message-ID: <060.4be14f8d2582e6e0a9e5d46aefdda91c@haskell.org> #9099: Add strict fmap -------------------------------+------------------------------------------- Reporter: quchen | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by bernalex): * cc: hvr, ekmett (added) * status: new => patch * component: None => libraries/base -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 11:55:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 11:55:03 -0000 Subject: [GHC] #9099: Add strict fmap In-Reply-To: <045.7f6cb28f3b97baef1a99c0725efe4db9@haskell.org> References: <045.7f6cb28f3b97baef1a99c0725efe4db9@haskell.org> Message-ID: <060.cc871ab84502e0eff778aab375a3e897@haskell.org> #9099: Add strict fmap -------------------------------+------------------------------------------- Reporter: quchen | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by ekmett): No objection here. It also passed unanimously through the libraries@ proposal process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 12:17:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 12:17:44 -0000 Subject: [GHC] #9102: Assertion failure in CoreUtils.lhs In-Reply-To: <048.72681b4014e365b606ae951bed049559@haskell.org> References: <048.72681b4014e365b606ae951bed049559@haskell.org> Message-ID: <063.0fc04b2c03d437c63e16acf61c675b31@haskell.org> #9102: Assertion failure in CoreUtils.lhs -------------------------------------+------------------------------------ Reporter: tmcdonell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 Simon Peyton Jones ): In [changeset:"4cfc1fae11ec9a5c4b34ac747f0ce50f52423eba/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4cfc1fae11ec9a5c4b34ac747f0ce50f52423eba" Lint should check that TyConAppCo doesn't have a synonym in the tycon position That is why Lint didn't nail Trac #9102 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 12:20:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 12:20:09 -0000 Subject: [GHC] #9102: Assertion failure in CoreUtils.lhs In-Reply-To: <048.72681b4014e365b606ae951bed049559@haskell.org> References: <048.72681b4014e365b606ae951bed049559@haskell.org> Message-ID: <063.6510965358825e006a7677644e9dfa2c@haskell.org> #9102: Assertion failure in CoreUtils.lhs -------------------------------------+------------------------------------ Reporter: tmcdonell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): This is the actual fix for #9102: {{{ commit 21f17d06aa5c33e639f1b0d37b4bf888b494c441 Author: Simon Peyton Jones Date: Tue May 13 13:17:19 2014 +0100 Fix invariant in mkAppCoFlexible mkAppCoFlexible was breaking the invariant that the head of a TyConAppCo cannot be a type synonym. This small patch fixes it. compiler/types/Coercion.lhs | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) }}} I forgot to mention the ticket in the commit message. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 12:20:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 12:20:54 -0000 Subject: [GHC] #9102: Assertion failure in CoreUtils.lhs In-Reply-To: <048.72681b4014e365b606ae951bed049559@haskell.org> References: <048.72681b4014e365b606ae951bed049559@haskell.org> Message-ID: <063.f75923188037931e973d6899cd5d5e69@haskell.org> #9102: Assertion failure in CoreUtils.lhs -------------------------------------+------------------------------------ Reporter: tmcdonell | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.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): * status: new => merge Comment: Merge to 7.8.2. I didn't get to a small test case, so no regression test for now. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 12:21:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 12:21:03 -0000 Subject: [GHC] #9055: unregisterised build fails with: globalRegMaybe not defined for this platform In-Reply-To: <047.895e86d82de4bb687806c7f173056b25@haskell.org> References: <047.895e86d82de4bb687806c7f173056b25@haskell.org> Message-ID: <062.7303b2f56be207e8305dadfd85bb62b0@haskell.org> #9055: unregisterised build fails with: globalRegMaybe not defined for this platform ---------------------------------------+----------------------------------- Reporter: trommler | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 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 Marlow ): In [changeset:"214ad2d24cda4aaef541df3e213d5c4845f95c71/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="214ad2d24cda4aaef541df3e213d5c4845f95c71" Fix globalRegMaybe for unregisterised build. In commit 83a003f globalRegMaybe will be called but panics for unregisterised compilers. In an unregisterised compiler there are no global registers so always return `Nothing`. Fixes #9055. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 14:36:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 14:36:35 -0000 Subject: [GHC] #9104: internal compiler error: Segmentation fault for haskell-src-exts-1.15.0.1 Message-ID: <047.0741014ef728e3872828ed17f196126d@haskell.org> #9104: internal compiler error: Segmentation fault for haskell-src-exts-1.15.0.1 ----------------------------------+--------------------------------------- Reporter: mhwombat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- {{{ amy at wombat$ cabal --no-require-sandbox install haskell-src-exts-1.15.0.1 Resolving dependencies... Configuring haskell-src-exts-1.15.0.1... Building haskell-src-exts-1.15.0.1... Failed to install haskell-src-exts-1.15.0.1 Last 10 lines of the build log ( /home/amy/.cabal/logs/haskell-src- exts-1.15.0.1.log ): [22 of 22] Compiling Language.Haskell.Exts ( src/Language/Haskell/Exts.hs, dist/build/Language/Haskell/Exts.o ) [ 1 of 22] Compiling Language.Haskell.Exts.Annotated.Syntax ( src/Language/Haskell/Exts/Annotated/Syntax.hs, dist/build/Language/Haskell/Exts/Annotated/Syntax.p_o ) /tmp/ghc23747_0/ghc23747_3.s:1:0: internal compiler error: Segmentation fault .section .rodata ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. cabal: Error: some packages failed to install: haskell-src-exts-1.15.0.1 failed during the building phase. The exception was: ExitFailure 1 }}} {{{ amy at wombat$ cabal --version cabal-install version 1.21.0.0 using version 1.21.0.0 of the Cabal library }}} {{{ amy at wombat$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 18:16:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 18:16:56 -0000 Subject: [GHC] #7104: Add tryWriteTBQueue to Control.Concurrent.STM.TBQueue In-Reply-To: <048.820960f7a81343147437e4061ea19d9b@haskell.org> References: <048.820960f7a81343147437e4061ea19d9b@haskell.org> Message-ID: <063.e6917c372fdd1b4a5edcf1d1ed096f8b@haskell.org> #7104: Add tryWriteTBQueue to Control.Concurrent.STM.TBQueue --------------------------------------+------------------------------------ Reporter: joeyadams | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries (other) | Version: 7.4.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by ihameed): * cc: idhameed@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 18:53:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 18:53:06 -0000 Subject: [GHC] #9105: Profiling binary consumes CPU even when idle on Linux. Message-ID: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> #9105: Profiling binary consumes CPU even when idle on Linux. ----------------------------+--------------------------------- Reporter: robinp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------- The program is main = forever $ threadDelay 1000000 >> return () . Compiled with 32bit GHC 7.6.3 or 7.8.2 on Debian (inside a VM), GHC 7.4.1 on Ubuntu (not VM). The non-profiling binary doesn't consume CPU, the profiling does ~10% (of a 2Ghz machine). Running with +RTS -I0, so this is not the idle gc. When strace-ing, the profiling one seems to receive a constant flow of SIGVTALRM, while the normal receives one burst each second. I see I can switch off "master tick interval" with -V0, and then CPU is not used, but the consequences of this are not very well documented (apart from context switching becoming deterministic). Interestingly, if I compile using profiling on Windows (latest haskell- platform, 64bit), it doesn't use more CPU than the non-profiling. So, the question is, why does this happen on Linux, and if it can be avoided somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 18:57:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 18:57:43 -0000 Subject: [GHC] #9055: unregisterised build fails with: globalRegMaybe not defined for this platform In-Reply-To: <047.895e86d82de4bb687806c7f173056b25@haskell.org> References: <047.895e86d82de4bb687806c7f173056b25@haskell.org> Message-ID: <062.f8567c5924f57782d560a235faccfe7b@haskell.org> #9055: unregisterised build fails with: globalRegMaybe not defined for this platform ---------------------------------------+----------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 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 simonmar): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 21:12:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 21:12:33 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.ca60593f64cb9bda9ded89530aef231e@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.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 ezyang): @chak Stable names are GC'd as normal (as opposed to stable *pointers*), so they'll get freed upon GCs. This behavior is new from fixing #7674, I assume that is how the bug got introduced too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 21:29:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 21:29:38 -0000 Subject: [GHC] #9106: GHC Panic related to functional dependencies - kindFunResult Message-ID: <044.0aafcc9fc1a20555c529d9fed2d8ec4a@haskell.org> #9106: GHC Panic related to functional dependencies - kindFunResult ----------------------------+--------------------------------------- Reporter: yuriy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------------- Minimal example: {{{ {-# LANGUAGE MultiParamTypeClasses, DataKinds, FunctionalDependencies, TypeOperators, KindSignatures, PolyKinds, FlexibleInstances, FlexibleContexts, UndecidableInstances #-} import GHC.TypeLits data Proxy (a :: k) = Proxy class FunctorN n f a fa | n f a -> fa where fmapn :: Proxy n -> Proxy f -> (a -> a) -> fa -> fa instance FunctorN 0 f a a where fmapn _ _ a = a instance (Functor f, FunctorN (n - 1) f a fa) => FunctorN n f a (f fa) where fmapn _ pf f = fmap (fmapn (Proxy :: Proxy (n-1)) pf f) }}} Crashes with ghc and ghci: {{{ >ghc test [1 of 1] Compiling Main ( test.hs, test.o ) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.20140130 for x86_64-unknown-mingw32): kindFunResult k{tv azb} [sk] >ghci test 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. [1 of 1] Compiling Main ( test.hs, interpreted ) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.20140130 for x86_64-unknown-mingw32): kindFunResult k{tv aPm} [sk] }}} Removing the functional dependency makes the code compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 13 21:44:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 May 2014 21:44:00 -0000 Subject: [GHC] #9106: GHC Panic related to functional dependencies - kindFunResult In-Reply-To: <044.0aafcc9fc1a20555c529d9fed2d8ec4a@haskell.org> References: <044.0aafcc9fc1a20555c529d9fed2d8ec4a@haskell.org> Message-ID: <059.7a27f7a1461a1fb55d329de131f06fe0@haskell.org> #9106: GHC Panic related to functional dependencies - kindFunResult ---------------------------------------+--------------------------- Reporter: yuriy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+--------------------------- Comment (by yuriy): The same code without {{{GHC.TypeLits}}} works: {{{ {-# LANGUAGE MultiParamTypeClasses, DataKinds, FunctionalDependencies, TypeOperators, KindSignatures, PolyKinds, FlexibleInstances, FlexibleContexts, UndecidableInstances, ScopedTypeVariables #-} data Proxy (a :: k) = Proxy data Nat = Z | P Nat class FunctorN n f a fa | n f a -> fa where fmapn :: Proxy n -> Proxy f -> (a -> a) -> fa -> fa instance FunctorN Z f a a where fmapn _ _ a = a instance (Functor f, FunctorN n f a fa) => FunctorN (P n) f a (f fa) where fmapn _ pf f = fmap (fmapn (Proxy :: Proxy n) pf f) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 05:37:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 05:37:29 -0000 Subject: [GHC] #8486: cannot derive new-typeable instances for promoted data types taking parameters In-Reply-To: <045.96a24a313436daca2fe26743eac0900c@haskell.org> References: <045.96a24a313436daca2fe26743eac0900c@haskell.org> Message-ID: <060.1e08e39944f01981f1d567f737d4516e@haskell.org> #8486: cannot derive new-typeable instances for promoted data types taking parameters -------------------------------------+------------------------------------ Reporter: aavogt | 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: 5682 -------------------------------------+------------------------------------ Changes (by aavogt): * status: new => closed * resolution: => fixed Comment: The instance is missing from 7.8.1's base. But I can now define the orphan myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 05:40:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 05:40:26 -0000 Subject: [GHC] #9107: An alternative to witness values Message-ID: <050.c090a92f66926c53f358a347814ab123@haskell.org> #9107: An alternative to witness values ----------------------------------------------+---------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- So, I might have come up with a nicer notation to providing type witnesses. Say I have a class thusly: {{{ class Metric a where measure :: Vector f -> Vector f -> f }}} and an example instance: {{{ instance Metric "Euclidean" where measure = sum . (zipWith (*)) }}} In order to actually use a specific metric, one would have to modify the type signature to include a witness, and use it such as {{{measure undefined::"Euclidean" a b}}}. Personally, I find such expressions to be ugly clutter. Instead, here are three alternate proposals which don't require including a witness: 1. {{{(Metric "Euclidean") => }}} for example {{{dot a b = (Metric "Euclidean") => measure a b}}} 2. New keyword similar to "where" {{{ dot a b = measure a b assuming (Metric "Euclidean") }}} 3. New keyword similar to "let..in" {{{dot a b = assume (Metric "Euclidean") in measure a b}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 05:48:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 05:48:05 -0000 Subject: [GHC] #9107: An alternative to witness values In-Reply-To: <050.c090a92f66926c53f358a347814ab123@haskell.org> References: <050.c090a92f66926c53f358a347814ab123@haskell.org> Message-ID: <065.cd5f8044d56e74210b77e019b541d824@haskell.org> #9107: An alternative to witness values ----------------------------+---------------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: 7.9 Priority: normal | Keywords: Component: | Architecture: Unknown/Multiple Compiler | Difficulty: Moderate (less than a day) Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by spacekitteh): Such an extension would appear to be relatively straightforward to implement, by simply adding extra constraints to the typechecker at the call site, and removing the "The class method 'measure' mentions none of the type variables of the class Metric k a" error during compilation of the typeclass. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 07:17:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 07:17:04 -0000 Subject: [GHC] #9099: Add strict fmap In-Reply-To: <045.7f6cb28f3b97baef1a99c0725efe4db9@haskell.org> References: <045.7f6cb28f3b97baef1a99c0725efe4db9@haskell.org> Message-ID: <060.c7fbe6183ff28bbac4a3eb83cf38e8de@haskell.org> #9099: Add strict fmap -------------------------------+------------------------------------------- Reporter: quchen | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | 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:"0148a1c416e42a7d7c9ff3624a0640963bfe0012/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0148a1c416e42a7d7c9ff3624a0640963bfe0012" Add strict ver. of (<$>): (<$!>) to Control.Monad A strict (<$>) has been proposed numerous times. The first time around[1] by Johan Tibell, and the last time around[2] by David Luposchainsky. David's thread was able to avoid The Bikeshed Monster, and his (<$!>) proposal received unanimous +1s all around. This addresses #9099. [1]: http://www.haskell.org/pipermail/libraries/2013-November/021728.html [2]: http://www.haskell.org/pipermail/libraries/2014-April/022864.html Authored-by: Alexander Berntsen Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 07:41:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 07:41:46 -0000 Subject: [GHC] #9099: Add strict fmap In-Reply-To: <045.7f6cb28f3b97baef1a99c0725efe4db9@haskell.org> References: <045.7f6cb28f3b97baef1a99c0725efe4db9@haskell.org> Message-ID: <060.285d64b6a442c8b6a1f1cc6d7e7f4509@haskell.org> #9099: Add strict fmap -------------------------------+------------------------------------------- Reporter: quchen | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 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: | -------------------------------+------------------------------------------- Changes (by tibbe): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 09:34:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 09:34:17 -0000 Subject: [GHC] #8991: HLint: Illegal instruction (core dumped) In-Reply-To: <046.b8f1a3100bdf99b93f640175af65e964@haskell.org> References: <046.b8f1a3100bdf99b93f640175af65e964@haskell.org> Message-ID: <061.b25ef4e8f1d3d2d20a405d710671de59@haskell.org> #8991: HLint: Illegal instruction (core dumped) -------------------------+------------------------------------------------- Reporter: | Owner: tensor5 | Status: closed Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Keywords: Component: | Architecture: x86_64 (amd64) Compiler | Difficulty: Unknown Resolution: | Blocked By: fixed | Related Tickets: https://github.com/haskell- Operating System: | suite/haskell-src-exts/issues/96 Unknown/Multiple | Type of failure: | Runtime crash | Test Case: | Blocking: | -------------------------+------------------------------------------------- Changes (by tensor5): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 10:02:55 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 10:02:55 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.ab7e80b569de87c2ba0a3c3e4e40481f@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.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 chak): @ezyang Yes, you are right. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 10:09:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 10:09:24 -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.f1189c4d568d90abbd34c7e70368555f@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: trommler Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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 simonmar): `bar.c`: {{{ static int bar = 1; int _getbar(void) { return bar; } void _setbar(int x) { bar = x; } }}} `foo.c`: {{{ extern int _getbar(void); extern void _setbar(int); int getbar(void) { return _getbar(); } int setbar(int x) { _setbar(x); } }}} `test.c`: {{{ #include #include #include extern int getbar(void); extern void setbar(int); int main(int argc, char *argv[]) { void *deflt, *hdl; int (*pgetbar)(void); int (*psetbar)(int); setbar(2); printf("getbar() = %d\n", getbar()); deflt = dlopen(NULL, RTLD_LAZY | RTLD_GLOBAL); if (deflt == NULL) { printf("%s\n", dlerror()); exit(1); } pgetbar = dlsym(deflt, "getbar"); printf("dlsym(deflt, \"getbar\") = %p, pgetbar() = %d\n", pgetbar, (*pgetbar)()); hdl = dlopen("libbar.so", RTLD_LOCAL | RTLD_LAZY); if (hdl == NULL) { printf("%s\n", dlerror()); exit(1); } pgetbar = dlsym(hdl, "_getbar"); psetbar = dlsym(hdl, "_setbar"); printf("dlsym(deflt, \"_getbar\") = %p, pgetbar() = %d\n", pgetbar, (*pgetbar)()); (*psetbar)(3); printf("(*psetbar)(3); pgetbar() = %d\n", (*pgetbar)()); hdl = dlopen("libfoo.so", RTLD_LOCAL | RTLD_LAZY); if (hdl == NULL) { printf("%s\n", dlerror()); exit(1); } pgetbar = dlsym(hdl, "getbar"); psetbar = dlsym(hdl, "setbar"); printf("dlsym(deflt, \"getbar\") = %p, pgetbar() = %d\n", pgetbar, (*pgetbar)()); (*psetbar)(4); printf("(*psetbar)(4); pgetbar() = %d\n", (*pgetbar)()); } }}} {{{ $ gcc -shared -fPIC bar.c -o libbar.so $ gcc -shared -fPIC foo.c -o libfoo.so -L. -lbar $ gcc test.c -L. -lfoo -lbar -ldl -g $ LD_LIBRARY_PATH=. ./a.out getbar() = 2 dlsym(deflt, "getbar") = 0x2b4660dcc61c, pgetbar() = 2 dlsym(deflt, "_getbar") = 0x2b46615a658c, pgetbar() = 2 (*psetbar)(3); pgetbar() = 3 dlsym(deflt, "getbar") = 0x2b4660dcc61c, pgetbar() = 3 (*psetbar)(4); pgetbar() = 4 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 14:03:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 14:03:34 -0000 Subject: [GHC] #9108: GADTs and pattern type annotations? Message-ID: <044.87ac903993cb8e53f719b4d9ed80567f@haskell.org> #9108: GADTs and pattern type annotations? ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-#?LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} import Data.Tagged data Sing (xs :: [k]) where SNil :: Sing '[] SCons :: SingI xs => Sing (x ': xs) class SingI (a :: [k]) where sing :: Sing a instance SingI '[] where sing = SNil instance SingI xs => SingI (x ': xs) where sing = SCons lengthSing :: forall (xs :: [k]). SingI xs => Tagged xs Int lengthSing = case sing :: Sing xs of SNil -> Tagged 0 (SCons :: Sing (x ': xs')) -> Tagged (1 + untag (lengthSing :: Tagged xs' Int)) }}} This gives a type error: {{{ Could not deduce (xs ~ (x : xs')) from the context (SingI xs) bound by the type signature for lengthSing :: SingI xs => Tagged xs Int at Bug.hs:23:15-59 ?xs? is a rigid type variable bound by the type signature for lengthSing :: SingI xs => Tagged xs Int at Bug.hs:23:22 Expected type: Sing xs Actual type: Sing (x : xs') }}} But once we pattern match on the `SCons` we know that `xs ~ x ': xs'` for some `x`, `xs'`, and we should be able to bring them into scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 15:29:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 15:29:42 -0000 Subject: [GHC] #9107: An alternative to witness values In-Reply-To: <050.c090a92f66926c53f358a347814ab123@haskell.org> References: <050.c090a92f66926c53f358a347814ab123@haskell.org> Message-ID: <065.d0534b567be8a5357e1f911fd454fd0d@haskell.org> #9107: An alternative to witness values ----------------------------+---------------------------------------------- Reporter: | Owner: spacekitteh | Status: closed Type: feature | Milestone: request | Version: 7.9 Priority: normal | Keywords: Component: | Architecture: Unknown/Multiple Compiler | Difficulty: Moderate (less than a day) Resolution: invalid | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by carter): * status: new => closed * resolution: => invalid Comment: This seems to be covered by using either of Implicit Params or Proxy types the Proxy witness type in http://www.haskell.org/ghc/docs/7.8.2/html/libraries/base-4.7.0.0/Data- Proxy.html see http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/other-type- extensions.html for info on implicit parameters closing. Also ask me or others on IRC if stumped about how to use those -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 18:25:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 18:25:26 -0000 Subject: [GHC] #9109: Improve error messages around "untouchable" type variables Message-ID: <047.8e8e8d32b365719fddf8914f1815c1c6@haskell.org> #9109: Improve error messages around "untouchable" type variables ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE GADTs #-} data G a where GBool :: G Bool foo GBool = True }}} I get {{{ Couldn't match expected type ?t? with actual type ?Bool? ?t? is untouchable inside the constraints (t1 ~ Bool) bound by a pattern with constructor GBool :: G Bool, in an equation for ?foo? at /Users/rae/temp/Bug.hs:6:5-9 ?t? is a rigid type variable bound by the inferred type of foo :: G t1 -> t at /Users/rae/temp/Bug.hs:6:1 Relevant bindings include foo :: G t1 -> t (bound at /Users/rae/temp/Bug.hs:6:1) In the expression: True In an equation for ?foo?: foo GBool = True }}} My code is indeed bogus and the error message is accurate. But, it's really unhelpful in that the solution to my problem is "add a type signature". In general, I occasionally see folks complain about "untouchable" error messages. Most recently, see [http://www.haskell.org/pipermail/glasgow-haskell- users/2014-May/024993.html this thread], which inspired this report. Is the solution ''always'' to just add a type signature/annotation? Would it make sense to include a link to a stable wiki page about just what "untouchable" variables are? I don't necessarily have a solution to this problem, but I think it's worth thinking about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 19:07:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 19:07:46 -0000 Subject: [GHC] #9110: MonomorphismRestriction too eager Message-ID: <047.859920e8e32f655f8e90914cf35ca628@haskell.org> #9110: MonomorphismRestriction too eager ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This strange example came up on IRC: {{{ {-# LANGUAGE MonoLocalBinds, MonomorphismRestriction #-} foo :: a foo = bar bar = undefined where _ = baz undefined baz = const [1] }}} yields {{{ /Users/rae/temp/Bug.hs:4:7: Couldn't match expected type ?a? with actual type ?t0? because type variable ?a? would escape its scope This (rigid, skolem) type variable is bound by the type signature for foo :: a at /Users/rae/temp/Bug.hs:3:8 Relevant bindings include foo :: a (bound at /Users/rae/temp/Bug.hs:4:1) In the expression: bar In an equation for ?foo?: foo = bar }}} Setting either `NoMonoLocalBinds` ''or'' `NoMonomorphismRestriction` fixes the problem. After some staring at this, I didn't get to the bottom of it. But I did learn some things: * If we remove the definition for `foo`, the module compiles. * With the monomorphism restriction (MR), `bar` gets the type `GHC.Exts.Any`. * Without the MR, `bar` gets the type `forall t.t`. * The MR bites `baz`, as it should. According to the rules in [http://www.haskell.org/onlinereport/decls.html#sect4.5.5 the Haskell Report], it seems that the MR should ''not'' bite `bar`, as `bar`'s inferred type's unification type variable is ''not'' constrained -- this is why I'm posting the example as a bug. But, I may be entirely mistaken, as the whole example makes my brain go a little fuzzy. In particular, I'm a little mystified how `MonoLocalBinds` enters the picture, but it is necessary to tickle the problem. Apologies if GHC is behaving correctly here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 19:22:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 19:22:15 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors Message-ID: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> #9111: base should export Typeable instances of its promoted data constructors ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As initially reported in #8486, `base` does not export `Typeable` instances for its promoted data constructors, as witnessed by this: {{{ {-# LANGUAGE DataKinds #-} import Data.Typeable x = typeRep (Proxy :: Proxy True) }}} yields {{{ No instance for (Typeable 'True) arising from a use of ?typeRep? In the expression: typeRep (Proxy :: Proxy True) In an equation for ?x?: x = typeRep (Proxy :: Proxy True) }}} It is indeed possible to derive these instances locally with standalone deriving, but that seems very problematic, should multiple modules do that independently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 19:23:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 19:23:06 -0000 Subject: [GHC] #8486: cannot derive new-typeable instances for promoted data types taking parameters In-Reply-To: <045.96a24a313436daca2fe26743eac0900c@haskell.org> References: <045.96a24a313436daca2fe26743eac0900c@haskell.org> Message-ID: <060.1e5a2bf3d8924d6a28d20c2cf86c2601@haskell.org> #8486: cannot derive new-typeable instances for promoted data types taking parameters -------------------------------------+------------------------------------ Reporter: aavogt | 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: 5682 -------------------------------------+------------------------------------ Comment (by goldfire): Just posted #9111 requesting that `base` export these instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 19:26:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 19:26:36 -0000 Subject: [GHC] #9001: unexpected runtime crash In-Reply-To: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> References: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> Message-ID: <060.34b5e58530b6f4df9327563d47f21091@haskell.org> #9001: unexpected runtime crash -------------------------------------+------------------------------------ Reporter: jwlato | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Marlow ): In [changeset:"fc0ed8a7309e7cc863b8155fae6b57cb23331c44/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fc0ed8a7309e7cc863b8155fae6b57cb23331c44" Add missing stack checks to stg_ap_* functions (#9001) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 19:29:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 19:29:06 -0000 Subject: [GHC] #9001: unexpected runtime crash In-Reply-To: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> References: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> Message-ID: <060.d2a6ec25762e255ad0775715dab8b954@haskell.org> #9001: unexpected runtime crash -------------------------------------+------------------------------------ Reporter: jwlato | Owner: simonmar Type: bug | Status: merge Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | 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 Wed May 14 19:37:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 19:37:41 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.9bf14110a204d523dab22e8441c912de@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 aavogt): This one doesn't work with standalone deriving either: {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE StandaloneDeriving #-} import Data.Proxy import Data.Typeable y = typeRep (Proxy :: Proxy "y") deriving instance Typeable "y" }}} The message is {{{ Can't make a derived instance of ?Typeable "y"?: The last argument of the instance must be a data or newtype application In the stand-alone deriving instance for ?Typeable "y"? }}} This issue breaks http://code.haskell.org/HList/examples/cmdargs.hs on ghc-7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 19:49:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 19:49:06 -0000 Subject: [GHC] #9108: GADTs and pattern type annotations? In-Reply-To: <044.87ac903993cb8e53f719b4d9ed80567f@haskell.org> References: <044.87ac903993cb8e53f719b4d9ed80567f@haskell.org> Message-ID: <059.fffb8e03e2e8600e3fa32ca88d4b0153@haskell.org> #9108: GADTs and pattern type annotations? -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 seems to be exactly the scenario in #6075. Essentially, GHC checks patterns from the outside working in, so it sees the type before the constructor, and before it knows about the GADT pattern match. I believe I've worked around this by doing the following painful construction: {{{ lengthSing = case sing :: Sing xs of SNil -> Tagged 0 SCons -> case sing :: Sing xs of (SCons :: Sing (x ': xs')) -> Tagged (1 + untag (lengthSing :: Tagged xs' Int)) }}} There may be a better way, but that's what I've done and it works. I suppose you could re-open as a feature request to change this behavior, if you feel so inclined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 20:00:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 20:00:48 -0000 Subject: [GHC] #9110: MonomorphismRestriction too eager In-Reply-To: <047.859920e8e32f655f8e90914cf35ca628@haskell.org> References: <047.859920e8e32f655f8e90914cf35ca628@haskell.org> Message-ID: <062.2d28ae74edf3c8a722970b5d79c475ff@haskell.org> #9110: MonomorphismRestriction too eager -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 dmwit): * cc: daniel@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 20:01:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 20:01:18 -0000 Subject: [GHC] #9109: Improve error messages around "untouchable" type variables In-Reply-To: <047.8e8e8d32b365719fddf8914f1815c1c6@haskell.org> References: <047.8e8e8d32b365719fddf8914f1815c1c6@haskell.org> Message-ID: <062.86790faaedc870d829aa10c1340605d3@haskell.org> #9109: Improve error messages around "untouchable" type variables -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 dmwit): * cc: daniel@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 20:31:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 20:31:24 -0000 Subject: [GHC] #9093: Type synonym accepted with out-of-scope kind variable In-Reply-To: <047.673f36a41cc96d4d0b95f272aa32aaf9@haskell.org> References: <047.673f36a41cc96d4d0b95f272aa32aaf9@haskell.org> Message-ID: <062.7ce216cc55e994335ef7fed6d36aa239@haskell.org> #9093: Type synonym accepted with out-of-scope kind variable ------------------------------------------------+-------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | 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 goldfire): * status: new => closed * resolution: => invalid Comment: OK -- makes sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 21:05:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 21:05: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.ee2868f2ea6142244a4017df8fba1ecc@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: trommler Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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 dagit): I think you test depends on how you link the program and libraries. I'm using your setup, but I made the following tweaks. `test.c`, in this version `dlopen` of libbar is `RTLD_GLOBAL`: {{{ #include #include #include extern int getbar(void); extern void setbar(int); int main(int argc, char *argv[]) { void *deflt, *hdl; int (*pgetbar)(void); int (*psetbar)(int); //setbar(2); //fprintf(stderr,"getbar() = %d\n", getbar()); deflt = dlopen(NULL, RTLD_LAZY | RTLD_GLOBAL); if (deflt == NULL) { fprintf(stderr,"%s\n", dlerror()); exit(1); } //pgetbar = dlsym(deflt, "getbar"); //fprintf(stderr,"dlsym(deflt, \"getbar\") = %p, pgetbar() = %d\n", pgetbar, (*pgetbar)()); hdl = dlopen("libbar.so", RTLD_GLOBAL | RTLD_LAZY); if (hdl == NULL) { fprintf(stderr,"%s\n", dlerror()); exit(1); } pgetbar = dlsym(hdl, "_getbar"); char* e; e = dlerror(); if( e != NULL ){ fprintf(stderr,"%s\n", e); } psetbar = dlsym(hdl, "_setbar"); e = dlerror(); if( e != NULL ){ fprintf(stderr,"%s\n", e); } fprintf(stderr,"dlsym(deflt, \"_getbar\") = %p, pgetbar() = %d\n", pgetbar, (*pgetbar)()); (*psetbar)(3); fprintf(stderr,"(*psetbar)(3); pgetbar() = %d\n", (*pgetbar)()); hdl = dlopen("libfoo.so", RTLD_LOCAL | RTLD_LAZY); if (hdl == NULL) { fprintf(stderr,"%s\n", dlerror()); exit(1); } pgetbar = dlsym(hdl, "getbar"); e = dlerror(); if( e != NULL ){ fprintf(stderr,"%s\n", e); } psetbar = dlsym(hdl, "setbar"); e = dlerror(); if( e != NULL ){ fprintf(stderr,"%s\n", e); } fprintf(stderr,"dlsym(deflt, \"getbar\") = %p, pgetbar() = %d\n", pgetbar, (*pgetbar)()); (*psetbar)(4); fprintf(stderr,"(*psetbar)(4); pgetbar() = %d\n", (*pgetbar)()); return 0; } }}} Here, I don't link together the libraries at compile time, not even for `test.c` (I'm trying to be careful not to call this static linking, because as we'll see later it's not): {{{ gcc -shared -fPIC bar.c -o libbar.so gcc -shared -fPIC foo.c -o libfoo.so gcc -Wall test.c -ldl -g LD_LIBRARY_PATH=. ./a.out }}} Now when I run the program I get: {{{ dlsym(deflt, "_getbar") = 0x7fddcc3a5698, pgetbar() = 1 (*psetbar)(3); pgetbar() = 3 dlsym(deflt, "getbar") = 0x7fddcc1a3728, pgetbar() = 3 (*psetbar)(4); pgetbar() = 4 }}} Okay, as we would expect libfoo uses the definition in libbar. Now, switch the `dlopen` to `RTLD_LOCAL`, and run it again: {{{ dlsym(deflt, "_getbar") = 0x7f056f698698, pgetbar() = 1 (*psetbar)(3); pgetbar() = 3 ./a.out: symbol lookup error: ./libfoo.so: undefined symbol: _getbar }}} Now if we link libbar and the final program: {{{ gcc -shared -fPIC bar.c -o libbar.so gcc -shared -fPIC foo.c -o libfoo.so gcc -Wall test.c -L. -lbar -ldl -g LD_LIBRARY_PATH=. ./a.out dlsym(deflt, "_getbar") = 0x7f75b9914698, pgetbar() = 1 (*psetbar)(3); pgetbar() = 3 dlsym(deflt, "getbar") = 0x7f75b96f9728, pgetbar() = 3 (*psetbar)(4); pgetbar() = 4 }}} Now it finds the symbol again. The difference seems to be this: {{{ readelf -Wa a.out.withbar | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [libbar.so] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] readelf -Wa a.out.withoutbar | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] }}} In other words, mentioning libbar on the gcc line for `test.c` adds an entry that the elf interpreter sees and it resolves the symbol, lazily, before we get into main. I would expect the same behavior if libfoo had been linked to libbar instead of with the main application. And indeed, that's what we get: {{{ gcc -shared -fPIC bar.c -o libbar.so gcc -shared -fPIC foo.c -o libfoo.so -L. -lbar gcc -Wall test.c -ldl -g -o a.out.withoutbar LD_LIBRARY_PATH=. ./a.out.withoutbar dlsym(deflt, "_getbar") = 0x7fc75e77c698, pgetbar() = 1 (*psetbar)(3); pgetbar() = 3 dlsym(deflt, "getbar") = 0x7fc75e57a728, pgetbar() = 3 (*psetbar)(4); pgetbar() = 4 readelf -Wa libfoo.so | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [libbar.so] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 21:21:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 21:21:41 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.8ca2dc4e4000e88df4d1f24d39082f14@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------ Reporter: simonpj | Owner: goldfire 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): See also [http://www.haskell.org/pipermail/glasgow-haskell- users/2014-May/025000.html this thread on the GHC users list], which offers (I think) another example of the importance of this feature. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 21:24:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 21:24:37 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.0032bb3ec7bc2c62372173a34b26d05b@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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): * cc: core-libraries-committee@? (added) Comment: What precisely is being requested here? Which instances? Would you care to offer a patch? I'm adding the core libraries committee to cc. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 21:57:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 21:57:32 -0000 Subject: [GHC] #9110: MonomorphismRestriction too eager In-Reply-To: <047.859920e8e32f655f8e90914cf35ca628@haskell.org> References: <047.859920e8e32f655f8e90914cf35ca628@haskell.org> Message-ID: <062.3c3ad293e9fffdf51c494754fb1fed6c@haskell.org> #9110: MonomorphismRestriction too eager -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): Here is what is happening: * `baz` gets the type `forall b. b -> alpha`, where `alpha` is a unification variable, plus a `Num alpha` constraint. The MR prevents us generalising the `alpha`. * Because `baz` is bitten by the MR, it is not considered "closed"; see [http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/other-type- extensions.html#monomorphism 7.13.9.3 in the user manual]. Actually the user manual is badly framed here. It should say "A binding is considered closed if (a) all its free variables are imported or closed, and (b) it is unaffected by the monomorphism restriction." * Because `baz` is not closed, and `bar` mentions `baz`, `bar` is not closed. Since `LocalMonoBinds` is force, `bar` is not generalised. * Since `bar` is not genrealised, `foo` really is not as polymorphic as its type signature claims. I'll fix the user manual, but otherwise things are working fine Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 23:42:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 23:42:04 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.c30d4723b877978c99384bf81e89c4cb@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): My original report was intended to suggest instances for all promotable types in base/ghc-prim that export `Typeable` instances for the unpromoted types, like `[]`, `Bool`, `Maybe`, `Either`, `Ordering`, tuples, etc. While we're at it, we should probably export `Typeable` instances for ''classes'', too, like `Eq` and `Monad`, among many others. If no one sees a downside to adding these instances, I can submit a patch yes. For the problem reported in the first comment -- about a `Typeable` instance for `Symbol`s (and presumably `Nat`s) -- the implementation technique is somewhat different and might best be something for Iavor. [http://www.haskell.org/pipermail/haskell-cafe/2013-August/109993.html This message] from August 2013 suggests that he is on it, but I don't know if there has been progress since then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 14 23:56:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 May 2014 23:56:48 -0000 Subject: [GHC] #9110: MonomorphismRestriction too eager In-Reply-To: <047.859920e8e32f655f8e90914cf35ca628@haskell.org> References: <047.859920e8e32f655f8e90914cf35ca628@haskell.org> Message-ID: <062.8fdb20dde7fa9b584b967a4ebf870796@haskell.org> #9110: MonomorphismRestriction too eager -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): Ah. I was thinking that the `MonoLocalBinds` was affecting the of the `where`-bound `_` and that somehow that was causing the problem, hence my deep confusion in that area. Your explanation makes good sense. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 01:54:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 01:54:41 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.7c39c208c6b9dcff6a30a5d094830d15@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------ Reporter: simonpj | Owner: goldfire 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 jwlato): I agree that the `vector` issue is related to this feature. In summary, we would like the following to work (greatly simplified from vector WLOG): {{{ class MVectorClass (v :: * -> * -> *) a where basicLength :: v s a -> Int data family MVector s a data instance MVector s Int -- implementation not important newtype Age = Age Int deriving (MVectorClass MVector) -- rejected }}} The deriving is rejected because it generates {{{ basicLength = coerce (basicLength :: MVector s Int -> Int) :: MVector s Age -> Int }}} If my understanding of role inference is correct, allowing {{{ type role instance MVector nominal representational }}} would allow for this coerce to take place. This means that we can't currently derive Unbox instances for vectors of newtypes (see https://github.com/haskell/vector/issues/16), which is rather unfortunate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 01:55:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 01:55:04 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.95a817e3f06ce87cc1f478e313955362@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------ Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: high | 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 jwlato): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 02:16:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 02:16:54 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.789ebced3e0d9f5cf69f6caece110593@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------ Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: high | 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 liyang): * cc: hackage.haskell.org@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 02:29:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 02:29:03 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.bd989c4ca52c4f7530c3fd0113522482@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------ Reporter: simonpj | Owner: goldfire 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 goldfire): * priority: high => normal Comment: Hmm... well, this just got a little more complicated. The full example John just posted would not be solved by fixing this ticket. That's because the data instance for `MVector` ''pattern-matches'' on `Int`. Currently in GHC, it would be sound to have both the instance given and a separate instance ending in `Age`, and have these instances be unrelated. Accordingly, if the `MVector` were declared to have a representational role for its last parameter, the instance given would be rejected for pattern-matching on a representational parameter. What it seems John wants is something new -- a data family that does ''representational'' matching, not nominal matching. Such a beast would consider `data instance MVector s Int` and `data instance MVector s Age` to overlap. Along similar lines, if a `MVector s Age` were requested, GHC would serve up the instance for `MVector s Int`. While I can imagine implementing such a feature (essentially by preventing newtypes from appearing in instance declarations, much like how type families can't appear in instance declarations today... and then normalizing with respect to newtypes at usage sites), the ramifications of the design are far from clear. In particular, what if the constructor of a newtype is not available? It would also mean, for example, that if a library exports a newtype `Foo` abstractly, a user wishing to have an `MVector` instance for `Foo` would need to know `Foo`'s representation type, something that the library author thought was hidden from users. It's all a little murky. So, I'm saying that John's use case does ''not'' qualify for this ticket, and I'll un-bump its priority. John, if in light of my analysis (and if you agree with it!) you still want this feature, create a new feature request with the priority you feel is appropriate. This seems related but quite separable to the features requested in this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 02:49:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 02:49:57 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.5b843edb547c5609a1068a85e5bf494f@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------ Reporter: simonpj | Owner: goldfire 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 jwlato): It's only outside the scope of this request if you insist on the rule that parameters at role R can't be matched against. I think I agree with Richard's analysis that this would entail a data family that does representational matching. I do think this is a valuable feature as ghc-7.8 broke code some code in the wild, so I'll make a new ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 02:57:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 02:57:18 -0000 Subject: [GHC] #9112: data families with representational matching Message-ID: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> #9112: data families with representational matching ------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Since ghc-7.8, the following is no longer possible: {{{ -- simplified example taken from the vector package class MVectorClass (v :: * -> * -> *) a where basicLength :: v s a -> Int data family MVector s a data instance MVector s Int -- implementation not important newtype Age = Age Int deriving (MVectorClass MVector) -- rejected }}} Following from discussion in #8177, to enable this ghc would need to support data families with representational matching, such that `MVector s Int` and `MVector s Age` are representationally equal. This has broken some code that previously worked, however as there are some workarounds I'm not sure how important it is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 03:16:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 03:16:08 -0000 Subject: [GHC] #9112: data families with representational matching In-Reply-To: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> References: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> Message-ID: <060.8813e0e0aac40e6b43bfd98fc0941bcd@haskell.org> #9112: data families with representational matching -------------------------------------+------------------------------------ Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 liyang): * cc: hackage.haskell.org@? (added) Comment: I'm not sure using [http://hackage.haskell.org/package/vector-th-unbox vector-th-unbox] counts as a complete workaround, as it amounts to giving the instance in full. Without coerce, I think it's also susceptible to the expensive "map id" issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 05:18:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 05:18:50 -0000 Subject: [GHC] #9113: Template Haskell should warn about non-exhaustive pattern matches Message-ID: <042.80c5d78608ff3c2a95ab5b9b46f7d317@haskell.org> #9113: Template Haskell should warn about non-exhaustive pattern matches -------------------------+------------------------------------------------- Reporter: tvh | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.8.2 Component: | Operating System: Unknown/Multiple Template Haskell | Type of failure: Incorrect warning at Keywords: | compile-time Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- When using Typed Template Haskell, There are no warings for non-exhaustive patterns inside the quote. {{{ {-# LANGUAGE TemplateHaskell #-} module Foo where import Language.Haskell.TH.Lib foo :: Maybe Int -> TExpQ Bool foo x = [||case x of Nothing -> False||] }}} Instead the warnings appear where the code is spliced. {{{ {-# LANGUAGE TemplateHaskell #-} module Bar where import Foo x = $$(foo (Just 1)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 06:12:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 06:12:11 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.f033eaa998aadee49ff395657a4a5e13@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 ekmett): It makes sense to me that everything that can be `Typeable` should be. Even `Typeable`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 06:15:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 06:15:28 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.51a896577c58ba5329f02d9cb2aaf1d5@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 ekmett): Should deriving Typeable on a type just also derive Typeable for its promoted constructors as well? That would cover most enduser use cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 06:17:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 06:17:23 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.e601b285b22f1d659cfb746aed0c4b37@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 snoyberg): Let me ask a possibly absurd question: should GHC just automatically derive Typeable for every single type, regardless of the presence of a deriving Typeable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 06:45:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 06:45:21 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.05972928ecc88e99277db8d5f190ac12@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 ekmett): It would be a lot less brittle than the current situation. Every time I turn around some package I need forgot to write the instance. The safety of Typeable comes from the Typeable requirement at the use site. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 07:10:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 07:10:44 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.c873ed35e5e6a01573d15ecca3f05bea@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.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: | -------------------------------+------------------------------------------- Comment (by spacekitteh): Here's another real world use case. Given {{{ class Manifold' a where type Field a type Base a type Tangent a type TangentBundle a type Dimension a? Nat type UsesMetric a? Symbol project ? a ? Base a unproject ? Base a? a tangent ? a ? TangentBundle a cotangent ? a ? (TangentBundle a? Field a) }}} then this works: {{{ id' ? ? a. ( Manifold' a) ? Base a ? Base a id' input= project out where out?a out = unproject input }}} whereas this requires injective type families: {{{ id' ? ? a. ( Manifold' a) ? Base a ? Base a id' = project ? unproject }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 07:32:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 07:32:03 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.279f011d98a27db130081948d7bfa003@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): Deriving `Typeable` automatically is exactly what `AutoDeriveTypeable` is for (see [http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html #auto-derive-typeable user manual]) Moreover the manual claims that `AutoDeriveTypeable` will also derive `Typeable` for the promoted data constructors. I think we should probably switch it on for the entire `base` package, and the chair of the core libraries committee seems to agree. That would be simpler than a lot of ad-hoc instances. (Indeed I kind of wonder '''whether it is ever useful NOT to derive `Typeable`'''? If not, we could just derive `Typeable` automatically for everything. In implementation terms it would mean we could get rid of all the instance declarations in the interface file, since they would all be there by implication.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 07:49:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 07:49:44 -0000 Subject: [GHC] #9112: data families with representational matching In-Reply-To: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> References: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> Message-ID: <060.7e225766a106a23a1b91bd459f995d3e@haskell.org> #9112: data families with representational matching -------------------------------------+------------------------------------ Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): The trouble is that you can say {{{ data instance MVector s Int = ...rep1... data instance MVector s Age = ...rep2... }}} so that `MVector` over `Int` has an entirely different representation to `MVector` over `Age`. Indeed that is often the very reason that people define a newtype in the first place! For example, if you want `sort` to sort into reverse order, can write {{{ import Data.Ord( Down(..) ) downSort :: Ord a => [a] -> [a] downSort xs = coerce (sort (coerce xs :: [Down a])) }}} We coerce the `[a]` to `[Down a]`, then sort (using `Down`'s ordering), then coerce back. It's going to be quite confusing `data instance` can sometimes match on a newtype, and sometimes not. And then there are nested cases to worry about: {{{ newtype MVector s [Age] = ... newtype MVector s [Int] = ... }}} Moreover, you still (presumably) want `MVector s Age` and `MVector s Int` to be distinct types! None of this smells good to me. But here's an idea. You want `MVector s Age` and `MVector s Int` But you want them to be represented the same way. That's what we use newtypes for. So how about this: {{{ newtype instance MVector s Age = MVA (MVector s Int) }}} Would that help? For example, this compiles without complaint: {{{ {-# LANGUAGE MultiParamTypeClasses, TypeFamilies, GeneralizedNewtypeDeriving #-} module T9112 where class MVectorClass (v :: * -> * -> *) a where basicLength :: v s a -> Int data family MVector s a data instance MVector s Int = MV -- implementation not important newtype Age = Age Int deriving (MVectorClass MVector) newtype instance MVector s Age = MV1 (MVector s Int) instance MVectorClass MVector Int where basicLength x = 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 08:22:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 08:22:25 -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.526fd0d4df82ed266adea3071d8f2a02@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: trommler Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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 simonmar): @dagit: that's right, the point of that test is to show that a library loaded with `RTLD_LOCAL` is used to satisfy a dependency of another library loaded with `RTLD_LOCAL`. The dependency is expressed by the `DT_NEEDED` tag, and is set up when you link the library. @trommler's point earlier was that if we use `RTLD_LOCAL` then we'll need to ensure that all the dependencies are specified with `DT_NEEDED` tags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 08:39:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 08:39:26 -0000 Subject: [GHC] #9108: GADTs and pattern type annotations? In-Reply-To: <044.87ac903993cb8e53f719b4d9ed80567f@haskell.org> References: <044.87ac903993cb8e53f719b4d9ed80567f@haskell.org> Message-ID: <059.25b601069e584e1b1166b71bf338e44b@haskell.org> #9108: GADTs and pattern type annotations? -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by edsko): Hmmmm, nasty :( I worked out in a different way, and Andres suggested yet another way (using a type family), but it seems me me that this evaluated- before-pattern-match behaviour is unfortunate behaviour; mightn't have made a difference before GADTs but with GADTs is just seems the wrong way around? Are there reasons ''not'' to evaluate the pattern match before the type annotation? (It's a tricky thing, type checking for GADTs, I realize that :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 09:11:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 09:11:22 -0000 Subject: [GHC] #9114: Invalid UTF8 not round-tripped correctly Message-ID: <046.a5f7211f47ee3c5c9ca358418466de36@haskell.org> #9114: Invalid UTF8 not round-tripped correctly ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | 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 reported by Robert Bihlmeyer at http://bugs.debian.org/748125, the promised round-tripping of invalid UTF8 sequences in filenames through String does not work: ``` $ mkdir foo $ touch foo/$(echo -e '\xC0\xB7.txt') $ ghc -e 'System.Directory.getDirectoryContents "foo" >>= print . last' "7.txt" ``` The sequence 0xC8B7 is an (invalid) encoding of 37, i.e. `'7'`, so if it is mapped to `'7'`, no round-tripping is possible. (Other invalid byte sequences are round-tripped.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 09:12:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 09:12:27 -0000 Subject: [GHC] #9114: Invalid UTF8 not round-tripped correctly In-Reply-To: <046.a5f7211f47ee3c5c9ca358418466de36@haskell.org> References: <046.a5f7211f47ee3c5c9ca358418466de36@haskell.org> Message-ID: <061.1099489b0e68813bd5d89623792cb66a@haskell.org> #9114: Invalid UTF8 not round-tripped correctly -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | 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: -------------------------------------+------------------------------------ Comment (by nomeata): Sigh, got the syntax wrong and am lacking the rights to edit my own posts. If someone with the rights feels like it, please replace {{{```}}} by {{{{{{}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 09:26:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 09:26:48 -0000 Subject: [GHC] #9114: Invalid UTF8 not round-tripped correctly In-Reply-To: <046.a5f7211f47ee3c5c9ca358418466de36@haskell.org> References: <046.a5f7211f47ee3c5c9ca358418466de36@haskell.org> Message-ID: <061.137c49b7fe616f47b7d8c0867981edac@haskell.org> #9114: Invalid UTF8 not round-tripped correctly -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | 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: -------------------------------------+------------------------------------ Description changed by tibbe: Old description: > As reported by Robert Bihlmeyer at http://bugs.debian.org/748125, the > promised round-tripping of invalid UTF8 sequences in filenames through > String does not work: > > ``` > $ mkdir foo > $ touch foo/$(echo -e '\xC0\xB7.txt') > $ ghc -e 'System.Directory.getDirectoryContents "foo" >>= print . last' > "7.txt" > ``` > > The sequence 0xC8B7 is an (invalid) encoding of 37, i.e. `'7'`, so if it > is mapped to `'7'`, no round-tripping is possible. (Other invalid byte > sequences are round-tripped.) New description: As reported by Robert Bihlmeyer at http://bugs.debian.org/748125, the promised round-tripping of invalid UTF8 sequences in filenames through String does not work: {{{ $ mkdir foo $ touch foo/$(echo -e '\xC0\xB7.txt') $ ghc -e 'System.Directory.getDirectoryContents "foo" >>= print . last' "7.txt" }}} The sequence 0xC8B7 is an (invalid) encoding of 37, i.e. `'7'`, so if it is mapped to `'7'`, no round-tripping is possible. (Other invalid byte sequences are round-tripped.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 10:15:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 10:15:23 -0000 Subject: [GHC] #9114: Invalid UTF8 not round-tripped correctly In-Reply-To: <046.a5f7211f47ee3c5c9ca358418466de36@haskell.org> References: <046.a5f7211f47ee3c5c9ca358418466de36@haskell.org> Message-ID: <061.313eb6ac5ec719db0a6d6f97532f74d6@haskell.org> #9114: Invalid UTF8 not round-tripped correctly -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | 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: -------------------------------------+------------------------------------ Comment (by hvr): Isn't this rather to be filed against `libraries/directory`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 11:33:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 11:33:16 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.59b8fa0624fa75e8b98cfaf14632df15@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 hvr): Replying to [comment:8 simonpj]: > I think we should probably switch it on for the entire `base` package, and the chair of the core libraries committee seems to agree. That would be simpler than a lot of ad-hoc instances. Btw, I just tried to enable it globally in order to get a list of additional `Typeable` instances becoming available by that, but you have to avoid using `AutoDeriveTypeable` at the same time with `NoImplicitPrelude`, as otherwise you get the error {{{ Failed to load interface for ?Data.Typeable.Internal? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 11:44:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 11:44:32 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.5f7bfccf99af8b4aa38f66d1f9255e71@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 hvr): Replying to [comment:9 hvr]: > have to avoid using `AutoDeriveTypeable` at the same time with `NoImplicitPrelude`, as otherwise you get the error Nevermind that, as all modules in `base` obviously have to have `NoImplicitPrelude` on. There's something else causing that error, as `Data.Monoid` and `Control.Applicative` work fine having `AutoDeriveTypeable` and `NoImplicitPrelude` enabled at the same time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 11:58:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 11:58:33 -0000 Subject: [GHC] #9114: Invalid UTF8 not round-tripped correctly In-Reply-To: <046.a5f7211f47ee3c5c9ca358418466de36@haskell.org> References: <046.a5f7211f47ee3c5c9ca358418466de36@haskell.org> Message-ID: <061.5914435f5954ab7d1536aad8bc1136b1@haskell.org> #9114: Invalid UTF8 not round-tripped correctly -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | 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: -------------------------------------+------------------------------------ Comment (by nomeata): No, I believe the bug is in `GHC.IO.Encoding` or `GHC.IO.Encoding.UTF8`. I tried to give an example using that interface, but failed to work with these buffers; the following code always prints `'\NUL'`: {{{ import GHC.IO.Encoding import GHC.IO.Buffer import GHC.IO.Encoding.Types main = do te <- getFileSystemEncoding case te of TextEncoding _ decIO _ -> do BufferCodec encode recover close getState setState <- decIO bb <- newByteBuffer 2 ReadBuffer writeWord8Buf (bufRaw bb) 0 0xC0 writeWord8Buf (bufRaw bb) 1 0xB7 checkBuffer bb cb <- newCharBuffer 1 WriteBuffer (InputUnderflow,_,cb') <- encode bb cb close c <- peekCharBuf (bufRaw cb') 0 print c }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 11:59:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 11:59:31 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.6f0a5ebdab97ae87c402eeeb49ca2185@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): See [https://ghc.haskell.org/trac/ghc/ticket/8950#comment:7 this comment] in #8950. I can't quite tell there if `AutoDeriveTypeable` derives for promoted data constructors without `DataKinds`. Would universally deriving `Typeable` break some abstraction guarantees? That is, if a library wanted to hide some types, could they be gotten through their (unhideable) `Typeable` instances? Template Haskell can surely do this, but I might be willing to ignore that particular attack. Are there others? What if a type is known but not the constructors? (I don't think `Typeable` can do this.) What about if a type synonym is known but the RHS isn't exported? (I bet it can do this.) I'm not strongly against this idea, but I just want to understand the ramifications of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 12:06:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 12:06:55 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.70a7d148a67cc12d3a313b63c1da7142@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 dreixel): Replying to [comment:11 goldfire]: > Would universally deriving `Typeable` break some abstraction guarantees? That is, if a library wanted to hide some types, could they be gotten through their (unhideable) `Typeable` instances? Template Haskell can surely do this, but I might be willing to ignore that particular attack. Are there others? What if a type is known but not the constructors? (I don't think `Typeable` can do this.) What about if a type synonym is known but the RHS isn't exported? (I bet it can do this.) `Typeable` knows nothing about the RHS of its type, so constructors are safe. Also, if you don't export a type nor any of its constructors, I don't see how you could use its |typeRep|, so I guess you're safe too (ignoring Template Haskell, of course). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 14:48:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 14:48:00 -0000 Subject: [GHC] #9106: GHC Panic related to functional dependencies - kindFunResult In-Reply-To: <044.0aafcc9fc1a20555c529d9fed2d8ec4a@haskell.org> References: <044.0aafcc9fc1a20555c529d9fed2d8ec4a@haskell.org> Message-ID: <059.0323f183631c21584af9505c446eb82e@haskell.org> #9106: GHC Panic related to functional dependencies - kindFunResult ---------------------------------------+--------------------------- Reporter: yuriy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): Also annotating the `Z` instance with an explicit kind, `(f :: *)`, makes the `GHC.TypeLits` version work: {{{ {-# LANGUAGE MultiParamTypeClasses, DataKinds, FunctionalDependencies, TypeOperators, KindSignatures, PolyKinds, FlexibleInstances, FlexibleContexts, UndecidableInstances, ScopedTypeVariables #-} module FunctorN where import GHC.TypeLits data Proxy (a :: k) = Proxy class FunctorN n f a fa | n f a -> fa where fmapn :: Proxy n -> Proxy f -> (a -> a) -> fa -> fa instance FunctorN 0 (f :: *) a a where fmapn _ _ a = a instance (Functor f, FunctorN (n - 1) f a fa) => FunctorN n f a (f fa) where fmapn _ pf f = fmap (fmapn (Proxy :: Proxy (n-1)) pf f) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 15:07:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 15:07:32 -0000 Subject: [GHC] #9102: Assertion failure in CoreUtils.lhs In-Reply-To: <048.72681b4014e365b606ae951bed049559@haskell.org> References: <048.72681b4014e365b606ae951bed049559@haskell.org> Message-ID: <063.e86bbea690d24cd000f8b06d2649f185@haskell.org> #9102: Assertion failure in CoreUtils.lhs -------------------------------------+------------------------------------ Reporter: tmcdonell | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 Simon Peyton Jones ): In [changeset:"022f8750edf6f413fba31293435dcc62600eab77/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="022f8750edf6f413fba31293435dcc62600eab77" Refactoring around TyCon.isSynTyCon * Document isSynTyCon better * Add isTypeSyonymTyCon for regular H98 type synonyms * Use isTypeSynonymTyCon rather than isSynTyCon where the former is really intended All arose as part of a bug I introduced when fixing Trac #9102, thinking that isSynTyCon meant H98 type syononyms. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 15:16:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 15:16:37 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.48720107e8288bf0e40b5429919a6739@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 ekmett): You could in theory go through it and find it inside of something else that is `Data`, (abusing `showsTypeRep` for instance), but that `Data` instance couldn't have been written without `Typeable` for the part before anyways. This doesn't strike me as a serious problem, personally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 16:09:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 16:09:44 -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.700ebdf664a3729d915d1e49c363f4ee@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: trommler Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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 dagit): Excellent. I must have missed trommler saying that. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 18:35:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 18:35:35 -0000 Subject: [GHC] #9115: The kind of (=>) Message-ID: <047.79a80bb2b897dcc6ec2d89a1e91dba60@haskell.org> #9115: The kind of (=>) ------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This is mainly a request for clarification, and not very important. Is there any good (theoretical, implementation, practical, ...) reason why (with `ConstraintKinds`) enabled, the `=>` symbol on the type-level is still treated as a built-in syntactic construct rather than a type-level operator with {{{ GHCi> :kind (=>) (=>) :: Constraint -> * -> * }}} Note that I'm not actually proposing to make it re-definable, but to treat it similarly to the `(->)` type operator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 18:47:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 18:47:24 -0000 Subject: [GHC] #9116: RTS Linker doesn't recognize .text.unlikely section on Windows Message-ID: <046.5c0df74d4f5647bfd1a9764670611eb2@haskell.org> #9116: RTS Linker doesn't recognize .text.unlikely section on Windows -------------------------------------+------------------------------------- Reporter: niklasl | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHC rejects Difficulty: Easy (less than 1 | valid program hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- When trying to use a newer gcc with GHC 7.8.2, some .o files are rejected by the linker for containing a .text.unlikely section with the following message: {{{ Loading package text-1.1.1.2 ... ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-mingw32): loadObj "C:\\Niklas\\src\\Idris-dev\\.cabal-sandbox\\x86_64 -windows-ghc-7.8.2\\text-1.1.1.2\\HStext-1.1.1.2.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghc.exe: Unknown PEi386 section name `.text.unlikely' (while processing: C:\Niklas\src\Idris-dev\.cabal-sandbox\x86_64-windows- ghc-7.8.2\text-1.1.1.2\HStext-1.1.1.2.o) }}} This comes from the ocGetNames_PEi386 function in rts/Linker.c. There is a list of section names recognized as code sections at line 4146- in that file. The fix is to add .text.unlikely there, or maybe the right solution is to cast the net wider and accept .text.* as code sections. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 18:54:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 18:54:47 -0000 Subject: [GHC] #9116: RTS Linker doesn't recognize .text.unlikely section on Windows In-Reply-To: <046.5c0df74d4f5647bfd1a9764670611eb2@haskell.org> References: <046.5c0df74d4f5647bfd1a9764670611eb2@haskell.org> Message-ID: <061.d3066a8befdfffe4205f8f19820fc2db@haskell.org> #9116: RTS Linker doesn't recognize .text.unlikely section on Windows -------------------------------------+------------------------------------- Reporter: niklasl | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Easy (less than 1 valid program | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by niklasl): Forgot to say that the newer gcc in question was version 4.9.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 18:59:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 18:59:23 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one Message-ID: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> #9117: Coercible constraint solver misses one ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I say {{{ import Data.Type.Coercion import Data.Coerce eta :: Coercible f g => Coercion (f a) (g a) eta = Coercion }}} I get {{{ Could not coerce from ?f a? to ?g a? because ?f a? and ?g a? are different types. arising from a use of ?Coercion? from the context (Coercible f g) bound by the type signature for eta :: Coercible f g => Coercion (f a) (g a) at /Users/rae/temp/Roles.hs:6:8-44 In the expression: Coercion In an equation for ?eta?: eta = Coercion }}} But, this coercion is easily expressible in Core. If `(co :: f ~R# g)` then `(co :: f a ~R# g a)`, where `` is the notation for a reflexivity coercion for the type `a`. The constraint solver should be able to do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 19:02:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 19:02:06 -0000 Subject: [GHC] #1475: Adding imports and exports with Template Haskell In-Reply-To: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@haskell.org> References: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@haskell.org> Message-ID: <059.a8833df46db8813ee05022ae440ed90b@haskell.org> #1475: Adding imports and exports with Template Haskell -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.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 yokto): * cc: silvio.frischi@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 19:06:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 19:06:35 -0000 Subject: [GHC] #9118: Can't eta-reduce representational coercions Message-ID: <047.51e26113c799743ba87b936ff219c6a7@haskell.org> #9118: Can't eta-reduce representational coercions ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I say {{{ import Data.Type.Coercion import Data.Coerce import Data.Proxy eta2 :: Coercible (f a) (g a) => Proxy a -> Coercion f g eta2 _ = Coercion }}} I get {{{ Could not coerce from ?f? to ?g? because ?f? and ?g? are different types. arising from a use of ?Coercion? from the context (Coercible (f a) (g a)) bound by the type signature for eta2 :: Coercible (f a) (g a) => Proxy a -> Coercion f g at /Users/rae/temp/Roles.hs:5:9-56 In the expression: Coercion In an equation for ?eta2?: eta2 _ = Coercion }}} Unlike the case for #9116, this one is ''not'' expressible in Core. (At least, I don't see a way to do it.) So, to do this, we would have to update Core and then update the constraint solver. I ''do'' think this would be type safe. But, I also think it's reasonable to wait for someone with a real use case to shout before doing this. The only use case I have is to be able to do this: {{{ -- says that a's parameter is representational class Rep (a :: k1 -> k2) where co :: Coercible x y => Coercible (a x) (a x) instance Rep f => Rep (Compose f) where ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 19:47:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 19:47:03 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.e199762d115b901b95377035b809edb3@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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: => nomeata Comment: Good point. Joachim, might you look at this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 20:37:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 20:37:50 -0000 Subject: [GHC] #8971: Native Code Generator for 7.8 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.6972adb508fee82cf2028b8f8253095e@haskell.org> #8971: Native Code Generator for 7.8 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (NCG) | 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 simonmar): * milestone: => 7.10.1 Comment: I looked at this. The short version is that this isn't going to be easy to fix, and I recommend using LLVM. The new code generator generates better code for let-no-escapes than the old code generator. Whereas previously a let-no-escape would be a whole function with a fixed calling convention, with the new code generator it is just a label, and to call it we assign local variables for the arguments. All things being equal, this is a better way to do things, because we're not fixing the arguments to particular registers, and we're giving the later phases more flexibility to optimise. However, the register allocator in our NCG isn't very good, particularly with loops, and it ends up doing a worse job with the new code than the old, even though previously most of the arguments were actually passed on the Haskell stack. I don't think there are any easy tweaks to improve things, unfortunately. On 64-bit we get away with it because we have more registers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 20:40:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 20:40:05 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.49d1249cb7c18a62875d7c2213c598ec@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 nomeata): Is this subsumed by #8555? Do we want a general ?instance? {{{Coercible f g => Coercion (f a) (g a)}}}? Wouldn?t that run into a dead end in situations like {{{ newtype Foo1 a = Foo1 (a,()) newtype Foo2 a = Foo2 (a,()) coerce :: Foo1 () -> Foo2 () }}} which might simplify this to {{{Coercible Foo1 Foo2}}} if that happens to happen before the newtype-unwrapping instance? So while it surely is possible to add that to the solver somehow, e.g. as a final thing to try, I?m not sure about all the implications. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 20:50:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 20:50:35 -0000 Subject: [GHC] #9108: GADTs and pattern type annotations? In-Reply-To: <044.87ac903993cb8e53f719b4d9ed80567f@haskell.org> References: <044.87ac903993cb8e53f719b4d9ed80567f@haskell.org> Message-ID: <059.dd26d7891e139d524f9ac872e33c26bf@haskell.org> #9108: GADTs and pattern type annotations? -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | 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): There is a slightly nicer encoding than Richards: {{{ lengthSing = case (sing :: Sing xs, sing) of (SNil, _) -> Tagged 0 (SCons, _ :: Sing (x ': xs')) -> Tagged (1 + untag (lengthSing :: Tagged xs' Int)) }}} We could try to make pattern signatures behave like this all the time. It's not even hard to do; I tried it and got these testsuite failures in `typecheck/` alone: {{{ Unexpected failures: should_compile T7827 [exit code non-0] (normal) should_compile tc194 [exit code non-0] (normal) should_compile tc211 [stderr mismatch] (normal) should_fail T5691 [stderr mismatch] (normal) }}} One reason is that it doesn't work for 'foralls'. Currently this works (just), and is quite convenient: {{{ f = \(x :: forall a. a -> a) -> (x True, x 'v') }}} But if you imagine applying the type signature "after the match", we'd end up unifying a forall type with a unification variable, which isn't allowed. Another thing that bugs me is that the unification that arises from a pattern signature gives rise to a coercion. What do we do with that coercion under the "match first then apply signature" story? I'm not sure what to do here. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 20:51:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 20:51:42 -0000 Subject: [GHC] #9118: Can't eta-reduce representational coercions In-Reply-To: <047.51e26113c799743ba87b936ff219c6a7@haskell.org> References: <047.51e26113c799743ba87b936ff219c6a7@haskell.org> Message-ID: <062.74cc919c3f35a37b42be2c27034f9aec@haskell.org> #9118: Can't eta-reduce representational coercions -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9117 -------------------------------------+------------------------------------ Changes (by nomeata): * cc: mail@? (added) * related: => #9117 Comment: Wouldn?t you need something like {{{ eta2 :: (forall a. Coercible (f a) (g a)) => Coercion f g }}} for this to be sound? Oterwise, assuming {{{eta2}}} would typecheck, and we had `eta` from #9117 I could write {{{ type family F1 a :: * type family F2 a :: * type instance F1 Int = Int type instance F2 Int = Int type instance F1 Bool = Bool type instance F2 Bool = Char }}} and then obtain {{{ let f1eqf2 = eta2 (Proxy :: Proxy Int) :: Coercion F1 F2 absurd = (eta f1eqf2 :: Coercion (F1 Bool) (F2 Bool)) :: Coercion Bool Char }}} (dry coding, I might be wrong) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 21:11:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 21:11:03 -0000 Subject: [GHC] #8971: Native Code Generator for 7.8 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.d211d05d2ab10b1ef1e93adddbee62d8@haskell.org> #8971: Native Code Generator for 7.8 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (NCG) | 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 carter): @simon, so the right path forward is someone putting some engineering time into the new ncg register allocator? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 21:20:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 21:20:15 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.2259f3cb3143db3181a622ca7fa3458c@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): I don't think it's related to #8555 at all. #8555 is to do with "given" constraints, whereas this ticket is entirely about wanted ones. But you make an excellent point about overlap with the newtype-unwrapping instances. I can't see an easy way round that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 21:23:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 21:23:01 -0000 Subject: [GHC] #9113: Template Haskell should warn about non-exhaustive pattern matches In-Reply-To: <042.80c5d78608ff3c2a95ab5b9b46f7d317@haskell.org> References: <042.80c5d78608ff3c2a95ab5b9b46f7d317@haskell.org> Message-ID: <057.7f6d5a80b44c91843753d0506aa92095@haskell.org> #9113: Template Haskell should warn about non-exhaustive pattern matches -------------------------------------------------+------------------------- Reporter: tvh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * cc: dimitris@? (added) Comment: Good point. Currently pattern-match overlap warnings are produced as part of desugaring, which doesn't happen when type-checking the quotation. However Dimitrios and some colleagues are thinking about how to integrate pattern-match overlap checking with the type checker, which would have the effect of solving this at the same time. I'll add him in cc. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 23:34:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 23:34:30 -0000 Subject: [GHC] #9112: data families with representational matching In-Reply-To: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> References: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> Message-ID: <060.b6e8cc8b3065f2b6ab9edc33405a7b4d@haskell.org> #9112: data families with representational matching -------------------------------------+------------------------------------ Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 jwlato): Simon, it's possible that suggestion will work, with a few other modifications to the way roles are currently handled. It doesn't work with vector/ghc as currently released due to some other methods. For example, if I add `basicUnsafeRead` {{{ class MVectorClass (v :: * -> * -> *) a where basicLength :: v s a -> Int basicUnsafeRead :: PrimMonad m => v (PrimState m) a -> Int -> m a }}} It's not possible to coerce `basicUnsafeRead` because of the coercion from `m Int` to `m Age`. There are a number of other methods that also can't be coerced, but I think they're all because `m`s type parameter is at a nominal role. If it were possible to express that `m`s parameter need only be representationally equal, I think this would work. (maybe related to the current issues with deriving and AMP?) I'm not sure what's involved with making that coercion happen, but it seems decidely less tricky than representationally-equal data families (I have quite a bit more to say about that also, but I'll leave it for another venue). I'm changing the title of this ticket to more closely reflect the actual goal, e.g. deriving vector instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 15 23:35:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 May 2014 23:35:10 -0000 Subject: [GHC] #9112: support for deriving Vector/MVector instances (was: data families with representational matching) In-Reply-To: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> References: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> Message-ID: <060.dba61d87050fabdc7dc81a5cb08fe1ed@haskell.org> #9112: support for deriving Vector/MVector instances -------------------------------------+------------------------------------ Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 Fri May 16 01:25:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 01:25:15 -0000 Subject: [GHC] #8971: Native Code Generator for 7.8 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.48f7081a5e9ee8dd4b574d44a1e68753@haskell.org> #8971: Native Code Generator for 7.8 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (NCG) | 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 GordonBGood): Replying to [comment:17 simonmar]: > The short version is that this isn't going to be easy to fix, and I recommend using LLVM. In fact, I prefer LLVM because it is more consistent for timing, but of course that brings us to that other bug for 64-bit Windows where 64-bit GHC 7.8.2 still doesn't work with LLVM (3.4/3.5) at least for mingw as per the distrubuted binary, although it does under 64-bit Linux. The above test program runs under LLVM for a 32-bit compile but crashes on run for 64-bit, both on Windows. Or perhaps there is something wrong with my compile of 64-bit LLVM even though I followed the exact same procedure as generating the 32-bit version from trunk. Don Stewart's entry that working LLVM should really be distributed with GHC is a very good one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 02:12:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 02:12:50 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.bbb5c226ed2bf669849300738cdbea62@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): But doesn't the constraint solver already deal with overlap somehow? For example, if we have `newtype MyMaybe a = Mk (Maybe a)`, and we want `Coercible (MyMaybe Int) (MyMaybe Age)`, there are two ways to get this.... unless there is a role annotation on `MyMaybe`, meaning only the unwrap-coerce-wrap solution is available, or unless the constructor is not available, when only the coerce-directly solution is available. So, if this all works, there has to be some way of dealing with the overlap and a small amount of "search". Is the case in this ticket somehow different/worse? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 05:06:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 05:06:05 -0000 Subject: [GHC] #8971: Native Code Generator for 7.8 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.e692c21aa34fe08ffc4b64d8a3aa7614@haskell.org> #8971: Native Code Generator for 7.8 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (NCG) | 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 awson): Replying to [comment:19 GordonBGood]: > but of course that brings us to that other bug for 64-bit Windows where 64-bit GHC 7.8.2 still doesn't work with LLVM (3.4/3.5) at least for mingw as per the distrubuted binary, although it does under 64-bit Linux. The above test program runs under LLVM for a 32-bit compile but crashes on run for 64-bit, both on Windows. > > Or perhaps there is something wrong with my compile of 64-bit LLVM even though I followed the exact same procedure as generating the 32-bit version from trunk. Don Stewart's entry that working LLVM should really be distributed with GHC is a very good one. This is #8974. My patch there makes your program work on 64-bit Windows (although I don't like it because it uses mangler). It is compatible with existing 64-bit LLVM-3.4, distributed by MSYS2 (mingw-w64) project. We could pack this LLVM distro along with 64-bit GHC binary and configure ghc to use it (then also #7143 would be solved, and I have the patch for this ready) - just like we go with gcc/binutils/perl in all windows distros. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 05:28:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 05:28:40 -0000 Subject: [GHC] #9031: ghc panic: RegAlloc.Liveness.computeLivenss In-Reply-To: <045.282178438a787f7ffeeca849ab71135d@haskell.org> References: <045.282178438a787f7ffeeca849ab71135d@haskell.org> Message-ID: <060.d26d59f7ccde2817a5d045efc97fb98a@haskell.org> #9031: ghc panic: RegAlloc.Liveness.computeLivenss ---------------------------------------+----------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): Paul, thanks very much. I've created a self-contained test case based on your code (I believe it's the same issue I'm having). When I try to compile the attached files with {{{ ghc -O2 Top.hs }}} I get the same error. One interesting thing is that this error seems to require that `pawnAdvanceSquares` is called in multiple locations, even though in the generated core it only appears once. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 07:30:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 07:30:23 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.b4a56c76183f2b599f04cb8535aa44d1@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 nomeata): > So, if this all works, there has to be some way of dealing with the overlap and a small amount of "search". Well, the way is ?do whatever comes first?. It works because the rewrite system is confluent (I hope that?s the right term), i.e. we don?t run into dead ends if we do on or the other first. > Is the case in this ticket somehow different/worse? Yes, as `Coercible Foo1 Foo2` would be a dead end. It ''might'' work to try `Coercible f g => Coercion (f a) (g a)` only if no other instance matches. The code is able to do so, but I don?t particularly like that. We can add it if we don?t have a better idea ''and'' there there is a use case for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 08:41:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 08:41:22 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.4417655e7302dc66dbb631796c401c0c@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): The trouble with "no other instance matches" is that the situation might change as we solve other constraints and learn more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 08:52:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 08:52:54 -0000 Subject: [GHC] #9068: Don't uninstall signal handlers if none were installed In-Reply-To: <044.7794aa4ce82ed5ecdcf0c07847cdd3ac@haskell.org> References: <044.7794aa4ce82ed5ecdcf0c07847cdd3ac@haskell.org> Message-ID: <059.69a6c713c6bc43b406d65c518df9fb96@haskell.org> #9068: Don't uninstall signal handlers if none were installed ------------------------------------------------+-------------------------- Reporter: tomgr | Owner: Type: bug | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Resolution: | Version: 7.8.2 Operating System: Windows | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Simon Marlow ): In [changeset:"bc7d49a658a516679cc264502e72560c1d2c2314/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bc7d49a658a516679cc264502e72560c1d2c2314" Only uninstall signal handlers if they were actually installed (#9068) Submitted by: tomgr }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 10:02:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 10:02:42 -0000 Subject: [GHC] #9068: Don't uninstall signal handlers if none were installed In-Reply-To: <044.7794aa4ce82ed5ecdcf0c07847cdd3ac@haskell.org> References: <044.7794aa4ce82ed5ecdcf0c07847cdd3ac@haskell.org> Message-ID: <059.d54cbe0a8c8f0348b85a63451aa93512@haskell.org> #9068: Don't uninstall signal handlers if none were installed ------------------------------------------------+-------------------------- Reporter: tomgr | Owner: Type: bug | simonmar Priority: normal | Status: merge Component: Runtime System | Milestone: 7.8.3 Resolution: | Version: 7.8.2 Operating System: Windows | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonmar): * status: new => merge * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 10:05:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 10:05:38 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.3051ec5748982a8d61d37a8f07e8fd96@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.3 Component: Compiler (LLVM) | Version: 7.9 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): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 10:15:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 10:15:11 -0000 Subject: [GHC] #8971: Native Code Generator for 7.8 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.fe2188fa2fb9204df0cbe0ffea0c6c18@haskell.org> #8971: Native Code Generator for 7.8 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (NCG) | 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 simonmar): Replying to [comment:18 carter]: > @simon, so the right path forward is someone putting some engineering time into the new ncg register allocator? If you mean `-fregs-graph`, then yes, working on that would be a good way to fix this bug. Right now I believe it has regressed since the switch to the new code generator: #7679 Another angle would be to change the calling convention so that we use `%ebx` for R1 on 32-bit platforms. Right now we use `%esi`, which doesn't have an 8-bit version so we can't let the register allocator use it on 32-bit x86 (because neither register allocator can handle the constraint that this reg can't be used for 8-bit calculations). Implementing that is more work than changing the calling convention, but changing the calling convention means doing the same thing in LLVM (and we get a dependency on a new version of LLVM, ugh). Yet another angle would be to make the linear scan allocator sensitive to loops. This might not be too hard, actually: the general plan would be to (a) identify the loops, (b) identify the important loop-carried variables, and (c) assign registers on entry to the loop so that the important variables go into regs. Still, I find it hard to get too excited about any of this when it doesn't affect 64-bit platforms and in any case we can use LLVM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 10:44:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 10:44:33 -0000 Subject: [GHC] #9119: Additional symbols for XUnicodeSyntax Message-ID: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> #9119: Additional symbols for XUnicodeSyntax -------------------------------------------+------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.8.2 Keywords: unicode | 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: -------------------------------------------+------------------------------- So, one of the things I love about Haskell is how relatively mathematically friendly it is. To that end, I propose the following additional unicode operators be added to XUnicodeSyntax: "? p ? x" for "let p in x" "?" "?" "?" "?" "?" "?" "?" "?" "?" be added as synonyms for "=" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 11:13:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 11:13:12 -0000 Subject: [GHC] #9119: Additional symbols for XUnicodeSyntax In-Reply-To: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> References: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> Message-ID: <065.81ebed60ac0a1f49c4fb168a27ab6cb8@haskell.org> #9119: Additional symbols for XUnicodeSyntax -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Parser) | Keywords: unicode 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 spacekitteh): I am building+testing these patches now, will report back, but they should work :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 11:47:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 11:47:42 -0000 Subject: [GHC] #9119: Additional symbols for XUnicodeSyntax In-Reply-To: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> References: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> Message-ID: <065.4503f76de597a3d8ae037278245cd0f1@haskell.org> #9119: Additional symbols for XUnicodeSyntax -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Parser) | Keywords: unicode 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 spacekitteh): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 14:02:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 14:02:40 -0000 Subject: [GHC] #9119: Additional symbols for XUnicodeSyntax In-Reply-To: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> References: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> Message-ID: <065.58420837ef5ecc4aa6157758900f9507@haskell.org> #9119: Additional symbols for XUnicodeSyntax -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Parser) | Keywords: unicode 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 spacekitteh): Oh, I did not realised that the tokens were context insensitive. I will have to find another symbol for "in." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 15:04:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 15:04:55 -0000 Subject: [GHC] #9120: Cache intermediate powers Message-ID: <049.1ee5b6115869efb06c318270302523f2@haskell.org> #9120: Cache intermediate powers ------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- `GHC.Float` caches powers of 2 and 10. The arrays of powers are currently constructed using: {{{ expts :: Array Int Integer expts = array (minExpt,maxExpt) [(n,2^n) | n <- [minExpt .. maxExpt]] }}} Unfortunately, the intermediate powers in the `2^n` computation are not stored back in the array, only the result is. I propose to use the following scheme that does store the intermediate powers: {{{ -- | Exponentiation with a cache for the most common numbers. expt :: Integer -> Int -> Integer expt _ e | e < 0 = error "Negative exponent" expt 2 e | e <= maxExpt2 = expts2 ! e | otherwise = expts2 ! maxExpt2 * 2^(e-maxExpt2) expt 10 e | e <= maxExpt10 = expts10 ! e | otherwise = expts10 ! maxExpt10 * 10^(e-maxExpt10) expt base e = base^e maxExpt2 :: Int maxExpt2 = 1100 maxExpt10 :: Int maxExpt10 = 324 expts2 :: Array Int Integer expts2 = expts 2 maxExpt2 expts2 expts10 :: Array Int Integer expts10 = expts 10 maxExpt10 expts10 expts :: Integer -> Int -> Array Int Integer -> Array Int Integer expts base hi arr = listArray (0, hi) $ 1 : base : go 2 where go :: Int -> [Integer] go !ix = xx : base*xx : go (ix+2) where xx = x * x x = arr ! half half = ix `unsafeShiftR` 1 }}} I will attach a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 15:05:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 15:05:28 -0000 Subject: [GHC] #9119: Additional symbols for XUnicodeSyntax In-Reply-To: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> References: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> Message-ID: <065.d4ccdccc2889ba8d4f879b99a8285a23@haskell.org> #9119: Additional symbols for XUnicodeSyntax -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Parser) | Keywords: unicode 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 spacekitteh): Ok, patch is validated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 15:12:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 15:12:23 -0000 Subject: [GHC] #9120: Cache intermediate powers In-Reply-To: <049.1ee5b6115869efb06c318270302523f2@haskell.org> References: <049.1ee5b6115869efb06c318270302523f2@haskell.org> Message-ID: <064.b4bd0c7adc4fb61c8981b0c2e927640d@haskell.org> #9120: Cache intermediate powers -------------------------------------+------------------------------------ Reporter: basvandijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): And perhaps some performance measurements that show it's a win? S -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 15:14:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 15:14:00 -0000 Subject: [GHC] #9120: Cache intermediate powers In-Reply-To: <049.1ee5b6115869efb06c318270302523f2@haskell.org> References: <049.1ee5b6115869efb06c318270302523f2@haskell.org> Message-ID: <064.1918c9872d6dcdd6b6c3cd6947dcf956@haskell.org> #9120: Cache intermediate powers -------------------------------------+------------------------------------ Reporter: basvandijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 basvandijk): > And perhaps some performance measurements that show it's a win? My GHC build is currently failing. Once it compiles I will try producing some benchmarks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 15:46:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 15:46:50 -0000 Subject: [GHC] #8712: Data.Ix missing info on row/column major indexing In-Reply-To: <044.f15edd3b54942a87b830ef4632f57c7e@haskell.org> References: <044.f15edd3b54942a87b830ef4632f57c7e@haskell.org> Message-ID: <059.00d43ba110d230d6ba165cc000f71a0c@haskell.org> #8712: Data.Ix missing info on row/column major indexing -------------------------------------+------------------------------------- Reporter: mirpa | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: row, column, Operating System: Unknown/Multiple | major, Ix Type of failure: Documentation | Architecture: Unknown/Multiple bug | Difficulty: Easy (less than 1 Test Case: | hour) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Changes (by bernalex): * cc: hvr, ekmett (added) * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 16:10:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 16:10:28 -0000 Subject: [GHC] #9119: Additional symbols for XUnicodeSyntax In-Reply-To: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> References: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> Message-ID: <065.2e559ec5c016cbef1e13abc7b63d1a32@haskell.org> #9119: Additional symbols for XUnicodeSyntax -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Parser) | Keywords: unicode 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 nomeata): I have strong doubts about the usefulness of the extra equality symbols. By making the parser detect them as `=` you take away the possibility for the user to define them as functions in their code. `?` might be quite useful in, say, test suites. Also, without knowing much about parsing, doesn?t {{{ ,("?", ITrarrow, unicodeSyntaxEnabled) ,("?", ITin, unicodeSyntaxEnabled) }}} conflict? Or will the parser do the right thing here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 17:34:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 17:34:34 -0000 Subject: [GHC] #9119: Additional symbols for XUnicodeSyntax In-Reply-To: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> References: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> Message-ID: <065.ec869a723a715e04b177ca5304a796bd@haskell.org> #9119: Additional symbols for XUnicodeSyntax -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Parser) | Keywords: unicode 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 carter): I'm inclined to agree with @nomeata. Nothing precludes you from having a "unicode symbols module" you import for your own codes, so that fails the "Fairbarn Threshold" heuristic http://www.haskell.org/pipermail/libraries/2012-February/017548.html This let syntax idea is interesting though! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 17:43:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 17:43:25 -0000 Subject: [GHC] #8971: Native Code Generator for 7.8 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.97c2525a03fcbc3e5fe41587738875f4@haskell.org> #8971: Native Code Generator for 7.8 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (NCG) | 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 carter): Which of these plans of attack are more likely (well, until benchmarks say otherwise) to also have a positive impact on 64-bit systems? (i'm similarly neutral about 32bit performance, but if theres some work that could have positive fallout for both, that'd be a good starting point) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 17:54:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 17:54:08 -0000 Subject: [GHC] #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. In-Reply-To: <054.2188bb19676a701eab2890d90541afc2@haskell.org> References: <054.2188bb19676a701eab2890d90541afc2@haskell.org> Message-ID: <069.64106855cdce222ce9a38a12d8a82c15@haskell.org> #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: Type: bug | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: acosh(-1) :: | Blocked By: Complex Double | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by carter): * cc: hvr, ekmett (added) Comment: hrmm, so one issue with complex functions in general is that there (is always) a "branch cut" http://mathworld.wolfram.com/BranchCut.html http://en.wikipedia.org/wiki/Branch_point http://math.stackexchange.com/questions/245579/how-does-a-branch-cut- define-a-branch are some of the first few decent hits on google for this topic. So do we standardize on the "common" branch cut choice? I'm not sure. If we don't enrich the complex function apis to be somehow parameterized by the branchcut choice, thats probably the "right" thing to do. ("right" being of course not quite the right term) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 18:39:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 18:39:44 -0000 Subject: [GHC] #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. In-Reply-To: <054.2188bb19676a701eab2890d90541afc2@haskell.org> References: <054.2188bb19676a701eab2890d90541afc2@haskell.org> Message-ID: <069.3b62fb78e0987dadd1490fc999cb67b4@haskell.org> #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: Type: bug | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: acosh(-1) :: | Blocked By: Complex Double | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by ekmett): We do pick the standard branch cut location. That said, it is possible to give a more general form with a specified branch cut. I do so for all of these functions and more for quaternions in http://hackage.haskell.org/package/linear-1.10.1.1/docs/Linear- Quaternion.html You pick the location of the branch cut by supplying a unit quaternion. Adapting this logic to a choice of point on the unit circle could be done, but I confess I'd rather hash that out in libraries before asserting it is the right approach for something like base. Almost nobody knows how to use the more exotic cuts, but importantly they can be formed from the standard cut and identities by somone with sufficient background to be aware of the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 18:54:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 18:54:30 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.1d23806e1124051846526babd44de886@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): Replying to [comment:5 nomeata]: > we don?t run into dead ends if we do on or the other first. I don't agree here. Say we have {{{ newtype Phant a = MkPhant Char type role Phant representational ex1 :: Phant Bool ex1 = coerce (MkPhant 'x' :: Phant Int) }}} This should succeed if we use newtype-unwrapping instances first but should fail if we use the congruence case first. And, indeed, it fails! I think it should succeed. Regardless of what we decide to do about the original feature requested, I think the failure of this example is a proper bug. I believe that if we try the newtype-unwrapping instances first, the algorithm would be sound. Why? Because the congruence case can never be more powerful than the newtype-unwrapping case, due to role inference. That is, the roles on any type parameters of the newtype can never be more permissive than the roles on its representation type. So, we actually ''already'' have an ordering dependence on the cases, in order to avoid dead ends -- but we didn't realize it! Is there a problem with adding one more layer to this? :) For use cases, see [https://github.com/ekmett/roles/blob/master/src/Data/Roles.hs here], some experimentation Edward K has done regarding tracking roles in type variables. He has to use `eta` in a fair number of constructions. Fixing the original ticket would allow these to be proven sound instead of relying on `unsafeCoerce`. And, in response to Simon, yes that's true that the situation might change, but I don't see how that's problematic. These instances are intentionally "incoherent", so we are robust in the presence of a change in exactly ''how'' the instance is solved for. The "changed situation" shouldn't make a previously-allowable coercion become otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 19:20:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 19:20:14 -0000 Subject: [GHC] #9120: Cache intermediate powers In-Reply-To: <049.1ee5b6115869efb06c318270302523f2@haskell.org> References: <049.1ee5b6115869efb06c318270302523f2@haskell.org> Message-ID: <064.49f57c17bf83d265f72fe1a1a2539538@haskell.org> #9120: Cache intermediate powers -------------------------------------+------------------------------------ Reporter: basvandijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 meteficha): I have no idea what is the purpose of this code, but why not the following? {{{#!haskell expt 2 e | e <= maxExpt2 = expts2 ! e | otherwise = expts2 ! maxExpt2 * expt 2 (e-maxExpt2) expt 10 e | e <= maxExpt10 = expts10 ! e | otherwise = expts10 ! maxExpt10 * expt 10 (e-maxExpt10) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 19:32:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 19:32:59 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.999c010b245678b07a30797bd1ff2eab@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 nomeata): > So, we actually already have an ordering dependence on the cases, in order to avoid dead ends -- but we didn't realize it! Well spotted. The fix for this should be simple, just re-order the cases in `getCoercibleInst`. I also believe that unwrapping `newtype`s should be strictly more powerful than the other. I?m still with Simon?s worries about changing situation. It is not coherence that we need to worry about, but, as you have just demonstrated, solvability. Adding the eta-contraction might give new possibilities to run into dead ends. But I?m still not able to give a good example of what I mean, so I guess I could just implement this and we?ll see what happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 20:34:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 20:34:48 -0000 Subject: [GHC] #8712: Data.Ix missing info on row/column major indexing In-Reply-To: <044.f15edd3b54942a87b830ef4632f57c7e@haskell.org> References: <044.f15edd3b54942a87b830ef4632f57c7e@haskell.org> Message-ID: <059.d2d169e3b3f58e1b48ab8537355673e9@haskell.org> #8712: Data.Ix missing info on row/column major indexing -------------------------------------+------------------------------------- Reporter: mirpa | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: row, column, Operating System: Unknown/Multiple | major, Ix Type of failure: Documentation | Architecture: Unknown/Multiple bug | Difficulty: Easy (less than 1 Test Case: | hour) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Comment (by ekmett): Sounds good to me. It is better to be explicit about these things and hurts nothing to add these few words on the topic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 20:40:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 20:40:50 -0000 Subject: [GHC] #9119: Additional symbols for XUnicodeSyntax In-Reply-To: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> References: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> Message-ID: <065.f4ef7ce5c57e1a8add89a849d246f807@haskell.org> #9119: Additional symbols for XUnicodeSyntax -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Parser) | Keywords: unicode 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 spacekitteh): No, the parser didn't like it, @nomeata, that's why I changed it to {{{ ,("?", ITin, unicodeSyntaxEnabled) ,("?", ITlet, unicodeSyntaxEnabled) }}} As for the extra equality symbols, I only ended up implementing three which make more sense as synonyms for assignment rather than equality testing: {{{ -- "Is estimated by" ,("?", ITequal, unicodeSyntaxEnabled) -- "Is definitally equal to" ,("?", ITequal, unicodeSyntaxEnabled) -- "Is measured by" ,("?", ITequal, unicodeSyntaxEnabled) }}} The first one would be useful for situations such as numerical integration: {{{ area ? rk4 f' }}} The second one would be useful with combinators: {{{ sum ? foldr1 (+) }}} The third one is useful for hardware IO: {{{ accel ::() -> IO Double accel ? readAccelerometer() -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 16 20:41:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 May 2014 20:41:08 -0000 Subject: [GHC] #9119: Additional symbols for XUnicodeSyntax In-Reply-To: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> References: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> Message-ID: <065.d84ba46ca9f246d2cf4eefc1e8a27124@haskell.org> #9119: Additional symbols for XUnicodeSyntax -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Parser) | Keywords: unicode 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 spacekitteh): Also, trac is weird so I couldn't figure out how to delete the first two patches. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 17 02:01:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 May 2014 02:01:52 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.e91e3e077e40d02148bed2161be19116@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): It strikes me that what we have here is a nice little programming- languages problem that would probably submit to standard techniques. Specifically, we have a specification of what things are coercible -- the typing rules for representational coercions -- and an algorithm for checking whether two things are coercible. The algorithm is straightforward and could be formalized beyond its Haskell implementation. Then, we could verify if the algorithm is sound and/or complete w.r.t. the specification. If it's not sound, we have the possibility of a Core Lint error. If it's not complete, we have the possibility of failing inappropriately. To be clear, I'm not quite volunteering to do this tonight or saying that it's an essential step, but it might be a nice thing to try if we want to understand this better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 17 03:02:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 May 2014 03:02:05 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.16c2b79b578651a41619bb30f1dbb866@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: -------------------------------------+------------------------------------ Changes (by maoe): * cc: maoe@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 17 03:14:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 May 2014 03:14:58 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.1a87d7bb278d25c1a5023f8d7a6369de@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | 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: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 17 09:31:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 May 2014 09:31:29 -0000 Subject: [GHC] #9120: Cache intermediate powers In-Reply-To: <049.1ee5b6115869efb06c318270302523f2@haskell.org> References: <049.1ee5b6115869efb06c318270302523f2@haskell.org> Message-ID: <064.bf9c33984f9bf1111bd51fcd777d6267@haskell.org> #9120: Cache intermediate powers -------------------------------------+------------------------------------ Reporter: basvandijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 basvandijk): > I have no idea what is the purpose of this code, but why not the following? ... Won't that have linear complexity instead of logarithmic? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 17 11:33:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 May 2014 11:33:57 -0000 Subject: [GHC] #9108: GADTs and pattern type annotations? In-Reply-To: <044.87ac903993cb8e53f719b4d9ed80567f@haskell.org> References: <044.87ac903993cb8e53f719b4d9ed80567f@haskell.org> Message-ID: <059.8b5fe172e0ea8c5f4593da9ef08b99c1@haskell.org> #9108: GADTs and pattern type annotations? -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by edsko): Ah, that's where the catch is -- of course. That makes sense. Tricky. For the record, Andres' workaround was {{{ type family Tail (xs :: [k]) :: [k] type instance Tail (x ': xs) = xs lengthSing :: forall (xs :: [k]). SingI xs => Tagged xs Int lengthSing = case sing :: Sing xs of SNil -> Tagged 0 SCons -> Tagged (1 + untag (lengthSing :: Tagged (Tail xs) Int)) }}} which avoids a second pattern match. The fact that we need a workaround at all does seem unfortunate but I understand better now why it's required. Tricky :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 17 12:32:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 May 2014 12:32:19 -0000 Subject: [GHC] #8972: Investigate adding fast compare-and-swap Int type/primops In-Reply-To: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> References: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> Message-ID: <059.82d078258733b4eea747de6d621b2a60@haskell.org> #8972: Investigate adding fast compare-and-swap Int type/primops -------------------------------------+------------------------------------ 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: #8157, #7883 -------------------------------------+------------------------------------ Changes (by ihameed): * cc: idhameed@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 17 12:44:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 May 2014 12:44:09 -0000 Subject: [GHC] #9121: Presence of dyn_o files not checked? upon recompilation Message-ID: <051.ef4d284e4c39d225b3b91119dd74ee0d@haskell.org> #9121: Presence of dyn_o files not checked? upon recompilation ------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I interrupt a compilation (initiated with cabal), and then recompile (with cabal), it can happen that gcc fails with missing .dyn_o file. I have "shared:True" in my .cabal/config file. [I can of course do cabal clean to work around, but since a full recompilation is about 10 min, I try to avoid this.] time cabal install --disable-library-profiling --disable-documentation Resolving dependencies... In order, the following will be installed: Agda-2.3.3 (latest: 2.3.2.2) (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring Agda-2.3.3... Building Agda-2.3.3... Preprocessing library Agda-2.3.3... [116 of 273] Compiling Agda.TypeChecking.Monad.Base[boot] ( src/full/Agda/TypeChecking/Monad/Base.hs-boot, dist/build/Agda/TypeChecking/Monad/Base.o-boot ) ... [239 of 273] Compiling Agda.TypeChecking.Conversion ( src/full/Agda/TypeChecking/Conversion.hs, dist/build/Agda/TypeChecking/Conversion.o ) [Agda.Syntax.Translation.InternalToAbstract changed] ^Cmake: *** [install-bin] Interrupt time cabal install --disable-library-profiling --disable-documentation Resolving dependencies... In order, the following will be installed: Agda-2.3.3 (latest: 2.3.2.2) (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring Agda-2.3.3... Building Agda-2.3.3... Preprocessing library Agda-2.3.3... [116 of 273] Compiling Agda.TypeChecking.Monad.Base[boot] ( src/full/Agda/TypeChecking/Monad/Base.hs-boot, dist/build/Agda/TypeChecking/Monad/Base.o-boot ) ... [273 of 273] Compiling Agda.Main ( src/full/Agda/Main.hs, dist/build/Agda/Main.o ) [Agda.Compiler.Epic.Compiler changed] gcc: error: dist/build/Agda/TypeChecking/Conversion.dyn_o: No such file or directory Failed to install Agda-2.3.3 cabal: Error: some packages failed to install: Agda-2.3.3 failed during the building phase. The exception was: ExitFailure 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 17 19:07:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 May 2014 19:07:18 -0000 Subject: [GHC] #8673: GHC could generate GADT record selectors in more cases In-Reply-To: <046.d1195e7d3c4ca30e9d2a1c73eb0a6ed3@haskell.org> References: <046.d1195e7d3c4ca30e9d2a1c73eb0a6ed3@haskell.org> Message-ID: <061.6059030c0d92a7d66d3837912aedd4ad@haskell.org> #8673: GHC could generate GADT record selectors in more cases -------------------------------------+------------------------------------ Reporter: simonpj | 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 br1): I just also hit this limitation, but I'm not sure if my case was included in the cases already discussed. I want to do something like: {{{#!haskell data Bar a where B1 :: { x :: Int } -> Bar Int B2 :: { x :: Char } -> Bar Char }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 17 20:50:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 May 2014 20:50:30 -0000 Subject: [GHC] #9035: ghci sometimes displays Word32 as Word64 In-Reply-To: <050.4f7983c683629a8769fe429d26145378@haskell.org> References: <050.4f7983c683629a8769fe429d26145378@haskell.org> Message-ID: <065.8a3cf10ae70b5a8c7e6ffdd272939030@haskell.org> #9035: ghci sometimes displays Word32 as Word64 ------------------------------------------------+-------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: This use of `unsafeCoerce` is not safe: See [http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.7.0.0 /Unsafe-Coerce.html this] which links to [http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-prim-0.3.1.0 /GHC-Prim.html#v:unsafeCoerce-35- here] for more details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 18 06:30:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 May 2014 06:30:54 -0000 Subject: [GHC] #9119: Additional symbols for XUnicodeSyntax In-Reply-To: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> References: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> Message-ID: <065.7461b14ab25f3bb36f13628bbada5f04@haskell.org> #9119: Additional symbols for XUnicodeSyntax -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 (Parser) | Keywords: unicode 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 spacekitteh): * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 18 08:05:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 May 2014 08:05:25 -0000 Subject: [GHC] #9119: Additional symbols for XUnicodeSyntax In-Reply-To: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> References: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> Message-ID: <065.237962ea25d3fd5c9f0ecb9e9e1d899f@haskell.org> #9119: Additional symbols for XUnicodeSyntax -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Parser) | Keywords: unicode 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 carter): * milestone: 7.8.3 => Comment: 7.8 series is only for bug fixes now. Removing the milestone for now :) And there hasn't really been any real discussion of the proposed syntactic extensions. That really needs to happen for them to be considered for merging. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 18 12:24:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 May 2014 12:24:53 -0000 Subject: [GHC] #9037: Add option to make selected warnings errors In-Reply-To: <042.6aee3bd7af8a4db00b8b565ec5ad1d4b@haskell.org> References: <042.6aee3bd7af8a4db00b8b565ec5ad1d4b@haskell.org> Message-ID: <057.37e34670ba4e2cd3328c24cd00739d1f@haskell.org> #9037: Add option to make selected warnings errors -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 schyler): * cc: schyler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 18 15:42:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 May 2014 15:42:37 -0000 Subject: [GHC] #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 In-Reply-To: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> References: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> Message-ID: <065.d5db344b2326d4e27a560f201f98dc8c@haskell.org> #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 ---------------------------------------+----------------------------------- Reporter: MichalGajda | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: cabal install hPDB | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7068, #7898 ---------------------------------------+----------------------------------- Comment (by George): Works for me on 64 bit 7.8.2 on MacOS. I have 12gb RAM but that shouldn't matter, the amount of virtual memory would be the limiting factor, wouldn't it? {{{ 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.2") ,("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.2") ,("Global Package DB","/usr/local/lib/ghc-7.8.2/package.conf.d") ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 18 21:27:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 May 2014 21:27:25 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.462a8e763224a565af545450a519f8e3@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.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 lerkok): * cc: erkokl@? (added) Comment: A recent bug reported in SBV points to the same problem: https://github.com/LeventErkok/sbv/issues/87 Only with GHC 7.8.2; heavy calls to SBV's `sat/prove` calls start causing seemingly random failures. We were able to track it down to the uses of `makeStableName`. We have '''not''' observed seg-faults, but we did observe erroneous behavior that we could not replicate with GHC 7.6.3 and earlier. SBV uses `makeStableName` to implement Andy Gill's type-safe observable sharing idea (as described here: http://www.ittc.ku.edu/csdl/fpg/papers/Gill-09-TypeSafeReification.html), which is a popular trick amongst DSL implementations these days. I'm not sure if Accelerate uses it for the same purpose, but I suspect this bug can impact a bunch of other DSL implementations out there, and would be really hard to debug for end-users. A timely fix before 7.8.2 becomes more widely adapted would be really good for the community. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 18 23:05:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 May 2014 23:05:07 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.0f4259f80f343d271f80abe80f17c6d7@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------ Reporter: simonpj | Owner: goldfire 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 crockeea): * cc: ecrockett0@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 00:42:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 00:42:38 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.af16c07a0d43bb731f85bf34fe4f08b4@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.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 chak): @erkokl Yes, Accelerate uses stable names for observable sharing. I agree that it is a nasty bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 00:43:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 00:43:38 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.62fbbb4fd845beb18bc0f92e22a48362@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.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 thoughtpolice): So we weren't sure when we wanted to release 7.8.3. But it looks like there are quite a few important bugfixes biting people at this point. I'll send an email to ghc-devs shortly... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 02:32:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 02:32:54 -0000 Subject: [GHC] #9021: [CID43168] rts/linker.c has a memory leak in the dlopen/dlerror code In-Reply-To: <046.338d06ed46ba2865fda90272f333c349@haskell.org> References: <046.338d06ed46ba2865fda90272f333c349@haskell.org> Message-ID: <061.9927ca00d53c300c58868942b6322f65@haskell.org> #9021: [CID43168] rts/linker.c has a memory leak in the dlopen/dlerror code -------------------------------------+------------------------------------- Reporter: hgolden | Owner: simonmar Type: bug | Status: closed Priority: low | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: fixed | Keywords: linker, memory Operating System: POSIX | leak, coverity Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: That was me, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 02:33:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 02:33:02 -0000 Subject: [GHC] #9021: [CID43168] rts/linker.c has a memory leak in the dlopen/dlerror code In-Reply-To: <046.338d06ed46ba2865fda90272f333c349@haskell.org> References: <046.338d06ed46ba2865fda90272f333c349@haskell.org> Message-ID: <061.520f6d3936b21b204bd6b8894e807c66@haskell.org> #9021: [CID43168] rts/linker.c has a memory leak in the dlopen/dlerror code -------------------------------------+------------------------------------- Reporter: hgolden | Owner: simonmar Type: bug | Status: merge Priority: low | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: fixed | Keywords: linker, memory Operating System: POSIX | leak, coverity Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 02:51:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 02:51:02 -0000 Subject: [GHC] #9035: ghci sometimes displays Word32 as Word64 In-Reply-To: <050.4f7983c683629a8769fe429d26145378@haskell.org> References: <050.4f7983c683629a8769fe429d26145378@haskell.org> Message-ID: <065.ee6f799ffea1829d76c8a69a147f0218@haskell.org> #9035: ghci sometimes displays Word32 as Word64 ------------------------------------------------+-------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by MikeIzbicki): Replying to [comment:2 igloo]: > This use of `unsafeCoerce` is not safe: See [http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.7.0.0 /Unsafe-Coerce.html this] which links to [http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-prim-0.3.1.0 /GHC-Prim.html#v:unsafeCoerce-35- here] for more details. I don't understand why it is incorrect. Is it because the float is boxed? We can easily change the code to: {{{ float2word32 :: Float -> Word32 float2word32 (F# f#) = W32# (unsafeCoerce# f#) }}} Now, we are casting between two unboxed types of the same size, which is explicitly allowed. The results, however, are exactly the same as before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 03:42:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 03:42:14 -0000 Subject: [GHC] #9035: ghci sometimes displays Word32 as Word64 In-Reply-To: <050.4f7983c683629a8769fe429d26145378@haskell.org> References: <050.4f7983c683629a8769fe429d26145378@haskell.org> Message-ID: <065.47831dc6e2216bf0d427f959dffeaffa@haskell.org> #9035: ghci sometimes displays Word32 as Word64 ------------------------------------------------+-------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by carter): you can't do an unsafe coerce between Words and Floats in ghc currently and have it be well defined . Its got nothing to do with boxing, it has to do with Floats and Words actually living is completely distinct groups of registers in the CPU. eg on x86, ghc currently only manipulates words in the general purpose registers, and floats are in SSE registers. (yes, there ARE word manipulation sse instructions, but ghc currently doesn't use them.. yet) NH2 wrote a cute wee lib to cast between float and words https://github.com/nh2/float-cast, which works by writing the input to memory as one type, and reading the memory location back as the other type. I think the only reason some of your code works at all is your unsafe coerce actually will by accident do that "casted memory read" off the heap. The other issue is your Word32 is actually going to be 64bit (1 whoel register) value on 64 bit systems, but Floats are always 32b bits, and your unsafe coerce doesn't actually have any well defined way of mapping between the two. Again, anything resembling that working in current GHC is actually a complete "this is undefined" accident :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 04:05:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 04:05:03 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.f143e78fd8ba9a9d5da67765364c400c@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------ Reporter: GregWeber | 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 GregWeber): After making the changes Nate suggested {{{ diff --git a/compiler/typecheck/TcRnMonad.lhs b/compiler/typecheck/TcRnMonad.lhs index 17700e7..4c4be49 100644 --- a/compiler/typecheck/TcRnMonad.lhs +++ b/compiler/typecheck/TcRnMonad.lhs @@ -502,7 +502,9 @@ traceOptTcRn flag doc = whenDOptM flag $ do dumpTcRn :: SDoc -> TcRn () dumpTcRn doc = do { rdr_env <- getGlobalRdrEnv ; dflags <- getDynFlags - ; liftIO (printInfoForUser dflags (mkPrintUnqualified dflags rdr_env) doc) } + ; liftIO $ do + dumpIfSet_dyn dflags Opt_D_dump_tc "Typechecker output" doc + (printInfoForUser dflags (mkPrintUnqualified dflags rdr_env) doc) } }}} running `ghc -ddump-tc -ddump-to-file Foo.hs` produces a file Foo.dump-tc: {{{ ==================== Typechecker output ==================== 2014-05-19 03:56:39.777604 UTC TYPE SIGNATURES TYPE CONSTRUCTORS Foo.Foo :: * data Foo No C type associated RecFlag NonRecursive, Not promotable = Foo :: GHC.Types.Int -> Foo Stricts: _ FamilyInstance: none COERCION AXIOMS Dependent modules: [] Dependent packages: [base, ghc-prim, integer-gmp] ==================== Typechecker output ==================== 2014-05-19 03:56:39.78129 UTC ==================== Typechecker ==================== }}} This only took me 10 minutes to make the code change, so that is an encouraging start. This is not what I want as an end result, but is this useful now for others that use -ddump-tc to debug? Should I add a new flag for my desired functionality? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 04:10:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 04:10:54 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.5db3e426c2f17b0212e3ae5b8df40554@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.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 --------------------------------------------+------------------------------ Comment (by archblob): I have added a working, validated patch. It can be reviewed and I'll make the necessary modification if all is not well. Otherwise I think it can be merged and I've also added tests. It does not include the fix for {{{:kind}}} because I thought it would be best to separate them. I will include another patch for that after we are done with this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 04:12:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 04:12:27 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.88be043a890a046cd35d474b60ff5791@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.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): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 05:10:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 05:10:22 -0000 Subject: [GHC] #8475: Library docs: broken links to Foreign.ForeignPtr In-Reply-To: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> References: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> Message-ID: <062.60fec2c7fc92a70ed1a968b048e6319b@haskell.org> #8475: Library docs: broken links to Foreign.ForeignPtr -------------------------------------+------------------------------------ Reporter: simonmar | Owner: hellertime Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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 Austin Seipp ): In [changeset:"4dac3a4124e5b3bb2ef8f9105f8921dcbb5183f7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4dac3a4124e5b3bb2ef8f9105f8921dcbb5183f7" base: Document Foreign.ForeignPtr (#8475) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 05:10:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 05:10:22 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.311cc0ee14bab676af412c9030fd2fb6@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.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 Austin Seipp ): In [changeset:"b75d126e779e8690c675be84e8972dc023e04b9b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b75d126e779e8690c675be84e8972dc023e04b9b" rts: remove stable-names from hashtable upon free This fixes #9078. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 05:10:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 05:10: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.efec34718fe55ffbfaf97b59f4017d7b@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.3 Component: libraries | Version: 7.8.1-rc2 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Solaris | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"39aa1e95f5ffaf3409ae9d741e4a886fcd38652b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="39aa1e95f5ffaf3409ae9d741e4a886fcd38652b" integer-gmp: do not confuse ./configure (#8783) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 05:10:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 05:10: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.dfd78566509e1e923b1382040890042c@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.3 Component: libraries | Version: 7.8.1-rc2 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Solaris | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"3df1c5109a6bd2a522717e524c10d842d4cd8ab8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3df1c5109a6bd2a522717e524c10d842d4cd8ab8" Extract derived constants from nm output for various OSes differently. Fixes #8783. In order to avoid querying the nm version that does not work on Mac OS X we use the "nm -P" output that is supposed to produce (more portable) POSIX output and works on all tested OSes (MinGW, Mac OS X, Solaris and Linux using GNU nm) although slightly different (as documented). The "nm -P" output is actually only needed to recognize the output of a non-GNU Solaris nm (all other OSes produce sane outut using "nm" only). Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 05:10:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 05:10:45 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.eb79cbceafde5170bfb4fecb7165a802@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.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 thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 05:10:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 05:10: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.cf9e24ea0c4542488d2da1d01399bf66@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: merge Priority: normal | Milestone: 7.8.3 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): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 05:11:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 05:11: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.ae18c5b2ecbe0ee144288a249c1c4d4e@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.3 Component: libraries | Version: 7.8.1-rc2 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Solaris | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 05:11:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 05:11:20 -0000 Subject: [GHC] #8475: Library docs: broken links to Foreign.ForeignPtr In-Reply-To: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> References: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> Message-ID: <062.34a96e87165f48bb3a887ce9f183344c@haskell.org> #8475: Library docs: broken links to Foreign.ForeignPtr -------------------------------------+------------------------------------ Reporter: simonmar | Owner: hellertime Type: bug | Status: merge Priority: high | Milestone: 7.8.3 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: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 05:28:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 05:28:27 -0000 Subject: [GHC] #9035: ghci sometimes displays Word32 as Word64 In-Reply-To: <050.4f7983c683629a8769fe429d26145378@haskell.org> References: <050.4f7983c683629a8769fe429d26145378@haskell.org> Message-ID: <065.e4100cfe93c257845de2ca199970f556@haskell.org> #9035: ghci sometimes displays Word32 as Word64 ------------------------------------------------+-------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by MikeIzbicki): Ahh, I see. I missed the clause in the documentation that says you can't convert between floating point and integer types. I have a handful of code that needs fixing now :( Just for my own curiosity, I'd like to read the spot in GHC that prevents this particular usage of unsafeCoerce. Any idea which files I should look at? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 07:16:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 07:16:28 -0000 Subject: [GHC] #9035: ghci sometimes displays Word32 as Word64 In-Reply-To: <050.4f7983c683629a8769fe429d26145378@haskell.org> References: <050.4f7983c683629a8769fe429d26145378@haskell.org> Message-ID: <065.f10ba0f9cca06000971eea09d0c8235c@haskell.org> #9035: ghci sometimes displays Word32 as Word64 ------------------------------------------------+-------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by simonpj): I think it would be a great idea for Core Lint to check for uses of `unsafeCoerce` that don't obey the rules. It won't catch all cases, of course, but it would have caught this one. Specficially, look for: * Coercions between lifted and unboxed types * Coercion between unboxed types of different sizes * Coercion between unboxed ints and floats. Would anyone like to make a patch for this? Anything that can be checked by Core Lint, should be checked! I'm afraid I don't know where to look for the reason for the int/float difficulty. I'd write a tiny function that exhibits the unsafe conversion and look the code it generates. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 07:26:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 07:26:03 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.644777b12e5956d18ce224ff80c1a1d5@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------ Reporter: GregWeber | 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 simonpj): I think you'll want a different flag. `-ddump-tc` is primarily for debugging, and so it's fine for it to spit out all kinds of non-Haskell- source-code stuff. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 08:35:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 08:35:10 -0000 Subject: [GHC] #4836: literate markdown not handled correctly by unlit In-Reply-To: <044.677d9d9819274dc3e0fccfc271c35be2@haskell.org> References: <044.677d9d9819274dc3e0fccfc271c35be2@haskell.org> Message-ID: <059.bf79991474417091885c4ab5ad7d0335@haskell.org> #4836: literate markdown not handled correctly by unlit ----------------------------------------------+---------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7120 ----------------------------------------------+---------------------------- Changes (by bjp): * cc: bjp@? (added) * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 09:05:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 09:05:36 -0000 Subject: [GHC] #9122: Make Lint check for bad uses of `unsafeCoerce` Message-ID: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> #9122: Make Lint check for bad uses of `unsafeCoerce` ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I think it would be a great idea for Core Lint to check for uses of `unsafeCoerce` that don't obey the rules. It won't catch all cases, of course, but it would have caught #9035. Specficially, look for: * Coercions between lifted and unboxed types * Coercion between unboxed types of different sizes * Coercion between unboxed ints and floats. Would anyone like to make a patch for this? Anything that can be checked by Core Lint, should be checked! I'm afraid I don't know where to look for the reason for the int/float difficulty. I'd write a tiny function that exhibits the unsafe conversion and look the code it generates. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 10:45:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 10:45:55 -0000 Subject: [GHC] #9123: Need for higher kinded roles Message-ID: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> #9123: Need for higher kinded roles ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This [http://www.haskell.org/pipermail/ghc-devs/2014-May/004964.html thread] on ghc-devs identifies a real shortcoming of the new roles system. Here's a compact example, from the thread {{{ class C m where ret :: a -> m a bind :: m a -> (a -> m b) -> m b join :: m (m a) -> m a newtype T m a = MkT (m a) deriving( C ) }}} The `deriving(C)` is accepted without `join` in the class, but rejected when `join` is added. And the AMP proposal adds `join` to class `Monad`! In one way it is rightly rejected: it really would be unsound to derive an instance for `C (T K)` where `K`'s argument had nominal (but not representational) role. But we have no way to limit the type constructors at which `T` can be used. This deficiency is noted in the [http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/ Safe Coercions paper], but this seems to be the first occasion on which it has bitten us badly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 10:48:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 10:48:55 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.fc9f8ffa4e1378a1aad3eb4774833b5e@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 simonpj: Old description: > This [http://www.haskell.org/pipermail/ghc-devs/2014-May/004964.html > thread] on ghc-devs identifies a real shortcoming of the new roles > system. Here's a compact example, from the thread > {{{ > class C m where > ret :: a -> m a > bind :: m a -> (a -> m b) -> m b > join :: m (m a) -> m a > > newtype T m a = MkT (m a) deriving( C ) > }}} > The `deriving(C)` is accepted without `join` in the class, but rejected > when `join` is added. And the AMP proposal adds `join` to class `Monad`! > > In one way it is rightly rejected: it really would be unsound to derive > an instance for `C (T K)` where `K`'s argument had nominal (but not > representational) role. But we have no way to limit the type > constructors at which `T` can be used. > > This deficiency is noted in the [http://research.microsoft.com/en- > us/um/people/simonpj/papers/ext-f/ Safe Coercions paper], but this seems > to be the first occasion on which it has bitten us badly. New description: This [http://www.haskell.org/pipermail/ghc-devs/2014-May/004964.html thread] on ghc-devs identifies a real shortcoming of the new roles system. Here's a compact example, from the thread {{{ class C m where ret :: a -> m a bind :: m a -> (a -> m b) -> m b join :: m (m a) -> m a newtype T m a = MkT (m a) deriving( C ) }}} The `deriving(C)` is accepted without `join` in the class, but rejected when `join` is added. And the AMP proposal adds `join` to class `Monad`! In one way it is rightly rejected: it really would be unsound to derive an instance for `C (T K)` where `K`'s argument had nominal (but not representational) role. But we have no way to limit the type constructors at which `T` can be used. This deficiency is noted in the [http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/ Safe Coercions paper], but this seems to be the first occasion on which it has bitten us badly. Edward [http://www.haskell.org/pipermail/ghc-devs/2014-May/004974.html made a suggestion] on the thread. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 10:51:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 10:51:02 -0000 Subject: [GHC] #9112: support for deriving Vector/MVector instances In-Reply-To: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> References: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> Message-ID: <060.7652acd28475e30f4d626d79c95c7320@haskell.org> #9112: support for deriving Vector/MVector instances -------------------------------------+------------------------------------ Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): Yes, the `basisUnsafeRead` thing is directly related to the AMP/GND question. See #9123. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 10:51:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 10:51:31 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.301502526c543e13c92e99982bcebe1e@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): See #9112 (comment 3) for another example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 12:38:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 12:38:04 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.8513cdc3c6c48b27218c6f682b304061@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): The only reason for giving a role signature that is less permissive than the actual newtype-unwrapping is, well, to be more restrictive. So I think it'd be rather unusual both to give a role signature, and to expose the data constructor of the newtype. So I'm not too bothered about this particular dead end. But still, yes, putting the rules in the other order would be a good idea. (Make sure you add a `Note`!) I'm a bit bugged that `Coercible (N Age) (N Int)` might take a rather long way round (unwrapping multiple layers of newtype) rather than the short cut (try `(Coercible Age Int)`). But maybe I should not worry about that. As to the "knowing more later" stuff, I'm just referring to situations like `(alpha t1) ~ (alpha t2)` where `alpha` is a unification variable. As constraint solving progresses we may learn what `alpha` is -- but if we have already decomposed the application it may now be too late. It's difficult to use the approach that Richard describes, because it interacts with all the other constraint solving that is going on during type inference. NB that this "more info later" stuff does not apply to the reordering to apply newtype unwrapping before decomposition, because both newtype unwrapping and decomposition apply only when the head is a known type constructor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 12:52:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 12:52:08 -0000 Subject: [GHC] #9124: Infinite loop when printing a (finite) list with just one element Message-ID: <042.05d54fa8f8b57cca28c73d9008cc417a@haskell.org> #9124: Infinite loop when printing a (finite) list with just one element ------------------------------------+--------------------------------- Reporter: OoS | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Yes Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- If I print a (finite) list with ohne element I get a "<>" from the runtime. When I remove some where clauses from "buildFrustum", the code works again flawlessly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 12:54:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 12:54:41 -0000 Subject: [GHC] #9124: Infinite loop when printing a (finite) list with just one element In-Reply-To: <042.05d54fa8f8b57cca28c73d9008cc417a@haskell.org> References: <042.05d54fa8f8b57cca28c73d9008cc417a@haskell.org> Message-ID: <057.a8f1c9b823fd9611a51d49e3c31b71e8@haskell.org> #9124: Infinite loop when printing a (finite) list with just one element ---------------------------------+------------------------------------ Reporter: OoS | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: Yes | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by OoS): * cc: oosync@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 12:56:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 12:56:56 -0000 Subject: [GHC] #9124: Infinite loop when printing a (finite) list with just one element In-Reply-To: <042.05d54fa8f8b57cca28c73d9008cc417a@haskell.org> References: <042.05d54fa8f8b57cca28c73d9008cc417a@haskell.org> Message-ID: <057.0e5108d07b1761bf0c6e71295a0b1a62@haskell.org> #9124: Infinite loop when printing a (finite) list with just one element ---------------------------------+------------------------------------ Reporter: OoS | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: Yes | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by nomeata): Could you try to minimize the example? I.e. remove code or replace it by constants and see if the problem still occurs, and then repeat until you cannot simplify it further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 13:00:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 13:00:28 -0000 Subject: [GHC] #9124: Infinite loop when printing a (finite) list with just one element In-Reply-To: <042.05d54fa8f8b57cca28c73d9008cc417a@haskell.org> References: <042.05d54fa8f8b57cca28c73d9008cc417a@haskell.org> Message-ID: <057.3dfb3b96dcbf48ecdb46091c0b2a0062@haskell.org> #9124: Infinite loop when printing a (finite) list with just one element ---------------------------------+------------------------------------ Reporter: OoS | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: Yes | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by OoS): Replying to [comment:2 nomeata]: > Could you try to minimize the example? I.e. remove code or replace it by constants and see if the problem still occurs, and then repeat until you cannot simplify it further. I've tried that before, but if i remove where clauses from "buildFrustum" the error doesn't occur, so i must show all the code. I try to make a simpler test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 13:07:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 13:07:37 -0000 Subject: [GHC] #9124: Infinite loop when printing a (finite) list with just one element In-Reply-To: <042.05d54fa8f8b57cca28c73d9008cc417a@haskell.org> References: <042.05d54fa8f8b57cca28c73d9008cc417a@haskell.org> Message-ID: <057.6df47fbaf9ebb9fa126a636d52a85ff5@haskell.org> #9124: Infinite loop when printing a (finite) list with just one element ---------------------------------+------------------------------------ Reporter: OoS | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: Yes | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by OoS): Replying to [comment:2 nomeata]: > Could you try to minimize the example? I.e. remove code or replace it by constants and see if the problem still occurs, and then repeat until you cannot simplify it further. I've simplified the test case as much as possible. If one removes line 61 (right = vec3Add origin $ rightScaled) the code works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 13:30:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 13:30:18 -0000 Subject: [GHC] #9124: Infinite loop when printing a (finite) list with just one element In-Reply-To: <042.05d54fa8f8b57cca28c73d9008cc417a@haskell.org> References: <042.05d54fa8f8b57cca28c73d9008cc417a@haskell.org> Message-ID: <057.ab19d144f0863f7529a1c98ae2203019@haskell.org> #9124: Infinite loop when printing a (finite) list with just one element ---------------------------------+------------------------------------ Reporter: OoS | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: Yes | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => invalid Comment: Yes, it is used: In the definition of `rightScaled` (which is used in the definition of `right`). Note that you also have a parameter called `right`. Passing `-Wall` to GHC will make the compiler help you to avoid such problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 15:04:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 15:04:32 -0000 Subject: [GHC] #9122: Make Lint check for bad uses of `unsafeCoerce` In-Reply-To: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> References: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> Message-ID: <061.ef9aa3fac477efa2174a5b3064c994e5@haskell.org> #9122: Make Lint check for bad uses of `unsafeCoerce` -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): What are "the rules"? Where are they written? And, what if someone ''wants'' to do one of the things mentioned? I can imagine wanting to coerce between lifted and unboxed types or between ints and floats. (Unboxed types of different sizes, I tend to agree, wouldn't want to get coerced.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 15:14:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 15:14:28 -0000 Subject: [GHC] #9122: Make Lint check for bad uses of `unsafeCoerce` In-Reply-To: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> References: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> Message-ID: <061.c3e63ac1ceb714f008c7405bdbdf6be0@haskell.org> #9122: Make Lint check for bad uses of `unsafeCoerce` -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): The rules are documented with `unsafeCoerce`, [http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-prim-0.3.1.0 /GHC-Prim.html#v:unsafeCoerce-35- here]. It's pretty much guaranteed that coercing from, say `Int#` to `Int` will give rise to serious problems. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 15:41:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 15:41:33 -0000 Subject: [GHC] #9110: MonomorphismRestriction too eager In-Reply-To: <047.859920e8e32f655f8e90914cf35ca628@haskell.org> References: <047.859920e8e32f655f8e90914cf35ca628@haskell.org> Message-ID: <062.4689e37dee1198d8bbcf51e870fcc8b0@haskell.org> #9110: MonomorphismRestriction too eager -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 Comment: User manual improvement: {{{ commit 3a61e6de311ad235aec9f0a55201656805e3c04e Author: Simon Peyton Jones Date: Fri May 16 08:34:44 2014 +0100 Tighten up wording in the section on let-generalisation and MonoLocalBinds docs/users_guide/glasgow_exts.xml | 49 ++++++++++++++++++++++++++----------- 1 file changed, 35 insertions(+), 14 deletions(-) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 15:54:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 15:54:31 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.5ca6811023c6f3916c34e2008ff783d5@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): I'm in support, generally, of Edward's suggestion on that thread. His idea does ''not'' go "all the way", in that there are some ideas we might want to express but cannot, as Edward points out. But, if the current roles story works for 95% of cases (where the `join` problem is an important member of the 5%), the current story + Edward's suggestion would probably cover 99.5%. And, the beauty of Edward's idea is that it is requires no change to Core and can mostly be implemented in user-land. GHC should support with magically-generated instances (like we already do for `Coercible`) and will need to incorporate these ideas into the `Coercible` solver, but these are relatively minor changes. Suppose that the class involved is named `Representational`, as Edward suggests. (I actually am against that name, because it makes the ''wrong'' thing sound representational. But, let's leave bikeshedding over names until later.) Should we make `Representational` a superclass of `Functor`? It "makes sense" that every `Functor` should treat its argument representationally. And, doing so would make GND work trivially with the new `Monad`. And, doing so would make `Traversable` GND'able (it currently is not). But, of course, it would mean that users may want to write `Functor` instances that are ''not'' representational and now cannot. (For example, [https://github.com/ekmett/lens/blob/master/src/Control/Lens/Internal/Magma.hs#L73 this one].) If we decide ''not'' to make `Representational` a (transitive) superclass of `Monad`, then `Monad` with `join` would only be GND'able if the GND instance has a `Representational` constraint in its context. This context could probably be inferred. But, any user writing a standalone GND for `Monad` (not an uncommon occurrence, I imagine) would have to be aware of this issue. These issues aren't meant to be "push-back" -- just some ramifications we should consider as we move forward. It is interesting to note that, had we gone with the POPL'11 implementation of roles, which included support for "higher-kinded" roles, we would be even more stuck here. That implementation tied a role in with a type's kind, which means that we would be ''forced'' to make every `Monad` representational in order to get GND to work with `join`. With the current plan, we have this free design choice. The current roles story may be somewhat less powerful than roles in POPL'11, but they are surely more flexible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 15:59:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 15:59:24 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.a8ec3421f4fd7cb3b0f765798f2ff347@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): Replying to [comment:9 hvr]: > Replying to [comment:8 simonpj]: > > I think we should probably switch it on for the entire `base` package, and the chair of the core libraries committee seems to agree. That would be simpler than a lot of ad-hoc instances. > > Btw, I just tried to enable it globally in order to get a list of additional `Typeable` instances becoming available by that, but you have to avoid using `AutoDeriveTypeable` at the same time with `NoImplicitPrelude`, as otherwise you get the error > > {{{ > Failed to load interface for ?Data.Typeable.Internal? > }}} Can you explain how to reproduce this error. Just add `AutoDeriveTypeable` to `base.cabal`? Or what? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 16:07:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 16:07:13 -0000 Subject: [GHC] #8555: Simplify given `Coercible` constraints In-Reply-To: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> References: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> Message-ID: <061.2b1966658ae0fafc3d14d0523b9e9db7@haskell.org> #8555: Simplify given `Coercible` constraints ----------------------------------------------+---------------------------- Reporter: nomeata | Owner: archblob Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8503 | #8555 ----------------------------------------------+---------------------------- Comment (by simonpj): I doubt that this is very useful in practice. I think there are plenty of other more directly useful tickets. Eg look at [wiki:Status/SLPJ- Tickets]. For example, #5610/#7243 looks tractable and useful. #8281 looks as if it needs a push. Etc. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 16:07:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 16:07:38 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.8619aacd08f883693ea6013126ae1722@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): Replying to [comment:10 simonpj]: > The only reason for giving a role signature that is less permissive than the actual newtype-unwrapping is, well, to be more restrictive. So I think it'd be rather unusual both to give a role signature, and to expose the data constructor of the newtype. So I'm not too bothered about this particular dead end. Actually, fixing this adds a nice feature to this whole area: the ability to have free conversions within a library but not to export this capability! If we have a newtype with a nominal role annotation, its constructor might be visible only among "friendly" modules, allowing the free conversion. Then, outside of the package, the constructor is inaccessible, so no conversions are possible. This ability was a desideratum at the beginning of the design process that we thought we threw away when we went with the idea of using class instances. But, now we have it back! > But still, yes, putting the rules in the other order would be a good idea. (Make sure you add a `Note`!) I'm a bit bugged that `Coercible (N Age) (N Int)` might take a rather long way round (unwrapping multiple layers of newtype) rather than the short cut (try `(Coercible Age Int)`). But maybe I should not worry about that. You shouldn't worry about that. :) I conjecture that coercion optimization ''already'' fixes this problem. (See uses of `matchAxiom` in !OptCoercion.) > > As to the "knowing more later" stuff, I'm just referring to situations like `(alpha t1) ~ (alpha t2)` where `alpha` is a unification variable. As constraint solving progresses we may learn what `alpha` is -- but if we have already decomposed the application it may now be too late. It's difficult to use the approach that Richard describes, because it interacts with all the other constraint solving that is going on during type inference. Ah. Good point. I hadn't thought of it that way. You're right -- we need to be careful here. But, if #9123 gets solved in the way that we're thinking of solving it now, we will want the functionality originally requested in this ticket available. So, it may be worth doing some Hard Thinking about this and getting it right. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 16:10:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 16:10:27 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.1bf05b6b5e0c10a62e36620924039af8@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.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 --------------------------------------------+------------------------------ Comment (by simonpj): Thank you! Did you do the performance comparisons? Does the compiler allocate more when compiling? Do hi files get bigger? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 16:18:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 16:18:20 -0000 Subject: [GHC] #9122: Make Lint check for bad uses of `unsafeCoerce` In-Reply-To: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> References: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> Message-ID: <061.fd37b395489c89c3b108706718535b7d@haskell.org> #9122: Make Lint check for bad uses of `unsafeCoerce` -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): I was thinking of someone who wanted the raw pointer associated with a value of a lifted type. Coercing `Int` to `Int#` would seemingly get that pointer value. It's conceivable to me to imagine scenarios where this behavior is desired, such as debugging against some sort of memory dump. Going the other way might also be desirable, if Haskell code has to operate against some pre-loaded memory image. Maybe these sorts of things never happen in Haskell, but I've done them (when debugging kernels / device drivers) in other languages. Or, is the idea that all such shenanigans are subsumed by `Foreign.Ptr` and friends? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 16:27:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 16:27:50 -0000 Subject: [GHC] #9122: Make Lint check for bad uses of `unsafeCoerce` In-Reply-To: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> References: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> Message-ID: <061.2e88aeb13564201ba8d37e045b7c32ac@haskell.org> #9122: Make Lint check for bad uses of `unsafeCoerce` -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): Right after you get the pointer in your hand, garbage collection may happen, which moves the object. This way lies madness. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 16:30:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 16:30:03 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.e5f72211959e0099448d3a3de31ae83b@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.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 --------------------------------------------+------------------------------ Comment (by archblob): Unfortunately my git workflow leaves a lot to be desired and I did not have a separate commit for each change I made and won't be able to give you separate numbers, I'm running benchmarks on the whole patch tonight and post the numbers when I'm done. I'll also have the numbers for separate changes in a couple of days, when I find the time to split the commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 16:36:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 16:36:28 -0000 Subject: [GHC] #9122: Make Lint check for bad uses of `unsafeCoerce` In-Reply-To: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> References: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> Message-ID: <061.a200bec6f2a8d71a82ededa5abdf11eb@haskell.org> #9122: Make Lint check for bad uses of `unsafeCoerce` -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): Fair enough -- such users can always simply avoid `-dcore-lint` anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 16:42:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 16:42:53 -0000 Subject: [GHC] #8555: Simplify given `Coercible` constraints In-Reply-To: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> References: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> Message-ID: <061.94f051a164586511fbf80e2b0dfa0ff0@haskell.org> #8555: Simplify given `Coercible` constraints ----------------------------------------------+---------------------------- Reporter: nomeata | Owner: archblob Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8503 | #8555 ----------------------------------------------+---------------------------- Comment (by archblob): Yeah, I am more interested in the typechecker part of ghc at the moment, so I just chose something recent. I'll certainly have a lookt at those tickets and see if I can help. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 16:48:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 16:48:09 -0000 Subject: [GHC] #4836: literate markdown not handled correctly by unlit In-Reply-To: <044.677d9d9819274dc3e0fccfc271c35be2@haskell.org> References: <044.677d9d9819274dc3e0fccfc271c35be2@haskell.org> Message-ID: <059.3ccc2e6d08804b84f919d088054e9edb@haskell.org> #4836: literate markdown not handled correctly by unlit ----------------------------------------------+---------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7120 ----------------------------------------------+---------------------------- Comment (by elliottt): I've updated my branch, and it's building successfully against master. I plan on testing a few corner cases, then submitting a patch. For reference, here's the branch: https://github.com/elliottt/ghc/tree/literate-markdown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 17:10:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 17:10:19 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.10e2a8f16d8945cd26c9c2ba651a33b3@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 nomeata): Replying to [comment:11 goldfire]: > Actually, fixing this adds a nice feature to this whole area: the ability to have free conversions within a library but not to export this capability! If we have a newtype with a nominal role annotation, its constructor might be visible only among "friendly" modules, allowing the free conversion. Then, outside of the package, the constructor is inaccessible, so no conversions are possible. This ability was a desideratum at the beginning of the design process that we thought we threw away when we went with the idea of using class instances. But, now we have it back! True, but only for newtypes, there is currently no way for ?I want to coerce under `Set` in my own modules only.?, that would require the are- all-type-constructors-in-scope test again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 17:20:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 17:20:06 -0000 Subject: [GHC] #9080: GHC error on Win 8.1 64bit In-Reply-To: <043.c0aa3d5bf848f70ddef90000b43fffd8@haskell.org> References: <043.c0aa3d5bf848f70ddef90000b43fffd8@haskell.org> Message-ID: <058.ac5397299180feaaba2b3ca11dad5316@haskell.org> #9080: GHC error on Win 8.1 64bit ---------------------------------------+---------------------------------- Reporter: maun | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by stuartallenmills): Obtained the exact same error under Windows 7 while trying to install yesod (excerpt): Loading package css-text-0.1.2.1 ... linking ... done. Loading package tagsoup-0.13.1 ... linking ... done. Loading package xss-sanitize-0.3.5.2 ... linking ... done. Loading package yesod-persistent-1.2.2.3 ... linking ... done. Loading package yesod-form-1.3.9 ... linking ... done. Loading package yesod-auth-1.3.0.5 ... linking ... done. Loading package yaml-0.8.8.2 ... ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-mingw32): loadObj "C:\\users\\smills\\Hask\\yesod\\.cabal-sandbox\\x86_64 -windows-ghc-7.8.2\\yaml-0.8.8.2\\HSyaml-0.8.8.2.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ... ghc.exe: Unknown PEi386 section name `.text.unlikely' (while processing: C:\users\smills\Hask\yesod\.cabal-sandbox\x86_64-windows- ghc-7.8.2\yaml-0.8.8.2\HSyaml-0.8.8.2.o) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 17:26:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 17:26:55 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.70a2c466817d01271b24e3873354eab3@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): Yes, but the library-writer could just use a newtype to get this functionality. For example, if the writer of `Set` wants coercions internally, they use `SetInternal` with no role annotations and then `Set` with a role annotation. It's a little bit of (compile-time-only) overhead, but it should be usable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 17:54:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 17:54:59 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM - 7.8.1-rc2 Message-ID: <046.674440465a685280d146765ea38d0bfb@haskell.org> #9125: int-to-float conversion broken on ARM - 7.8.1-rc2 --------------------------+------------------------------------------------ Reporter: | Owner: Ansible | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.1 Component: | Operating System: Linux Compiler | Type of failure: Incorrect result at runtime Keywords: | Test Case: Architecture: arm | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ I compiled ghc on the raspberry pi. See this bug for more about that build of ghc: [https://ghc.haskell.org/trac/ghc/ticket/8896 8896]. A simple test program: {{{ main = do mapM_ (print . (fromInteger :: Integer -> Float)) [0..100] }}} And the result: {{{ 0.0 127.0 256.0 257.0 516.0 517.0 518.0 519.0 1040.0 1041.0 1042.0 1043.0 1044.0 1045.0 1046.0 1047.0 2096.0 2097.0 2098.0 2099.0 2100.0 2101.0 2102.0 2103.0 2104.0 2105.0 2106.0 2107.0 2108.0 2109.0 2110.0 2111.0 4224.0 4225.0 4226.0 4227.0 4228.0 4229.0 4230.0 4231.0 4232.0 4233.0 4234.0 4235.0 4236.0 4237.0 4238.0 4239.0 4240.0 4241.0 4242.0 4243.0 4244.0 4245.0 4246.0 4247.0 4248.0 4249.0 4250.0 4251.0 4252.0 4253.0 4254.0 4255.0 8512.0 8513.0 8514.0 8515.0 8516.0 8517.0 8518.0 8519.0 8520.0 8521.0 8522.0 8523.0 8524.0 8525.0 8526.0 8527.0 8528.0 8529.0 8530.0 8531.0 8532.0 8533.0 8534.0 8535.0 8536.0 8537.0 8538.0 8539.0 8540.0 8541.0 8542.0 8543.0 8544.0 8545.0 8546.0 8547.0 8548.0 8538.0 }}} This code, however, works normally: {{{ main = do mapM_ (print . (fromInteger :: Integer -> Double)) [0..100] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 18:16:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 18:16:40 -0000 Subject: [GHC] #9126: -ddump-to-file in TcRnMonad.lhs Message-ID: <048.69a311618464257df9b637c94b74c85f@haskell.org> #9126: -ddump-to-file in TcRnMonad.lhs ------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As part of #8624, the first thing we realized is -ddump-to-file wasn't being respected. This is against HEAD, but I would really like to merge it to 7.8.3 if that is ok. I tested this with -ddump-tc and -ddump-splices. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 18:21:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 18:21:49 -0000 Subject: [GHC] #9126: -ddump-to-file in TcRnMonad.lhs In-Reply-To: <048.69a311618464257df9b637c94b74c85f@haskell.org> References: <048.69a311618464257df9b637c94b74c85f@haskell.org> Message-ID: <063.8c65418a2bdf6cfe4ec610cf486758af@haskell.org> #9126: -ddump-to-file in TcRnMonad.lhs -------------------------------------+------------------------------------ Reporter: GregWeber | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 GregWeber): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 18:23:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 18:23:24 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.b2a89871dfb443ca58d58c7d39129984@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------ Reporter: GregWeber | 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 GregWeber): I submitted a patch in #9126 to get -ddump-to-file to work with more debug options. I will pursue a more ideal output with a different flag on this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 18:29:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 18:29:08 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.9f77aeafad3556e77d670a56dea0f4d1@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 nomeata): Replying to [comment:13 goldfire]: > Yes, but the library-writer could just use a newtype to get this functionality. For example, if the writer of `Set` wants coercions internally, they use `SetInternal` with no role annotations and then `Set` with a role annotation. It's a little bit of (compile-time-only) overhead, but it should be usable. Ah, right. I think we had this discussion before, and you told me that back then :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 19:03:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 19:03:30 -0000 Subject: [GHC] #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` Message-ID: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` ------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- With GHC 7.8.2, code like {{{ let !_ = rqPostParams rq let !_ = rqParams rq }}} triggers the following warnings: {{{ src/Snap/Internal/Test/RequestBuilder.hs:150:13: Warning: This pattern-binding binds no variables: !_ = rqPostParams rq src/Snap/Internal/Test/RequestBuilder.hs:151:13: Warning: This pattern-binding binds no variables: !_ = rqParams rq }}} I think that `let !_ = rhs` shouldn't trigger a warning, just like `let _ = rhs` doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 20:48:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 20:48:20 -0000 Subject: [GHC] #9128: Possible bug in strictness analyzer when where clause declared NOINLINE Message-ID: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> #9128: Possible bug in strictness analyzer when where clause declared NOINLINE -----------------------------------------+--------------------------------- Reporter: aalevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: strictness bytestring | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | crash Related Tickets: | Test Case: | Blocking: -----------------------------------------+--------------------------------- I've encountered the following error message using a relatively straight forward library that wraps postgresql-simple in certain edge cases: {{{ *** Exception: Oops! Entered absent arg a_sYDl{v} [lid] bytestring-0.10.4.0:Data.ByteString.Internal.ByteString{tc r5T} }}} This happens on an invocation of a function, `dbSelect` under certain compilation conditions: {{{ dbSelect :: (Model a) => Connection -> DBSelect a -> IO [a] {-# INLINE #-} dbSelect conn dbs = map lookupRow <$> query_ conn q where {-# NOINLINE #-} q = renderDBSelect dbs }}} A DBSelect is just a data-structure with different `Query` (wrapper around strict bytestring) fields for clauses in a SQL select query. `renderDBSelect` generates a single `Query` value from the DBSelect (by way of contructing a Blaze.Builder as an intermediate step). When compiled with no optimizations, this works fine, no issues. With -O1, I get the error above. The errors goes away, if I compile with -fno- strictness or remove the NOINLINE *or* INLINE pragmas. We've worked around this for now in the library by removgin the NOINLINE pragmas, but tracking this down it seems like the strictness analyzer might be falsly assuming `q` is never actually evaluated. For reference, this is a commit that still exhibits the bug: https://github.com/alevy/postgresql- orm/tree/93075d56ae5ffeb8f80ecc8c01436713c2656a6b I've also attached a small test application that excercises the bug. Because of how the library sets up a scratch database, the test application requires postgres and pg_ctl to be available in the path. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 21:31:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 21:31:30 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.48182dc525d95dd89d3381fc5859ecdb@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 hvr): Replying to [comment:14 simonpj]: > > {{{ > > Failed to load interface for ?Data.Typeable.Internal? > > }}} btw, that message is just asking to add an `import Data.Typeable.Internal` in the module triggering that error (which often isn't possible due to import-cycles) > Can you explain how to reproduce this error. Just add `AutoDeriveTypeable` to `base.cabal`? Or what? Adding `default-extension: AutoDeriveTypeable` to `base.cabal` is one way. But a more interesting case to try out is to enable `AutoDeriveTypeable` just inside a single module such as `GHC/Flaot.lhs` which doesn't `import Data.Typeable` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 21:34:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 21:34:07 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.c5af3d5f5a71047ffd0ffbab0e7ad3c2@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): OK, so I think at least part of this ticket has a conclusion: * We should try newtype unwrapping before trying decomposition. (But please let's try identity first of all in case the two types are identical.) * The reason for this ordering should be captured in a `Note` * I think it would also be highly worthwhile to start a new "user- documentation" page on the Haskell wiki, linked from [http://www.haskell.org/haskellwiki/GHC/Type_system GHC type system extensions]. This gives a user-updatable place to explain how to use the raw facilities. The points explained above in comments 11-14 are far from obvious, and it'd be great to have them articulated there. Joachim might you do these things? Thanks. That still leaves the original topic of the ticket (decomposing applications) open. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 21:39:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 21:39:26 -0000 Subject: [GHC] #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` In-Reply-To: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> References: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> Message-ID: <060.35edbde530acec2063ba00f41438698f@haskell.org> #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` -------------------------------------+------------------------------------ Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): Harump. Maybe `let _ = rhs` ''should'' trigger a warning! It's dead code after all. But the `let !_ = e in b` means just {{{e `seq` b}}} so I suppose you could argue that it non-warnable. Does anyone else care? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 21:43:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 21:43:47 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.f6a55a8758ac6424b9faf2af92a6c68b@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.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 --------------------------------------------+------------------------------ Comment (by archblob): I have comparte the sizes of .hi files on a number of libraries individually and also did the whole libraries folder. The results are in the attached file. It is roughly a 0.04% increase in interface file size. I will post performance numbers too when i have them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 21:48:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 21:48:43 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.f729f425ecb21a57d49c03392c305b8f@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 simonpj: Old description: > This [http://www.haskell.org/pipermail/ghc-devs/2014-May/004964.html > thread] on ghc-devs identifies a real shortcoming of the new roles > system. Here's a compact example, from the thread > {{{ > class C m where > ret :: a -> m a > bind :: m a -> (a -> m b) -> m b > join :: m (m a) -> m a > > newtype T m a = MkT (m a) deriving( C ) > }}} > The `deriving(C)` is accepted without `join` in the class, but rejected > when `join` is added. And the AMP proposal adds `join` to class `Monad`! > > In one way it is rightly rejected: it really would be unsound to derive > an instance for `C (T K)` where `K`'s argument had nominal (but not > representational) role. But we have no way to limit the type > constructors at which `T` can be used. > > This deficiency is noted in the [http://research.microsoft.com/en- > us/um/people/simonpj/papers/ext-f/ Safe Coercions paper], but this seems > to be the first occasion on which it has bitten us badly. > > Edward [http://www.haskell.org/pipermail/ghc-devs/2014-May/004974.html > made a suggestion] on the thread. New description: This [http://www.haskell.org/pipermail/ghc-devs/2014-May/004964.html thread] on ghc-devs identifies a real shortcoming of the new roles system. Here's a compact example, from the thread {{{ class C m where ret :: a -> m a bind :: m a -> (a -> m b) -> m b join :: m (m a) -> m a newtype T m a = MkT (m a) deriving( C ) }}} The `deriving(C)` is accepted without `join` in the class, but rejected when `join` is added. {{{ T9123.hs:10:37: Could not coerce from `m (m a)' to `m (T m a)' because `m (m a)' and `m (T m a)' are different types. arising from the coercion of the method `join' from type `forall a. m (m a) -> m a' to type `forall a. T m (T m a) -> T m a' }}} Note that the AMP proposal adds `join` to class `Monad`! In one way it is rightly rejected: it really would be unsound to derive an instance for `C (T K)` where `K`'s argument had nominal (but not representational) role. But we have no way to limit the type constructors at which `T` can be used. This deficiency is noted in the [http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/ Safe Coercions paper], but this seems to be the first occasion on which it has bitten us badly. Edward [http://www.haskell.org/pipermail/ghc-devs/2014-May/004974.html made a suggestion] on the thread. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 21:52:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 21:52:24 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.71d512ed60a0c40f1da18f754579a222@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 nomeata): I?ll do 1 and 2 (that?s why I already assigned the ticket to me) and might start on 3, although Richard appears to has a better overview, so I hope he?ll help me with that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 22:05:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 22:05:03 -0000 Subject: [GHC] #9118: Can't eta-reduce representational coercions In-Reply-To: <047.51e26113c799743ba87b936ff219c6a7@haskell.org> References: <047.51e26113c799743ba87b936ff219c6a7@haskell.org> Message-ID: <062.faf8888353fddf6624f9e35e43593e26@haskell.org> #9118: Can't eta-reduce representational coercions -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9117 -------------------------------------+------------------------------------ Description changed by simonpj: Old description: > When I say > > {{{ > import Data.Type.Coercion > import Data.Coerce > import Data.Proxy > > eta2 :: Coercible (f a) (g a) => Proxy a -> Coercion f g > eta2 _ = Coercion > }}} > > I get > > {{{ > Could not coerce from ?f? to ?g? > because ?f? and ?g? are different types. > arising from a use of ?Coercion? > from the context (Coercible (f a) (g a)) > bound by the type signature for > eta2 :: Coercible (f a) (g a) => Proxy a -> Coercion f g > at /Users/rae/temp/Roles.hs:5:9-56 > In the expression: Coercion > In an equation for ?eta2?: eta2 _ = Coercion > }}} > > Unlike the case for #9116, this one is ''not'' expressible in Core. (At > least, I don't see a way to do it.) So, to do this, we would have to > update Core and then update the constraint solver. I ''do'' think this > would be type safe. But, I also think it's reasonable to wait for someone > with a real use case to shout before doing this. The only use case I have > is to be able to do this: > > {{{ > -- says that a's parameter is representational > class Rep (a :: k1 -> k2) where > co :: Coercible x y => Coercible (a x) (a x) > > instance Rep f => Rep (Compose f) where ... > }}} New description: When I say {{{ import Data.Type.Coercion import Data.Coerce import Data.Proxy eta2 :: Coercible (f a) (g a) => Proxy a -> Coercion f g eta2 _ = Coercion }}} I get {{{ Could not coerce from ?f? to ?g? because ?f? and ?g? are different types. arising from a use of ?Coercion? from the context (Coercible (f a) (g a)) bound by the type signature for eta2 :: Coercible (f a) (g a) => Proxy a -> Coercion f g at /Users/rae/temp/Roles.hs:5:9-56 In the expression: Coercion In an equation for ?eta2?: eta2 _ = Coercion }}} Unlike the case for #9117, this one is ''not'' expressible in Core. (At least, I don't see a way to do it.) So, to do this, we would have to update Core and then update the constraint solver. I ''do'' think this would be type safe. But, I also think it's reasonable to wait for someone with a real use case to shout before doing this. The only use case I have is to be able to do this: {{{ -- says that a's parameter is representational class Rep (a :: k1 -> k2) where co :: Coercible x y => Coercible (a x) (a x) instance Rep f => Rep (Compose f) where ... }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 22:26:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 22:26:28 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.8b32e23e71f071e2a1bf525b3b09dfcb@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): Let's articulate Edward's proposal explicitly, so we all know what we are talking about. Here is one possible version, expressed in the language of the Safe Coercions paper. Yell if I get this wrong. * We add the following decomposition rule to the solution rules for `Coercible`: {{{ instance (Repesentational f, Coercible a b) => Coercible (f a) (f b) }}} Edward actually suggested something more like {{{ instance (Representational f, Coercible f g, Coercible a b) => Coercible (f a) (g b) }}} but I dislike the assymetry in `f`, `g`, and I think this weaker thing will do. * The `Representational` class would have built-in solution rules (as `Coercible` does), all of the form: {{{ instance Representational (T a b c) }}} whenever the ''next'' argument of `T` is representational. I am hazy about * Whether it should be possible to have user-written instances for `Representational` * How `Representational` is defined. It could be {{{ class Representational f where rep :: Coercion a b -> Coercion (f a) (f b) }}} or {{{ class Representational f where rep :: Coercible a b => Coercion (f a) (f b) }}} or (if `Representational` is built in) {{{ class Representational f where rep :: Coercible a b => Coercible (f a) (f b) }}} The latter is easiest for the type checker. I see no need to make `Representational` a superclass of `Functor`. Rather, GND on {{{ data T m a = MkT (m a) deriving( Monad ) }}} would yield an instance {{{ instance (Representational m, Monad m) => Monad (T m) where ... }}} which is absolutely fine. No need for every monad to be representational. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 22:56:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 22:56:51 -0000 Subject: [GHC] #9128: Possible bug in strictness analyzer when where clause declared NOINLINE In-Reply-To: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> References: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> Message-ID: <060.ece61e53c0a6c4414c6391f3b36b240f@haskell.org> #9128: Possible bug in strictness analyzer when where clause declared NOINLINE ---------------------------------+----------------------------------------- Reporter: aalevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: strictness bytestring Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | ---------------------------------+----------------------------------------- Comment (by simonpj): Can you give clear instructions for how to reproduce, starting from a fresh GHC 7.8.2. Doubtless some libraries to install? Then get some specific (non Hackage) version of postgres SQL, or something. Assume I am stupid and you won't go far wrong. Thanks, Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 19 23:07:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 May 2014 23:07:34 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.01e3d4b251d2a30d64a5bc3fc8c37ca3@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): Ah yes I see. * The key module is `Data.Typeable.Internal`. * It declares the `Typeable` class, which mentions the data type `TypeRep`. * In turn `TypeRep` uses `Fingerprint` from `GHC.Fingerprint.Type` * And fingerprints use various `Word` types to do grungy stuff. As a result, `Data.Typeable.Internal` has to depend on `GHC.Word` etc. It also depends on a bunch of other things and I'm not sure they are all necessary. It would be good to make it depend on as little as possible. Regardless, * the modules "below" `Data.Typeable.Internal` (i.e. the modules on which `D.T.I` depends) can't be compiled with `DeriveAutoTypeable`; instead there are `deriving instance Typeable T` declarations in `D.T.I` for all of their types. * all other modules in `base` can have `DeriveAutoTypeable`. Does that make sense? Who would like to do it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 00:08:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 00:08:29 -0000 Subject: [GHC] #9128: Possible bug in strictness analyzer when where clause declared NOINLINE In-Reply-To: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> References: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> Message-ID: <060.2553ec0c62dae3186e1cd6dd2f8acaa5@haskell.org> #9128: Possible bug in strictness analyzer when where clause declared NOINLINE ---------------------------------+----------------------------------------- Reporter: aalevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: strictness bytestring Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | ---------------------------------+----------------------------------------- Comment (by aalevy): Yes, sorry. From a fresh install with ghc-7.8.2 and cabal (1.20 in my case, but since it's just for installing dependencies, and I don't think default optimization levels have changed recently, I suspect it doesn't matter): 0. Prerequisites: postgresql (I'm using 9.3, but probably doesn't matter) with tools (specifically pg_ctl). Tools, for example, are not installed by default on the postgresql version that comes with OS X -- you have to install from homebrew I think. pg_ctl comes with postgresql on most distros of linux though. Unfortunately, I don't know about windows and don't have an install available to test with. 1. Grab the unpatched version of the postgresql-orm from github: {{{ $ git clone https://github.com/alevy/postgresql-orm.git $ cd postgresql-orm $ git checkout 93075d56ae5ffeb8f80ecc8c01436713c2656a6b }}} 2. Install library dependencies (inside a cabal sandbox if you care about not polluting your global environment): {{{ $ cabal sandbox init $ cabal install --only-dependencies }}} 3. Copy test.hs into the project directory 4. Compile with O1: {{{ $ ghc -O1 test.hs -package-db ./.cabal-sandbox/x86_64-linux- ghc-7.8.2-packages.conf.d }}} 5. Run: {{{ $ ./test test: Oops! Entered absent arg a_sYDl{v} [lid] bytestring-0.10.4.0:Data.ByteString.Internal.ByteString{tc r5T} }}} All the machines I've tested this on are running Arch Linux, with ghc-7.8.2 Are there any steps I haven't thought to include? Thanks! -amit -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 00:23:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 00:23:10 -0000 Subject: [GHC] #9126: -ddump-to-file in TcRnMonad.lhs In-Reply-To: <048.69a311618464257df9b637c94b74c85f@haskell.org> References: <048.69a311618464257df9b637c94b74c85f@haskell.org> Message-ID: <063.b849fced2c43a914e1ffa33caa8eccbc@haskell.org> #9126: -ddump-to-file in TcRnMonad.lhs -------------------------------------+------------------------------------ Reporter: GregWeber | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 GregWeber): It looks like there are a few test case failures, I will try to clean them up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 00:30:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 00:30:23 -0000 Subject: [GHC] #9128: Possible bug in strictness analyzer when where clause declared NOINLINE In-Reply-To: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> References: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> Message-ID: <060.2ea870f89901dbeda0d1ff9e655c2ac9@haskell.org> #9128: Possible bug in strictness analyzer when where clause declared NOINLINE ---------------------------------+----------------------------------------- Reporter: aalevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: strictness bytestring Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | ---------------------------------+----------------------------------------- Comment (by aalevy): OK, I can reproduce it without a dependency on the database (which should make it easier to repro for others...) Same instructions as before, except no need to install/setup the postgresql database server, and use the new attached (test2.hs) file instead: 1. Grab the unpatched version of the postgresql-orm from github: {{{ $ git clone https://github.com/alevy/postgresql-orm.git $ cd postgresql-orm $ git checkout 93075d56ae5ffeb8f80ecc8c01436713c2656a6b }}} 2. Install library dependencies (inside a cabal sandbox if you care about not polluting your global environment): {{{ $ cabal sandbox init $ cabal install --only-dependencies }}} 3. Copy test2.hs into the project directory 4. Compile with O1: {{{ $ ghc -O1 test2.hs -package-db ./.cabal-sandbox/x86_64-linux- ghc-7.8.2-packages.conf.d }}} 5. Run: {{{ $ ./test test: Oops! Entered absent arg a_sYDl{v} [lid] bytestring-0.10.4.0:Data.ByteString.Internal.ByteString{tc r5T} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 00:59:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 00:59:17 -0000 Subject: [GHC] #9129: link error: unknown symbol `diagramszmlibzm1zi1zi0zi1_DiagramsziDirection_Direction_closure' Message-ID: <047.21067b3ced4e298ca552ea93ba25495c@haskell.org> #9129: link error: unknown symbol `diagramszmlibzm1zi1zi0zi1_DiagramsziDirection_Direction_closure' ----------------------------------+------------------------------------- Reporter: dmbergey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- When trying to build libraries linking against https://github.com/diagrams /diagrams-lib/tree/direction I get an error, in both GHC 7.6.3 and GHC 7.8.2. In 7.6.3: `Loading package diagrams-lib-1.1.0.1 ... linking ... ghc: /home/vagrant/.cabal/lib/diagrams-lib-1.1.0.1/ghc-7.6.3/HSdiagrams- lib-1.1.0.1.o: unknown symbol \`diagramszmlibzm1zi1zi0zi1_DiagramsziDirection_Direction_closure'` In 7.8.2: `Loading package diagrams-lib-1.1.0.1 ... : can't load .so/.DLL for: /home/bergey/code/diagrams/.cabal-sandbox/lib/x86_64-linux- ghc-7.8.2/diagrams-lib-1.1.0.1/libHSdiagrams-lib-1.1.0.1-ghc7.8.2.so (/home/bergey/code/diagrams/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.2 /diagrams-lib-1.1.0.1/libHSdiagrams-lib-1.1.0.1-ghc7.8.2.so: undefined symbol: diagramszmlibzm1zi1zi0zi1_DiagramsziDirection_Direction_con_info)` The problem seems specific to this branch. I can install the package, but cannot link against it. The following steps reproduce the error in a clean Linux (Ubuntu) VM with HP 2013.2 installed: set -e sudo aptitude install git -y git clone https://github.com/diagrams/diagrams-core.git core git clone https://github.com/diagrams/diagrams-lib.git lib git clone https://github.com/diagrams/diagrams-svg.git svg cabal update cd lib/ git checkout direction cd .. cabal install core/ lib/ svg/ I'm happy to do more debugging if someone can advise me what to try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 05:14:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 05:14:55 -0000 Subject: [GHC] #9016: Add System.Exit.die In-Reply-To: <050.e4566798430f089e73482601b9abc89f@haskell.org> References: <050.e4566798430f089e73482601b9abc89f@haskell.org> Message-ID: <065.e779fb4b249c1db3c9031b9efd706fd8@haskell.org> #9016: Add System.Exit.die -------------------------------------+------------------------------------ Reporter: SimonHengel | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 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 bjornars): I compiled GHC from git with 7.6.3, which worked ok. Now trying to compile GHC from git again, with my newly compiled compiler, I get complaints about: {{{ utils/deriveConstants/DeriveConstants.hs:32:48: Ambiguous occurrence ?die? It could refer to either ?Main.die?, defined at utils/deriveConstants/DeriveConstants.hs:880:1 or ?System.Exit.die?, imported from ?System.Exit? at utils/deriveConstants/DeriveConstants.hs:22:1-18 utils/deriveConstants/DeriveConstants.hs:104:28: Ambiguous occurrence ?die? It could refer to either ?Main.die?, defined at utils/deriveConstants/DeriveConstants.hs:880:1 or ?System.Exit.die?, imported from ?System.Exit? at utils/deriveConstants/DeriveConstants.hs:22:1-18 utils/deriveConstants/DeriveConstants.hs:742:21: Ambiguous occurrence ?die? It could refer to either ?Main.die?, defined at utils/deriveConstants/DeriveConstants.hs:880:1 or ?System.Exit.die?, imported from ?System.Exit? at utils/deriveConstants/DeriveConstants.hs:22:1-18 utils/deriveConstants/DeriveConstants.hs:744:28: Ambiguous occurrence ?die? It could refer to either ?Main.die?, defined at utils/deriveConstants/DeriveConstants.hs:880:1 or ?System.Exit.die?, imported from ?System.Exit? at utils/deriveConstants/DeriveConstants.hs:22:1-18 utils/deriveConstants/DeriveConstants.hs:770:29: Ambiguous occurrence ?die? It could refer to either ?Main.die?, defined at utils/deriveConstants/DeriveConstants.hs:880:1 or ?System.Exit.die?, imported from ?System.Exit? at utils/deriveConstants/DeriveConstants.hs:22:1-18 utils/deriveConstants/DeriveConstants.hs:888:11: Ambiguous occurrence ?die? It could refer to either ?Main.die?, defined at utils/deriveConstants/DeriveConstants.hs:880:1 or ?System.Exit.die?, imported from ?System.Exit? at utils/deriveConstants/DeriveConstants.hs:22:1-18 }}} Is this the same issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 07:44:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 07:44:27 -0000 Subject: [GHC] #9016: Add System.Exit.die In-Reply-To: <050.e4566798430f089e73482601b9abc89f@haskell.org> References: <050.e4566798430f089e73482601b9abc89f@haskell.org> Message-ID: <065.c8f4b912ae55f2447e095e8fbfceb79f@haskell.org> #9016: Add System.Exit.die -------------------------------------+------------------------------------ Reporter: SimonHengel | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 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 Herbert Valerio Riedel ): In [changeset:"a15d243e4c15c45a401dec8c30a5135b6b006115/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a15d243e4c15c45a401dec8c30a5135b6b006115" Harden imports in `DeriveConstants.hs` module This was generated by applying `-ddump-minimal-imports` and addresses the current compile failure (see #9016) with GHC HEAD due to the new `die` being exported by `System.Exit` Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 08:48:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 08:48:12 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.fa6ae4db24f61b329cd9cb6f30be9f33@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 Joachim Breitner ): In [changeset:"7e78faf033405bd5f3b6b787343c98e33d767bda/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7e78faf033405bd5f3b6b787343c98e33d767bda" Coercible: Unwrap newtypes before coercing under tycons This fixes parts of #9117. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 08:53:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 08:53:25 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.c238088a27b3f2d54b7b17aa3c16351c@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 Joachim Breitner ): In [changeset:"94c57676d7f88cd9edcc522aa3dc3ec6e3ad6633/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="94c57676d7f88cd9edcc522aa3dc3ec6e3ad6633" Coercible: Test case for now broken(?) corner case involving a non-terminating newtype. This worked before 7e78faf03. Probably not a problem, but still better to have a test case for it. See ticket #9117. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 08:53:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 08:53:36 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.268ce3cfa0a31c5c7fe5c3d62692f158@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 nomeata): I implemented the changed order (code is running a validate right now). There are still weird corner-cases. Consider: {{{ newtype Foo a = Foo (Foo a) newtype Age = MkAge Int ex1 :: (Foo Age) -> (Foo Int) ex1 = coerce }}} Previously, this would be solvable; now it starts unrolling the infinite newtype. (But we don?t have a good story for newtypes anyways). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 09:23:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 09:23:36 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.0d291888fa7ae9ae2a5b8a9b3a8ca4e6@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 nomeata): Started http://www.haskell.org/haskellwiki/GHC/Coercible and added the bits about how to achieve different `Coercible` behaviour in internal and external code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 12:19:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 12:19:22 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.9808ff104bbc1c7fc8894133d7dca5fd@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): Your non-terminating `Foo` example seems pathological, but what about this, somewhat more sensible example: {{{ newtype Bar a = Bar (Either a (Bar a)) x :: Bar Age x = coerce (Bar (Left (5 :: Int))) }}} This example works in 7.8.2. PS: Will contribute to the "Coercible" page in due course. Thanks for starting it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 12:52:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 12:52:47 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.c77ebc1949f6499da71feb652d2c2a1f@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 nomeata): Yes, that?s a better example. So we have a dilemma: Should we support recursive newtypes better, or should we support different internal/external coercions better? Your trick in comment:13, shouldn?t that work for newtypes just as well? So maybe the original order was better after all... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 13:29:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 13:29:27 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.9a19fbca5a4b4e0e7f9e6a152e1c86bd@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): I suppose it would. But, if we decide not to let my example in comment:7 work, we need to articulate this clearly somewhere. According to all the "rules" around `Coercible`, it would seem that the code in comment:7 should work and may surprise folks when it doesn't. I have to say I don't love the idea of not handling comment:7, but if we can't find a way to do it, it's not the end of the world. Would it make sense to detect the recursion and then switch techniques? Seems ad-hoc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 13:39:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 13:39:15 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.3b6a14ca95c86ff3a3f57fbf3b9f555f@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 nomeata): In the paper comments you write > Suppose module `A` uses `coerce` somewhere and contains a newtype whose constructor is not imported. We now modify `A` to import the constructor. Is it guaranteed that the use(s) of `coerce` will still work? We would want to offer such a guarantee I think. We are unable to give this guarantee with either of the two solving strategies. Consider: {{{#!haskell module Foo where newtype Rec a = Rec a newtype Hide a = Hide (Rec a) module Bar where import Foo (Hide(Hide), Rec) ex :: Rec Age -> Hide Int ex = coerce }}} This works (`Hide` is unrolled, then we can lift through `Rec` and are done). If we also import `Rec`, then `Coercible (Rec Age) (Hide Int)` (where no lifting is possible yet, so the order does not matter) will cause it to loop. I couldn?t construct it with a less pathological newtype yet, though, as these will cause a proper data tycon to appear, then the newtypes on the RHS get unwrapped and eventually the terms on both sides match. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 13:47:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 13:47:43 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.31641cb18d308d262ce7c801601b0ad0@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.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 --------------------------------------------+------------------------------ Comment (by archblob): It seems I'm doing time and allocation profiling wrong so I need some quidance. Right now I'm building stage 3 with +RTS -pa -RTS but the prof file I get seems to be only from the last run ghc made. So I don't really know how to procede. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 14:22:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 14:22:49 -0000 Subject: [GHC] #9130: Segmentation fault in ThreadPaused.c:223 when compiled with -O Message-ID: <042.2152cafa14f5b78ade36a176855acf11@haskell.org> #9130: Segmentation fault in ThreadPaused.c:223 when compiled with -O ----------------------------------+---------------------------------- Reporter: twi | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- Compiling the following program with {{{ghc --make -fforce-recomp -O Tests}}} gives me a segmentation fault when running the resulting executable whereas without {{{-O}}} it runs to completion. {{{ module Main where import Control.Concurrent.Async main :: IO () main = test 100 test :: Int -> IO () test s = do mapM_ wait =<< mapM b [0 .. s] where b _ = async $ return () }}} valgrind and gdb indicate that an invalid read in threadPaused is causing this: {{{ $ valgrind ./Tests ==17550== Memcheck, a memory error detector ==17550== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==17550== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==17550== Command: ./Tests ==17550== ==17550== Invalid read of size 4 ==17550== at 0x46C2BE: threadPaused (ThreadPaused.c:223) ==17550== by 0x48FC72: stg_returnToSched (in /tmp/xxx/Tests) ==17550== Address 0x1f is not stack'd, malloc'd or (recently) free'd ==17550== ==17550== ==17550== Process terminating with default action of signal 11 (SIGSEGV) ==17550== Access not within mapped region at address 0x1F ==17550== at 0x46C2BE: threadPaused (ThreadPaused.c:223) ==17550== by 0x48FC72: stg_returnToSched (in /tmp/xxx/Tests) ==17550== If you believe this happened as a result of a stack ==17550== overflow in your program's main thread (unlikely but ==17550== possible), you can try to increase the size of the ==17550== main thread stack using the --main-stacksize= flag. ==17550== The main thread stack size used in this run was 8388608. ==17550== ==17550== HEAP SUMMARY: ==17550== in use at exit: 76,884 bytes in 34 blocks ==17550== total heap usage: 53 allocs, 19 frees, 81,122 bytes allocated ==17550== ==17550== LEAK SUMMARY: ==17550== definitely lost: 0 bytes in 0 blocks ==17550== indirectly lost: 0 bytes in 0 blocks ==17550== possibly lost: 0 bytes in 0 blocks ==17550== still reachable: 76,884 bytes in 34 blocks ==17550== suppressed: 0 bytes in 0 blocks ==17550== Rerun with --leak-check=full to see details of leaked memory ==17550== ==17550== For counts of detected and suppressed errors, rerun with: -v ==17550== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 3) Segmentation fault (core dumped) }}} {{{ (gdb) run Starting program: /tmp/xxx/Tests warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x000000000046c2be in threadPaused (cap=0x6f5dc0 , tso=0x7ffff6b05390) at rts/ThreadPaused.c:223 223 switch (info->i.type) { (gdb) info locals frame = 0x7ffff6b050f0 info = 0xf bh_info = 0x4779fe bh = 0x7ffff6b10790 stack_end = 0x7ffff6b05390 words_to_squeeze = 0 weight = 0 weight_pending = 9 prev_was_update_frame = rtsFalse }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 15:15:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 15:15:08 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.44a939ca000c01f6ababe7aa3aa31b41@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.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 --------------------------------------------+------------------------------ Comment (by archblob): Simon Marlow confirmed my suspicions on irc, and guided me to either testsuite/tests/perf/compiler or nofib for large files on which to benchmark. I have attached the -pa output on several files from the testsuite and i see no differences that stand out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 22:05:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 22:05:39 -0000 Subject: [GHC] #9130: Segmentation fault in ThreadPaused.c:223 when compiled with -O In-Reply-To: <042.2152cafa14f5b78ade36a176855acf11@haskell.org> References: <042.2152cafa14f5b78ade36a176855acf11@haskell.org> Message-ID: <057.ebf0bf99ed9cdd4b772adcbb7b53c48e@haskell.org> #9130: Segmentation fault in ThreadPaused.c:223 when compiled with -O -----------------------------------+---------------------------------- Reporter: twi | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 7.8.2 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 ezyang): I cannot reproduce on HEAD (7d958ce323e3433c9e996e1a240a5741bfcfc341). {{{ [ezyang at hs01 ghc-validate]$ cabal install --with-ghc=/home/hs01/ezyang /ghc-validate/inplace/bin/ghc-stage2 async Resolving dependencies... Configuring stm-2.4.3... Building stm-2.4.3... Preprocessing library stm-2.4.3... [ 1 of 10] Compiling Control.Sequential.STM ( Control/Sequential/STM.hs, dist/build/Control/Sequential/STM.o ) [ 2 of 10] Compiling Control.Concurrent.STM.TBQueue ( Control/Concurrent/STM/TBQueue.hs, dist/build/Control/Concurrent/STM/TBQueue.o ) [ 3 of 10] Compiling Control.Concurrent.STM.TQueue ( Control/Concurrent/STM/TQueue.hs, dist/build/Control/Concurrent/STM/TQueue.o ) [ 4 of 10] Compiling Control.Concurrent.STM.TChan ( Control/Concurrent/STM/TChan.hs, dist/build/Control/Concurrent/STM/TChan.o ) [ 5 of 10] Compiling Control.Concurrent.STM.TMVar ( Control/Concurrent/STM/TMVar.hs, dist/build/Control/Concurrent/STM/TMVar.o ) [ 6 of 10] Compiling Control.Concurrent.STM.TVar ( Control/Concurrent/STM/TVar.hs, dist/build/Control/Concurrent/STM/TVar.o ) [ 7 of 10] Compiling Control.Concurrent.STM.TArray ( Control/Concurrent/STM/TArray.hs, dist/build/Control/Concurrent/STM/TArray.o ) [ 8 of 10] Compiling Control.Monad.STM ( Control/Monad/STM.hs, dist/build/Control/Monad/STM.o ) [ 9 of 10] Compiling Control.Concurrent.STM ( Control/Concurrent/STM.hs, dist/build/Control/Concurrent/STM.o ) [10 of 10] Compiling Control.Concurrent.STM.TSem ( Control/Concurrent/STM/TSem.hs, dist/build/Control/Concurrent/STM/TSem.o ) In-place registering stm-2.4.3... Installing library in /home/u1/ezyang/.cabal/lib/x86_64-linux-ghc-7.9.20140520/stm-2.4.3 Registering stm-2.4.3... Installed stm-2.4.3 Configuring async-2.0.1.5... Building async-2.0.1.5... Preprocessing library async-2.0.1.5... [1 of 1] Compiling Control.Concurrent.Async ( Control/Concurrent/Async.hs, dist/build/Control/Concurrent/Async.o ) In-place registering async-2.0.1.5... Installing library in /home/u1/ezyang/.cabal/lib/x86_64-linux-ghc-7.9.20140520/async-2.0.1.5 Registering async-2.0.1.5... Installed async-2.0.1.5 [ezyang at hs01 ghc-validate]$ vim Tests.hs ld/Control/Concurrent/STM/TArray.o ) [ 8 of 10] Compiling Control.Monad.STM ( Control/Monad/STM.hs, dist/build/Control/Monad/STM.o ) [ 9 of 10] Compiling Control.Concurrent.STM ( Control/Concurrent/STM.hs, dist/build/Control/Concurrent/STM.o ) [10 of 10] Compiling Control.Concurrent.STM.TSem ( Control/Concurrent/STM/TSem.hs, dist/build/Control/Concurrent/STM/TSem.o ) In-place registering stm-2.4.3... Installing library in /home/u1/ezyang/.cabal/lib/x86_64-linux-ghc-7.9.20140520/stm-2.4.3 Registering stm-2.4.3... Installed stm-2.4.3 Configuring async-2.0.1.5... Building async-2.0.1.5... Preprocessing library async-2.0.1.5... [1 of 1] Compiling Control.Concurrent.Async ( Control/Concurrent/Async.hs, dist/build/Control/Concurrent/Async.o ) In-place registering async-2.0.1.5... Installing library in /home/u1/ezyang/.cabal/lib/x86_64-linux-ghc-7.9.20140520/async-2.0.1.5 Registering async-2.0.1.5... Installed async-2.0.1.5 [ezyang at hs01 ghc-validate]$ vim Tests.hs [ezyang at hs01 ghc-validate]$ inplace/bin/ghc-stage2 --make -fforce-recomp -O Tests [1 of 1] Compiling Main ( Tests.hs, Tests.o ) Linking Tests ... [ezyang at hs01 ghc-validate]$ ./Tests [ezyang at hs01 ghc-validate]$ valgrind ./Tests ==24993== Memcheck, a memory error detector ==24993== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==24993== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==24993== Command: ./Tests ==24993== ==24993== ==24993== HEAP SUMMARY: ==24993== in use at exit: 4,108 bytes in 2 blocks ==24993== total heap usage: 51 allocs, 49 frees, 64,682 bytes allocated ==24993== ==24993== LEAK SUMMARY: ==24993== definitely lost: 0 bytes in 0 blocks ==24993== indirectly lost: 0 bytes in 0 blocks ==24993== possibly lost: 0 bytes in 0 blocks ==24993== still reachable: 4,108 bytes in 2 blocks ==24993== suppressed: 0 bytes in 0 blocks ==24993== Rerun with --leak-check=full to see details of leaked memory ==24993== ==24993== For counts of detected and suppressed errors, rerun with: -v ==24993== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 20 22:07:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 May 2014 22:07:14 -0000 Subject: [GHC] #9131: Experiment with a dedicated solver for Coercible Message-ID: <046.fb02102a150822314d950303bdd7564a@haskell.org> #9131: Experiment with a dedicated solver for Coercible ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This is something that I might want to do some time; it should not distract us from working and improving the current design and implementation. But I think it should be explored. Currently `Coercible` appears as a type class, we have instances to explain it, and use the existing solver to solve them. The last part sometimes causes problems: * the order the instances are tried matters, there might be dead ends (#9117) * recursive newtypes are not handled as good as they could be. It would be worth exploring if a dedicated solver for `Coercible` constraints could solve these issues. It could replace the existing `getCoercibleInst`. Given a constraint `Coercible s t` it would solve it completely, do nothing or (and this is not planned out yet) return some sufficient and in some sense primitive constraint that should appear in inferred type signatures etc. Ideally we could still explain `Coercible` in terms of the instances written in the ICFP?14 paper, and simply state ?GHC will find a solution using these instances, if there are any.? instead of ?The usual solver is employed, it might run into dead ends (or not, hard to tell).? When tackling this task, I should do something that I keep postponing (because I don?t like to admit my lack of knowlege about that) but I think is really important: What are the theoretical properties of solving `Coercible` constraints? Is it even decidable? Semi decidable? Are there existing standard algorithms? How does this relate to SMT solving? And why don?t I know these things... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 21 01:32:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 May 2014 01:32:15 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible Message-ID: <051.252bf456ce6fe936293a4484081567fb@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: fusion | 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: | -------------------------------------+------------------------------------- takeWhile is not still fusible, 2 1/2 years after this report: http://www.haskell.org/pipermail/glasgow-haskell- users/2011-December/021299.html The discussion suggests making takeWhile a good producer/consumer with foldr/build fusion: takeWhile' :: (a -> Bool) -> [a] -> [a] takeWhile' p xs = build $ \c n -> foldr (takeWhileF p c n) n xs {-# INLINE takeWhile' #-} takeWhileF p c n x xs = if p x then x `c` xs else n Furthermore, the discussion suggests having rewrite rules to go to this version and then rewrite back (if fusion fails). The report also mentions concatMap (which is a separate known problem). It also mentions drop and dropWhile, but I don't see when they perform allocations, so I think that's an erroneous request. I experienced the bug on GHC 7.6.3, but it seems still there in base-4.7.0.0, judging from the source: http://hackage.haskell.org/package/base-4.7.0.0/docs/src/GHC- List.html#takeWhile -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 21 06:57:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 May 2014 06:57:29 -0000 Subject: [GHC] #7505: Commentary shipped with GHC sources is outdated In-Reply-To: <048.1cd7fed045284a41827f21479206b9aa@haskell.org> References: <048.1cd7fed045284a41827f21479206b9aa@haskell.org> Message-ID: <063.2387adeda40fca52f7a2520cf278f732@haskell.org> #7505: Commentary shipped with GHC sources is outdated --------------------------------------+------------------------------------ Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by jstolarek): * status: new => closed * resolution: => fixed Comment: This was fixed by 0960a37868e6d08857e86465c8ca346b29b1c813. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 21 07:11:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 May 2014 07:11:14 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.751667f1e44e2c9e6e7ddfec5ac12628@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion 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: -------------------------------------+------------------------------------- Changes (by nomeata): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 21 07:13:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 May 2014 07:13:29 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.f6e9084d86307a09389fa7f3de4e9071@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion 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: -------------------------------------+------------------------------------- Comment (by nomeata): I think the request got stuck after ?Please submit a patch? ? ?Will do?. So, whose up for writing a patch? (I?ll put the ticket on the suitable- tickets-for-[wiki:ZuriHac2014] list). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 21 07:15:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 May 2014 07:15:38 -0000 Subject: [GHC] #9046: Panic in GHCi when using :print In-Reply-To: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> References: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> Message-ID: <060.f0c735f52460a873903ff95dab8f45d4@haskell.org> #9046: Panic in GHCi when using :print -------------------------------------+------------------------------------ Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by chris.parks): I'm seeing the same thing on x86_64-apple-darwin in GHC HEAD: {{{ > :t _t1 ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20140520 for x86_64-apple-darwin): ASSERT failed! file compiler/typecheck/TcType.lhs line 640 t }}} That ASSERT is in `isMetaTyVar`: {{{ isMetaTyVar tv = ASSERT2( isTcTyVar tv, ppr tv ) case tcTyVarDetails tv of MetaTv {} -> True _ -> False }}} We're expecting that `tv` was constructed by the `TcTyVar` constructor of the `Var` datatype. However, what little printf-debugging I've been able to do indicates that we're getting a plain `TyVar` instead. Maybe someone with more debugging experience can shed some light on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 21 07:53:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 May 2014 07:53:01 -0000 Subject: [GHC] #9131: Experiment with a dedicated solver for Coercible In-Reply-To: <046.fb02102a150822314d950303bdd7564a@haskell.org> References: <046.fb02102a150822314d950303bdd7564a@haskell.org> Message-ID: <061.b9083ec47d394573a9ae397c2bd92ef1@haskell.org> #9131: Experiment with a dedicated solver for Coercible -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.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 nomeata): > What are the theoretical properties of solving Coercible constraints? Is it even decidable? Semi decidable? Are there existing standard algorithms? How does this relate to SMT solving? And why don?t I know these things... Pondering this a bit, I think it is unsolvable, as we can encode the problem of whether two simply typed lambda terms with fix are equivalent. (It?s simply typed because our types are kinded). For `fix :: (* -> *) -> *`, we need {{{ newtype Fix1 f = Fix1 (f (Fix1 f)) }}} (and similar code for `fix` at higher types). So given a lambda expression, we do full lambda lifting to give the lambdas names, eta-expand according to their type and turn them into newtypes. {{{ module Lambda where import Data.Coerce newtype Fix1 f = Fix1 (f (Fix1 f)) newtype Fix2 f x = Fix2 (f (Fix2 f) x) -- lambda terms -- a = ? f. ? y. f (f y) :: (* -> *) -> * -> * -- b = ? f. ? y. fix (? x. f x) :: (* -> *) -> * -> * -- lambda lifted -- a1 f y = f (f y) -- a f = a1 f -- b1 f x = f x -- b2 f y = fix (b1 f) -- b f = b2 f -- The newtypes newtype A1 f y = A1 (f (f y)) newtype A y x = A (A1 y x) newtype B1 f x = B1 (f x) newtype B2 f y = B2 (Fix1 (B1 f)) newtype B f x = B (B2 f x) -- Querying equivalence (Passing types with representational arguments as -- parameters so that the solver doesn't stop at `Coercible (f ...) (f ...)` ex :: A Maybe () -> B Maybe () ex = coerce }}} This is not fully worked out yet, but it seems to be reasonable to assume that our `Coercible` solver will never be complete and we?ll live with some shortcomings anyways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 21 10:11:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 May 2014 10:11:10 -0000 Subject: [GHC] #9045: threads006: internal error: scavenge_stack: weird activation record found on stack: 415597384 In-Reply-To: <047.0aa4066036390bb00a4e5f6d7de13d4a@haskell.org> References: <047.0aa4066036390bb00a4e5f6d7de13d4a@haskell.org> Message-ID: <062.de02f7d6df403eaeef167265e3eb174c@haskell.org> #9045: threads006: internal error: scavenge_stack: weird activation record found on stack: 415597384 -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8866 -------------------------------------+------------------------------------ Comment (by edsko): For what it's worth, I discovered another fairly minimal example where this happens. It may or may not be useful, mentioning it here just in case. See the Postscript of http://www.well-typed.com/blog/94/. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 21 13:29:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 May 2014 13:29:13 -0000 Subject: [GHC] #9133: Improve parser error reporting in `ghc-pkg` Message-ID: <042.589ce745aa2aedb1e720940256bec0a9@haskell.org> #9133: Improve parser error reporting in `ghc-pkg` ------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: ghc-pkg | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Here's what I was confronted recently due to a broken sandbox environment: {{{ $ cabal info parsec cabal: ghc-pkg: Data.Binary.Get.runGet at position 9583: demandInput: not enough bytes }}} The main problem is that this message is not very helpful (other than telling that `ghc-pkg` wasn't able to do something). Duncan told me, that the recent `binary` API now provides better facilities for error reporting. That could be used to improve the UI of `ghc-pkg` when reporting errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 21 13:50:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 May 2014 13:50:10 -0000 Subject: [GHC] #9131: Experiment with a dedicated solver for Coercible In-Reply-To: <046.fb02102a150822314d950303bdd7564a@haskell.org> References: <046.fb02102a150822314d950303bdd7564a@haskell.org> Message-ID: <061.ad1ae8097af85543ab18903955a92540@haskell.org> #9131: Experiment with a dedicated solver for Coercible -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.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 goldfire): Hmmm... this makes sense. Solving for a `Coercible` constraint involves "looking through" newtypes, which may be recursive. This is analogous to the situation with type families, where we require `UndecidableInstances` to do this sort of thing. For good reasons, we can't require `UndecidableInstances` for recursive newtypes. I'm not sure what the best solution here is, though. A part of me would like to define some subset of this problem for which we guarantee completeness (perhaps this subset is "non-recursive newtypes"), not unlike with type families. Good idea to pursue this line. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 21 14:07:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 May 2014 14:07:31 -0000 Subject: [GHC] #3719: Literate code with # In-Reply-To: <046.119383e131eabeee5d5ffb7da02e279e@haskell.org> References: <046.119383e131eabeee5d5ffb7da02e279e@haskell.org> Message-ID: <061.51f47f13319b90adbaba1ef240725327@haskell.org> #3719: Literate code with # ----------------------------------------------+---------------------------- Reporter: zenzike | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by heisenbug): * difficulty: => Unknown Comment: `unlit` already has shebang filtering: https://github.com/ghc/ghc/blob/master/utils/unlit/unlit.c#L184 Why not give a `-filter-cpp` option to it, so that all lines with whitespace followed by '#' are filtered out? Then GHC (when invoked with -XNoCPP) would just pass on `-filter-cpp` to `unlit`. My use-case is an `emacs` org-mode document with embedded literate Haskell like this: {{{ #+begin_src literate-haskell > expr2final :: (Arith' repr, Cond repr) => Expr a -> repr a > expr2final (Lit i) = lit' i > expr2final (e `Plus` e') = expr2final e `plus'` expr2final e' > expr2final (e `Cmp` e') = expr2final e `cmp` expr2final e' > expr2final (If c e e') = if' (expr2final c) (expr2final e) (expr2final e') #+end_src }}} This results in the same error {{{ lexical error at character '+' }}} and is pretty annoying. Org-mode expects the '#' int the first column, so indenting does not help here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 21 14:24:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 May 2014 14:24:23 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.2ce04463d2ab56f28ac34f9be9ce331f@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): I agree with everything Simon said. About hand-written instances of `Representational`: We need some facility for this. For example, take `ReaderT`: {{{ newtype ReaderT r m a = ReaderT (r -> m a) }}} `ReaderT` gets roles R, R, N. But, this instance is sensible: {{{ instance Representational m => Representational (ReaderT r m) }}} I suppose it wouldn't be beyond possibility to beef up the role inference algorithm to spit out such `Representational` instances. Or, we could require that users request such instances (with a standalone `deriving` perhaps) but fill in the details automatically. If we do allow users to write their own instances, we seem to lose the guarantee that `coerce` is free at runtime, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 21 14:25:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 May 2014 14:25:45 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.598b21425501409637eafc02690e5251@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): While we're thinking about this, is it at all worthwhile to have a `Phantom` class analogous to `Representational`? My first thought is "no, not until someone shouts." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 21 14:33:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 May 2014 14:33:02 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.9ecb38d5c901b8170cffe78454bec22c@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 nomeata): > If we do allow users to write their own instances, we seem to lose the guarantee that coerce is free at runtime, no? Did anyone say guarantee? It?s a promise, not more :-) What I?m saying: By passing around boxed `Coercible` witnesses (e.g. in the `Coercion` data type) you can probably create quite complex terms that the compiler will not be able to simplify completely. Then `coerce` still incurs the cost of evaluating that box. So I would not worry that a ill- meaning user can make `coerce` expensive by writing strange `Representational` instances, as long as he can write good instances where there are good instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 21 15:49:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 May 2014 15:49:26 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.05c072d5d161778a663b1e617f628491@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.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 --------------------------------------------+------------------------------ Comment (by archblob): In fixing {{{:kind}}} we just have to also tidy the type because currently it's not for some reason. I could patch that by setting {{{-fprint- explicit-foralls}}}, {{{-fprint-expicit-kinds}}} and printing thorough {{{pprTypeForUser}}} but I remember that you mentioned something about removing tidying from {{{pprTypeForUser}}} so I would like some input on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 01:57:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 01:57:34 -0000 Subject: [GHC] #9134: ghci: internal error: PAP object entered! Message-ID: <048.b921f3efffe30ffce5b18894d1c401d4@haskell.org> #9134: ghci: internal error: PAP object entered! ------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- {{{ : internal error: PAP object entered! (GHC version 7.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} I am doing development in ghci as described here: https://github.com/chrisdone/ghci-reload-demo I startup ghci from a cabal sandbox with: `cabal repl --ghc-options="-O0 -fobject-code"` I see this error every once in a while. I do not have a reproducible test case, but if I see this when working on a smaller project I can try to create one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 01:58:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 01:58:15 -0000 Subject: [GHC] #9134: internal error: PAP object entered! (was: ghci: internal error: PAP object entered!) In-Reply-To: <048.b921f3efffe30ffce5b18894d1c401d4@haskell.org> References: <048.b921f3efffe30ffce5b18894d1c401d4@haskell.org> Message-ID: <063.1feb90c690a1abf4394ec45981c1b11d@haskell.org> #9134: internal error: PAP object entered! -------------------------------------+------------------------------------ Reporter: GregWeber | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.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 GregWeber): * cc: hvr (added) * component: Compiler => GHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 07:41:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 07:41:15 -0000 Subject: [GHC] #9106: GHC Panic related to functional dependencies - kindFunResult In-Reply-To: <044.0aafcc9fc1a20555c529d9fed2d8ec4a@haskell.org> References: <044.0aafcc9fc1a20555c529d9fed2d8ec4a@haskell.org> Message-ID: <059.990b6b316f04c93dc0c72b19f8761fbe@haskell.org> #9106: GHC Panic related to functional dependencies - kindFunResult ---------------------------------------+--------------------------- Reporter: yuriy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): The type family version also works: {{{ {-# LANGUAGE DataKinds, FlexibleInstances, MultiParamTypeClasses, PolyKinds, ScopedTypeVariables, TypeFamilies, TypeOperators, UndecidableInstances #-} module FunctorN where import GHC.TypeLits data Proxy (a :: k) = Proxy type family F n f a where F 0 f a = a F n f a = f (F (n-1) f a) class F n f a ~ fa => FunctorN n f a fa where fmapn :: Proxy n -> Proxy f -> (a -> a) -> fa -> fa instance FunctorN 0 f a a where fmapn _ _ a = a instance ( Functor f, FunctorN (n-1) f a fa, F (n - 1) f a ~ fa , F n f a ~ f fa) => FunctorN n f a (f fa) where fmapn _ pf f = fmap (fmapn (Proxy :: Proxy (n-1)) pf f) test :: Maybe (Maybe (Maybe Int)) test = fmapn (Proxy :: Proxy 3) (Proxy :: Proxy Maybe) (+1) (Just (Just (Just 3))) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 07:57:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 07:57:43 -0000 Subject: [GHC] #9131: Experiment with a dedicated solver for Coercible In-Reply-To: <046.fb02102a150822314d950303bdd7564a@haskell.org> References: <046.fb02102a150822314d950303bdd7564a@haskell.org> Message-ID: <061.4c3e0ba8cadd1c863b5369390a5d428c@haskell.org> #9131: Experiment with a dedicated solver for Coercible -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.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 simonpj): In effect we already ''have'' a separate solver, namely special-purpose handling of the `Coercible` constraints, which works interleaved with the current one. Interleaving is good because the two interact. I'm not sure that anything would be gained by separating them out. Though perhaps the code could be separated in a more modular fashion. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 08:07:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 08:07:27 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.b93b94cd7fc7114fd622abd52bfb1753@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion 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: -------------------------------------+------------------------------------- Comment (by simonpj): Joachim is right. Things get fixed when someone decides to fix them! In this case the fix is not hard, but needs a clean `nofib` comparision run to make sure that there are no performance regressions; and preferably a performance test we can add to `testsuite/perf` to check that the fusion really does happen. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 08:11:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 08:11:32 -0000 Subject: [GHC] #9131: Experiment with a dedicated solver for Coercible In-Reply-To: <046.fb02102a150822314d950303bdd7564a@haskell.org> References: <046.fb02102a150822314d950303bdd7564a@haskell.org> Message-ID: <061.bab32d4d1c29a55a350d6f2bef9b7bae@haskell.org> #9131: Experiment with a dedicated solver for Coercible -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.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 nomeata): > In effect we already have a separate solver, namely special-purpose handling of the Coercible constraints, which works interleaved with the current one. I?d disagree. What we have is a custom lookup routine that creates the instances on demand instead of looking them up in the instance environment (and chooses one if there are several, i.e. the issue of ordering). How the instances are used to solve a constraint is still up to the general code, nothing `Coercible`-specific in there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 08:29:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 08:29:18 -0000 Subject: [GHC] #9130: Segmentation fault in ThreadPaused.c:223 when compiled with -O In-Reply-To: <042.2152cafa14f5b78ade36a176855acf11@haskell.org> References: <042.2152cafa14f5b78ade36a176855acf11@haskell.org> Message-ID: <057.fee6a7aa5c6be0876b652b7133a5be75@haskell.org> #9130: Segmentation fault in ThreadPaused.c:223 when compiled with -O -----------------------------------+---------------------------------- Reporter: twi | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: Fails in 7.8.2 but not in HEAD; I suspect this is #9045. Please test with the 7.8.3 RC when it comes out and re-open if it still fails. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 09:15:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 09:15:09 -0000 Subject: [GHC] #9106: GHC Panic related to functional dependencies - kindFunResult In-Reply-To: <044.0aafcc9fc1a20555c529d9fed2d8ec4a@haskell.org> References: <044.0aafcc9fc1a20555c529d9fed2d8ec4a@haskell.org> Message-ID: <059.5ecf867d5f22f4c54bf318b7b154d4c8@haskell.org> #9106: GHC Panic related to functional dependencies - kindFunResult ---------------------------------------+--------------------------- Reporter: yuriy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): I'm working on this... I know more or less what's happening. Thanks for the examples -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 09:19:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 09:19:14 -0000 Subject: [GHC] #9131: Experiment with a dedicated solver for Coercible In-Reply-To: <046.fb02102a150822314d950303bdd7564a@haskell.org> References: <046.fb02102a150822314d950303bdd7564a@haskell.org> Message-ID: <061.a9b7731e19bfc0a7289d77ca06f1c73a@haskell.org> #9131: Experiment with a dedicated solver for Coercible -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.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 simonpj): We are mostly arguing terminology here. Most solvers work by saying "let me take this goal, and solve it by breaking it up into sub-goals and solving those". That's exactly what the `Coercible`-specific code does here. You do not need to use that language of "instances" unless you want to. What the current solver does ''not'' do is ''search'', exploring many different paths to solving the goal. And indeed search is problemantic when combined with the need to infer a substitution for unification variables. Anyway, we don't need to discuss terminology! This ticket is really about whether a different solution strategy would be better. And thus far I don't see any candidates on the table. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 09:20:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 09:20:50 -0000 Subject: [GHC] #9131: Experiment with a dedicated solver for Coercible In-Reply-To: <046.fb02102a150822314d950303bdd7564a@haskell.org> References: <046.fb02102a150822314d950303bdd7564a@haskell.org> Message-ID: <061.3522bfe43b5d277af63b6bbf89cee2d4@haskell.org> #9131: Experiment with a dedicated solver for Coercible -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.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 nomeata): > This ticket is really about whether a different solution strategy would be better. Agreed :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 13:03:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 13:03:57 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.da4c8b440c456a6e0a04e0e07e8cf447@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion 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: -------------------------------------+------------------------------------- Comment (by Blaisorblade): Thanks for your answer! And sorry if I complained. I hope having a ticket already helps, but I've also given a try at "reproducing the (++) scheme" (following also map, where the scheme is clearer). For now I hacked it in a separate file, and I could verify that fusion still happens in my example. (And that tweaking even small things has nontrivial effects). Does the below make enough sense to go on? If so, the next main step (for me, or anybody who beats me) is just learning how to rebuild GHC and run nofib. {{{ module IntToString where import Prelude hiding (takeWhile) import GHC.Exts --takeWhile' :: (a -> Bool) -> [a] -> [a] --takeWhile' p xs = build $ \c n -> foldr (takeWhileFB p c n) n xs --{-# INLINE takeWhile' #-} -- But this is a foldr, while takeWhile should be a foldl! takeWhileFB p c n x xs = if p x then x `c` xs else n {-# INLINE [0] takeWhileFB #-} {-# NOINLINE [1] takeWhile #-} -- We want the RULE to fire first. takeWhile :: (a -> Bool) -> [a] -> [a] takeWhile _ [] = [] takeWhile p (x:xs) | p x = x : takeWhile p xs | otherwise = [] {- -- STUPID "takeWhile/backBad" [1] forall p xs. takeWhile' p xs = takeWhile p xs -} -- Why can't I use, on the RHS, a function I mark with INLINE such as takeWhile' above? If I do that, the final program contains takeWhile. Probably just a phase ordering problem. {-# RULES "takeWhile/fuse" [~1] forall p xs. takeWhile p xs = build $ \c n -> foldr (takeWhileFB p c n) n xs "takeWhile/back" [1] forall p xs. foldr (takeWhileFB p (:) []) [] xs = takeWhile p xs #-} toChar digit = toEnum $ digit + fromEnum '0' intToString i = if i < 0 then '-' : digits else digits where digits = reverse . map (toChar . (`mod` 10)) . takeWhile (/=0) . iterate (`div` 10) . abs $ i }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 13:34:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 13:34:56 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.e9746b7f474165f90d1095cc1a49fe5f@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion 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: -------------------------------------+------------------------------------- Comment (by nomeata): Looks ok, so if you want go ahead with building GHC and running nofib. BTW, wat do you mean by > But this is a foldr, while takeWhile should be a foldl! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 15:47:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 15:47:06 -0000 Subject: [GHC] #9135: readProcessWithExitCode leaks when the program does not exist Message-ID: <044.d94b762093486fb03a7765d4a9e7d317@haskell.org> #9135: readProcessWithExitCode leaks when the program does not exist -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{#!haskell import Control.Monad import System.Process import qualified Control.Exception as C try' :: IO a -> IO (Either C.SomeException a) try' = C.try main = replicateM_ 1000 $ do try' (readProcessWithExitCode "doesnotexist" [] "") print =<< try' (readProcessWithExitCode "/bin/echo" ["it works"] "") }}} This eventually runs out of file descriptors and fails to start the existing process. Tested with process 1.2.0.0 and GHC 7.8.2 on OS X -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 16:02:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 16:02:10 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.2b50ae124738819de1691989166a8d68@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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): * cc: ekmett@? (added) Comment: Adding Edward in cc. How bad would it be to leave `join` out of `Monad`, for now at any rate, so that we can get AMP implemented? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 19:03:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 19:03:27 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.b8cbcbb7ce7748efd3e3a7a9c9fa331c@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): Just wrote up [wiki:Roles2 this wiki page] describing the design and laying out some challenges. The page includes a pie-in-the-sky idea for a new design for roles that might fix this problem, at the cost of quite a bit more complexity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 19:53:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 19:53:09 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.ab3161a62b27d7756c987032d6be93b6@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): You've revealed yet another interesting characteristic of this algorithm. The order ''of the coercion'' matters! Here is my test case: {{{ newtype Rec a = Rec (Rec a) newtype Hide a = Hide (Rec a) ex :: Hide Age -> Rec Int ex = coerce }}} (Note -- no module boundary.) This example (on GHC 7.8.2, without the updated solver earlier in this ticket) works fine. If I reverse the order of the coercion, though, it fails. This, of course, makes sense when thinking about the implementation, but it's weird if you don't think about that. This is all suggesting to me that the "correct" thing to do when recursion gets out of hand is not to immediately fail, but to try other techniques. I know this idea violates the maxim of "do no search", but I'm not sure what's so terrible about searching here. Getting back to your example, I posit that, with my ordering above (`Hide Int -> Rec Age`) the new solver will fail. This makes the new solver less (not?) dependent on coercion order. Is that better? Perhaps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 20:04:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 20:04:04 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.0dce4aedb873c39c0aa34c5569d1adf0@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): I'm disinclined to get bent out of shape by pathologically recursive newtypes. Whereas the place this ticket started was with more reasonable cases. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 20:18:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 20:18:55 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.e6285f9b322e8dbb244ce11ff01e79ea@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): Fair enough. I believe any of these problems exist with non-pathologically recursive newtypes, such as my `Bar` example in comment:21. But, I'm also happy enough to say "caveat programmer" if they use recursive newtypes with `Coercible`. We should make sure to say that somewhere, though. If we neglect recursive newtypes (which is reasonable, I would say) then the reordered solver (as it is in HEAD, as I understand) seems better than the one released with 7.8.2. But, how are we faring on the original request at the top? PS: Just realized that I never contributed to the wiki page. Will do shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 20:24:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 20:24:53 -0000 Subject: [GHC] #9128: Possible bug in strictness analyzer when where clause declared NOINLINE In-Reply-To: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> References: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> Message-ID: <060.3d7fc1723a7bd8a3092baf9ec0736f84@haskell.org> #9128: Possible bug in strictness analyzer when where clause declared NOINLINE ---------------------------------+----------------------------------------- Reporter: aalevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: strictness bytestring Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: Blocking: | ---------------------------------+----------------------------------------- Changes (by aalevy): * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 20:30:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 20:30:09 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.24afb7c5bac847aa7dab73b12197c537@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): OK. Added section on [http://www.haskell.org/haskellwiki/GHC/Coercible the wiki page] about recursive newtypes. Let me know if there's something else that should be there -- I think Joachim addressed the other salient points well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 23:01:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 23:01:03 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.17a3962a37454cb55bbbbff111ff7898@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 altaic): * difficulty: => Unknown Comment: It appears that the LLVM IR now includes function prefix data: http://llvm.org/docs/LangRef.html#prefix-data Background: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-February/047514.html http://www.haskell.org/pipermail/ghc-devs/2013-September/002565.html http://llvm.org/bugs/show_bug.cgi?id=14080 http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of- Mon-20130909/188042.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 22 23:15:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 May 2014 23:15:36 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.14da95421df1a3a3e7b67fac63083b37@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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): Nice catch! Perhaps I'll try putting together a patch for this in the coming weeks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 00:07:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 00:07:33 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.a3320d35129c69849c02d1c78260299a@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 altaic): I just had a look at the llvm codegen and this looks pretty simple to implement. If I've got some time in the next couple days, I may have a crack at it. On a related note, is there any interest in using the llvm api directly in the back end? If so, I can write up another ticket for that. I suspect that it would result in a bit of a speed up. The easiest method would be to depend on one of the llvm bindings, though I don't know if that's acceptable in ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 00:35:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 00:35:37 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.4335be63c815a707526146f462537924@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 ekmett): Richard, The asymmetry is annoying but without it you cannot write the lifting for `Representational (StateT s m)`. I started without it for the same reason you dislike it and added it only when forced. Simon, As for dropping join for now I'd be sad to see it lost, but if we at least commit to seeking a solution to this problem, I'd be personally okay with sacrificing it for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 01:11:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 01:11:23 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.877394ecb4b53a2b388b27232ce00bb5@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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): Looking at the semantics of LLVM's prefix data concept, it seems like it doesn't map terribly well on to our use-case. Namely, the `prefix` attribute allows you to prepend arbitrary data to the beginning of the symbol's definition. While we would want LLVM to place the symbol's address after info table, naive use of prefix data would produce symbols pointing at the beginning of each function's info table. The documentation suggests that this is supposed to be worked around by beginning the prefix data with a trampoline to jump to the true beginning of the symbol. Given we already have a hack that works, I don't see any good reason to implement this hack. However, when used with another pending LLVM [feature](http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061511.html) allowing an offset to be applied to a symbol's address prefix data will become much more useful. I suggest we hold off on using LLVM's prefix data until this has been implemented. Unfortunately, it seems that the proposal is more than a year old with no activity but I can try to resuscitate it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 03:40:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 03:40:36 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.7c1d1742f8213eaf273b5e1a09fd0b32@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 altaic): Not necessarily, I think. Sure, the symbols point to the beginning of the prefix data rather than the function body, however twiddling the symbol table is a lot easier than mangling the whole assembly file. Coincidentally, using the LLVM API allows us mutable access to the symbol table among other things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 05:12:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 05:12:40 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.63c15b7c92d4fb6a73fd9514d927a0fe@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 awson): I'm extremely sorry for a kind of OT. There is another LLVM/infotable related ticket, which I don't know how to solve [https://ghc.haskell.org/trac/ghc/ticket/8974 without the mangler]. Could you, please, look into it and check if we can fix that without mangler or, perhaps, understand what a feature we could ask LLVM people to introduce. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 06:49:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 06:49:19 -0000 Subject: [GHC] #9106: GHC Panic related to functional dependencies - kindFunResult In-Reply-To: <044.0aafcc9fc1a20555c529d9fed2d8ec4a@haskell.org> References: <044.0aafcc9fc1a20555c529d9fed2d8ec4a@haskell.org> Message-ID: <059.46e162dadf7416e6470afc7b4cb3554c@haskell.org> #9106: GHC Panic related to functional dependencies - kindFunResult ---------------------------------------+--------------------------- Reporter: yuriy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+--------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d8d97113c24e7216be36c9cdfc58e91f26528f06/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d8d97113c24e7216be36c9cdfc58e91f26528f06" Make the unifier a fixpoint even for the free kind vars of a tyvar The (pure) unifier tcUnifyTys returns an idempotent substitution. But previously the kinds of type variables free in the range of the subst could have un-substituted kind variables. This patch fixes that, fixing Trac #9106. See Note [Finding the substitution fixpoint] in Unify }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 07:54:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 07:54:37 -0000 Subject: [GHC] #9136: Constant folding in Core could be better Message-ID: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> #9136: Constant folding in Core could be better ------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Constant folding in Core is still a bit feeble. For example, when staring at the code for `nofib/shootout/k-nucleotide` I saw this expression: {{{ (x +# 8) -# 1 }}} which would be relatively easy to optimise. The difficulty is knowing where to stop. What about `(8 +# x) -# 1`? Anyway, this ticket is to record the issue. Currently constant folding is done by the built-in RULES in `compiler/prelude/PrelRules`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 08:07:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 08:07:45 -0000 Subject: [GHC] #9137: A way to match RULES only for literals Message-ID: <046.beaebd120563c793d8d6d0e627d6471a@haskell.org> #9137: A way to match RULES only for literals ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In `GHC/Enum` we have {{{ {-# RULES "enumDeltaToInteger1" [0] forall c n x . enumDeltaToIntegerFB c n x 1 = up_fb c n x 1 #-} -- This rule ensures that in the common case (delta = 1), we do not do the check here, -- and also that we have the chance to inline up_fb, which would allow the constructor to be -- inlined and good things to happen. -- We do not do it for Int this way because hand-tuned code already exists, and -- the special case varies more from the general case, due to the issue of overflows. }}} This rule would be useful for all literals, not just for `1`. I remember a discussion that such a rule would be more useful if we had a way to specify that, for example (random syntax). {-# RULES "enumDeltaToInteger1" [0] forall c n x d . isLiteral d => enumDeltaToIntegerFB c n x d = up_fb c n x d #-} I?m reporting this now to be able to link to it from #9136, where this feature might also help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 08:10:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 08:10:02 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.277790c75a5e64784498836af0691136@haskell.org> #9136: Constant folding in Core could be better --------------------------------------------+------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): That reminded me of something, so I filed #9137. If we had that we could specify create RULES like {{{ forall x y z. (isLiteral y, isLiteral z) => (x +# y) -# z = x +# (y -# z) forall x y z. (isLiteral y, isLiteral z) => (x -# y) -# z = x -# (y +# z) ... }}} that would rewrite the terms to have the literals next to each other. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 08:15:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 08:15:07 -0000 Subject: [GHC] #9138: Allow users to edit their own tickets Message-ID: <046.b3e5925750fb7dd4ccafa83e8bdf4ab9@haskell.org> #9138: Allow users to edit their own tickets ------------------------------------+------------------------------------- Reporter: nomeata | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Non-power-users can edit their own comments, but not their tickets. That is annoying when one makes mistakes in the syntax. There is a history of changes, so it really wouldn't be a problem to allow that. The required permissions according to [TracPermissions] seems to be `TICKET_EDIT_DESCRIPTION`. `TICKET_EDIT_CC` would also be useful (#8881), as I can put people on CC when I create a ticket, but I cannot change that later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 08:20:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 08:20:12 -0000 Subject: [GHC] #9106: GHC Panic related to functional dependencies - kindFunResult In-Reply-To: <044.0aafcc9fc1a20555c529d9fed2d8ec4a@haskell.org> References: <044.0aafcc9fc1a20555c529d9fed2d8ec4a@haskell.org> Message-ID: <059.5b002e05363e7a59cfd916a450f916e2@haskell.org> #9106: GHC Panic related to functional dependencies - kindFunResult ---------------------------------------+--------------------------- Reporter: yuriy | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: polykinds/T9106 | Blocked By: Blocking: | Related Tickets: ---------------------------------------+--------------------------- Changes (by simonpj): * status: new => merge * testcase: => polykinds/T9106 Comment: Thank you. I've fixed the crash. Now we get {{{ T9106.hs:13:10: Illegal instance declaration for ?FunctorN n f a (f fa)? The liberal coverage condition fails in class ?FunctorN? for functional dependency: ?n f a -> fa? Reason: lhs types ?n?, ?f?, ?a? do not jointly determine rhs type ?f fa? In the instance declaration for ?FunctorN n f a (f fa)? }}} which looks right to me. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 08:23:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 08:23:43 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.6262f52eb54aee916e2c00745a857524@haskell.org> #9136: Constant folding in Core could be better --------------------------------------------+------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): You could do that in `PrelRules` too. Yes, being able to do it in source code would be cool, but it all requires more syntax, a story about what predicates are allowed, etc etc, and it is far from obvious where to stop. The advantage of `PrelRules` is that you can do anything! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 08:24:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 08:24:17 -0000 Subject: [GHC] #9138: Allow users to edit their own tickets In-Reply-To: <046.b3e5925750fb7dd4ccafa83e8bdf4ab9@haskell.org> References: <046.b3e5925750fb7dd4ccafa83e8bdf4ab9@haskell.org> Message-ID: <061.243fa37f2b86480bfde0e57f1ec5040e@haskell.org> #9138: Allow users to edit their own tickets -------------------------------------+------------------------------------ Reporter: nomeata | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.8.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 simonpj): Indeed, that would be a good thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 08:35:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 08:35:49 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.e4299280269925ab56827608608ba7a8@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): Edward, can you elaborate the "without it you cannot write.." issue, perhaps on the wiki page, so we have it recorded properly? In the short term (i.e. before we converge on a better design for roles) I think we have these alternatives: * Defer AMP altogether (very undesirable) * Remove `join` from `Monad` in the AMP story (better) * Adopt full AMP (`join` and all), but accept that GND `deriving( Monad )` won't work for some monad transformers; you have to write it by hand. I am agnostic. It's a library issue. Edward, which would you like? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 09:03:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 09:03:10 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.61051365434dc237b6ed80170c6b8a0e@haskell.org> #9136: Constant folding in Core could be better --------------------------------------------+------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 schyler): I'd be against the thought of this kind of optimization being a rewrite rule. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 09:06:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 09:06:28 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.acd9381ecd17851e5fb143d9242618b5@haskell.org> #9136: Constant folding in Core could be better --------------------------------------------+------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): Care to explain? `(x +# y) -# z = x +# (y -# z)` looks very much like rewriting to me, and rewrite rules are a powerful mechanism for that. And if we were able to specify that declaratively in source code, instead of letting the compiler grow and grow, even better, I?d say. Also note that constant folding is also done with (built-in, more powerful) RULES already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 10:07:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 10:07:39 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.93973b3c6c90034bb482a8012f02ab87@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 ekmett): {{{ newtype StateT s m a = StateT { runStateT :: s -> m (a, s) } }}} This means that when you go to describe the instance for `Representational (StateT s m)` it needs to convert `s -> m (a, s)` into `s -> m (b, s)` given a coercion between a and b. But that means we're coercing `(,) a` into `(,) b` -- let's call those f and g respectively -- and we're expanding that with the coercion from s into s which is trivial. If we can't lift `(Representable f, Coercion f g, Coercion a b)` into `Coercion (f a) (g b)` but can only go `(Representable f, Coercion a b) => Coercion (f a) (f b)` then we get stuck, as we only have `(Representable ((,) a), Coercion ((,) a) (,) b, Coercion s s)`! For state you could actually get by with a _different_ weaker rule added to the one Richard offered: {{{ ext :: forall (f :: x -> y) (g :: x -> y) (a :: x). Coercion f g -> Coercion (f a) (g a) }}} which I fake with `unsafeCoerce` right now in https://github.com/ekmett/roles/blob/master/src/Data/Roles.hs But that isn't enough to handle lifting a coercion where what 'a' occurs on both sides of the nested, which is what you get for free monads, cofree comonads, etc. The simplest case that fails is probably: {{{ newtype Pair a = Pair (a, a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 10:09:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 10:09:52 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.0ae86d8921a4849cb065c38229bb0eb9@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 ekmett): Let's remove `join` from `Monad` for now, and see if we can't resolve this issue before we're forced to release. That lets GND work for `Monad`, which I agree is critical; it is a very common idiom to hide `transformers` monads inside a newtype wrapper and derive `Monad` and the related mtl instances and I'd hate to lose that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 10:55:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 10:55:39 -0000 Subject: [GHC] #9138: Allow users to edit their own tickets In-Reply-To: <046.b3e5925750fb7dd4ccafa83e8bdf4ab9@haskell.org> References: <046.b3e5925750fb7dd4ccafa83e8bdf4ab9@haskell.org> Message-ID: <061.eab24cf1caf5461c44a2395db60145db@haskell.org> #9138: Allow users to edit their own tickets -------------------------------------+------------------------------------ Reporter: nomeata | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.8.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 hvr): I've just granted both, `TICKET_EDIT_DESCRIPTION` and `TICKET_EDIT_CC`, to the authenticated users However, I doubt that #8881 will be resolved by that, as there's an implicit set of subscribers (i.e. those that have commented on the ticket) which doesn't show up in the CC property -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 11:08:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 11:08:23 -0000 Subject: [GHC] #9137: A way to match RULES only for literals In-Reply-To: <046.beaebd120563c793d8d6d0e627d6471a@haskell.org> References: <046.beaebd120563c793d8d6d0e627d6471a@haskell.org> Message-ID: <061.4b7571c43b7c18ce7088175371fb9046@haskell.org> #9137: A way to match RULES only for literals -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 nomeata: Old description: > In `GHC/Enum` we have > {{{ > {-# RULES > "enumDeltaToInteger1" [0] forall c n x . enumDeltaToIntegerFB c n x 1 = > up_fb c n x 1 > #-} > -- This rule ensures that in the common case (delta = 1), we do not do > the check here, > -- and also that we have the chance to inline up_fb, which would allow > the constructor to be > -- inlined and good things to happen. > -- We do not do it for Int this way because hand-tuned code already > exists, and > -- the special case varies more from the general case, due to the issue > of overflows. > }}} > This rule would be useful for all literals, not just for `1`. > > I remember a discussion that such a rule would be more useful if we had a > way to specify that, for example (random syntax). > {-# RULES > "enumDeltaToInteger1" [0] forall c n x d . isLiteral d => > enumDeltaToIntegerFB c n x d = up_fb c n x d > #-} > I?m reporting this now to be able to link to it from #9136, where this > feature might also help. New description: In `GHC/Enum` we have {{{ {-# RULES "enumDeltaToInteger1" [0] forall c n x . enumDeltaToIntegerFB c n x 1 = up_fb c n x 1 #-} -- This rule ensures that in the common case (delta = 1), we do not do the check here, -- and also that we have the chance to inline up_fb, which would allow the constructor to be -- inlined and good things to happen. -- We do not do it for Int this way because hand-tuned code already exists, and -- the special case varies more from the general case, due to the issue of overflows. }}} This rule would be useful for all literals, not just for `1`. I remember a discussion that such a rule would be more useful if we had a way to specify that, for example (random syntax). {{{ {-# RULES "enumDeltaToInteger1" [0] forall c n x d . isLiteral d => enumDeltaToIntegerFB c n x d = up_fb c n x d #-} }}} I?m reporting this now to be able to link to it from #9136, where this feature might also help. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 11:10:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 11:10:17 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.6733cd8a7119a504af6da4e3977ae53f@haskell.org> #9136: Constant folding in Core could be better --------------------------------------------+------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): > The difficulty is knowing where to stop. What about `(8 +# x) -# 1`? Surely there must be standard solutions in (non-functional) compilers. I asked the compiler guys next door and they pointed me to Muchnick?s Advanced Compiler Design & Implementation, where Fig 12.6 lists 20 transformation rules which should move constants in an expression involving `+`, `-` and `*` together and combine the constants. [http://stackoverflow.com/questions/23827531/reassociation-according-to- muchnick I don?t understand them yet], but something along these lines would work well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 11:22:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 11:22:38 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.6325b974275332175372d2fa40bc6073@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion 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: -------------------------------------+------------------------------------- Comment (by Blaisorblade): > BTW, wat do you mean by >>But this is a foldr, while takeWhile should be a foldl! Please ignore that, I've just removed that comment from my example. (If you're curious, when I wrote that comment I hadn't realized that right folds in a lazy language process the list left-to-right rather than right- to-left, and more such confusion; then I figured it out but forgot to remove the comment). > Looks ok, so if you want go ahead with building GHC and running nofib. On it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 12:25:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 12:25:22 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.6b42d7c06d62131f8fee9fd7d629fc67@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): The question, as I see it, is this: If we know `(Rep m, Coercible a b)` can we derive `Coercible (s -> m (a, s)) (s -> m (b, s))`? We assume that the ''only'' way we can use `Rep` is in the following rule: `(Rep m, Coercible x y)` implies `Coercible (m x) (m y)`. Call that rule (*). Yes: 1. Decompose the `(->)` to get that we need to show `Coercible (m (a, s)) (m (b, s))`. 2. Use (*) to get that we need to show `Coercible (a, s) (b, s)`. 3. By the roles of `(,)`, this reduces to `Coercible a b`. 4. We are done by assumption. What have I missed? Where did the asymmetry come into play? I'm not saying that the current solver does this, but it seems possible. You may also want to see the original post in #9117 which may be of interest. (Much of the ensuing commentary is not as relevant.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 12:56:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 12:56:54 -0000 Subject: [GHC] #9139: Using lift with StateT and Maybe on GHCI Message-ID: <047.0a1fe1e18f9b312fbc876c04256783a0@haskell.org> #9139: Using lift with StateT and Maybe on GHCI ------------------------------------+---------------------------- Reporter: Jefffrey | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------- I was playing around with `StateT` and `Maybe` today and I run the following two commands (consider that `TC` == `import qualified Control.Monad.Trans.Class as TC`: {{{ ghci> let g = TC.lift Just [3, 4] :: StateT [Int] Maybe Int }}} which led to a: {{{ :54:9: Couldn't match kind `* -> *' with `*' Expected type: [t0] -> StateT [Int] Maybe Int Actual type: [t0] -> StateT [Int] Maybe Int Kind incompatibility when matching types: [t_i] :: * -> * [t0] :: * The function `TC.lift'ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): kindFunResult <
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} and {{{ > let g = TC.lift Just (1, [3, 4]) :: StateT [Int] Maybe Int }}} which led to: {{{ :55:9: Couldn't match kind `* -> *' with `*' Expected type: (t0, [t1]) -> StateT [Int] Maybe Int Actual type: (t0, [t1]) -> StateT [Int] Maybe Int Kind incompatibility when matching types: (t_i, [t_l]) :: * -> * (t0, [t1]) :: * The function `TC.lift'ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): kindFunResult <
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I'm just doing what the last line asked me. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 13:02:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 13:02:28 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.6b9265fdc89f088b171f807635ece9a6@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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): Replying to [comment:13 altaic]: > Not necessarily, I think. Sure, the symbols point to the beginning of the prefix data rather than the function body, however twiddling the symbol table is a lot easier than mangling the whole assembly file. Coincidentally, using the LLVM API allows us mutable access to the symbol table among other things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 13:12:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 13:12:37 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.2b97773c61eae99d3292fe08685c0aaa@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.3 Component: Compiler (LLVM) | Version: 7.9 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 bgamari): Replying to [comment:12 awson]: > > I'm in no way an LLVM expert and know very little about it. Is there a way to make LLVM generate the code we want or are we use the mangler here? Any thoughts? I'm not sure I understand why LLVM produces the assembler it does in this case. Have you tried bringing this up with the LLVM folks? It may be that the fix belongs in LLVM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 13:39:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 13:39:32 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.d0cfb1d4c52c04ac0cc327704bee2d28@haskell.org> #9136: Constant folding in Core could be better --------------------------------------------+------------------------------ Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 nomeata): * owner: => nomeata Comment: I couldn?t resist to get started on this, so branch `wip/T9136` contains a test case ([changeset:d4081919/ghc]) and a first implementation for `+` ([changeset:115fd8b043/ghc]). Not polished and complete yet, and not yet validated, but it goes in the right direction I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 14:36:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 14:36:35 -0000 Subject: [GHC] #9139: Using lift with StateT and Maybe on GHCI In-Reply-To: <047.0a1fe1e18f9b312fbc876c04256783a0@haskell.org> References: <047.0a1fe1e18f9b312fbc876c04256783a0@haskell.org> Message-ID: <062.7a8be2a6e7bdcdb97382c28715db2a4b@haskell.org> #9139: Using lift with StateT and Maybe on GHCI ------------------------------+------------------------------------ Reporter: Jefffrey | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: GHCi | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: I suspect this is #7368. Anyway it works fine in 7.8 I think. Do reopen if I'm wrong. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 14:47:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 14:47:26 -0000 Subject: [GHC] #9050: Panic when compiling cmm file together with -outputdir In-Reply-To: <044.0c851e057b25561ca3c3a92b801901b3@haskell.org> References: <044.0c851e057b25561ca3c3a92b801901b3@haskell.org> Message-ID: <059.d2cbd7a3b9458da7f2f1372dbdb83b7b@haskell.org> #9050: Panic when compiling cmm file together with -outputdir ---------------------------------------+----------------------------------- Reporter: Yuras | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 Yuras): I know everybody is busy with more important thinks. Just raising in case it was just lost. Could anyone take a look please? Note: the code I want to delete is dead anyway because ghc doesn't support external core any more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 15:03:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 15:03:59 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.ff245af66d003dd532a6a83f8e10410c@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 have the beginning of a patch for symbol offset support here, https://github.com/bgamari/llvm/compare/symbol-offset#diff- c532266337d9a5b54a3b1dc8c25df12fR551. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 15:25:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 15:25:42 -0000 Subject: [GHC] #9140: Unboxed tuples fails in GHCi (7.8.2) Message-ID: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> #9140: Unboxed tuples fails in GHCi (7.8.2) ------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Creating an unboxed tuple in GHCi causes panic: {{{ ? ~ ghci -XUnboxedTuples GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. ghci> let a = (# 1 #) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): dsLet: unlifted AbsBinds [a{tv auv} [tv]] [$dNum_auw{v} [lid]] {Exports: [a{v asV} [lid] <= a{v asY} [lid] /\(@ a{tv auy} [tv]). \($dNum_auz{v} [lid] :: base:GHC.Num.Num{tc 2b} a{tv auy} [tv]). let {EvBinds{$dNum_auC{v} [lid] = $dNum_auz{v} [lid]}} (<>) @ a{tv auy} [tv] $dNum_auC{v} [lid]] Exported types: a{v asV} [lid] :: forall a{tv auv} [tv]. base:GHC.Num.Num{tc 2b} a{tv auv} [tv] => (# a{tv auv} [tv] #) [LclId, Str=DmdType] Binds: {:2:5-15} a{v asY} [lid] :: (# a{tv auv} [tv] #) [LclId, Str=DmdType] a{v asY} = {:2:9-15} (# 1 ((base:GHC.Num.fromInteger{v 02A}) @ a{tv auv} [tv] $dNum_au8{v} [lid] 1) #) <> Evidence: EvBinds{$dNum_au8{v} [lid] = $dNum_auw{v} [lid]}} base:GHC.Base.returnIO{v 0z} [gid] @ [()] (ghc-prim:GHC.Types.:{(w) v 65} [gid[DataCon]] @ () (ghc-prim:GHC.Prim.unsafeCoerce#{(w) v 0u} [gid] @ (forall a{tv auv} [tv]. base:GHC.Num.Num{tc 2b} a{tv auv} [tv] => (# a{tv auv} [tv] #)) @ () a{v asV} [lid]) (ghc-prim:GHC.Types.[]{(w) v 6n} [gid[DataCon]] @ ())) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghci> let a = (# 1, 2 #) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): dsLet: unlifted AbsBinds [a{tv auW} [tv], a{tv auX} [tv]] [$dNum_auY{v} [lid], $dNum_auZ{v} [lid]] {Exports: [a{v auK} [lid] <= a{v auN} [lid] /\(@ a{tv av1} [tv]). /\(@ a{tv av2} [tv]). \($dNum_av3{v} [lid] :: base:GHC.Num.Num{tc 2b} a{tv av2} [tv]). \($dNum_av4{v} [lid] :: base:GHC.Num.Num{tc 2b} a{tv av1} [tv]). let {EvBinds{$dNum_av8{v} [lid] = $dNum_av3{v} [lid] $dNum_av9{v} [lid] = $dNum_av4{v} [lid]}} (<>) @ a{tv av1} [tv] @ a{tv av2} [tv] $dNum_av8{v} [lid] $dNum_av9{v} [lid]] Exported types: a{v auK} [lid] :: forall a{tv auW} [tv] a{tv auX} [tv]. (base:GHC.Num.Num{tc 2b} a{tv auX} [tv], base:GHC.Num.Num{tc 2b} a{tv auW} [tv]) => (# a{tv auW} [tv], a{tv auX} [tv] #) [LclId, Str=DmdType] Binds: {:3:5-18} a{v auN} [lid] :: (# a{tv auW} [tv], a{tv auX} [tv] #) [LclId, Str=DmdType] a{v auN} = {:3:9-18} (# 1 ((base:GHC.Num.fromInteger{v 02A}) @ a{tv auW} [tv] $dNum_auR{v} [lid] 1), 2 ((base:GHC.Num.fromInteger{v 02A}) @ a{tv auX} [tv] $dNum_auT{v} [lid] 2) #) <> Evidence: EvBinds{$dNum_auR{v} [lid] = $dNum_auZ{v} [lid] $dNum_auT{v} [lid] = $dNum_auY{v} [lid]}} base:GHC.Base.returnIO{v 0z} [gid] @ [()] (ghc-prim:GHC.Types.:{(w) v 65} [gid[DataCon]] @ () (ghc-prim:GHC.Prim.unsafeCoerce#{(w) v 0u} [gid] @ (forall a{tv auW} [tv] a{tv auX} [tv]. (base:GHC.Num.Num{tc 2b} a{tv auX} [tv], base:GHC.Num.Num{tc 2b} a{tv auW} [tv]) => (# a{tv auW} [tv], a{tv auX} [tv] #)) @ () a{v auK} [lid]) (ghc-prim:GHC.Types.[]{(w) v 6n} [gid[DataCon]] @ ())) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghci> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 15:58:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 15:58:28 -0000 Subject: [GHC] #7241: GHC-7.6.1 panics on template haskell code In-Reply-To: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> References: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> Message-ID: <061.c0311ae016aadaab1cbc2cd05e1ee551@haskell.org> #7241: GHC-7.6.1 panics on template haskell code ---------------------------------------+----------------------------------- Reporter: akamaus | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Template Haskell | Version: 7.6.1 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 Yuras): * status: infoneeded => new Comment: Well, the original issue was indeed fixed by #8932, but it still crashes a bit later: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20140523 for x86_64-unknown-linux): kcLookupKind APromotionErr RecDataConPE }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 16:31:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 16:31:21 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.82a52965d6e7df8e23a2a6d099a7f9af@haskell.org> #9136: Constant folding in Core could be better --------------------------------------------+------------------------------ Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): Ok, implemented also for `Word`. The code does a transformation from `x -# (Lit n)` to `x +# (Lit -n)` and then only works on tress of additions. I didn?t do that for `Word` yet, because `foo +# 4294967295` is not very readable in Core. Should I? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 16:55:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 16:55:10 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.4417f0091401f4498de621db06421172@haskell.org> #9136: Constant folding in Core could be better --------------------------------------------+------------------------------ Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): One concern if have off hand: couldn't this sort of optimization change how a program under/overflows? I can't think of an example off hand, but could that happen? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 17:03:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 17:03:18 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.7d3520e37ae3e76beb77acd6d277fac1@haskell.org> #9136: Constant folding in Core could be better --------------------------------------------+------------------------------ Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): As long as you do it on types that wrap around (like `Int#` and `Word#`) or are unbounded (`Integer`): No, I don?t think so. Also, if there are any issues, I assume they would already be present in the existing constant folding code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 17:13:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 17:13:37 -0000 Subject: [GHC] #7241: GHC-7.6.1 panics on template haskell code In-Reply-To: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> References: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> Message-ID: <061.bc27b049522f478004f6a0e96990727b@haskell.org> #7241: GHC-7.6.1 panics on template haskell code ---------------------------------------+----------------------------------- Reporter: akamaus | Owner: Yuras Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Template Haskell | Version: 7.6.1 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 Yuras): * owner: simonpj => Yuras Comment: So, the comment added in changeset:d8d798b1b33ab0593ed03f193360b8725ba2c2ba is not fully correct. `findLocalDupsRdrEnv` doesn't catch this particular case because duplicate `Name`s are totally identical, including `SrcSpan`. I'll prepare a patch to emit error in case of duplicate GRE. The test case from #8932 will produce two errors, but I think it is ok. Definitely better then obscure panic. Please let me know if I'm going in wrong direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 18:23:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 18:23:14 -0000 Subject: [GHC] #7241: GHC-7.6.1 panics on template haskell code In-Reply-To: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> References: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> Message-ID: <061.cc710d28d3ec3f8a5e87362d308151f0@haskell.org> #7241: GHC-7.6.1 panics on template haskell code ---------------------------------------+----------------------------------- Reporter: akamaus | Owner: Yuras Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Template Haskell | Version: 7.6.1 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 Yuras): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 18:44:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 18:44:23 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.a31d0fc8c28ecbd7fca529be98e03b53@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 rwbarton): If we mangle the symbol table of the output .o file then it will be too late for intra-module references to be fixed up. So either we need to mangle the assembly anyways, or we need to adjust the input to LLVM taking this into account. That means when we build a thunk, we need to obtain the pointer to the end of the info table, which will be the symbol as known by LLVM plus some constant, but only when the symbol is in the current module; and when we want to jump to another function we need that function to start with one of these little jmps to skip the info table, since we can't tell LLVM to do a jump to a symbol plus some random byte offset. The symbol offset approach sounds workable to me. I assume it's not possible to tell LLVM to emit a global symbol in the middle of a function, as a second entry point? That would also solve our problem, as we could then stick the _info symbol after the prefix data and use it (rather than the symbol for the function, which points to the start of the info table) for building thunks and calling as usual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 18:50:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 18:50:19 -0000 Subject: [GHC] #9129: link error: unknown symbol `diagramszmlibzm1zi1zi0zi1_DiagramsziDirection_Direction_closure' In-Reply-To: <047.21067b3ced4e298ca552ea93ba25495c@haskell.org> References: <047.21067b3ced4e298ca552ea93ba25495c@haskell.org> Message-ID: <062.2798e88c7c78d7db98e37232f77caf92@haskell.org> #9129: link error: unknown symbol `diagramszmlibzm1zi1zi0zi1_DiagramsziDirection_Direction_closure' -------------------------------------+---------------------------------- Reporter: dmbergey | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 rwbarton): * status: new => closed * resolution: => invalid Comment: You need to list `Diagrams.Direction` in `diagrams-lib.cabal` somewhere, or Cabal won't link it into the library. Admittedly the diagnostic messages are not good, but it's unclear to me who is at fault here (GHC or Cabal). Please reopen if you think it is that GHC should be producing a more informative error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 19:22:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 19:22:42 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.1b55143651a5569c936b3f4f0fef6934@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 ekmett): True, if you keep the existing role rules that works for the concrete choice of (,) and State works. Consider a parameterized version where we fuse the two parameters into arguments of the same type argument, but don't make it concrete. e.g. {{{ newtype Foo s p a = Foo (s -> p a s) }}} and there you get stuck on GND for `a` whether or not you keep the existing role-based machinery for lifting coercions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 19:44:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 19:44:32 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.3c4bdb5678e78091d1594adfee39182a@haskell.org> #9136: Constant folding in Core could be better --------------------------------------------+------------------------------ Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): Refactored the code; no more transformation `x -# (Lit n)` to `x +# (Lit -n)` unless it is required to combine some literals. This yields prettier Core and this way it validates without having to update test result core output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 19:50:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 19:50:14 -0000 Subject: [GHC] #9118: Can't eta-reduce representational coercions In-Reply-To: <047.51e26113c799743ba87b936ff219c6a7@haskell.org> References: <047.51e26113c799743ba87b936ff219c6a7@haskell.org> Message-ID: <062.5472ae1f51e9454e545d61cd92f98c76@haskell.org> #9118: Can't eta-reduce representational coercions -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9117 -------------------------------------+------------------------------------ Comment (by rwbarton): nomeata: A type variable can't be instantiated at a(n unsaturated) type family (application), right? So `Coercion F1 F2` isn't a legal type-level expression at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 19:53:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 19:53:40 -0000 Subject: [GHC] #9104: internal compiler error: Segmentation fault for haskell-src-exts-1.15.0.1 In-Reply-To: <047.0741014ef728e3872828ed17f196126d@haskell.org> References: <047.0741014ef728e3872828ed17f196126d@haskell.org> Message-ID: <062.7040b79bec0434b793ef54d3a355afaf@haskell.org> #9104: internal compiler error: Segmentation fault for haskell-src-exts-1.15.0.1 ---------------------------------------+---------------------------------- Reporter: mhwombat | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 rwbarton): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. This appears to be a duplicate of #8768. (Note also that it's gcc that's segfaulting here, not ghc! Fun.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 19:54:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 19:54:02 -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.d84b1b6618b7d55ec807849428b99bf7@haskell.org> #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ---------------------------------------+---------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 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 rwbarton): So, this is fixed, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 19:59:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 19:59:12 -0000 Subject: [GHC] #9118: Can't eta-reduce representational coercions In-Reply-To: <047.51e26113c799743ba87b936ff219c6a7@haskell.org> References: <047.51e26113c799743ba87b936ff219c6a7@haskell.org> Message-ID: <062.620712eed45a40c8b96489cd7498ce05@haskell.org> #9118: Can't eta-reduce representational coercions -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9117 -------------------------------------+------------------------------------ Comment (by nomeata): Possibly; I?m don?t know all the details of type families. What `eta2 :: Coercible (f a) (g a) => Proxy a -> Coercion f g` says is: If `f` and `g` are the same for one arbitrary argument, they must be the same function. Maybe this is the case if type families are excluded for syntactical reasons. In that case, isn?t this an instance of #8555? We are given a more complex constraint `Coercible (f a) (g a)` and want to decompose it to the simpler `Coercible f g`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 20:02:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 20:02:46 -0000 Subject: [GHC] #9103: hackage's type-level-0.2.4 fails to compile In-Reply-To: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> References: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> Message-ID: <060.011aed21e3bc19075675761bdbaa7af4@haskell.org> #9103: hackage's type-level-0.2.4 fails to compile ----------------------------------------------+---------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8634 ----------------------------------------------+---------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid * related: => #8634 Comment: The error looks correct to me. {{{ class Succ' xh xl yh yl yz | xh xl -> yh yl yz, yh yl yz -> xh xl instance Failure (PredecessorOfZeroError x) => Succ' (x,x) (x,x) D0 D0 True }}} The functional dependency `yh yl yz -> xh xl` is violated because `D0 D0 True` do not determine `(x,x) (x,x)`: `x` is free. An instance of #8634. I'm going to mark this ticket as invalid (since it seems to me that you are considering this as a regression rather than a feature request), but see that ticket and its related tickets for ongoing discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 20:16:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 20:16:22 -0000 Subject: [GHC] #9118: Can't eta-reduce representational coercions In-Reply-To: <047.51e26113c799743ba87b936ff219c6a7@haskell.org> References: <047.51e26113c799743ba87b936ff219c6a7@haskell.org> Message-ID: <062.8847f7272a8e71612b90f4189d79eac9@haskell.org> #9118: Can't eta-reduce representational coercions -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9117 -------------------------------------+------------------------------------ Comment (by rwbarton): (Type families are like type synonyms in this regard; you can't define `type Pair a = (a, a)` and then talk about `Functor Pair`.) It looks like #8555 is for `Coercion (f a) (f b) -> Coercion a b`, while this ticket is for `Coercion (f a) (g a) -> Coercion f g`. I don't know whether those are literally the same construction in Core but I expect they are equally easy if not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 20:21:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 20:21:52 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.b510d6205ae8d6822d6b9d4e71741682@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 altaic): Yikes, I'm definitely not suggesting mangling the object file! I'd like to be rid of manglers entirely. Replying to [comment:15 bgamari]: > In my opinion, it would be wise to avoid linking against LLVM. Any particular reason? In my experience (which is probably much more limited than yours), getting upstream patches accepted is much more difficult, especially if there is a workaround. In addition, one of the main downsides of the LLVM backend is that compile time is much slower. Linking against LLVM would improve compilation time, make mangling unnecessary, and there may be other advantages as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 20:47:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 20:47:08 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.0dc0fbc491652ed864ed60e19f25e106@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 altaic): Re. patching LLVM: Are there any other uses of the symbol offset feature than fixing the symbols for functions that use prefix data? If not, how about patching the LLVM prefix code to accept an option (a bool) to have symbols point to the function entry? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 22:03:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 22:03:43 -0000 Subject: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS In-Reply-To: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> References: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> Message-ID: <060.c5d866e6a43ee62f0cda60436a1ccaa3@haskell.org> #4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Runtime System | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by slyfox): * cc: simonmar (added) * difficulty: => Unknown Comment: 0001-rts-posix-Select.c-remove-unused-select_succeeded.patch is a cleanup patch removing unused variable 0002-rts-posix-Select.c-search-for-EBADFs.patch is a patch, that finds bad file descriptors passed to select() What is the easiest way to convert such TSOs into IOException thunks? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 23:12:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 23:12:34 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.44d30d1e4e1d9b4026caefb0f6e06819@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 dterei): Firstly, its cool that LLVM has added this. It seems we could indeed implement TNTC with it. However based my quick understanding we couldnt implement it in a wag compatible with the current design. I believe the LLVM feature only allows us to place data at the very start of the function, after the label not before it. And your meant to ensure the very first instruction of the function is a jump that jumps over the data. We could use this, Simon Marlow and I discussed such a design in the past. But it's a change from the current scheme so the NCG would also need to change and it isn't clear if it would be as good as our current design. The other issue is that fixing TNTC doesn't eliminate the mangler. We use it for a few different reasons now. I can think of at least 3 I believe: TNTC, SIMD, and Windows. As for moving to the LLVM api. No, I think that isn't a great idea. I'm not convinced its will gain much compilation speed improvement. This is testable vy measuring how much time is actually spent invoking the LLVM binaries and how much time they spend serializing and parsing files. Given we need to go to an intermediary file of assembly for the mangler... Using the API also creates a GHC build time dependency on LLVM. Right now we avoid that which has advantages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 23:15:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 23:15:41 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.8547ee8372b1e2c270591f3abf3961c8@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 altaic): Is there any reason to not propose to change LLVM's prefix semantics such that the function's symbol points to the function body rather than the prefix data? To keep the optimization passes happy, it seems like one could have symbols for both the prefix data and the function body. The prefix data seems to be stuffed in a return instruction, so I'd think with both symbols, dead code elimination and other optimization passes wouldn't mess with the prefix data. I see two advantages to this approach: ? no extra unconditional branch ? prefix would no longer require the front end to construct target specific instructions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 23 23:29:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 May 2014 23:29:50 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.1da6093800fe0413867e226ef1119052@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 altaic): Replying to [comment:20 dterei]: > The other issue is that fixing TNTC doesn't eliminate the mangler. We use it for a few different reasons now. I can think of at least 3 I believe: TNTC, SIMD, and Windows. I didn't know the mangler is used for Windows, though I recall it was (is?) used for stack alignment on OSX. I was hoping that a move to using the LLVM API would allow enough control to be rid of the mangler once and for all, but it seems the idea is not getting much traction. I may press on in my own tree to gather some stats and become more familiar with LLVM's internals. Maybe it'll bear some unexpected fruit. Cheers, Will -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 01:06:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 01:06:16 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.2e74ec887f402a6dd58fcaf869ddaa83@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 dterei): I'm very in support of getting rid of the mangler. I just don't think we can given what LLVM supports today. I may be wrong about Windows, but I thought someone added support to the mangler to handle some Windows specific issues. I had forgotten about the OSX alignment issue, so that is one other use case. Perhaps the LLVM API would allow this, I didn't think it was more expressive than the LLVM language but haven't checked. It's worth playing around with this new function data prefix if you have the inclination just to see what we can get done with it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 01:55:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 01:55:16 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.509a5b4c0838b9a94957230ccca32b91@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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): '''Replying to [comment:21 altaic]''' > Is there any reason to not propose to change LLVM's prefix semantics such that the function's symbol points to the function body rather than the prefix data? I hope that the LLVM folks would reject outright any proposal to change the semantics of an already released feature in a non-compatible way. Especially when there is nothing wrong with the existing semantics. '''Replying to [comment:19 altaic]:''' > Re. patching LLVM: Are there any other uses of the symbol offset feature than fixing the symbols for functions that use prefix data? If not, how about patching the LLVM prefix code to accept an option (a bool) to have symbols point to the function entry? As I understand it, the proposals were designed explicitly to keep the matters of prefix data and symbol offsets orthogonal. In my opinion this was the right decision, even if it does require a bit more work. The only issue here is that symbol offset support was never implemented. I have a patch for this although it needs a little reworking. '''Replying to [comment:20 dterei]:''' > Firstly, its cool that LLVM has added this. It seems we could indeed implement TNTC with it. However based my quick understanding we couldnt implement it in a wag compatible with the current design. See above. There is no reason why TNTC can't be implemented once symbol offsets are in place. Your points surrounding the mangler's other roles are valid but I'd still say we should start trimming it where we can. If we can support TNTC without shuffling sections around, we are a little closer to deprecating the mangler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 02:39:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 02:39:09 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.a5c2497a73eaeb56845d3e8142be6a75@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 altaic): Replying to [comment:23 dterei]: > I'm very in support of getting rid of the mangler. FWIW, I just had a peek at the mangler, and it appears that it is now only used for TNTC and stack alignment. I also looked for references to the mangler with respect to SIMD in the wiki, but couldn't find anything other than a blank section [https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Mangler here]. I also couldn't find anything WRT Windows and the mangler. Finally, according to #4211 (as of commit 8a1c644af72caf122e73dac801496c055fc82dd9), the mangler is no longer needed to fix the stack on OSX. If true, completing this ticket may be the end of the mangler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 04:09:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 04:09:26 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.ebcaa3b3a05c0c88e7a5667bc0b2d722@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 awson): Replying to [comment:25 altaic]: > I also couldn't find anything WRT Windows and the mangler. Now LLVM-compiled 64-bit code segfaults on Windows. I've prepared the patch, but [https://ghc.haskell.org/trac/ghc/ticket/8974#comment:10 I don't know the way to implement it without mangler] because LLVM does not want to silently truncate 64-bit address constant to 32-bit but bitwise ands it with `-1` (`&-1`) also. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 05:29:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 05:29:29 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.834e1869e5622538996c51def2a7811c@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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): For the record, the current state of my experiments with implementing TNTC on top of LLVM's new IR features can be found here, https://github.com/bgamari/ghc/compare/ghc:ghc-7.8...llvm-demangle. Note that this needs to be used with my llvm branch for symbol offset support, https://github.com/bgamari/llvm/compare/symbol-offset -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 08:07:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 08:07:48 -0000 Subject: [GHC] #8657: -fregs-graph still has a limit on spill slots In-Reply-To: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> References: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> Message-ID: <062.ca1c57d8cdd83407b7addeab6abb64a9@haskell.org> #8657: -fregs-graph still has a limit on spill slots ---------------------------------------+----------------------------------- Reporter: simonmar | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7679 ---------------------------------------+----------------------------------- Changes (by archblob): * owner: => archblob Comment: I'll be working on this, should be easy once I understand the code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 08:11:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 08:11:16 -0000 Subject: [GHC] #8555: Simplify given `Coercible` constraints In-Reply-To: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> References: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> Message-ID: <061.312d37d2afa68cf39f24f85aa7f2ae39@haskell.org> #8555: Simplify given `Coercible` constraints ----------------------------------------------+---------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8503 | #8555 ----------------------------------------------+---------------------------- Changes (by archblob): * owner: archblob => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 10:06:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 10:06:05 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.479345e2bc39a3db6967065d73ccf183@haskell.org> #9136: Constant folding in Core could be better --------------------------------------------+------------------------------ Reporter: simonpj | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 nomeata): * status: new => patch Comment: Nofib shows that this optimization yields no measurable gain ? most likely because later stages (maybe gcc) perform them anyways. So do we still want it, for the sake of pleasing Core, and maybe for the benefit of other backends like GHCJS? If yes, this can go in, so marking this as ready for review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 17:16:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 17:16:57 -0000 Subject: [GHC] #9141: ghc panic linking persistent-sqlite ghc 7.8.2 x86_64-unknown-mingw32 Win 7 Message-ID: <055.26d5698b6733baf75b34263df9d3687b@haskell.org> #9141: ghc panic linking persistent-sqlite ghc 7.8.2 x86_64-unknown-mingw32 Win 7 ------------------------------------+------------------------------------- Reporter: stuartallenmills | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Error occurs attempting to build MFlow. The following is the relevant excerpt: Loading package persistent-sqlite-1.3.0.5 ... ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-mingw32): loadObj "C:\\shared\\msys64\\home\\smills\\Hask\\mflow\\.cabal- sandbox\\x86_64-windows-ghc-7.8.2\\persistent-sqlite-1.3.0.5 \\HSpersistent-sqlite-1.3.0.5.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug .... ghc.exe: Unknown PEi386 section name `.text.unlikely' (while processing: C:\shared\msys64\home\smills\Hask\mflow\.cabal-sandbox\x86_64-windows- ghc-7.8.2\persistent-sqlite-1.3.0.5\HSpersistent-sqlite-1.3.0.5.o) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 18:24:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 18:24:57 -0000 Subject: [GHC] #8197: telling people how to use GHC 7.6 correctly with Xcode 5/ OS X Mavericks In-Reply-To: <045.1e967ff64efa7a75edbb04c17766d7fe@haskell.org> References: <045.1e967ff64efa7a75edbb04c17766d7fe@haskell.org> Message-ID: <060.67410150768babf45418af4ddcde8511@haskell.org> #8197: telling people how to use GHC 7.6 correctly with Xcode 5/ OS X Mavericks ---------------------------------+---------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8480 ---------------------------------+---------------------------------- Changes (by carter): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 18:56:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 18:56:56 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.6370a8dde1b7eb3c015f44da93608ac6@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 altaic): Replying to [comment:26 awson]: > Now LLVM-compiled 64-bit code [https://ghc.haskell.org/trac/ghc/ticket/8974 segfaults on Windows]. I've prepared the patch, but [https://ghc.haskell.org/trac/ghc/ticket/8974#comment:10 I don't know the way to implement it without mangler] because LLVM does not want to silently truncate 64-bit address constant to 32-bit but bitwise ands it with `-1` (`&-1`) also. Ah, my apologies, I'm not sure why your ticket didn't appear on my trac query. LLVM does have a {{{trunc .. to}}} instruction, which may be of use to you, though admittedly I don't really know what's going on in your ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 19:06:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 19:06:24 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.fd7c25140aedeee739c42621b81dcd82@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 dterei): So I haven't looked at the proposed offsetting feature for LLVM. If that feature indeed means we can support TNTC without any changes to our current design (i.e., no changes to NCG or RTS) then awesome! We should defiantly make that change. I agree that minimizing how much we use the mangler is a good thing. If we can remove it then we should be able to avoid any intermediate files at all other than the .ll file. It's silly right now that we run `opt` and produce an intermediate .bc file, and then run `llc`. We should be able to just use a driver to go from .ll to an object file. At that point I'd be very surprised if changing to the LLVM API had any advantage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 19:31:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 19:31:20 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.ba2f3a862249a3478716b6888367aa83@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.3 Component: Compiler (LLVM) | Version: 7.9 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 altaic): LLVM has to be able to do a proper pointer cast. I'd definitely take Ben's advise and talk to the LLVM folks about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 19:43:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 19:43:45 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen Message-ID: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen ------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- LLVM HEAD has [https://github.com/llvm- mirror/llvm/commit/38048cdb1c016e1429004ddf4adfa40a8d853cbf changed] the behavior of aliases to reject references to things other than definitions. This unfortunately means that the handling of externs breaks, {{{ "inplace/bin/ghc-stage1" -static -H64m -O0 -fllvm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -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 You are using a new version of LLVM that hasn't been tested yet! We will try though... Alias must point to a definition i8* @"barf$alias" Alias must point to a definition i8* @"stg_gc_unpt_r1$alias" Alias must point to a definition i8* @"stg_apply_interp_info$alias" Alias must point to a definition i8* @"stg_yield_to_interpreter$alias" Alias must point to a definition i8* @"stg_ap_stack_entries$alias" Alias must point to a definition i8* @"__stg_gc_enter_1$alias" Alias must point to a definition i8* @"stg_upd_frame_info$alias" LLVM ERROR: Broken module found, compilation aborted! }}} In reference to the following aliases,. {{{ @barf = external global i8 @barf$alias = alias private i8* @barf @stg_gc_unpt_r1 = external global i8 @stg_gc_unpt_r1$alias = alias private i8* @stg_gc_unpt_r1 @stg_apply_interp_info = external global i8 @stg_apply_interp_info$alias = alias private i8* @stg_apply_interp_info @stg_yield_to_interpreter = external global i8 @stg_yield_to_interpreter$alias = alias private i8* @stg_yield_to_interpreter @stg_ap_stack_entries = external global i8 @stg_ap_stack_entries$alias = alias private i8* @stg_ap_stack_entries @__stg_gc_enter_1 = external global i8 @__stg_gc_enter_1$alias = alias private i8* @__stg_gc_enter_1 @stg_upd_frame_info = external global i8 @stg_upd_frame_info$alias = alias private i8* @stg_upd_frame_info }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 20:06:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 20:06:05 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.ea6e7904e6446d8b7030757cf75b7f16@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 altaic): Replying to [comment:24 bgamari]: > I hope that the LLVM folks would reject outright any proposal to change the semantics of an already released feature in a non-compatible way. An already released feature which is likely to have yet to be used in the wild. > Especially when there is nothing wrong with the existing semantics. I pointed out two shortcomings of the current semantics already. Even with the proposed symbol offsets, the prefix data must start with a target- dependent frontend-constructed instruction, which is subsequently not used. I.e. it requires carefully constructed garbage bytes. To me, that sounds kind of... not good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 20:18:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 20:18:37 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.6aacd3f60c347bb63a653f23260c803f@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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): Replying to [comment:30 altaic]: > I pointed out two shortcomings of the current semantics already. Even with the proposed symbol offsets, the prefix data must start with a target-dependent frontend-constructed instruction, which is subsequently not used. I.e. it requires carefully constructed garbage bytes. To me, that sounds kind of... not good. I could be mistaken but I don't believe this should be necessary with symbol offsets as the inliner won't see the info table at all (since the symbol points to the entrypoint of the function as it should). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 20:28:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 20:28:22 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.1092770851304513377b495c30e76e46@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 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 altaic): Replying to [comment:31 bgamari]: > I could be mistaken but I don't believe this should be necessary with symbol offsets as the inliner won't see the info table at all (since the symbol points to the entrypoint of the function as it should). Oh, that sounds right. Cool. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 21:19:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 21:19:10 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.c2e30f9146096e9c0764a0f2e9127006@haskell.org> #9136: Constant folding in Core could be better --------------------------------------------+------------------------------ Reporter: simonpj | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): @nomeata .... so I thought a bit about your reply... and part of my concern stems from the fact that the wrapping behavior of Int in GHC is actually a choice of "undefined" behavior by the various Haskell language standards. Point being, while wrap around is "folklore behavior", its actually deemed undefined by the standard. And it constitutes moving that undefined "folklore" into being a strong assumption in ghc. how would GCC come into play? theres no peephole optimization by the system assembler level in -fasm to my knowledge. most of the examples i've seen where arithmetic optimization makes a HUGE win are in the context of heavy bit fiddling sequences (I have some example that are 40 instructions long in -fasm, but optimized to NOOP on -fllvm), and various sophisticated array indexing computations. If nofib doesn't show a measurable difference and theres no motivating example program that shows a strong win.. I'd argue its not worth adding the rules. I'm happy to share some more interesting examples, but I'm not sure if they actually can be handled by a rewrite rules discipline. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 21:52:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 21:52:12 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.25cac84bfd4baeee2d140fa094560605@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.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 bgamari): There are two cases to worry about here, as shown in [https://github.com/ghc/ghc/blob/a948fe838bc79363d7565033d6ee42bf24d52fdc/compiler/llvmGen/LlvmCodeGen/Base.hs#L441 generateAliases], 1. The case of an externally defined symbol where we don't know the type (where `m_ty` is `Nothing`) 2. The case of a symbol for which we have a definition and therefore a type Case 1 can be handled with something like the attached patch. Frustratingly, case 2 cannot be as LLVM already knows the type and [https://github.com/llvm- mirror/llvm/blob/68b0d1d2b47f1be8eec2ce57c8119906c354ccd8/lib/AsmParser/LLParser.cpp#L692 refuses] to accept that we know what we are doing when we attempt to cast to a `i8*` (e.g. with a `bitcast` or `inttoptr`/`ptrtoint`). It seems that this will require an upstream fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 22:45:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 22:45:13 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.8d2d87b6212ccc1923ee467f5b1a7a73@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.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 bgamari): According to folks in `#llvm`, aliases are currently in a sad state and need to be rewritten. Attached above is a hack to allow bitcasts in aliasee position. I'll need to talk to more LLVM folks to see how to proceed from here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 23:23:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 23:23:44 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.672e3a26f45fc9466745415536e5c17f@haskell.org> #9136: Constant folding in Core could be better --------------------------------------------+------------------------------ Reporter: simonpj | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): If you have examples where such constant folding can be a win I?d of course be interested. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 24 23:58:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 May 2014 23:58:16 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.bda67b47736b62b3bc33dffd0c941638@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.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 bgamari): Unfortunately this isn't quite enough, {{{ /home/ben/trees/root-llvm-head/bin/opt: utils/hpc/dist- install/build/HpcParser.ll:44714:37: error: Alias must point to function or variable @c3rB_str$alias = alias private i8* bitcast (%c3rB_str_struct* @c3rB_str to i8*) ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 25 03:06:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 May 2014 03:06:01 -0000 Subject: [GHC] #9116: RTS Linker doesn't recognize .text.unlikely section on Windows In-Reply-To: <046.5c0df74d4f5647bfd1a9764670611eb2@haskell.org> References: <046.5c0df74d4f5647bfd1a9764670611eb2@haskell.org> Message-ID: <061.b85e7db1c58bddcc7bd7f13fe82e8823@haskell.org> #9116: RTS Linker doesn't recognize .text.unlikely section on Windows -------------------------------------+------------------------------------- Reporter: niklasl | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Easy (less than 1 valid program | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by rcook): * cc: rcook (added) Comment: Bug is probably a duplicate of https://ghc.haskell.org/trac/ghc/ticket/9080. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 25 03:06:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 May 2014 03:06:23 -0000 Subject: [GHC] #9141: ghc panic linking persistent-sqlite ghc 7.8.2 x86_64-unknown-mingw32 Win 7 In-Reply-To: <055.26d5698b6733baf75b34263df9d3687b@haskell.org> References: <055.26d5698b6733baf75b34263df9d3687b@haskell.org> Message-ID: <070.39562e42fe0ebb6ff86fa5a1e4a15c33@haskell.org> #9141: ghc panic linking persistent-sqlite ghc 7.8.2 x86_64-unknown-mingw32 Win 7 -------------------------------------+------------------------------------ Reporter: stuartallenmills | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 rcook): * cc: rcook (added) Comment: Bug is probably a duplicate of https://ghc.haskell.org/trac/ghc/ticket/9080. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 25 03:06:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 May 2014 03:06:50 -0000 Subject: [GHC] #9080: GHC error on Win 8.1 64bit In-Reply-To: <043.c0aa3d5bf848f70ddef90000b43fffd8@haskell.org> References: <043.c0aa3d5bf848f70ddef90000b43fffd8@haskell.org> Message-ID: <058.f78d0993852fcb93906bd0b7e7b9b6d5@haskell.org> #9080: GHC error on Win 8.1 64bit ---------------------------------------+---------------------------------- Reporter: maun | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by rcook): * cc: rcook (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 25 03:40:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 May 2014 03:40:11 -0000 Subject: [GHC] #9112: support for deriving Vector/MVector instances In-Reply-To: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> References: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> Message-ID: <060.6dad62397d5b8e61bfa46023aa200ee0@haskell.org> #9112: support for deriving Vector/MVector instances -------------------------------------+------------------------------------ Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 bitemyapp): I am trying to build hackage-server on Mac OS X with GHC 7.8 and I was told this ticket is relevant to my problems. I've included the build error in this comment. {{{ When deriving the instance for (VecMut.MVector VecBase.MVector DocId) Distribution/Server/Features/Search/DocIdSet.hs:38:13: Could not coerce from ?Data.Vector.Primitive.Mutable.MVector s Word32? to ?VecBase.MVector s DocId? because ?Data.Vector.Primitive.Mutable.MVector s Word32? and ?VecBase.MVector s DocId? are different types. arising from the coercion of the method ?VecMut.basicOverlaps? from type ?forall s. VecBase.MVector s Word32 -> VecBase.MVector s Word32 -> Bool? to type ?forall s. VecBase.MVector s DocId -> VecBase.MVector s DocId -> Bool? Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (VecMut.MVector VecBase.MVector DocId) Distribution/Server/Features/Search/DocIdSet.hs:38:13: Could not coerce from ?Data.Vector.Primitive.Mutable.MVector s Word32? to ?VecBase.MVector s DocId? because ?Data.Vector.Primitive.Mutable.MVector s Word32? and ?VecBase.MVector s DocId? are different types. arising from the coercion of the method ?VecMut.basicUnsafeSlice? from type ?forall s. Int -> Int -> VecBase.MVector s Word32 -> VecBase.MVector s Word32? to type ?forall s. Int -> Int -> VecBase.MVector s DocId -> VecBase.MVector s DocId? Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (VecMut.MVector VecBase.MVector DocId) Distribution/Server/Features/Search/DocIdSet.hs:38:13: Could not coerce from ?Data.Vector.Primitive.Mutable.MVector s Word32? to ?VecBase.MVector s DocId? because ?Data.Vector.Primitive.Mutable.MVector s Word32? and ?VecBase.MVector s DocId? are different types. arising from the coercion of the method ?VecMut.basicLength? from type ?forall s. VecBase.MVector s Word32 -> Int? to type ?forall s. VecBase.MVector s DocId -> Int? Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (VecMut.MVector VecBase.MVector DocId) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 25 09:58:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 May 2014 09:58:33 -0000 Subject: [GHC] #9080: GHC error on Win 8.1 64bit In-Reply-To: <043.c0aa3d5bf848f70ddef90000b43fffd8@haskell.org> References: <043.c0aa3d5bf848f70ddef90000b43fffd8@haskell.org> Message-ID: <058.b5f1a46ede333d58a0bdf5c06126be25@haskell.org> #9080: GHC error on Win 8.1 64bit ---------------------------------------+---------------------------------- Reporter: maun | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by niklasl): I added a patch that recognized .text.unlikely sections, as described in #9116. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 25 09:59:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 May 2014 09:59:58 -0000 Subject: [GHC] #9116: RTS Linker doesn't recognize .text.unlikely section on Windows In-Reply-To: <046.5c0df74d4f5647bfd1a9764670611eb2@haskell.org> References: <046.5c0df74d4f5647bfd1a9764670611eb2@haskell.org> Message-ID: <061.1066ca0b483dad2ae7016e18ff336663@haskell.org> #9116: RTS Linker doesn't recognize .text.unlikely section on Windows -------------------------------------+------------------------------------- Reporter: niklasl | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Easy (less than 1 valid program | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by niklasl): If it can happen with the mingw distributed with GHC it's quite a bit more urgent to fix. Added a patch to #9080. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 25 17:15:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 May 2014 17:15:33 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.ccf5957a57cd3e34d039ca2dbfd30ca7@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.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 scpmw): Not quite sure I understand how your patch works - isn't this basically allocating a bunch of static null-initialized `i8` fields to point to? That's hardly what we want, even if it compiles. It would be really interesting to get a statement from LLVM people on this. If they think that we are mis-using aliases, that's reason enough to do something else. One possible solution that occurred to me was that we could use type aliases - but instead of writing the definitions at the end of the session we'd close the file and /prepend/ them. That could be a cheap and easy way to get the LLVM parser to like us again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 25 18:18:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 May 2014 18:18:36 -0000 Subject: [GHC] #9118: Can't eta-reduce representational coercions In-Reply-To: <047.51e26113c799743ba87b936ff219c6a7@haskell.org> References: <047.51e26113c799743ba87b936ff219c6a7@haskell.org> Message-ID: <062.19f6789a09a5f4d7ebff5aafce795501@haskell.org> #9118: Can't eta-reduce representational coercions -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9117 -------------------------------------+------------------------------------ Comment (by goldfire): I agree with rwbarton on this -- I think the `F1`/`F2` example doesn't really apply. But, there remains a problem case: {{{ newtype Pair a = Mk (a, a) }}} We can easily derive `Coercible (Pair Int) ((,) Int Int)`, but it would be bad to derive `Coercible Pair ((,) Int)`. The problem is that the newtype definition has a repeated variable on the right, and thus the definition cannot be eta-reduced. Probably, a sufficiently complicated Core construction can detect and avoid this case, but I don't think it would be easy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 25 19:34:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 May 2014 19:34:52 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.aea3c516b339e4c84212ebdf7769558c@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: -------------------------------------+------------------------------------ Changes (by altaic): * cc: william.knop.nospam@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 25 19:41:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 May 2014 19:41:36 -0000 Subject: [GHC] #8226: Remove the old style -- # Haddock comments. In-Reply-To: <047.96b6209768296ad11c174e077e349059@haskell.org> References: <047.96b6209768296ad11c174e077e349059@haskell.org> Message-ID: <062.bc90ca19b58fc968b78c3011081bc727@haskell.org> #8226: Remove the old style -- # Haddock comments. -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.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: -------------------------------------+------------------------------------ Comment (by adinapoli): (Rewriting comment that the tracker wiped :'( ) In a nutshell this is my first session of GHC hacking ever, so please be patient if - as I'm certain - my patch doesn't fully fix the issue or is going in the wrong direction. I have manually tested the fix modifying slightly the testcase attached to the relevant haddock ticket: http://trac.haskell.org/haddock/ticket/171 {{{ {- # LANGUAGE RecordWildCards #-} module Fail where data Foo = Foo { a :: String , b :: Int } showFoo Foo{..} = a main :: IO () main = print $ showFoo (Foo "a" 10) }}} As pointed out that one is _not_ a pragma (mind the space), so it needs to be interpreted as a normal comment, but Haddock chokes on it: {{{ -- pre-fix [nix-shell:ghc]$ ghc -haddock Fail.hs [1 of 1] Compiling Main ( Fail.hs, Fail.o ) Fail.hs:1:4: parse error on input ?#? }}} But after my patch it seems to accept it: {{{ [nix-shell:ghc]$ ghc-dev -haddock Fail.hs [1 of 1] Compiling Fail ( Fail.hs, Fail.o ) Fail.hs:10:9: Illegal `..' in record pattern Use RecordWildCards to permit this }}} I have ran "validate" before and after the patch and it seems no regression was introduces, but being the Lexer such a delicate part I really want to be cautious with it :) Thanks guys, hope I'm on the right track :) Alfredo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 25 22:51:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 May 2014 22:51:38 -0000 Subject: [GHC] #9143: feature request: way to set actual program argv Message-ID: <047.14769c1c2bab59d46b7097edaaa12dc6@haskell.org> #9143: feature request: way to set actual program argv ----------------------------------------------+---------------------------- Reporter: joeyhess | Owner: Type: feature request | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Keywords: | Version: 7.8.2 Architecture: Unknown/Multiple | Operating System: Linux Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- It's not currently possible to write a program with ghc that changes its argv, so as to change what the program name/parameters appear to be in ps. An example of a program that does this is sshd, which arranges for the process name to say which user it's serving. For example, "sshd: joey [priv]" I'd like to be able to write such programs using haskell too. Also, I have a haskell program that, due to the way it is executed, has a really horrible display in ps: /usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib64/ld-linux-x86-64.so.2 --library-path /usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib/x86_64-linux- gnu:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux- gnu:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib64:/usr/local/propellor/docker /android-git-annex- builder.orca.kitenet.net.propellor.shim/etc/ld.so.conf.d:/usr/local/propellor/docker /android-git-annex-builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64 -linux-gnu/audit:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux-gnu/gconv /usr/local/propellor/propellor That's enough motivation for me to dig into this. :) In rts/RtsMain.c, progargv is set to point to argv. However, it's static, so this cannot be (ab)used from the FFI to change argv. So, a minimal change would be to make progargv not be static, and perhaps give it a more formal name or minimal FFI binding. A GHC-specific library could then use this to modify argv. The haskell interface I'm considering would be: displayArgv :: [String] -> IO () It would need to truncate strings to fit within the available argv space. (This would not affect the argv used by System.Environment, which is a copy of argv.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 25 23:32:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 May 2014 23:32:33 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.c639ce8f7b51e7889a9935ba37d40b0d@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.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 bgamari): Replying to [comment:4 scpmw]: > Not quite sure I understand how your patch works - isn't this basically allocating a bunch of static null-initialized `i8` fields to point to? That's hardly what we want, even if it compiles. > Frankly I'm not too clear on this either. I modelled the change after similar [https://github.com/llvm- mirror/llvm/commit/38048cdb1c016e1429004ddf4adfa40a8d853cbf#diff- 6888511bd2c39203c5f7a7e314bdd2ebL40 changes] made in the commit in question to testcases. However, you are right, it would appear that the local definitions will be used in lieu of the external symbols the references are supposed to use. All I know at the moment is that the code compiles. It likely does the wrong thing. > It would be really interesting to get a statement from LLVM people on this. > Indeed it would. At this point my next goal is to chase down the relevant LLVM people. > If they think that we are mis-using aliases, that's reason enough to do something else. One possible solution could again be type aliases - but instead of writing the definitions at the end of the session we'd close the file and /prepend/ them. That could be a cheap and easy way to get the LLVM parser to like us again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 26 05:57:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 May 2014 05:57:42 -0000 Subject: [GHC] #9109: Improve error messages around "untouchable" type variables In-Reply-To: <047.8e8e8d32b365719fddf8914f1815c1c6@haskell.org> References: <047.8e8e8d32b365719fddf8914f1815c1c6@haskell.org> Message-ID: <062.1797b7761a022b0a7565a451ed917be0@haskell.org> #9109: Improve error messages around "untouchable" type variables -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 jstolarek): * cc: jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 26 06:08:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 May 2014 06:08:57 -0000 Subject: [GHC] #7961: Remove restrictions on promoting GADT's In-Reply-To: <047.d0069eb42fb0ed6b29e5044acfcdabb7@haskell.org> References: <047.d0069eb42fb0ed6b29e5044acfcdabb7@haskell.org> Message-ID: <062.fde9e8a5f6d9f03e83f4adca350fa094@haskell.org> #7961: Remove restrictions on promoting GADT's -------------------------------------+------------------------------------ Reporter: danharaj | 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: #6024 -------------------------------------+------------------------------------ Changes (by jstolarek): * cc: jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 26 07:10:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 May 2014 07:10:29 -0000 Subject: [GHC] #8226: Remove the old style -- # Haddock comments. In-Reply-To: <047.96b6209768296ad11c174e077e349059@haskell.org> References: <047.96b6209768296ad11c174e077e349059@haskell.org> Message-ID: <062.89ce221b3a3357af609ebefddb7c98b0@haskell.org> #8226: Remove the old style -- # Haddock comments. -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.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: -------------------------------------+------------------------------------ Comment (by simonpj): It'd be great if a Haddock-aware person was able to take a look. Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 26 08:51:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 May 2014 08:51:47 -0000 Subject: [GHC] #8226: Remove the old style -- # Haddock comments. In-Reply-To: <047.96b6209768296ad11c174e077e349059@haskell.org> References: <047.96b6209768296ad11c174e077e349059@haskell.org> Message-ID: <062.9400e11c8358fec4c5838d009d5410c2@haskell.org> #8226: Remove the old style -- # Haddock comments. -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.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: -------------------------------------+------------------------------------ Changes (by adinapoli): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 26 11:11:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 May 2014 11:11:42 -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.63324bbcd25cdd10fde746b47f96b2d9@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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 trommler): * owner: trommler => simonmar Comment: The attached patches change the way shared libraries are loaded (dlopen) by the runtime system and the way temporary shared libraries are linked for files compiled to object code in GHCi. The first patch [https://ghc.haskell.org/trac/ghc/attachment/ticket/8935/0001-Fix-GHCi- crash-on-access-to-process-environment.patch] implements the changes for Linux and I validated those on x86_64 (openSUSE 13.1). The second patch [https://ghc.haskell.org/trac/ghc/attachment/ticket/8935/0001-Fix-GHCi- linking-of-files-compiled-to-object-code.patch] might be needed for OS X. This patch is not validated as I do not have access to an OS X machine at the moment. Simon, please have a look at the patches and the commit messages and let me know what could be improved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 26 11:36:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 May 2014 11:36:01 -0000 Subject: [GHC] #9112: support for deriving Vector/MVector instances In-Reply-To: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> References: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> Message-ID: <060.8cb9e8794ef34e1efbbe2ea064c52d18@haskell.org> #9112: support for deriving Vector/MVector instances -------------------------------------+------------------------------------ Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): I can't reproduce this because I fall at an early fence: {{{ bash$ cabal install hackage-server Resolving dependencies... cabal: Could not resolve dependencies: trying: hackage-server-0.4 (user goal) trying: base-4.7.0.0/installed-018... (dependency of hackage-server-0.4) next goal: process (dependency of hackage-server-0.4) rejecting: process-1.2.0.0/installed-eaf... (conflict: process => unix==2.7.0.1/installed-23f..., hackage-server => unix<2.7) trying: process-1.2.0.0 next goal: Cabal (dependency of hackage-server-0.4) rejecting: Cabal-1.18.1.3/installed-9a9..., 1.20.0.0, 1.18.1.3, 1.18.1.2, 1.18.1.1, 1.18.1, 1.18.0 (conflict: hackage-server => Cabal>=1.16 && <1.17) trying: Cabal-1.16.0.3 rejecting: Cabal-1.16.0.3:+base3 (conflict: process==1.2.0.0, Cabal-1.16.0.3:base3 => process>=1 && <1.2) rejecting: Cabal-1.16.0.3:-base3 (conflict: base==4.7.0.0/installed-018..., Cabal-1.16.0.3:base3 => base<3) Backjump limit reached (change with --max-backjumps). bash$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.2 }}} I have no idea what all this means. But it looks plausible that it's the same issue, and is rightly rejected on the grounds that it could be unsound. We have yet to figure out a way to solve this; see #9123. I do not know whether this is a show-stopper any particular packages, and if so which. Nor do I know if there is a reasonable way to work around it. Perhaps others will know more than I do. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 26 13:51:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 May 2014 13:51:53 -0000 Subject: [GHC] #9112: support for deriving Vector/MVector instances In-Reply-To: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> References: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> Message-ID: <060.503632582038c72e439f1cd1a692c8b5@haskell.org> #9112: support for deriving Vector/MVector instances -------------------------------------+------------------------------------ Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 tibbe): Replying to [comment:7 simonpj]: > I have no idea what all this means. But it looks plausible that it's the same issue, and is rightly rejected on the grounds that it could be unsound. We have yet to figure out a way to solve this; see #9123. I can't tell, from the cabal message, whether cabal gave up early or there's in fact no install plan possible. If it's the former then cabal- install-1.20.0.2 (released last weekend) has several solver improvements that might let it find a solution that lets you build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 26 14:25:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 May 2014 14:25:51 -0000 Subject: [GHC] #7269: GeneralizedNewtypeDeriving and PolyKinds In-Reply-To: <046.1e47fafa481c78cda2f9c785dd9f4aa3@haskell.org> References: <046.1e47fafa481c78cda2f9c785dd9f4aa3@haskell.org> Message-ID: <061.1b0181a1e4d4025c522edaa3684eafd2@haskell.org> #7269: GeneralizedNewtypeDeriving and PolyKinds -------------------------------------+------------------------------------ Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | 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: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"b1436f55da2b0e005ac09be6651a2c4d934027ec/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b1436f55da2b0e005ac09be6651a2c4d934027ec" Fix yet another bug in 'deriving' for polykinded classes (Trac #7269) This patch makes the code a bit simpler if anything. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 26 14:26:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 May 2014 14:26:26 -0000 Subject: [GHC] #7269: GeneralizedNewtypeDeriving and PolyKinds In-Reply-To: <046.1e47fafa481c78cda2f9c785dd9f4aa3@haskell.org> References: <046.1e47fafa481c78cda2f9c785dd9f4aa3@haskell.org> Message-ID: <061.8f9d7128cd21a4b12c0c66f926d931a4@haskell.org> #7269: GeneralizedNewtypeDeriving and PolyKinds -------------------------------------------------+------------------------- Reporter: dreixel | Owner: Type: bug | dreixel Priority: normal | Status: merge Component: Compiler | Milestone: Resolution: | 7.10.1 Operating System: Unknown/Multiple | Version: 7.6.1 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: deriving/should_compile/T7269 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => merge * testcase: => deriving/should_compile/T7269 Comment: Fixed at last. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 26 15:49:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 May 2014 15:49:54 -0000 Subject: [GHC] #7269: GeneralizedNewtypeDeriving and PolyKinds In-Reply-To: <046.1e47fafa481c78cda2f9c785dd9f4aa3@haskell.org> References: <046.1e47fafa481c78cda2f9c785dd9f4aa3@haskell.org> Message-ID: <061.863996d981e48e309a757632542f05c9@haskell.org> #7269: GeneralizedNewtypeDeriving and PolyKinds -------------------------------------------------+------------------------- Reporter: dreixel | Owner: Type: bug | dreixel Priority: normal | Status: merge Component: Compiler | Milestone: Resolution: | 7.10.1 Operating System: Unknown/Multiple | Version: 7.6.1 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: deriving/should_compile/T7269 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nomeata): Please add the test case: {{{ : does not exist: T7269.hs *** unexpected failure for T7269(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 26 16:04:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 May 2014 16:04:04 -0000 Subject: [GHC] #7269: GeneralizedNewtypeDeriving and PolyKinds In-Reply-To: <046.1e47fafa481c78cda2f9c785dd9f4aa3@haskell.org> References: <046.1e47fafa481c78cda2f9c785dd9f4aa3@haskell.org> Message-ID: <061.f66eca663a2c2eea788a791324fadcdc@haskell.org> #7269: GeneralizedNewtypeDeriving and PolyKinds -------------------------------------------------+------------------------- Reporter: dreixel | Owner: Type: bug | dreixel Priority: normal | Status: merge Component: Compiler | Milestone: Resolution: | 7.10.1 Operating System: Unknown/Multiple | Version: 7.6.1 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: deriving/should_compile/T7269 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): Sorry, done -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 26 18:40:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 May 2014 18:40:01 -0000 Subject: [GHC] #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` In-Reply-To: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> References: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> Message-ID: <060.5d1e6d55e96cab7fd1835469cd44665b@haskell.org> #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` -------------------------------------+------------------------------------ Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 igloo): This sounds a little odd to me. What's the actual use-case here? A test that the parameter parser doesn't thrown an exception? Unless there's a common reason for wanting to do this, I think it would be better for people who really want to do this to have to use `seq` or `!_rqPostParams = ...` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 26 19:21:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 May 2014 19:21:07 -0000 Subject: [GHC] #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` In-Reply-To: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> References: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> Message-ID: <060.c0dcb010bb5b83df1b7315ba4d9b8c44@haskell.org> #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` -------------------------------------+------------------------------------ Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 refold): Replying to [comment:2 igloo]: > This sounds a little odd to me. What's the actual use-case here? A test that the parameter parser doesn't thrown an exception? The code looks like this: {{{ foo :: RequestBuilder foo = do rq <- rGet let !_ = rqPostParams rq ... rPut rq }}} where `RequestBuilder` is a state monad (`StateT ...`). So we're forcing some parts of the state before passing it along; `let !_ = rhs` is used as a nicer syntax for `seq`. IMO it's a valid idiom. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 26 22:01:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 May 2014 22:01:12 -0000 Subject: [GHC] #9144: Incorrect error reported with poly-kinded type families Message-ID: <047.a2a118726fc4bf731f1c4cf9b107992e@haskell.org> #9144: Incorrect error reported with poly-kinded type families ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I compile {{{ {-# LANGUAGE PolyKinds, DataKinds, TypeFamilies, GADTs, RankNTypes #-} module Bug where import Data.Proxy import GHC.TypeLits data family Sing (a :: k) data SomeSing :: KProxy k -> * where SomeSing :: forall (a :: k). Sing a -> SomeSing ('KProxy :: KProxy k) class kproxy ~ 'KProxy => SingKind (kproxy :: KProxy k) where fromSing :: forall (a :: k). Sing a -> DemoteRep ('KProxy :: KProxy k) toSing :: DemoteRep ('KProxy :: KProxy k) -> SomeSing ('KProxy :: KProxy k) type family DemoteRep (kproxy :: KProxy k) :: * data Foo = Bar Nat data FooTerm = BarTerm Integer data instance Sing (x :: Foo) where SBar :: Sing n -> Sing (Bar n) type instance DemoteRep ('KProxy :: KProxy Nat) = Integer type instance DemoteRep ('KProxy :: KProxy Foo) = FooTerm instance SingKind ('KProxy :: KProxy Nat) where fromSing = undefined toSing = undefined instance SingKind ('KProxy :: KProxy Foo) where fromSing (SBar n) = BarTerm (fromSing n) toSing n = case toSing n of SomeSing n' -> SomeSing (SBar n') }}} I get (with `-fprint-explicit-kinds`) {{{ /Users/rae/temp/Bug.hs:33:32: Couldn't match type ?FooTerm? with ?Integer? Expected type: Integer Actual type: DemoteRep Nat ('KProxy Nat) In the first argument of ?BarTerm?, namely ?(fromSing n)? In the expression: BarTerm (fromSing n) /Users/rae/temp/Bug.hs:34:26: Couldn't match type ?Integer? with ?FooTerm? Expected type: DemoteRep Nat ('KProxy Nat) Actual type: DemoteRep Foo ('KProxy Foo) In the first argument of ?toSing?, namely ?n? In the expression: toSing n }}} The second error reported is correct -- the last line in the code should start `toSing (FooTerm n) = ...` to fix the code. However, the first error reported is bogus, given that `DemoteRep ('KProxy :: KProxy Nat)` is clearly `Integer`. I tried to simplify the test case with no luck -- sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 26 22:02:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 May 2014 22:02:33 -0000 Subject: [GHC] #9144: Incorrect error reported with poly-kinded type families In-Reply-To: <047.a2a118726fc4bf731f1c4cf9b107992e@haskell.org> References: <047.a2a118726fc4bf731f1c4cf9b107992e@haskell.org> Message-ID: <062.2f89d7f5faa31b17e39f6fc915abb873@haskell.org> #9144: Incorrect error reported with poly-kinded type families -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Old description: > When I compile > > {{{ > {-# LANGUAGE PolyKinds, DataKinds, TypeFamilies, GADTs, RankNTypes #-} > > module Bug where > > import Data.Proxy > import GHC.TypeLits > > data family Sing (a :: k) > > data SomeSing :: KProxy k -> * where > SomeSing :: forall (a :: k). Sing a -> SomeSing ('KProxy :: KProxy k) > > class kproxy ~ 'KProxy => SingKind (kproxy :: KProxy k) where > fromSing :: forall (a :: k). Sing a -> DemoteRep ('KProxy :: KProxy k) > toSing :: DemoteRep ('KProxy :: KProxy k) -> SomeSing ('KProxy :: > KProxy k) > > type family DemoteRep (kproxy :: KProxy k) :: * > > data Foo = Bar Nat > data FooTerm = BarTerm Integer > > data instance Sing (x :: Foo) where > SBar :: Sing n -> Sing (Bar n) > > type instance DemoteRep ('KProxy :: KProxy Nat) = Integer > type instance DemoteRep ('KProxy :: KProxy Foo) = FooTerm > > instance SingKind ('KProxy :: KProxy Nat) where > fromSing = undefined > toSing = undefined > > instance SingKind ('KProxy :: KProxy Foo) where > fromSing (SBar n) = BarTerm (fromSing n) > toSing n = case toSing n of SomeSing n' -> SomeSing (SBar n') > }}} > > I get (with `-fprint-explicit-kinds`) > > {{{ > /Users/rae/temp/Bug.hs:33:32: > Couldn't match type ?FooTerm? with ?Integer? > Expected type: Integer > Actual type: DemoteRep Nat ('KProxy Nat) > In the first argument of ?BarTerm?, namely ?(fromSing n)? > In the expression: BarTerm (fromSing n) > > /Users/rae/temp/Bug.hs:34:26: > Couldn't match type ?Integer? with ?FooTerm? > Expected type: DemoteRep Nat ('KProxy Nat) > Actual type: DemoteRep Foo ('KProxy Foo) > In the first argument of ?toSing?, namely ?n? > In the expression: toSing n > }}} > > The second error reported is correct -- the last line in the code should > start `toSing (FooTerm n) = ...` to fix the code. However, the first > error reported is bogus, given that `DemoteRep ('KProxy :: KProxy Nat)` > is clearly `Integer`. > > I tried to simplify the test case with no luck -- sorry. New description: When I compile {{{ {-# LANGUAGE PolyKinds, DataKinds, TypeFamilies, GADTs, RankNTypes #-} module Bug where import Data.Proxy import GHC.TypeLits data family Sing (a :: k) data SomeSing :: KProxy k -> * where SomeSing :: forall (a :: k). Sing a -> SomeSing ('KProxy :: KProxy k) class kproxy ~ 'KProxy => SingKind (kproxy :: KProxy k) where fromSing :: forall (a :: k). Sing a -> DemoteRep ('KProxy :: KProxy k) toSing :: DemoteRep ('KProxy :: KProxy k) -> SomeSing ('KProxy :: KProxy k) type family DemoteRep (kproxy :: KProxy k) :: * data Foo = Bar Nat data FooTerm = BarTerm Integer data instance Sing (x :: Foo) where SBar :: Sing n -> Sing (Bar n) type instance DemoteRep ('KProxy :: KProxy Nat) = Integer type instance DemoteRep ('KProxy :: KProxy Foo) = FooTerm instance SingKind ('KProxy :: KProxy Nat) where fromSing = undefined toSing = undefined instance SingKind ('KProxy :: KProxy Foo) where fromSing (SBar n) = BarTerm (fromSing n) toSing n = case toSing n of SomeSing n' -> SomeSing (SBar n') }}} I get (with `-fprint-explicit-kinds`) {{{ /Users/rae/temp/Bug.hs:33:32: Couldn't match type ?FooTerm? with ?Integer? Expected type: Integer Actual type: DemoteRep Nat ('KProxy Nat) In the first argument of ?BarTerm?, namely ?(fromSing n)? In the expression: BarTerm (fromSing n) /Users/rae/temp/Bug.hs:34:26: Couldn't match type ?Integer? with ?FooTerm? Expected type: DemoteRep Nat ('KProxy Nat) Actual type: DemoteRep Foo ('KProxy Foo) In the first argument of ?toSing?, namely ?n? In the expression: toSing n }}} The second error reported is correct -- the last line in the code should start `toSing (BarTerm n) = ...` to fix the code. However, the first error reported is bogus, given that `DemoteRep ('KProxy :: KProxy Nat)` is clearly `Integer`. I tried to simplify the test case with no luck -- sorry. -- Comment (by goldfire): Corrected typo in initial report (`FooTerm` --> `BarTerm` in a critical spot). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 01:11:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 01:11:57 -0000 Subject: [GHC] #7961: Remove restrictions on promoting GADT's In-Reply-To: <047.d0069eb42fb0ed6b29e5044acfcdabb7@haskell.org> References: <047.d0069eb42fb0ed6b29e5044acfcdabb7@haskell.org> Message-ID: <062.9ac09f8b8c7874f56f17a148354983b4@haskell.org> #7961: Remove restrictions on promoting GADT's -------------------------------------+------------------------------------ Reporter: danharaj | 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: #6024 -------------------------------------+------------------------------------ Changes (by altaic): * cc: william.knop.nospam@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 02:00:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 02:00:32 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.f73912d20ad82bcda56d15e8e7f066c7@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.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 chak): @thoughtpolice Is there any news on a timeline? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 06:30:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 06:30:39 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.7ef37352f9de51001d81d5a9e01cf0b9@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.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 simonpj): Manuel, you mean a timeline for 7.8.3? What would be helpful for you? (You can always build your own 7.8.3 working copy.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 08:01:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 08:01:18 -0000 Subject: [GHC] #9144: Incorrect error reported with poly-kinded type families In-Reply-To: <047.a2a118726fc4bf731f1c4cf9b107992e@haskell.org> References: <047.a2a118726fc4bf731f1c4cf9b107992e@haskell.org> Message-ID: <062.c84d3358bcc0e06e911be0d3a0b82e5c@haskell.org> #9144: Incorrect error reported with poly-kinded type families -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): Happily, I believe that this works on the 7.8 branch, and HEAD, and hence is already fixed. I don't know what the fix was! Still pending: add the test case to HEAD Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 08:08:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 08:08:02 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.0f8787d5244a7628a7076adf2d1d3327@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.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 thoughtpolice): I have posted an update here, please let me know what you think: http://www.haskell.org/pipermail/glasgow-haskell- users/2014-May/025022.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 09:15:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 09:15:35 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.222afc40dd40408e664052edea59ee7c@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.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 chak): Replying to [comment:18 simonpj]: > Manuel, you mean a timeline for 7.8.3? What would be helpful for you? (You can always build your own 7.8.3 working copy.) > > Simon Simon, I'm worried that the Haskell Platform might ship with 7.8.2 (including this bug). It would mean that the Platform would be unusable for Accelerate (and possibly all other EDSLs that use Andy Gill's method to implement observable sharing). Hence, I would much appreciate if 7.8.3 could be pushed out of the door in time to get included in the forthcoming Haskell Platform. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 10:14:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 10:14:27 -0000 Subject: [GHC] #9089: Local .ghci_history In-Reply-To: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> References: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> Message-ID: <064.b0580b8fa4d0abe7eb2c3a4107720981@haskell.org> #9089: Local .ghci_history -------------------------------------+------------------------------------ Reporter: jcristovao | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.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 jcristovao): I've added a diff showing a very simple implementation of this. I've only included code, not the corresponding documentation patch, but I can also do that, of course. What do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 10:15:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 10:15:02 -0000 Subject: [GHC] #9145: hp2ps produces odd negative sawtooth Message-ID: <047.03c89688f26e28e9e8632b9beeab4491@haskell.org> #9145: hp2ps produces odd negative sawtooth --------------------------+------------------------------------------------ Reporter: | Owner: blackdog | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: | Operating System: Linux Profiling | Type of failure: Incorrect result at runtime Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ i'm profiling a process with about 22gb of usage before the OOMkiller gets it. the heap profile for it is very odd: -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 10:17:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 10:17:13 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.746893ef4333e6e48ff52446384ae34a@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.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 --------------------------------------------+------------------------------ Comment (by archblob): I've gone ahead and just used {{{pprTypeForUser}}} to also print the type in the {{{:kind!}}} command, without any modifications in {{{pprTypeForUser}}}. The second patch fixes just {{{:kind!}}} and I think it can also be cherry-picked for 7.8.3 as it is just a one line change that does not interfere with anything else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 10:29:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 10:29:02 -0000 Subject: [GHC] #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files In-Reply-To: <048.42d4a7f7acd8ddc9572d2421e0cac286@haskell.org> References: <048.42d4a7f7acd8ddc9572d2421e0cac286@haskell.org> Message-ID: <063.41f2d69f7328776e7414783fc53bc3e4@haskell.org> #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files -------------------------------------+------------------------------------ Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 choenerzs): * cc: choener@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 11:56:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 11:56:31 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.b561d66676e91e16a718e11196ad1a39@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 Herbert Valerio Riedel ): In [changeset:"6ed54303e2d3f1ef19df1312331a1740eca3ccdc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6ed54303e2d3f1ef19df1312331a1740eca3ccdc" Replace DeriveDataTypeable by AutoDeriveTypeable This is a first step towards addressing #9111 This results in the following additional Typeable (exported) instances being generated (list was compiled by diff'ing hoogle txt output): instance Typeable CFile instance Typeable 'CFile instance Typeable CFpos instance Typeable 'CFpos instance Typeable CJmpBuf instance Typeable 'CJmpBuf instance Typeable ChItem instance Typeable QSem instance Typeable ID instance Typeable 'ID instance Typeable CONST instance Typeable Qi instance Typeable Qr instance Typeable Mp instance Typeable ConstrRep instance Typeable Fixity instance Typeable 'Prefix instance Typeable 'Infix instance Typeable Constr instance Typeable DataType instance Typeable DataRep instance Typeable Data instance Typeable HasResolution instance Typeable IsList Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 13:14:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 13:14:38 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.b06b22611d6ee2f04983b67face0e920@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.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 bgamari): There has been some discussion around this issue on [http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073203.html llvmdev]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 13:16:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 13:16:42 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.8d7e21ef366a5e5e1b22634e4becc8d7@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9142 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by bgamari): * blockedby: => 9142 Comment: As it turns out, the LLVM backend is currently broken due to #9142. This work will need to be delayed until this has been resolved and my symbol offset [http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073235.html patches] have been merged. My [https://github.com/bgamari/ghc/tree/llvm-demangle llvm-demangle] branch contains what should be a workable implementation of TNTC, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 13:44:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 13:44:48 -0000 Subject: [GHC] #1620: Bug in debugger 6.7.20070817 In-Reply-To: <044.53d725b3007e15a81cf7af24407f5869@haskell.org> References: <044.53d725b3007e15a81cf7af24407f5869@haskell.org> Message-ID: <059.ff1fe817d329d2125d3817978860a5f5@haskell.org> #1620: Bug in debugger 6.7.20070817 -------------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.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 pupfish): * cc: hvr (added) * failure: => None/Unknown Comment: I get the same error in 7.8.2 (using ghc-7.8.2-i386-unknown-linux- deb7.tar.xz from [http://www.haskell.org/ghc/download_ghc_7_8_2]): {{{ GHCi, version 7.8.2: 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> :cd ticket-1620/ Prelude> :l qsort.hs [1 of 1] Compiling Main ( qsort.hs, interpreted ) Ok, modules loaded: Main. *Main> :break 2 Breakpoint 0 activated at qsort.hs:2:16-47 *Main> :cd .. Warning: changing directory causes all loaded modules to be unloaded, because the search path has changed. Prelude> :cd ticket-1620/ Prelude> :l qsort.hs Failed to load interface for `Main' Use -v to see a list of the files searched for. Prelude> :l qsort.hs *** Exception: ModBreaks.modBreaks_array not initialised Prelude> }}} Contents of qsort.hs (from chapter [http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci- debugger.html 2.5. The GHCi Debugger] in the GHC user's guide): {{{ qsort [] = [] qsort (a:as) = qsort left ++ [a] ++ qsort right where (left,right) = (filter (<=a) as, filter (>a) as) main = print (qsort [8, 4, 0, 3, 1, 23, 11, 18]) }}} I can't seem to load any other files (even in a different directory) when this error occurs. I have to restart GHCi in order for it to work correctly again. I usually trigger this error by typing ":c" and accidentally hitting enter instead of typing ":co" (":continue"). I'm not sure if it's related to #1650, which was fixed by commit [https://github.com/ghc/ghc/commit/e2782137c799a08711cac0844418cc0345a7ceb5 e2782137c7]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 16:25:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 16:25:15 -0000 Subject: [GHC] #9080: GHC error on Win 8.1 64bit In-Reply-To: <043.c0aa3d5bf848f70ddef90000b43fffd8@haskell.org> References: <043.c0aa3d5bf848f70ddef90000b43fffd8@haskell.org> Message-ID: <058.22b294db92a182a53fc45bc222217d80@haskell.org> #9080: GHC error on Win 8.1 64bit ---------------------------------------+---------------------------------- Reporter: maun | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 19:59:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 19:59:15 -0000 Subject: [GHC] #9032: Panic with self-import In-Reply-To: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> References: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> Message-ID: <063.bd6e06215fcf6eeba2640de3f82c7a6d@haskell.org> #9032: Panic with self-import ---------------------------------------+----------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 monoidal): Here's a test case with no external dependencies, obtained from singletons and th-desugar; crashes 7.8.2 and HEAD. Put two files CustomStar.hs {{{ {-# LANGUAGE TypeFamilies, KindSignatures, TemplateHaskell #-} module CustomStar ( singletonStar ) where import Language.Haskell.TH import Language.Haskell.TH.Syntax ( Quasi(..) ) data family Sing a singFamilyName :: Name singFamilyName = ''Sing singletonStar :: Quasi q => q [Dec] singletonStar = do aName <- qNewName "z" return $ [DataInstD [] singFamilyName [SigT (VarT aName) StarT] [] []] }}} Star.hs {{{ {-# LANGUAGE CPP, TemplateHaskell, TypeFamilies #-} module Star where import CustomStar #ifdef ERR import Star #endif $(singletonStar) }}} and execute {{{ rm -f *.dyn_hi *.dyn_o *.hi *.o ghc CustomStar.hs ghc -c Star.hs ghc -c Star.hs -DERR }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 20:26:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 20:26:38 -0000 Subject: [GHC] #9146: GHC.TypeLits import don't quite work Message-ID: <045.e3c1b5113437eab4f3312fd97fc6ff0e@haskell.org> #9146: GHC.TypeLits import don't quite work ------------------------------------+------------------------------------- Reporter: yuriyt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If you explicitly import any of the things that are Compiler Magic from `GHC.TypeLits` you get an error: {{{ import GHC.TypeLits ((+), (-)) ... }}} {{{ [1 of 1] Compiling Main ( typelit_export_bug.hs, interpreted ) typelit_export_bug.hs:1:22: Module `GHC.TypeLits' does not export `(+)' typelit_export_bug.hs:1:27: Module `GHC.TypeLits' does not export `(-)' Failed, modules loaded: none. }}} If you do the opposite, it also doesn't work {{{ import GHC.TypeLits hiding ((+), (-)) ... }}} {{{ [1 of 1] Compiling Main ( typelit_export_bug.hs, interpreted ) typelit_export_bug.hs:3:1: Warning: Module `GHC.TypeLits' does not export `(+)' typelit_export_bug.hs:3:1: Warning: Module `GHC.TypeLits' does not export `(-)' }}} The use case is that I would like to define my own `+` and have one instance for `Nat` and others for other types of my choosing. It isn't more than a minor annoyance, however, there aren't many thing defined in `GHC.TypeLits` so I can write `import qualified GHC.TypeLits; import GHC.TypeLits (Nat, natVal, Symbol, symbolVal ...` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 20:34:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 20:34:28 -0000 Subject: [GHC] #9146: GHC.TypeLits import don't quite work In-Reply-To: <045.e3c1b5113437eab4f3312fd97fc6ff0e@haskell.org> References: <045.e3c1b5113437eab4f3312fd97fc6ff0e@haskell.org> Message-ID: <060.e90a4bd9204c125c0e4f96fa1f0a5d56@haskell.org> #9146: GHC.TypeLits import don't quite work -------------------------------------+------------------------------------ Reporter: yuriyt | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 rwbarton): * status: new => closed * resolution: => invalid Comment: Your import statement tries to import (ordinary value-level) ''functions'' `(+)`, `(-)` from `GHC.TypeLits`. Instead, use the `ExplicitNamespaces` language extension and write {{{ import GHC.TypeLits (type (+), type (-)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 20:36:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 20:36:29 -0000 Subject: [GHC] #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` In-Reply-To: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> References: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> Message-ID: <060.b088f98944f185545b5b56fec7bb6b6b@haskell.org> #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` -------------------------------------+------------------------------------ Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 igloo): Ah, well, it'll ''probably'' do what you want. But if, for example, at a usage site GHC can see the expression that has been put in `rqPostParams` and thinks that it is cheap, then it may evaluate a copy of it rather than sharing the value. #2273 is an example of something similar. To be sure, I think you'd need something like: {{{ foo :: RequestBuilder foo = do rq <- rGet let !rqPostParams' = rqPostParams rq ... rPut $! (rq { rqPostParams = rqPostParams' }) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 22:15:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 22:15:55 -0000 Subject: [GHC] #9144: Incorrect error reported with poly-kinded type families In-Reply-To: <047.a2a118726fc4bf731f1c4cf9b107992e@haskell.org> References: <047.a2a118726fc4bf731f1c4cf9b107992e@haskell.org> Message-ID: <062.b9e77210c945d725b2a5f516e1fe6306@haskell.org> #9144: Incorrect error reported with poly-kinded type families -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 Simon Peyton Jones ): In [changeset:"2745dfb56414269ea53e75136166a5ed0452b2af/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2745dfb56414269ea53e75136166a5ed0452b2af" Test Trac #9144 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 22:16:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 22:16:57 -0000 Subject: [GHC] #9144: Incorrect error reported with poly-kinded type families In-Reply-To: <047.a2a118726fc4bf731f1c4cf9b107992e@haskell.org> References: <047.a2a118726fc4bf731f1c4cf9b107992e@haskell.org> Message-ID: <062.24bd3aa835931cc77b8188b46618ee2f@haskell.org> #9144: Incorrect error reported with poly-kinded type families -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: polykinds/T9144 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * testcase: => polykinds/T9144 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 22:56:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 22:56:52 -0000 Subject: [GHC] #9089: Local .ghci_history In-Reply-To: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> References: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> Message-ID: <064.ec99057ab6a6127dbf5241a288c35f5d@haskell.org> #9089: Local .ghci_history -------------------------------------+------------------------------------ Reporter: jcristovao | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.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 nsch): * cc: nsch (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 27 22:58:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 May 2014 22:58:50 -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.b859ebaa5b8d2e54505465bc17077712@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: -------------------------------------+------------------------------------- Changes (by nsch): * cc: nsch (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 28 05:14:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 May 2014 05:14:10 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.885633321ea931edf48796a76a042d19@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.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 lerkok): @chak Looks like the next platform will indeed ship with 7.8.2; so maybe it's already too late: https://github.com/haskell/haskell-platform/blob /new-build/hptool/src/Releases2014.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 28 07:46:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 May 2014 07:46:15 -0000 Subject: [GHC] #5599: msys has bad Unicode support In-Reply-To: <046.3f625e98390ad242d829f3e1c223a6bd@haskell.org> References: <046.3f625e98390ad242d829f3e1c223a6bd@haskell.org> Message-ID: <061.eb4f14ed452f671b2a4175c8c7389c6b@haskell.org> #5599: msys has bad Unicode support -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.4.1 Resolution: fixed | Version: 7.2.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: llibraries/tests/IO/T3307, | Unknown/Multiple environment001 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => closed * testcase: => llibraries/tests/IO/T3307, environment001 * resolution: => fixed Comment: MSYS2 is way better than MSYS, so I think we should just adopt it. I'm making it an expected pass. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 28 08:20:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 May 2014 08:20:16 -0000 Subject: [GHC] #9140: Unboxed tuples fails in GHCi (7.8.2) In-Reply-To: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> References: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> Message-ID: <058.9fa4650b807573468d469d6aa74978d1@haskell.org> #9140: Unboxed tuples fails in GHCi (7.8.2) -------------------------------------+------------------------------------ Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by archblob): This should probably say {{{GHCi can't bind a variable of unlifted type: a :: (# Integer #)}}} and by doing {{{:set -XMonomorphismRestriction}}} it sure does. Otherwise it gets generalised to {{{Num a => (# a #)}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 28 12:37:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 May 2014 12:37:57 -0000 Subject: [GHC] #9140: Unboxed tuples fails in GHCi (7.8.2) In-Reply-To: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> References: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> Message-ID: <058.c6ccb69a3e082f34f10a6d4ad9a089e5@haskell.org> #9140: Unboxed tuples fails in GHCi (7.8.2) -------------------------------------+------------------------------------ Reporter: osa1 | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by archblob): * owner: => archblob -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 28 12:45:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 May 2014 12:45:41 -0000 Subject: [GHC] #8038: Old-time is not built when building GHC 7.7.20130704 (perf) for Windows x86_64 In-Reply-To: <044.55aa122bcc6b9f876d44905db661d111@haskell.org> References: <044.55aa122bcc6b9f876d44905db661d111@haskell.org> Message-ID: <059.db29ced0a9f5d0f622ed6b27f3e400ea@haskell.org> #8038: Old-time is not built when building GHC 7.7.20130704 (perf) for Windows x86_64 ----------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: libraries/old-time | Version: 7.7 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by gidyn): I had this when attempting a parallel make-install without running install first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 28 14:59:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 May 2014 14:59:01 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.fb123b8f364c30d6c579aa66b5abb5de@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by jstolarek): * owner: => jstolarek -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 28 15:07:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 May 2014 15:07:21 -0000 Subject: [GHC] #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` In-Reply-To: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> References: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> Message-ID: <060.5c744f189209851dbfb80c18c5ae381f@haskell.org> #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` -------------------------------------+------------------------------------ Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 refold): Replying to [comment:4 igloo]: Thanks, that's good to know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 28 18:34:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 May 2014 18:34:51 -0000 Subject: [GHC] #9147: defining data type in GHC results in ghc: panic! (the 'impossible' happened) Message-ID: <047.15a69e3a80350cc77ed80edf963dfa1d@haskell.org> #9147: defining data type in GHC results in ghc: panic! (the 'impossible' happened) ------------------------------------+------------------------------- Reporter: tdp93422 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------- vagrant at precise32:~/xml$ ghci -XOverloadedStrings 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> data Plant = Plant {common :: String, botanical :: String, zone :: Integer, light :: String, price :: String, availability :: String} deriving (read, show, eq, ord) ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for i386-unknown-linux): nameModule read{tv a9Q} 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 May 28 18:43:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 May 2014 18:43:08 -0000 Subject: [GHC] #9147: defining data type in GHC results in ghc: panic! (the 'impossible' happened) In-Reply-To: <047.15a69e3a80350cc77ed80edf963dfa1d@haskell.org> References: <047.15a69e3a80350cc77ed80edf963dfa1d@haskell.org> Message-ID: <062.cdce7642d528371c192bc7a37b12c336@haskell.org> #9147: defining data type in GHC results in ghc: panic! (the 'impossible' happened) -------------------------------+------------------------------------ Reporter: tdp93422 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------ Changes (by rwbarton): * status: new => closed * resolution: => duplicate Comment: Duplicate of #5961, fixed since GHC 7.6. `deriving (read, show, eq, ord)` should be `deriving (Read, Show, Eq, Ord)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 28 20:44:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 May 2014 20:44:54 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.16a4a083f1bcf0dbf88e34c07aa3e5db@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 4213 | Related Tickets: -------------------------------------+------------------------------------ Comment (by altaic): As I understand it from the thread on LLVMDev, the stumbling block is that we don't have a function definition's type until we see a call to it. LLVM doesn't care about the ordering of definitions and calls, so at least that's one thing we don't have to worry about. Several options came to mind in no particular order: 1. Store untyped definitions and calls in some sort of data structure until we've got a matching pair, at which point we know the type of the definition and we can queue it to be emitted as soon as the current object is finished being emitted. Unfortunately, I think this would mean that non-function data would be stored until the entire stream has been read. Additionally, functions being stored is dependent on the distance between a definition and a call-- if they are maximally unsorted, we could be storing the whole stream in memory. 2. Iterate through the cmm twice, collecting type information for definitions on the first pass, and emitting code on the second pass. The drawback is the extra time from processing the stream twice, and a bit of extra memory usage, dependent on the number of definitions. 3. Generate invalid LLVM IR and mangle definitions with the type info before handing it off to LLVM. This has all of the drawbacks of 2, with the added drawback of more cringeworthy text mangling. 4. Generate an auxiliary data structure when we're processing the STG which contains the type information to pass to the LLVM backend. I don't know how complicated this would be to implement, nor if the extra cruft in other stages of the compilation pipeline would be acceptable. 5. Generate LLVM from STG rather than cmm. As I understand it, David considered this when designing the LLVM backend, but decided against it due to code duplication. I imagine this would be a lot more work than the other options, though it may not have the drawbacks the other options have. 6. Convince the LLVM folks to reverse the change they made with aliases, or otherwise add a new feature to LLVM. Not sure if we were abusing aliases, or if our use case fits into some sort of feature they'd like to offer, but it might take awhile for an upstream fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 28 23:04:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 May 2014 23:04:34 -0000 Subject: [GHC] #9140: Unboxed tuples fails in GHCi (7.8.2) In-Reply-To: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> References: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> Message-ID: <058.fe9f571469cd823071df2c6054c60c70@haskell.org> #9140: Unboxed tuples fails in GHCi (7.8.2) -------------------------------------+------------------------------------ Reporter: osa1 | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by archblob): I have attached a fix that validates and I think it's correct, but it should be checked first as there maybe be something I have missed.I have ventured far deeper than I'm comfortable at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 28 23:26:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 May 2014 23:26:36 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.8bf9d901a8f787917f392d3e60a0c211@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9142 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bgamari): Replying to [comment:30 altaic]: > Replying to [comment:24 bgamari]: > > I hope that the LLVM folks would reject outright any proposal to change the semantics of an already released feature in a non-compatible way. > > An already released feature which is likely to have yet to be used in the wild. > It seems like there's a chance that the revision that you suggest might happen. In the [http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073260.html words] of LLVM-er Reid Kleckner, > I worry that symbol_offset combined with prefix are too low-level. What if we split this up into something like prefix data "prologue" data? Prefix data would be an arbitrary LLVM constant, and prologue data is a byte sequence of native executable code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 28 23:35:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 May 2014 23:35:29 -0000 Subject: [GHC] #9075: Per-thread weak pointer list (remove global lock on mkWeak#) In-Reply-To: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> References: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> Message-ID: <060.aa61683d66e9c2af1d83e23cbf722531@haskell.org> #9075: Per-thread weak pointer list (remove global lock on mkWeak#) --------------------------------------------+------------------------------ Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.9 Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 28 23:51:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 May 2014 23:51:39 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.058ddf6a541b5a5bdfe961fd19afd14b@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 4213 | Related Tickets: -------------------------------------+------------------------------------ Comment (by bgamari): Altaic, thanks for writing these down! I'd just like to mention one further complication (and please someone correct me if I'm wrong here): It's not sufficient to just match up definitions and calls as in some cases (e.g. symbols defined outside of the current compilation unit) we will never see the definition we are looking for. In the case of functions, we can sometimes infer the type with the information in a `CmmCall` node, but as far as I can tell there's no guarantee that we will ever see one of these (e.g. we may only see the symbol in a `CmmLabel` node within an expression). My thoughts on these options are, 1. In light of the external symbol problem, I'm not convinced it's worth paying this much to back out types for LLVM. The compiler has already demonstrated that the program is well-typed so the exercise doesn't gain us any safety (other than rejecting the occasional code generator bug). 2. See above 3. Eww. 4. I don't know how much work this work be either. Unless there's some user for this sort of information in downstream consumers other than the LLVM codegen I'm not convinced we want to go this route. 5. An interesting idea that I hadn't considered. Perhaps if the C-- lowering code were refactored a bit the code duplication could be reduced. Perhaps (4) is better in this case? Either way, this sounds like a lot of work for relative little benefit (could LLVM better optimize the STG representation? I suspect not; C-- is about the right level of abstraction for LLVM's IR). 6. This is probably the most likely option. I've been doing a pretty poor job in conveying our needs the LLVM folks but we'll see what they say. Our usecase doesn't seem too outlandish so there should be a path forward one way or another. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 01:29:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 01:29:53 -0000 Subject: [GHC] #9075: Per-thread weak pointer list (remove global lock on mkWeak#) In-Reply-To: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> References: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> Message-ID: <060.0bce8ef7d5b45ac27705f499a5bf90cf@haskell.org> #9075: Per-thread weak pointer list (remove global lock on mkWeak#) --------------------------------------------+------------------------------ Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.9 Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by ezyang): * owner: simonmar => ezyang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 07:21:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 07:21:50 -0000 Subject: [GHC] #9075: Per-thread weak pointer list (remove global lock on mkWeak#) In-Reply-To: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> References: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> Message-ID: <060.163a900633483c51aeacc8b6c8b54dc5@haskell.org> #9075: Per-thread weak pointer list (remove global lock on mkWeak#) --------------------------------------------+------------------------------ Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.9 Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by ezyang): Suggested patch, still validating: {{{ From 28cb3e18051db7d858bd913c002aedb78630bcdb Mon Sep 17 00:00:00 2001 From: "Edward Z. Yang" Date: Thu, 29 May 2014 00:18:33 -0700 Subject: [PATCH] Per-capability nursery weak pointer lists. Signed-off-by: Edward Z. Yang --- rts/Capability.c | 2 ++ rts/Capability.h | 5 +++++ rts/PrimOps.cmm | 9 +++++---- rts/RetainerProfile.c | 6 ++++++ rts/RtsStartup.c | 5 ++++- rts/sm/GC.c | 1 + rts/sm/MarkWeak.c | 18 ++++++++++++++++++ rts/sm/MarkWeak.h | 1 + utils/deriveConstants/DeriveConstants.hs | 2 ++ 9 files changed, 44 insertions(+), 5 deletions(-) diff --git a/rts/Capability.c b/rts/Capability.c index 16b71b7..805a35b 100644 --- a/rts/Capability.c +++ b/rts/Capability.c @@ -273,6 +273,8 @@ initCapability( Capability *cap, nat i ) cap->mut_lists[g] = NULL; } + cap->weak_ptr_list_hd = NULL; + cap->weak_ptr_list_tl = NULL; cap->free_tvar_watch_queues = END_STM_WATCH_QUEUE; cap->free_invariant_check_queues = END_INVARIANT_CHECK_QUEUE; cap->free_trec_chunks = END_STM_CHUNK_LIST; diff --git a/rts/Capability.h b/rts/Capability.h index f342d92..d36d502 100644 --- a/rts/Capability.h +++ b/rts/Capability.h @@ -79,6 +79,11 @@ struct Capability_ { // full pinned object blocks allocated since the last GC bdescr *pinned_object_blocks; + // per-capability weak pointer list associated with nursery (older + // lists stored in generation object) + StgWeak *weak_ptr_list_hd; + StgWeak *weak_ptr_list_tl; + // Context switch flag. When non-zero, this means: stop running // Haskell code, and switch threads. int context_switch; diff --git a/rts/PrimOps.cmm b/rts/PrimOps.cmm index 1dc232d..84bcea5 100644 --- a/rts/PrimOps.cmm +++ b/rts/PrimOps.cmm @@ -577,10 +577,11 @@ stg_mkWeakzh ( gcptr key, StgWeak_finalizer(w) = finalizer; StgWeak_cfinalizers(w) = stg_NO_FINALIZER_closure; - ACQUIRE_LOCK(sm_mutex); - StgWeak_link(w) = generation_weak_ptr_list(W_[g0]); - generation_weak_ptr_list(W_[g0]) = w; - RELEASE_LOCK(sm_mutex); + StgWeak_link(w) = Capability_weak_ptr_list_hd(MyCapability()); + Capability_weak_ptr_list_hd(MyCapability()) = w; + if (Capability_weak_ptr_list_tl(MyCapability()) == NULL) { + Capability_weak_ptr_list_tl(MyCapability()) = w; + } IF_DEBUG(weak, ccall debugBelch(stg_weak_msg,w)); diff --git a/rts/RetainerProfile.c b/rts/RetainerProfile.c index bdfc831..bfc9624 100644 --- a/rts/RetainerProfile.c +++ b/rts/RetainerProfile.c @@ -1781,6 +1781,12 @@ computeRetainerSet( void ) // // The following code assumes that WEAK objects are considered to be roots // for retainer profilng. + for (n = 0; n < n_capabilities; n++) { + // NB: after a GC, all nursery weak_ptr_lists have been migrated + // to the global lists living in the generations + ASSERT(capabilities[n]->weak_ptr_list_hd == NULL); + ASSERT(capabilities[n]->weak_ptr_list_tl == NULL); + } for (g = 0; g < RtsFlags.GcFlags.generations; g++) { for (weak = generations[g].weak_ptr_list; weak != NULL; weak = weak->link) { // retainRoot((StgClosure *)weak); diff --git a/rts/RtsStartup.c b/rts/RtsStartup.c index 15e48a6..06e888c 100644 --- a/rts/RtsStartup.c +++ b/rts/RtsStartup.c @@ -304,7 +304,7 @@ hs_add_root(void (*init_root)(void) STG_UNUSED) static void hs_exit_(rtsBool wait_foreign) { - nat g; + nat g, i; if (hs_init_count <= 0) { errorBelch("warning: too many hs_exit()s"); @@ -336,6 +336,9 @@ hs_exit_(rtsBool wait_foreign) exitScheduler(wait_foreign); /* run C finalizers for all active weak pointers */ + for (i = 0; i < n_capabilities; i++) { + runAllCFinalizers(capabilities[i]->weak_ptr_list_hd); + } for (g = 0; g < RtsFlags.GcFlags.generations; g++) { runAllCFinalizers(generations[g].weak_ptr_list); } diff --git a/rts/sm/GC.c b/rts/sm/GC.c index d22a31e..2122385 100644 --- a/rts/sm/GC.c +++ b/rts/sm/GC.c @@ -378,6 +378,7 @@ GarbageCollect (nat collect_gen, #endif // Mark the weak pointer list, and prepare to detect dead weak pointers. + collectFreshWeakPtrs(); markWeakPtrList(); initWeakForGC(); diff --git a/rts/sm/MarkWeak.c b/rts/sm/MarkWeak.c index af953cd..1a7359f 100644 --- a/rts/sm/MarkWeak.c +++ b/rts/sm/MarkWeak.c @@ -341,6 +341,24 @@ static void tidyThreadList (generation *gen) } } +void collectFreshWeakPtrs() +{ + nat i; + generation *gen = &generations[0]; + // move recently allocated weak_ptr_list to the old list as well + for (i = 0; i < n_capabilities; i++) { + Capability *cap = capabilities[i]; + if (cap->weak_ptr_list_tl != NULL) { + cap->weak_ptr_list_tl->link = gen->weak_ptr_list; + gen->weak_ptr_list = cap->weak_ptr_list_hd; + cap->weak_ptr_list_tl = NULL; + cap->weak_ptr_list_hd = NULL; + } else { + ASSERT(cap->weak_ptr_list_hd == NULL); + } + } +} + /* ----------------------------------------------------------------------------- Evacuate every weak pointer object on the weak_ptr_list, and update the link fields. diff --git a/rts/sm/MarkWeak.h b/rts/sm/MarkWeak.h index f9bacfa..bd0231d 100644 --- a/rts/sm/MarkWeak.h +++ b/rts/sm/MarkWeak.h @@ -20,6 +20,7 @@ extern StgWeak *old_weak_ptr_list; extern StgTSO *resurrected_threads; extern StgTSO *exception_threads; +void collectFreshWeakPtrs ( void ); void initWeakForGC ( void ); rtsBool traverseWeakPtrList ( void ); void markWeakPtrList ( void ); diff --git a/utils/deriveConstants/DeriveConstants.hs b/utils/deriveConstants/DeriveConstants.hs index d15f619..9bf2160 100644 --- a/utils/deriveConstants/DeriveConstants.hs +++ b/utils/deriveConstants/DeriveConstants.hs @@ -349,6 +349,8 @@ wanteds = concat ,structField C "Capability" "context_switch" ,structField C "Capability" "interrupt" ,structField C "Capability" "sparks" + ,structField C "Capability" "weak_ptr_list_hd" + ,structField C "Capability" "weak_ptr_list_tl" ,structField Both "bdescr" "start" ,structField Both "bdescr" "free" -- 1.9.2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 07:29:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 07:29:48 -0000 Subject: [GHC] #9148: tryReadMVar locks up the process with +RTS -N2 or greater Message-ID: <047.60c6cfd551628c7f0ad6d52e55f6dbba@haskell.org> #9148: tryReadMVar locks up the process with +RTS -N2 or greater ------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The new `tryReadMVar` is missing an `unlockClosure` call, which causes the whole process to hang when used with +RTS -N2 or greater. I'll push the fix shortly. We should treat this as a blocker for 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 08:11:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 08:11:15 -0000 Subject: [GHC] #9148: tryReadMVar locks up the process with +RTS -N2 or greater In-Reply-To: <047.60c6cfd551628c7f0ad6d52e55f6dbba@haskell.org> References: <047.60c6cfd551628c7f0ad6d52e55f6dbba@haskell.org> Message-ID: <062.88c6abf32a66020f4f02af8e767edf14@haskell.org> #9148: tryReadMVar locks up the process with +RTS -N2 or greater -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): Eep, sorry about that! That's what I get for cargo-culting the test-case definitions and forgetting to have them run multithreaded as well. Are you going to push updates to the test suite as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 08:23:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 08:23:18 -0000 Subject: [GHC] #9075: Per-thread weak pointer list (remove global lock on mkWeak#) In-Reply-To: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> References: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> Message-ID: <060.e4dfdfbda7d5e4e8f37cbf9e1a5109bb@haskell.org> #9075: Per-thread weak pointer list (remove global lock on mkWeak#) --------------------------------------------+------------------------------ Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.9 Resolution: | Keywords: easy 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): Patch looks good to me, nice work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 08:40:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 08:40:24 -0000 Subject: [GHC] #9140: Unboxed tuples fails in GHCi (7.8.2) In-Reply-To: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> References: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> Message-ID: <058.2a891303672e7c140fed1e90c2492462@haskell.org> #9140: Unboxed tuples fails in GHCi (7.8.2) -------------------------------------+------------------------------------ Reporter: osa1 | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by archblob): The error message will print the binding without a type signature if it was inferred and not given by the user and would be a bit of a nuisance to add. I suggest that we maybe just print the thype like so {{{a :: forall a. Num a => (# a #)}}} instead of {{{a = (# 1, 3 #) :: forall a. Num a => (# a #) }}}. I don't think any valuable info is really lost given that the location information is also printed. If this is not ok I will see what I can do with regard to printing the binding as per the second example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 08:40:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 08:40:53 -0000 Subject: [GHC] #9140: Unboxed tuples fails in GHCi (7.8.2) In-Reply-To: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> References: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> Message-ID: <058.fddbd24ca291e46d3bca9cbcedb0816f@haskell.org> #9140: Unboxed tuples fails in GHCi (7.8.2) -------------------------------------+------------------------------------ Reporter: osa1 | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by archblob): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 10:41:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 10:41:02 -0000 Subject: [GHC] #5610: Improve "Unacceptable argument type in foreign declaration" error message In-Reply-To: <046.fdf192326307b04dbc38c6023f0d4891@haskell.org> References: <046.fdf192326307b04dbc38c6023f0d4891@haskell.org> Message-ID: <061.bf8413f0b3eb6fe16747352e3930699e@haskell.org> #5610: Improve "Unacceptable argument type in foreign declaration" error message -------------------------------------------------+------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.4.1 Component: Compiler (Type checker) | Version: Resolution: | 7.6.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by archblob): I have time to work on this and do a little refactoring to improve the error messages. The comment history is a little confusing and I'm not really sure that a better error message is the only thing requested here, and if the whole importing of constructors for foreign declarations story is also in need of fixing. It's the same story with #7243, if someone could make things clear for me I would be happy to start working. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 10:52:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 10:52:53 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.7009be8fe9292abaa3536556d5f1eea9@haskell.org> #9136: Constant folding in Core could be better --------------------------------------------+------------------------------ Reporter: simonpj | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): @SPJ: Since you opened the ticket I guess it?s your call whether you think this is worth it, even if nofib shows no measurable improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 11:32:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 11:32:48 -0000 Subject: [GHC] #5610: Improve "Unacceptable argument type in foreign declaration" error message In-Reply-To: <046.fdf192326307b04dbc38c6023f0d4891@haskell.org> References: <046.fdf192326307b04dbc38c6023f0d4891@haskell.org> Message-ID: <061.5e57b935b205a8b179ca3b788e497cf5@haskell.org> #5610: Improve "Unacceptable argument type in foreign declaration" error message -------------------------------------------------+------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.4.1 Component: Compiler (Type checker) | Version: Resolution: | 7.6.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by archblob): * cc: fcsernik@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 11:44:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 11:44:07 -0000 Subject: [GHC] #9140: Unboxed tuples fails in GHCi (7.8.2) In-Reply-To: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> References: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> Message-ID: <058.72be681317428db9de36676b1d6635b7@haskell.org> #9140: Unboxed tuples fails in GHCi (7.8.2) -------------------------------------+------------------------------------ Reporter: osa1 | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by archblob): * cc: simonpj@? (added) Comment: This looks like your area of expertise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 13:05:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 13:05:34 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.035282611da8c4ad1592e6b1605e9a68@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 4213 | Related Tickets: -------------------------------------+------------------------------------ Comment (by scpmw): Function definitions aren't really the problem. Once we know the live global registers, we'd know their type (see `llvmFunTy`). We could /theoretically/ find these from a call in Cmm. However, I feel like this is the wrong approach anyway. Even if we could enumerate all offending Cmm constructs at this point, there is no telling whether we will have more problematic Cmm in the future. We don't want to get into a game of whack-a-mole just for a rather cosmetic feature like streaming. Bringing Stg into the fold would most likely to make that problem even worse. In my mind, we should wait for the LLVM situation to stabilize, then we'll implement either 1. What we have right now, with possibly minor changes 2. A step prepending aliases, if this is what LLVM likes better (unlikely, but I'll test it) 3. A search-and-replace step where we first emit placeholders, then later fill in the types (your option 3) 4. Remove streaming entirely (pretty much equivalent to your options 1 and 2) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 13:27:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 13:27:43 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.5603b7c54e3683ceac8798793b677dd8@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by jstolarek): I have spent some time on this today and I have some questions. As I understand Simon's comment the idea is to handle the arrow do-notation similarly to the monadic do-notation. Looking at the handling of monadic bind I see that indeed each `BindStmt` stores a unique call to `>>=` and `fail`. These are [https://github.com/ghc/ghc/blob/master/compiler/rename/RnExpr.lhs#L681 generated in the renamer] and then [https://github.com/ghc/ghc/blob/master/compiler/deSugar/DsExpr.lhs#L775 converted to explicit lambda by the desugarer]. For arrow operations - `arr`, `(>>>)`, `first` and possibly `loop`, `(|||)` and `app` - [https://github.com/ghc/ghc/blob/master/compiler/rename/RnExpr.lhs#L416 renamer creates a shared table of names]. [https://github.com/ghc/ghc/blob/master/compiler/deSugar/DsArrows.lhs#L69 Desugarer creates a command environment] that contains identifiers that are shared by all desugared expressions. This basicaly rephrases what Simon wrote. Now I have reached a point where I'm not sure what to do. For monads calls to bind are introduced only (?) when we encounter `BindStmt`. For arrows it is not that simple. For example calls to `>>>` are introduced when we desugar `BodyStmt`, `BindStmt` and `RecStmt` but also by [https://github.com/ghc/ghc/blob/master/compiler/deSugar/DsArrows.lhs#L94 `do_compose`], which does not correspond to any particular source construct but is called in many places of arrow notation desugarer. Another place where we introduce `>>>` is [https://github.com/ghc/ghc/blob/master/compiler/deSugar/DsArrows.lhs#L1038 desugaring of CmdLStmt]. I might be wrong, but it seems to me that adding `SyntaxExpr` to `HsCmd` constructors won't help us here. We need a way of generating fresh calls to desugared arrow operations out of thin air. I also don't understand why is arrow notation [https://github.com/ghc/ghc/blob/master/compiler/rename/RnExpr.lhs#L803 considered not rebindable]? The comment suggests that this is because !DsArrows performs a separate desugaring of arrow notation. Am I right to think that after this change is implemented arrow notation will be marked as rebindable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 13:35:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 13:35:06 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.5cb80bc25390bc5905775478fbbd0a7c@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by jstolarek): * cc: ross@?, jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 16:12:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 16:12:16 -0000 Subject: [GHC] #9149: Description of openFileBlocking is wrong Message-ID: <044.5c835f25372cd920667deec884e080e9@haskell.org> #9149: Description of openFileBlocking is wrong ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The documentation states: ''Like openFile, but opens the file in ordinary blocking mode. This can be useful for opening a FIFO for reading: if we open in non-blocking mode then the open will fail if there are no writers, whereas a blocking open will block until a writer appears. '' but I think this is the wrong way around, and should be: ''Like openFile, but opens the file in ordinary blocking mode. This can be useful for opening a FIFO for writing: if we open in non-blocking mode then the open will fail if there are no readers, whereas a blocking open will block until a reader appears. '' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 16:56:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 16:56:46 -0000 Subject: [GHC] #9150: libraries/time: parseTime barfs on leading space in format string Message-ID: <042.1b275f11b4cf8dd08f74601d64b4d5b4@haskell.org> #9150: libraries/time: parseTime barfs on leading space in format string --------------------------+------------------------------------------------ Reporter: mjo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries (other) | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ This used to work around 1.4.0, one of my test suites caught it: {{{ module Main where import Data.Time.Clock import Data.Time.Format import System.Locale main :: IO () main = do putStrLn "Trailing space is handled:" print $ (parseTime defaultTimeLocale "%M " "15 " :: Maybe UTCTime) putStrLn "\nBut leading space isn't:" print $ (parseTime defaultTimeLocale " %M" " 15" :: Maybe UTCTime) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 17:10:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 17:10:52 -0000 Subject: [GHC] #9151: Recursive default associated types don't kind-generalize properly Message-ID: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> #9151: Recursive default associated types don't kind-generalize properly ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE PolyKinds, DataKinds, TypeFamilies, UndecidableInstances #-} module Bug where import Data.Proxy class PEnum (kproxy :: KProxy a) where type ToEnum (x :: a) :: Bool type ToEnum x = TEHelper type TEHelper = ToEnum Int }}} I get {{{ /Users/rae/temp/Bug.hs:11:24: The first argument of ?ToEnum? should have kind ?a?, but ?Int? has kind ?*? In the type ?ToEnum Int? In the type declaration for ?TEHelper? }}} I believe my original code should kind-check, as `ToEnum` should be applicable to any kind. My guess is that this sort of recursion isn't properly accounted for in the kind-checking algorithm in !TcTyClsDecls, and that we kind-check `TEHelper` before `ToEnum` is kind-generalized. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 17:52:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 17:52:45 -0000 Subject: [GHC] #9152: internal error: scavenge_stack: weird activation record found on stack Message-ID: <042.a2974f03a7d25533cb345aa8df8a5d28@haskell.org> #9152: internal error: scavenge_stack: weird activation record found on stack ----------------------------------+--------------------------------- Reporter: mjo | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- This is a semi-reproducible error that shows up in the test suite for http://hackage.haskell.org/package/htsn-import. You have to run the test suite a few times, but it does crash regularly. Steps to reproduce: {{{ $ ghc --make -O2 -o setup Setup.hs $ ./setup configure --user --enable-tests $ ./setup build $ ./setup test testsuite }}} If that doesn't crash, `./setup test testsuite` can be re-run until it does. Sample crash: {{{ $ ./setup test testsuite Running 1 test suites... Test suite testsuite: RUNNING... All tests AutoRacingSchedule tests cascading delete tests deleting auto_racing_schedules deletes its children: OK deleting auto_racing_schedules deletes its children (miles track length): OK pickle-unpickle tests pickle composed with unpickle is the identity: OK pickle composed with unpickle is the identity (miles track length): OK unpickle tests unpickling succeeds: OK unpickling succeeds (non-int team_id): OK Heartbeat tests pickle composed with unpickle is the identity: OK unpickling succeeds: OK Injuries tests deleting an injuries deletes its children: OK pickle composed with unpickle is the identity: OK unpickling succeeds: OK InjuriesDetail tests cascading delete tests delete of injuries_detail deletes its children: OK delete of injuries_detail deletes its children (non-int team_id): OK pickle-unpickle tests pickle composed with unpickle is the identity: OK pickle composed with unpickle is the identity (non-int team_id): OK unpickle tests unpickling succeeds: OK unpickling succeeds (non-int team_id): OK News tests news fields get correct database names: OK cascading delete tests deleting news deletes its children: OK pickle-unpickle tests pickle composed with unpickle is the identity: OK pickle composed with unpickle is the identity (with Editor): OK unpickle tests unpickling succeeds: OK unpickling succeeds (with Editor): OK Odds tests cascading delete tests deleting odds deletes its children: OK deleting odds deletes its children (non-int team_id): OK deleting odds deleted its children (positive(+) line): OK deleting odds deleted its children (large file): OK pickle-unpickle tests pickle composed with unpickle is the identity: OK pickle composed with unpickle is the identity (non-int team_id): OK pickle composed with unpickle is the identity (positive(+) line): OK pickle composed with unpickle is the identity (large file): testsuite: internal error: scavenge_stack: weird activation record found on stack: 415597384 (GHC version 7.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Test suite testsuite: FAIL Test suite logged to: dist/test/htsn-import-0.0.5-testsuite.log 0 of 1 test suites (0 of 1 test cases) passed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 20:09:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 20:09:41 -0000 Subject: [GHC] #9152: internal error: scavenge_stack: weird activation record found on stack In-Reply-To: <042.a2974f03a7d25533cb345aa8df8a5d28@haskell.org> References: <042.a2974f03a7d25533cb345aa8df8a5d28@haskell.org> Message-ID: <057.37bdf803a130ed1e98bf75322defe6cd@haskell.org> #9152: internal error: scavenge_stack: weird activation record found on stack -----------------------------------+---------------------------------- Reporter: mjo | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 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 simonmar): * status: new => closed * resolution: => duplicate * milestone: => 7.8.3 Comment: Probably #9045 - please test with 7.8.3 when the release candidate is out, and if the bug still persists then reopen the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 20:30:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 20:30:40 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.4cfd6975598d76c76b7263c482b06470@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): Yes, I think if we made the change suggested here, arrow notation would become rebindable. I think the idea would be that each construct becomes decorated with the overloaded operations necessary to desugar it. Indeed, in the case of monad syntax, the effect is exactly as if you first desugared and then typechecked. For example `x <- e; rest` desugars into something like `e >>= \x -> rest`. So to typecheck `x <- e` (a `BindStmt`), we look up `>>=`, instantiate its type, unify `e`'s type with the first argument type of `>>=`, and so on. We hang onto the instantiated `>>=` in the typechecked `BindStmt`. The idea is to do the same for arrows, but I have little idea of how hard it is. But the thought experiment of first desugaring and then type checking may be an instructive one. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 22:15:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 22:15:13 -0000 Subject: [GHC] #5916: runST isn't free In-Reply-To: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> References: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> Message-ID: <059.a2ff13b68b8ae4bb8b6b4c2b1556eff6@haskell.org> #5916: runST isn't free -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | 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: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by WrenThornton): * cc: winterkoninkje@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 29 22:15:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 May 2014 22:15:56 -0000 Subject: [GHC] #5916: runST isn't free In-Reply-To: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> References: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> Message-ID: <059.dcf5bcf39d2bf7388e4e08a397d5d212@haskell.org> #5916: runST isn't free -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | 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: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by WrenThornton): * cc: winterkoninkje@? (removed) * cc: wren@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 00:34:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 00:34:43 -0000 Subject: [GHC] #9153: TcCoercible test is failing with context reduction stack overflow Message-ID: <045.f5d79c915ee5723d2f4d907329f0b069@haskell.org> #9153: TcCoercible test is failing with context reduction stack overflow ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Test Suite | 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: | ------------------------------------+------------------------------------- Here is the error: {{{ TcCoercible.hs:62:12: Context reduction stack overflow; size = 21 Use -fcontext-stack=N to increase stack size to N Coercible Int Int In the expression: coerce In the first argument of ?print?, namely ?(coerce $ (FixEither (Left age) :: FixEither Age) :: Either Int (FixEither Int))? In a stmt of a 'do' block: print (coerce $ (FixEither (Left age) :: FixEither Age) :: Either Int (FixEither Int)) }}} I do not know enough to know if bumping the stack size is correct. Additionally, when run as GHCi I get: {{{ =====> TcCoercible(ghci) 2784 of 3970 [0, 7, 0] cd ./typecheck/should_run && '/home/hs01/ezyang/ghc-validate/inplace/bin /ghc-stage2' -fforce-re comp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history Tc Coercible.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS TcCo ercible.interp.stdout 2>TcCoercible.interp.stderr Actual stderr output differs from expected: --- /dev/null 2014-02-15 17:35:19.578872448 -0800 +++ ./typecheck/should_run/TcCoercible.run.stderr 2014-05-29 16:27:30.476701835 -0700 @@ -0,0 +1,2 @@ + +TcCoercible:7:30: Not in scope: ?Main.main? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 01:09:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 01:09:23 -0000 Subject: [GHC] #9075: Per-thread weak pointer list (remove global lock on mkWeak#) In-Reply-To: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> References: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> Message-ID: <060.22174a53ef8d7915c45ec557cd298de7@haskell.org> #9075: Per-thread weak pointer list (remove global lock on mkWeak#) --------------------------------------------+------------------------------ Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.9 Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by ezyang): Posted patch fails memo001 test, investigating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 03:09:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 03:09:14 -0000 Subject: [GHC] #9075: Per-thread weak pointer list (remove global lock on mkWeak#) In-Reply-To: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> References: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> Message-ID: <060.e507375b26e2d8d145201eb71167a8ce@haskell.org> #9075: Per-thread weak pointer list (remove global lock on mkWeak#) --------------------------------------------+------------------------------ Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.9 Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Edward Z. Yang ): In [changeset:"723095b0e4c5838c7eefd757af56ab2a7c614801/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="723095b0e4c5838c7eefd757af56ab2a7c614801" Per-capability nursery weak pointer lists, fixes #9075 Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 03:11:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 03:11:05 -0000 Subject: [GHC] #9075: Per-thread weak pointer list (remove global lock on mkWeak#) In-Reply-To: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> References: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> Message-ID: <060.15aed34f900feceac5aad888556b7c93@haskell.org> #9075: Per-thread weak pointer list (remove global lock on mkWeak#) --------------------------------------------+------------------------------ Reporter: ezyang | Owner: ezyang Type: bug | Status: merge Priority: low | Milestone: Component: Runtime System | Version: 7.9 Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by ezyang): * status: new => merge Comment: (The bug was collectFreshWeakPtrs was being called too late, after some scavenging had occurred). I am indifferent to whether or not this feature goes in 7.8 stable, but maybe someone else wants to lobby for it, so I'll leave it as merge for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 07:37:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 07:37:16 -0000 Subject: [GHC] #9153: TcCoercible test is failing with context reduction stack overflow In-Reply-To: <045.f5d79c915ee5723d2f4d907329f0b069@haskell.org> References: <045.f5d79c915ee5723d2f4d907329f0b069@haskell.org> Message-ID: <060.e6c791bcaa35b73fae5418554364fb30@haskell.org> #9153: TcCoercible test is failing with context reduction stack overflow -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Test Suite | 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): This must be collateral damage from #9117 ([changeset:7e78faf033405bd5f3b6b787343c98e33d767bda/ghc], I just wonder it validated for me back then... I?m rebuilding my tree to find out. The discussion which behaviour is better (around [ticket:9117#comment:21]) concluded that recursive newtypes are going to be treated novercally, and otherwise the new behaviour is better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 08:05:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 08:05:09 -0000 Subject: [GHC] #9153: TcCoercible test is failing with context reduction stack overflow In-Reply-To: <045.f5d79c915ee5723d2f4d907329f0b069@haskell.org> References: <045.f5d79c915ee5723d2f4d907329f0b069@haskell.org> Message-ID: <060.7cd958ad4fab64dca63e0ac36b4b78cd@haskell.org> #9153: TcCoercible test is failing with context reduction stack overflow -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Test Suite | 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:"5a392ca14b3698d1be5166dd7a6a40b268e948e5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5a392ca14b3698d1be5166dd7a6a40b268e948e5" Disable FixEither tests in TcCoercible This fixes #9153. It has not been noticed before because this TcCoercible does not run with "make fast=YES" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 08:05:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 08:05:54 -0000 Subject: [GHC] #9153: TcCoercible test is failing with context reduction stack overflow In-Reply-To: <045.f5d79c915ee5723d2f4d907329f0b069@haskell.org> References: <045.f5d79c915ee5723d2f4d907329f0b069@haskell.org> Message-ID: <060.3c978751253e98776d315dbfc39a07d0@haskell.org> #9153: TcCoercible test is failing with context reduction stack overflow -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Test Suite | 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 nomeata): * status: new => closed * resolution: => fixed Comment: Too bad that travis?s timelimit prevents us from running the tests without `fast=Yes`, otherwise I would have noticed this much earlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 08:49:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 08:49:53 -0000 Subject: [GHC] #9148: tryReadMVar locks up the process with +RTS -N2 or greater In-Reply-To: <047.60c6cfd551628c7f0ad6d52e55f6dbba@haskell.org> References: <047.60c6cfd551628c7f0ad6d52e55f6dbba@haskell.org> Message-ID: <062.72ea5b71daf64793cf9cde9658730035@haskell.org> #9148: tryReadMVar locks up the process with +RTS -N2 or greater -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Marlow ): In [changeset:"96a95f0513de785a185fd8a46c7ed2643f698295/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="96a95f0513de785a185fd8a46c7ed2643f698295" Fix missing unlockClosure() call in tryReadMVar (#9148) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 09:06:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 09:06:04 -0000 Subject: [GHC] #9153: TcCoercible test is failing with context reduction stack overflow In-Reply-To: <045.f5d79c915ee5723d2f4d907329f0b069@haskell.org> References: <045.f5d79c915ee5723d2f4d907329f0b069@haskell.org> Message-ID: <060.479b8206df2f7a4f033a86ac0195db46@haskell.org> #9153: TcCoercible test is failing with context reduction stack overflow -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Test Suite | 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 simonpj): Just to be clear, the relevant test is this: {{{ newtype FixEither a = FixEither (Either a (FixEither a)) deriving Show -- And then try -- Coercible (FixEither Age) (Either Int (FixEither Int)) -- Coercible (Either Int (FixEither Age)) (FixEither Age) }}} It is entirely moot whether these two "should" work or not. But #9117 suggests not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 09:25:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 09:25:41 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.2722b6c8c4db251f17a2262c0f77f4b0@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 Simon Peyton Jones ): In [changeset:"9e10963e394680dbb1b964c66cb428a2aa03df09/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9e10963e394680dbb1b964c66cb428a2aa03df09" Improve Note [Order of Coercible Instances] about Trac #9117 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 09:26:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 09:26:19 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.14cf1b4ca69c0f45d3db5a673ccbd160@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): See also #9153 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 09:49:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 09:49:46 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.41f24ef848b91e2723e626a802ac85f5@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by jstolarek): > I think the idea would be that each construct becomes decorated with the overloaded operations necessary to desugar it. Technically this is simple but I feel the resulting design will be inelegant. We use `StmtLR` datatype to represent both the monadic and arrow do-notation. This means that desugaring `BindStmt` inside a monadic `do` requires calls to `>>=` and `fail` ([https://github.com/ghc/ghc/blob/master/compiler/deSugar/DsExpr.lhs#L765 here]), whereas desugaring the same `BindStmt` inside the arrow `do` requires a call to `first`, two different calls to `>>>` and two different calls to `arr` ([https://github.com/ghc/ghc/blob/master/compiler/deSugar/DsArrows.lhs#L838 here]). Adding five extra fields to `BindStmt` feels like a lot of unnecessary noise. Perhaps creating helper datatypes to store these extra identifiers would be better? But then every (or almost every) constructor of `StmtLR` would require such extra datatype. I don't yet see a clean solution. Augmenting `HsCmd` with this extra information seems relatively simple, with `HsCmdCase` being the only tricky case. (It reuses a call to `(|||)` in every branch of a case ([https://github.com/ghc/ghc/blob/master/compiler/deSugar/DsArrows.lhs#L555 here]), which means we need to generate a whole list of new identifiers.) What do you think about the design I describe above? Is it acceptable? Janek -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 09:56:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 09:56:47 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.f3fffece2b811b6c039c1b54b9f399d4@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): Well in principle with rebindable syntax, each of those calls to `>>>` at different types (I assume they are at different types?) could in principle be overloaded a different way. So * There really is no alternative to generating them all * I really don't know what sort of error message you'd generate for the user if one of the calls to `>>>` failed but the others didn't, say. Before going further I think we need help from Ross, to see if the "thought experiment of desugar and then typecheck" makes sense for arrows. We MUST give a clear story to the programmer of what will type check and what will not. We have that for rebindable syntax and do-notation. I don't know what the story is for rebindable syntax and arrow notation. Until we know that we can't implement anything. > What do you think about the design I describe above? What precisely is "above". I don't see a proposed design. We really need help from Ross here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 10:29:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 10:29:23 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.ce2064f91e599601767ea430f25dd2a1@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by jstolarek): > There really is no alternative to generating them all Yes, I am not questioning that. > What precisely is "above". I don't see a proposed design. I meant storing IDs of calls necessary for desugaring in the extra fields (or extra datatypes) of the constructors of `StmtLR`. Of course this assumes that it is correct to "desugar then typecheck" the arrow do- notation. After reading "A New Notation for Arrows" I feel this should be perfectly OK, just as it is OK for monadic do, but of course that's a layman's perspective. I have a few questions about implementation in `DsArrows` - I think these go to Ross. 1. What is the purpose of the stack created in the desugaring process? 2. How do I read the notation describing each case of `dsCmd`? Eg. the `HsCmdApp` case has this comment: {{{ -- D; ys |-a cmd : (t,stk) --> t' -- D, xs |- exp :: t -- ------------------------ -- D; xs |-a cmd exp : stk --> t' -- -- ---> premap (\ ((xs),stk) -> ((ys),(e,stk))) cmd }}} What is `|-a`, `xs` and `ys`? What is the difference between `:` and `::`? Could you tell me how to read this particular comment? I should then be able to understand all the others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 14:51:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 14:51:57 -0000 Subject: [GHC] #9075: Per-thread weak pointer list (remove global lock on mkWeak#) In-Reply-To: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> References: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> Message-ID: <060.f68e0502d8f0ac90cdfe7b48769b6217@haskell.org> #9075: Per-thread weak pointer list (remove global lock on mkWeak#) --------------------------------------------+------------------------------ Reporter: ezyang | Owner: ezyang Type: bug | Status: merge Priority: low | Milestone: Component: Runtime System | Version: 7.9 Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by ekmett): My needs aren't pressing. Knowing that a long term solution exists is good enough for me. Thank you very much for jumping in and fixing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 16:01:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 16:01:44 -0000 Subject: [GHC] #9154: Links to Cabal documentation from the user guide are broken Message-ID: <046.fc5b062da2d1072804978e34c9b0db1c@haskell.org> #9154: Links to Cabal documentation from the user guide are broken ------------------------------------+------------------------------------- Reporter: etrepum | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- At http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/packages.html there are two broken links to Cabal documentation, there's also a broken absolute link to the same place from the haddock documentation. {{{ $ find ./share/doc/ghc -name "*.html" -exec grep -H "Cabal/index.html" {} \; ./share/doc/ghc/html/haddock/invoking.html: tool Cabal ./share/doc/ghc/html/users_guide/packages.html: Cabal documentation ./share/doc/ghc/html/users_guide/packages.html: Cabal infrastructure }}} I suppose the right place for all of these links is probably http://www.haskell.org/cabal/users-guide/ ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 16:33:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 16:33:46 -0000 Subject: [GHC] #9154: Links to Cabal documentation from the user guide are broken In-Reply-To: <046.fc5b062da2d1072804978e34c9b0db1c@haskell.org> References: <046.fc5b062da2d1072804978e34c9b0db1c@haskell.org> Message-ID: <061.5704103a62a670f9358393cded3f5559@haskell.org> #9154: Links to Cabal documentation from the user guide are broken -------------------------------------+------------------------------------ Reporter: etrepum | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.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 etrepum): 0001-Use-absolute-links-to-Cabal-docs-from-the-GHC-users-.patch only updates the GHC users guide, does not fix the issue with haddock's documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 17:51:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 17:51:43 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym In-Reply-To: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> References: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> Message-ID: <066.69c61822a04b0a27c626ba01972dc9e0@haskell.org> #9023: Error when using empty record update on binary pattern synonym ---------------------------------+--------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Changes (by archblob): * status: new => patch Comment: This is actually not an error, just a {{{pprTrace}}} that I think was left there accidentally. Everything actually type-checks and works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 19:35:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 19:35:51 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.cfa98cfd36a9dedf255c3c26e4288c4e@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.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: | -------------------------------+------------------------------------------- Comment (by hpacheco): Is there a current version of the path that works against the current GHC HEAD? The 2-year-old one fails. I can say that I have been trying to define injective type families ever since TypeFamilies were introduced! Especially to define functions like the fmap that MikeIzbicki showed or very simple type-level aliases between different type classes. It also increases modularity. For example, to define the datatypes in different modules, and define an type family aliases in a parent module. {{{ module A where data A = ... data FA = ... module B where data B = ... data FB = ... module Main where import A import B type family F a :: * type instance F A = FA type instance F A = FB }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 20:13:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 20:13:46 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.b5c26c73ae8f48a20160e4181a43835e@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.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: | -------------------------------+------------------------------------------- Comment (by acowley): My intended uses seem to arise quite often, but I've not found one that boils down into a small, self-contained, compelling example. In broad terms, I would like to use type families for decoupling, as hpacheco describes, and to do things like move back and forth between a set of distinct types and singleton Nats. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 20:39:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 20:39:03 -0000 Subject: [GHC] #7521: Simplifier ticks exhausted when compiling Accelerate example. In-Reply-To: <046.a165b81ceec1b63f8c0bcb4e673ec08e@haskell.org> References: <046.a165b81ceec1b63f8c0bcb4e673ec08e@haskell.org> Message-ID: <061.38a1e82e794180bc34fcf45d9d4c8a9a@haskell.org> #7521: Simplifier ticks exhausted when compiling Accelerate example. ---------------------------------------+----------------------------------- Reporter: eamsden | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by George): Does this fail on 7.8.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 20:39:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 20:39:52 -0000 Subject: [GHC] #7521: Simplifier ticks exhausted when compiling Accelerate example. In-Reply-To: <046.a165b81ceec1b63f8c0bcb4e673ec08e@haskell.org> References: <046.a165b81ceec1b63f8c0bcb4e673ec08e@haskell.org> Message-ID: <061.6b34cae86bc620f34b0938a4df51119e@haskell.org> #7521: Simplifier ticks exhausted when compiling Accelerate example. ---------------------------------------+----------------------------------- Reporter: eamsden | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by George): * cc: george.colpitts@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 21:11:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 21:11:43 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.d621e6fa7d9b2837ab33823471b08829@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 4213 | Related Tickets: -------------------------------------+------------------------------------ Comment (by altaic): I'm looking in to option 5, mostly because I'd like to familiarize myself with the STG machine and Hoopl. I expect the other approaches discussed here will be more fruitful, however my unfamiliarity with GHC internals limit how much I can currently contribute. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 30 21:19:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 21:19:25 -0000 Subject: [GHC] #9148: tryReadMVar locks up the process with +RTS -N2 or greater In-Reply-To: <047.60c6cfd551628c7f0ad6d52e55f6dbba@haskell.org> References: <047.60c6cfd551628c7f0ad6d52e55f6dbba@haskell.org> Message-ID: <062.73a0e1f623c92be13d66d664b23558f0@haskell.org> #9148: tryReadMVar locks up the process with +RTS -N2 or greater -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: merge Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | 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 Fri May 30 23:52:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 May 2014 23:52:59 -0000 Subject: [GHC] #9075: Per-thread weak pointer list (remove global lock on mkWeak#) In-Reply-To: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> References: <045.e63f29ed3d4a4d63c446d1a6df24cd67@haskell.org> Message-ID: <060.623b237f3b2f01adb9b0cfc3456f988d@haskell.org> #9075: Per-thread weak pointer list (remove global lock on mkWeak#) --------------------------------------------+------------------------------ Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: low | Milestone: Component: Runtime System | Version: 7.9 Resolution: fixed | Keywords: easy Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by ezyang): * status: merge => closed * resolution: => fixed Comment: OK, closing this then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 31 05:00:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 May 2014 05:00:08 -0000 Subject: [GHC] #7241: GHC-7.6.1 panics on template haskell code In-Reply-To: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> References: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> Message-ID: <061.5eb867d8ceb5dd670d986bbd763945eb@haskell.org> #7241: GHC-7.6.1 panics on template haskell code ---------------------------------------+----------------------------------- Reporter: akamaus | Owner: Yuras Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Template Haskell | Version: 7.6.1 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 Amatic): * cc: lightwing15@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 31 07:35:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 May 2014 07:35:47 -0000 Subject: [GHC] #1388: Newbie help features In-Reply-To: <044.efaff92cf2e79b2f529fa901fdcbafbb@haskell.org> References: <044.efaff92cf2e79b2f529fa901fdcbafbb@haskell.org> Message-ID: <059.9723d230c8420d558272270da3b244ce@haskell.org> #1388: Newbie help features -------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature | Status: new request | Milestone: ? Priority: low | Version: 6.6.1 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 nomeata): * cc: hvr (added) * failure: => None/Unknown Comment: `type Bar = (Char, Int)` works now in GHCi. `f = 1` doesn?t, but given that GHCi supports all(?) other toplevel declarations by now, I wonder why. I could even print something helpful like {{{ > f = 1 Defined: f :: Num a => a }}} or less verbose {{{ > f = 1 f :: Num a => a }}} so that the user knows what?s going on. Or simply treat it exactly like `let f = 1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 31 08:56:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 May 2014 08:56:54 -0000 Subject: [GHC] #5599: msys has bad Unicode support In-Reply-To: <046.3f625e98390ad242d829f3e1c223a6bd@haskell.org> References: <046.3f625e98390ad242d829f3e1c223a6bd@haskell.org> Message-ID: <061.aff0d6f7fb7c1b3a3736242eff8ea9c5@haskell.org> #5599: msys has bad Unicode support -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.4.1 Resolution: fixed | Version: 7.2.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: llibraries/tests/IO/T3307, | Unknown/Multiple environment001 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by schyler): Replying to [comment:5 simonpj]: > MSYS2 is way better than MSYS, so I think we should just adopt it. I'm making it an expected pass. > > Simon #8842 would be a good thing to check before making it default. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 31 09:21:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 May 2014 09:21:12 -0000 Subject: [GHC] #5599: msys has bad Unicode support In-Reply-To: <046.3f625e98390ad242d829f3e1c223a6bd@haskell.org> References: <046.3f625e98390ad242d829f3e1c223a6bd@haskell.org> Message-ID: <061.820a58727b63606785bdc1761f0182ed@haskell.org> #5599: msys has bad Unicode support -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.4.1 Resolution: fixed | Version: 7.2.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: llibraries/tests/IO/T3307, | Unknown/Multiple environment001 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by awson): Replying to [comment:6 schyler]: > #8842 would be a good thing to check before making it default. You shall *never* install msys2 runtime and development tools. You should only install msys2-base distribution and mingw(32|64)-* runtime and development tools. You also shall start msys2 shell with mingw(32|64)_shell.bat script included into distribution. This way you receive (native 32 or 64 bit windows) mingw-w64 runtime based development environment with no remnants of Msys2 runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 31 11:11:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 May 2014 11:11:43 -0000 Subject: [GHC] #9155: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) Message-ID: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> #9155: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When building all world with '''-O2''' I've stuck on wxhaskell (all versions): {{{ [11 of 16] Compiling Graphics.UI.WX.Controls ( src/Graphics/UI/WX/Controls.hs, dist/build/Graphics/UI/WX/Controls.o ) : ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O }}} I've stripped it down to minimal complete example (but it significantly changed error message) {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): RegAlloc.Liveness.computeLivenss SCCs aren't in reverse dependent order bad blockId c1tU [NONREC c1uc: movq $-8,%rbx andq $main:M.AlignLeft{v rb}_closure+1,%rbx addq $8,%rbp jmp *(%rbx), NONREC ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 31 11:13:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 May 2014 11:13:05 -0000 Subject: [GHC] #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) (was: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux)) In-Reply-To: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> References: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> Message-ID: <060.2c6d22b0087ceb518beeeb4481affc5a@haskell.org> #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 slyfox): Compile as: {{{ ghc -c --make -hide-all-packages -package base -O2 M }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 31 13:23:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 May 2014 13:23:25 -0000 Subject: [GHC] #9156: Duplicate record field Message-ID: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> #9156: Duplicate record field ------------------------------------+------------------------------------- Reporter: wojteknar | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This compiles. {{{ #!haskell data D = D1 { f1 :: Int } | D2 { f1, f1 :: Int } -- Oops, duplicate }}} Probably harmless, but still. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 31 13:48:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 May 2014 13:48:39 -0000 Subject: [GHC] #9156: Duplicate record field In-Reply-To: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> References: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> Message-ID: <063.05a904472576be27a0055f52c7beacaa@haskell.org> #9156: Duplicate record field ------------------------------------------------+-------------------------- Reporter: wojteknar | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | 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 wojteknar): * failure: None/Unknown => GHC accepts invalid program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 31 14:26:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 May 2014 14:26:34 -0000 Subject: [GHC] #9157: cmm common block not eliminated Message-ID: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> #9157: cmm common block not eliminated ------------------------------------+------------------------------------- Reporter: wojteknar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- For the toTuple# function (in the attached file) GHC generates a cmm switch statement, with all the alternatives, unsurprisingly, the same. Yet, cmm common block elimination does not kick in. In this particular example, the whole case statement could be annihilated, because all alternatives lead to the same code. BTW, this is how they match in France. {{{ #!ocaml type alt = A of int | B of int | C of int | D of int let g x = match x with A v | B v | C v | D v -> v }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 31 15:39:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 May 2014 15:39:27 -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.7678721df94dae14b21b801a1cb46951@haskell.org> #8736: GHCi doesn't load .dyn_o files appropriately -------------------------------------+------------------------------------ Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.3 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 George): Replying to [comment:4 simonpj]: > Summarising the behaviour. If you say `:load Foo` in GHCi > * `Foo` was compiled with `-dynamic`: loads `Foo.o` > * `Foo` was compiled without any dynamic flag: does not find object files, so interprets. > * `Foo` was compiled with `-dynamic-too`: fails as above. > > Not a release blocker. > The first case > * `Foo` was compiled with `-dynamic`: loads `Foo.o` does not seem to be the case in 7.8.2, at least on the Mac where the .o file does not get loaded {{{ ghc --make -O2 -DYNAMIC pfp1.hs [1 of 1] Compiling Main ( pfp1.hs, pfp1.o ) Linking pfp1 ... bash-3.2$ ghci -ignore-dot-ghci GHCi, version 7.8.2: 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> :load pfp1 [1 of 1] Compiling Main ( pfp1.hs, interpreted ) Ok, modules loaded: Main. }}} Should I file a bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 31 17:31:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 May 2014 17:31:57 -0000 Subject: [GHC] #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) In-Reply-To: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> References: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> Message-ID: <060.36f1f391677402cfbb087cb9dc4b8dc2@haskell.org> #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 slyfox): -HEAD has the same disease: {{{ [sf] ~/dev/git/ghc:inplace/bin/ghc-stage2 --make -O2 /tmp/M.hs [1 of 1] Compiling M ( /tmp/M.hs, /tmp/M.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20140531 for x86_64-unknown-linux): RegAlloc.Liveness.computeLivenss SCCs aren't in reverse dependent order bad blockId c1cG ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 31 19:00:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 May 2014 19:00:21 -0000 Subject: [GHC] #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) In-Reply-To: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> References: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> Message-ID: <060.6e3e6a11d3c3be8bcdb6abe23bc16692@haskell.org> #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) ---------------------------------------+---------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by slyfox): * cc: simonmar (added) * failure: None/Unknown => Compile-time crash * component: Compiler => Compiler (NCG) * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 31 23:04:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 May 2014 23:04:10 -0000 Subject: [GHC] #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) In-Reply-To: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> References: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> Message-ID: <060.c27c8b9202d374e809634d760605fb5f@haskell.org> #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) ---------------------------------------+---------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by niklasl): The issue disappears when I revert commit f5879acd018494b84233f26fba828ce376d0f81d -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 2 20:57:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 May 2014 20:57:54 -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.6b21b88442bc138bff68b03bee5cfcc7@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 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 dagit): I hope this helps! This is from the Fedora 19 system I mentioned earlier. {{{ $ LD_DEBUG=symbols ./check-environ /usr/lib64/libgmp.so /usr/lib64/libpthread.so 5823: symbol=_res; lookup in file=./check-environ [0] 5823: symbol=_res; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_res; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=stderr; lookup in file=./check-environ [0] 5823: symbol=stderr; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=stderr; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=error_one_per_line; lookup in file=./check-environ [0] 5823: symbol=error_one_per_line; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=error_one_per_line; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__malloc_initialize_hook; lookup in file=./check- environ [0] 5823: symbol=__malloc_initialize_hook; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__malloc_initialize_hook; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_dl_starting_up; lookup in file=./check-environ [0] 5823: symbol=_dl_starting_up; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_dl_starting_up; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_dl_starting_up; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__morecore; lookup in file=./check-environ [0] 5823: symbol=__morecore; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__morecore; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__key_encryptsession_pk_LOCAL; lookup in file =./check-environ [0] 5823: symbol=__key_encryptsession_pk_LOCAL; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__key_encryptsession_pk_LOCAL; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__progname_full; lookup in file=./check-environ [0] 5823: symbol=__progname_full; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__progname_full; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__ctype32_tolower; lookup in file=./check-environ [0] 5823: symbol=__ctype32_tolower; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__ctype32_tolower; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_environ; lookup in file=./check-environ [0] 5823: symbol=_rtld_global; lookup in file=./check-environ [0] 5823: symbol=_rtld_global; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_rtld_global; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_rtld_global; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__progname; lookup in file=./check-environ [0] 5823: symbol=__progname; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__progname; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=argp_err_exit_status; lookup in file=./check- environ [0] 5823: symbol=argp_err_exit_status; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=argp_err_exit_status; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=mallwatch; lookup in file=./check-environ [0] 5823: symbol=mallwatch; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=mallwatch; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__rcmd_errstr; lookup in file=./check-environ [0] 5823: symbol=__rcmd_errstr; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__rcmd_errstr; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__vdso_clock_gettime; lookup in file=./check- environ [0] 5823: symbol=__vdso_clock_gettime; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__vdso_clock_gettime; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=svcauthdes_stats; lookup in file=./check-environ [0] 5823: symbol=svcauthdes_stats; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=svcauthdes_stats; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__libc_enable_secure; lookup in file=./check- environ [0] 5823: symbol=__libc_enable_secure; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__libc_enable_secure; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__libc_enable_secure; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=_res_hconf; lookup in file=./check-environ [0] 5823: symbol=_res_hconf; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_res_hconf; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=malloc; lookup in file=./check-environ [0] 5823: symbol=malloc; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=malloc; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=getdate_err; lookup in file=./check-environ [0] 5823: symbol=getdate_err; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=getdate_err; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__tzname; lookup in file=./check-environ [0] 5823: symbol=__tzname; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__tzname; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__timezone; lookup in file=./check-environ [0] 5823: symbol=__timezone; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__timezone; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_rtld_global_ro; lookup in file=./check-environ [0] 5823: symbol=_rtld_global_ro; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_rtld_global_ro; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_rtld_global_ro; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=optarg; lookup in file=./check-environ [0] 5823: symbol=optarg; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=optarg; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__ctype_tolower; lookup in file=./check-environ [0] 5823: symbol=__ctype_tolower; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__ctype_tolower; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__ctype_toupper; lookup in file=./check-environ [0] 5823: symbol=__ctype_toupper; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__ctype_toupper; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=svc_max_pollfd; lookup in file=./check-environ [0] 5823: symbol=svc_max_pollfd; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=svc_max_pollfd; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__ctype_b; lookup in file=./check-environ [0] 5823: symbol=__ctype_b; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__ctype_b; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=argp_program_version_hook; lookup in file=./check- environ [0] 5823: symbol=argp_program_version_hook; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=argp_program_version_hook; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__after_morecore_hook; lookup in file=./check- environ [0] 5823: symbol=__after_morecore_hook; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__after_morecore_hook; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__environ; lookup in file=./check-environ [0] 5823: symbol=__ctype32_b; lookup in file=./check-environ [0] 5823: symbol=__ctype32_b; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__ctype32_b; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__curbrk; lookup in file=./check-environ [0] 5823: symbol=__curbrk; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__curbrk; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=argp_program_version; lookup in file=./check- environ [0] 5823: symbol=argp_program_version; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=argp_program_version; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__daylight; lookup in file=./check-environ [0] 5823: symbol=__daylight; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__daylight; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__memalign_hook; lookup in file=./check-environ [0] 5823: symbol=__memalign_hook; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__memalign_hook; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__malloc_hook; lookup in file=./check-environ [0] 5823: symbol=__malloc_hook; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__malloc_hook; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__free_hook; lookup in file=./check-environ [0] 5823: symbol=__free_hook; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__free_hook; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=svc_pollfd; lookup in file=./check-environ [0] 5823: symbol=svc_pollfd; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=svc_pollfd; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_nl_domain_bindings; lookup in file=./check- environ [0] 5823: symbol=_nl_domain_bindings; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_nl_domain_bindings; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_nl_msg_cat_cntr; lookup in file=./check-environ [0] 5823: symbol=_nl_msg_cat_cntr; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_nl_msg_cat_cntr; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=argp_program_bug_address; lookup in file=./check- environ [0] 5823: symbol=argp_program_bug_address; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=argp_program_bug_address; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__key_decryptsession_pk_LOCAL; lookup in file =./check-environ [0] 5823: symbol=__key_decryptsession_pk_LOCAL; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__key_decryptsession_pk_LOCAL; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=h_errlist; lookup in file=./check-environ [0] 5823: symbol=h_errlist; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=h_errlist; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=program_invocation_short_name; lookup in file =./check-environ [0] 5823: symbol=program_invocation_short_name; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=program_invocation_short_name; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=optind; lookup in file=./check-environ [0] 5823: symbol=optind; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=optind; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=stdout; lookup in file=./check-environ [0] 5823: symbol=stdout; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=stdout; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=obstack_alloc_failed_handler; lookup in file =./check-environ [0] 5823: symbol=obstack_alloc_failed_handler; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=obstack_alloc_failed_handler; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=error_print_progname; lookup in file=./check- environ [0] 5823: symbol=error_print_progname; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=error_print_progname; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=optopt; lookup in file=./check-environ [0] 5823: symbol=optopt; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=optopt; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_IO_funlockfile; lookup in file=./check-environ [0] 5823: symbol=_IO_funlockfile; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_IO_funlockfile; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=obstack_exit_failure; lookup in file=./check- environ [0] 5823: symbol=obstack_exit_failure; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=obstack_exit_failure; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=error_message_count; lookup in file=./check- environ [0] 5823: symbol=error_message_count; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=error_message_count; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=svc_fdset; lookup in file=./check-environ [0] 5823: symbol=svc_fdset; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=svc_fdset; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=program_invocation_name; lookup in file=./check- environ [0] 5823: symbol=program_invocation_name; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=program_invocation_name; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=loc1; lookup in file=./check-environ [0] 5823: symbol=loc1; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=loc1; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=free; lookup in file=./check-environ [0] 5823: symbol=free; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=free; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=loc2; lookup in file=./check-environ [0] 5823: symbol=loc2; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=loc2; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__fpu_control; lookup in file=./check-environ [0] 5823: symbol=__fpu_control; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__fpu_control; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=re_syntax_options; lookup in file=./check-environ [0] 5823: symbol=re_syntax_options; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=re_syntax_options; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=stdin; lookup in file=./check-environ [0] 5823: symbol=stdin; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=stdin; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__check_rhosts_file; lookup in file=./check- environ [0] 5823: symbol=__check_rhosts_file; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__check_rhosts_file; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=opterr; lookup in file=./check-environ [0] 5823: symbol=opterr; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=opterr; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__ctype32_toupper; lookup in file=./check-environ [0] 5823: symbol=__ctype32_toupper; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__ctype32_toupper; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__realloc_hook; lookup in file=./check-environ [0] 5823: symbol=__realloc_hook; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__realloc_hook; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_dl_argv; lookup in file=./check-environ [0] 5823: symbol=_dl_argv; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_dl_argv; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_dl_argv; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=rpc_createerr; lookup in file=./check-environ [0] 5823: symbol=rpc_createerr; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=rpc_createerr; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_IO_2_1_stderr_; lookup in file=./check-environ [0] 5823: symbol=_IO_2_1_stderr_; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_IO_2_1_stderr_; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_IO_2_1_stdout_; lookup in file=./check-environ [0] 5823: symbol=_IO_2_1_stdout_; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_IO_2_1_stdout_; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_IO_2_1_stdin_; lookup in file=./check-environ [0] 5823: symbol=_IO_2_1_stdin_; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_IO_2_1_stdin_; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=realloc; lookup in file=./check-environ [0] 5823: symbol=realloc; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=realloc; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=memset; lookup in file=./check-environ [0] 5823: symbol=memset; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=memset; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=malloc; lookup in file=./check-environ [0] 5823: symbol=malloc; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=malloc; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__tls_get_addr; lookup in file=./check-environ [0] 5823: symbol=__tls_get_addr; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__tls_get_addr; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__tls_get_addr; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=memmove; lookup in file=./check-environ [0] 5823: symbol=memmove; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=memmove; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=memalign; lookup in file=./check-environ [0] 5823: symbol=memalign; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=memalign; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=calloc; lookup in file=./check-environ [0] 5823: symbol=calloc; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=calloc; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=free; lookup in file=./check-environ [0] 5823: symbol=free; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=free; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__vdso_time; lookup in file=linux-vdso.so.1 [0] 5823: symbol=__vdso_gettimeofday; lookup in file=linux- vdso.so.1 [0] 5823: symbol=__pthread_key_create; lookup in file=./check- environ [0] 5823: symbol=__pthread_key_create; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__pthread_key_create; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__pthread_key_create; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=_ITM_deregisterTMCloneTable; lookup in file =./check-environ [0] 5823: symbol=_ITM_deregisterTMCloneTable; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_ITM_deregisterTMCloneTable; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_ITM_deregisterTMCloneTable; lookup in file=/lib64 /ld-linux-x86-64.so.2 [0] 5823: symbol=__pthread_getspecific; lookup in file=./check- environ [0] 5823: symbol=__pthread_getspecific; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__pthread_getspecific; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__pthread_getspecific; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmon_start__; lookup in file=./check-environ [0] 5823: symbol=__gmon_start__; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmon_start__; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmon_start__; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=_rtld_global_ro; lookup in file=./check-environ [0] 5823: symbol=_rtld_global_ro; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_rtld_global_ro; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_rtld_global_ro; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__pthread_once; lookup in file=./check-environ [0] 5823: symbol=__pthread_once; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__pthread_once; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__pthread_once; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=_libc_intl_domainname; lookup in file=./check- environ [0] 5823: symbol=_libc_intl_domainname; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_libc_intl_domainname; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_Jv_RegisterClasses; lookup in file=./check- environ [0] 5823: symbol=_Jv_RegisterClasses; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_Jv_RegisterClasses; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_Jv_RegisterClasses; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__environ; lookup in file=./check-environ [0] 5823: symbol=_ITM_registerTMCloneTable; lookup in file=./check- environ [0] 5823: symbol=_ITM_registerTMCloneTable; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_ITM_registerTMCloneTable; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_ITM_registerTMCloneTable; lookup in file=/lib64 /ld-linux-x86-64.so.2 [0] 5823: symbol=__pthread_setspecific; lookup in file=./check- environ [0] 5823: symbol=__pthread_setspecific; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__pthread_setspecific; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__pthread_setspecific; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=_rtld_global; lookup in file=./check-environ [0] 5823: symbol=_rtld_global; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_rtld_global; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_rtld_global; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__cxa_finalize; lookup in file=./check-environ [0] 5823: symbol=__cxa_finalize; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__cxa_finalize; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmon_start__; lookup in file=./check-environ [0] 5823: symbol=__gmon_start__; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmon_start__; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmon_start__; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__environ; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__environ; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_r_debug; lookup in file=./check-environ [0] 5823: symbol=_r_debug; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_r_debug; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_r_debug; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=free; lookup in file=./check-environ [0] 5823: symbol=free; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=free; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__libc_memalign; lookup in file=./check-environ [0] 5823: symbol=__libc_memalign; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__libc_memalign; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=malloc; lookup in file=./check-environ [0] 5823: symbol=malloc; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=malloc; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__tls_get_addr; lookup in file=./check-environ [0] 5823: symbol=__tls_get_addr; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__tls_get_addr; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__tls_get_addr; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=calloc; lookup in file=./check-environ [0] 5823: symbol=calloc; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=calloc; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=realloc; lookup in file=./check-environ [0] 5823: symbol=realloc; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=realloc; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=free; lookup in file=./check-environ [0] 5823: symbol=free; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=free; lookup in file=/lib64/libc.so.6 [0] 5823: 5823: calling init: /lib64/ld-linux-x86-64.so.2 5823: 5823: 5823: calling init: /lib64/libc.so.6 5823: 5823: symbol=__vdso_clock_gettime; lookup in file=linux- vdso.so.1 [0] 5823: symbol=__vdso_getcpu; lookup in file=linux-vdso.so.1 [0] 5823: 5823: calling init: /lib64/libdl.so.2 5823: 5823: symbol=__libc_start_main; lookup in file=./check-environ [0] 5823: symbol=__libc_start_main; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__libc_start_main; lookup in file=/lib64/libc.so.6 [0] 5823: 5823: initialize program: ./check-environ 5823: 5823: 5823: transferring control: ./check-environ 5823: 5823: symbol=dlopen; lookup in file=./check-environ [0] 5823: symbol=dlopen; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=printf; lookup in file=./check-environ [0] 5823: symbol=printf; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=printf; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=dlsym; lookup in file=./check-environ [0] 5823: symbol=dlsym; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_dl_sym; lookup in file=./check-environ [0] 5823: symbol=_dl_sym; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_dl_sym; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=environ; lookup in file=./check-environ [0] 5823: symbol=obstack_vprintf; lookup in file=./check-environ [0] 5823: symbol=obstack_vprintf; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=obstack_vprintf; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=vfprintf; lookup in file=./check-environ [0] 5823: symbol=vfprintf; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=vfprintf; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_asprintf_memory; lookup in file=./check- environ [0] 5823: symbol=__gmp_asprintf_memory; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_asprintf_memory; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_asprintf_memory; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_asprintf_memory; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_asprintf_reps; lookup in file=./check- environ [0] 5823: symbol=__gmp_asprintf_reps; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_asprintf_reps; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_asprintf_reps; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_asprintf_reps; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_asprintf_final; lookup in file=./check- environ [0] 5823: symbol=__gmp_asprintf_final; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_asprintf_final; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_asprintf_final; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_asprintf_final; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__isoc99_fscanf; lookup in file=./check-environ [0] 5823: symbol=__isoc99_fscanf; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__isoc99_fscanf; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=fgetc; lookup in file=./check-environ [0] 5823: symbol=fgetc; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=fgetc; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=ungetc; lookup in file=./check-environ [0] 5823: symbol=ungetc; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=ungetc; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_randget_mt; lookup in file=./check-environ [0] 5823: symbol=__gmp_randget_mt; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_randget_mt; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_randget_mt; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_randget_mt; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_randclear_mt; lookup in file=./check-environ [0] 5823: symbol=__gmp_randclear_mt; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_randclear_mt; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_randclear_mt; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_randclear_mt; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_randiset_mt; lookup in file=./check-environ [0] 5823: symbol=__gmp_randiset_mt; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_randiset_mt; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_randiset_mt; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_randiset_mt; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=_ITM_deregisterTMCloneTable; lookup in file =./check-environ [0] 5823: symbol=_ITM_deregisterTMCloneTable; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_ITM_deregisterTMCloneTable; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_ITM_deregisterTMCloneTable; lookup in file=/lib64 /ld-linux-x86-64.so.2 [0] 5823: symbol=_ITM_deregisterTMCloneTable; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=_ITM_deregisterTMCloneTable; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_ITM_deregisterTMCloneTable; lookup in file=/lib64 /ld-linux-x86-64.so.2 [0] 5823: symbol=stdout; lookup in file=./check-environ [0] 5823: symbol=stdout; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=stdout; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_reallocate_func; lookup in file=./check- environ [0] 5823: symbol=__gmp_reallocate_func; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_reallocate_func; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_reallocate_func; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_reallocate_func; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=stdin; lookup in file=./check-environ [0] 5823: symbol=stdin; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=stdin; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_fib_table; lookup in file=./check-environ [0] 5823: symbol=__gmp_fib_table; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_fib_table; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_fib_table; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_fib_table; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_fprintf_funs; lookup in file=./check-environ [0] 5823: symbol=__gmp_fprintf_funs; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_fprintf_funs; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_fprintf_funs; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_fprintf_funs; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmpz_sub; lookup in file=./check-environ [0] 5823: symbol=__gmpz_sub; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmpz_sub; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmpz_sub; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmpz_sub; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_allocate_func; lookup in file=./check- environ [0] 5823: symbol=__gmp_allocate_func; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_allocate_func; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_allocate_func; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_allocate_func; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_oddfac_table; lookup in file=./check-environ [0] 5823: symbol=__gmp_oddfac_table; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_oddfac_table; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_oddfac_table; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_oddfac_table; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_junk; lookup in file=./check-environ [0] 5823: symbol=__gmp_junk; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_junk; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_junk; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_junk; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_0; lookup in file=./check-environ [0] 5823: symbol=__gmp_0; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_0; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_0; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_0; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_asprintf_funs; lookup in file=./check- environ [0] 5823: symbol=__gmp_asprintf_funs; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_asprintf_funs; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_asprintf_funs; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_asprintf_funs; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_jacobi_table; lookup in file=./check-environ [0] 5823: symbol=__gmp_jacobi_table; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_jacobi_table; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_jacobi_table; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_jacobi_table; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_limbroots_table; lookup in file=./check- environ [0] 5823: symbol=__gmp_limbroots_table; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_limbroots_table; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_limbroots_table; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_limbroots_table; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_errno; lookup in file=./check-environ [0] 5823: symbol=__gmp_errno; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_errno; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_errno; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_errno; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmon_start__; lookup in file=./check-environ [0] 5823: symbol=__gmon_start__; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmon_start__; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmon_start__; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmon_start__; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmon_start__; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmon_start__; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_default_reallocate; lookup in file=./check- environ [0] 5823: symbol=__gmp_default_reallocate; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_default_reallocate; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_default_reallocate; lookup in file=/lib64 /ld-linux-x86-64.so.2 [0] 5823: symbol=__gmp_default_reallocate; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_digit_value_tab; lookup in file=./check- environ [0] 5823: symbol=__gmp_digit_value_tab; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_digit_value_tab; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_digit_value_tab; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_digit_value_tab; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_odd2fac_table; lookup in file=./check- environ [0] 5823: symbol=__gmp_odd2fac_table; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_odd2fac_table; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_odd2fac_table; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_odd2fac_table; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmpn_bases; lookup in file=./check-environ [0] 5823: symbol=__gmpn_bases; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmpn_bases; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmpn_bases; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmpn_bases; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_sprintf_funs; lookup in file=./check-environ [0] 5823: symbol=__gmp_sprintf_funs; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_sprintf_funs; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_sprintf_funs; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_sprintf_funs; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_binvert_limb_table; lookup in file=./check- environ [0] 5823: symbol=__gmp_binvert_limb_table; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_binvert_limb_table; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_binvert_limb_table; lookup in file=/lib64 /ld-linux-x86-64.so.2 [0] 5823: symbol=__gmp_binvert_limb_table; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_default_fp_limb_precision; lookup in file =./check-environ [0] 5823: symbol=__gmp_default_fp_limb_precision; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_default_fp_limb_precision; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_default_fp_limb_precision; lookup in file=/lib64/ld-linux-x86-64.so.2 [0] 5823: symbol=__gmp_default_fp_limb_precision; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmpn_gcdext_hook; lookup in file=./check-environ [0] 5823: symbol=__gmpn_gcdext_hook; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmpn_gcdext_hook; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmpn_gcdext_hook; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmpn_gcdext_hook; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_rands; lookup in file=./check-environ [0] 5823: symbol=__gmp_rands; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_rands; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_rands; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_rands; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_sscanf_funs; lookup in file=./check-environ [0] 5823: symbol=__gmp_sscanf_funs; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_sscanf_funs; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_sscanf_funs; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_sscanf_funs; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_fac2cnt_table; lookup in file=./check- environ [0] 5823: symbol=__gmp_fac2cnt_table; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_fac2cnt_table; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_fac2cnt_table; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_fac2cnt_table; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmpz_add; lookup in file=./check-environ [0] 5823: symbol=__gmpz_add; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmpz_add; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmpz_add; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmpz_add; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_default_allocate; lookup in file=./check- environ [0] 5823: symbol=__gmp_default_allocate; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_default_allocate; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_default_allocate; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_default_allocate; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=_Jv_RegisterClasses; lookup in file=./check- environ [0] 5823: symbol=_Jv_RegisterClasses; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_Jv_RegisterClasses; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_Jv_RegisterClasses; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=_Jv_RegisterClasses; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=_Jv_RegisterClasses; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_Jv_RegisterClasses; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_free_func; lookup in file=./check-environ [0] 5823: symbol=__gmp_free_func; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_free_func; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_free_func; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_free_func; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_snprintf_funs; lookup in file=./check- environ [0] 5823: symbol=__gmp_snprintf_funs; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_snprintf_funs; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_snprintf_funs; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_snprintf_funs; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_default_free; lookup in file=./check-environ [0] 5823: symbol=__gmp_default_free; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_default_free; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_default_free; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_default_free; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_rands_initialized; lookup in file=./check- environ [0] 5823: symbol=__gmp_rands_initialized; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_rands_initialized; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_rands_initialized; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_rands_initialized; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=__gmp_obstack_printf_funs; lookup in file=./check- environ [0] 5823: symbol=__gmp_obstack_printf_funs; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_obstack_printf_funs; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_obstack_printf_funs; lookup in file=/lib64 /ld-linux-x86-64.so.2 [0] 5823: symbol=__gmp_obstack_printf_funs; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=_ITM_registerTMCloneTable; lookup in file=./check- environ [0] 5823: symbol=_ITM_registerTMCloneTable; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=_ITM_registerTMCloneTable; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_ITM_registerTMCloneTable; lookup in file=/lib64 /ld-linux-x86-64.so.2 [0] 5823: symbol=_ITM_registerTMCloneTable; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=_ITM_registerTMCloneTable; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=_ITM_registerTMCloneTable; lookup in file=/lib64 /ld-linux-x86-64.so.2 [0] 5823: symbol=__cxa_finalize; lookup in file=./check-environ [0] 5823: symbol=__cxa_finalize; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__cxa_finalize; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=stderr; lookup in file=./check-environ [0] 5823: symbol=stderr; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=stderr; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_fscanf_funs; lookup in file=./check-environ [0] 5823: symbol=__gmp_fscanf_funs; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__gmp_fscanf_funs; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=__gmp_fscanf_funs; lookup in file=/lib64/ld- linux-x86-64.so.2 [0] 5823: symbol=__gmp_fscanf_funs; lookup in file=/usr/lib64/libgmp.so [0] 5823: 5823: calling init: /usr/lib64/libgmp.so 5823: 5823: symbol=environ; lookup in file=/usr/lib64/libgmp.so [0] 5823: symbol=environ; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=free; lookup in file=./check-environ [0] 5823: symbol=free; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=free; lookup in file=/lib64/libc.so.6 [0] 5823: symbol=environ; lookup in file=./check-environ [0] 5823: 5823: calling fini: ./check-environ [0] 5823: 5823: 5823: calling fini: /lib64/libdl.so.2 [0] 5823: 5823: symbol=__cxa_finalize; lookup in file=./check-environ [0] 5823: symbol=__cxa_finalize; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__cxa_finalize; lookup in file=/lib64/libc.so.6 [0] 5823: 5823: calling fini: /usr/lib64/libgmp.so [0] 5823: 5823: symbol=__cxa_finalize; lookup in file=./check-environ [0] 5823: symbol=__cxa_finalize; lookup in file=/lib64/libdl.so.2 [0] 5823: symbol=__cxa_finalize; lookup in file=/lib64/libc.so.6 [0] environ = 0x601058 dlsym(deflt, "environ") = 0x601058 dlsym("libgmp", "environ") = 0x31e45bd508 dlsym("libpthread", "environ") = 0x601058 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler